Repository navigation
Say when an embargo date assumes a long review - #141
Closed
arav-agarwal2 wants to merge 1 commit into
Closed
arav-agarwal2 wants to merge 1 commit into
arav-agarwal2 wants to merge 1 commit into
Conversation
Submission Rules §4.2 caps a confidential-review embargo (§6.2.2) at "up to 60 days after the completion of review". Nothing checked it. It cannot be checked at submission time — review has not started, so there is no completion date to measure 60 days from, and no upper bound on the embargo follows from anything known then. Half the rule does follow: review completes no earlier than now, so an embargo within 60 days of today is inside the cap whatever happens. Past that, the date is legal only if review runs long enough, and that is worth saying out loud rather than discovering at finalization. So --embargo-date now prints how much review time the date assumes, and creates the submission anyway. A hard rejection would be wrong: the submitter may well be right that review will take that long. Provisional submissions (§6.2.3) are exempt — their embargo may be any date before finalization — and `submissions update` hedges, since a PATCH does not say which §6.2 mode the submission is in. The cap itself still needs enforcing at finalization, where the completion date exists. That is lifecycle-manager work, not this. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
MLCommons CLA bot All contributors have signed the MLCommons CLA ✍️ ✅ |
Collaborator
Author
|
Closing: the cap can't be settled submitter-side, so this could only ever be advisory. Enforcement belongs at finalization — tracked in mlcommons/endpoints-lifecycle-manager#72. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Submission Rules §4.2 caps a confidential-review embargo (§6.2.2) at "up to 60
days after the completion of review". Nothing checked it —
--embargo-datewent straight into the payload once its time zone was validated.
Why this is a note and not a rejection
The cap cannot be enforced at submission time. Review has not started, so
there is no completion date to measure 60 days from, and no upper bound on the
embargo follows from anything known then — a date 200 days out is perfectly
legal if review takes 140 days.
Half the rule does follow, though. Review completes no earlier than now, so an
embargo within 60 days of today is inside the cap whatever happens. Past that,
the date is legal only if review runs long enough — and that is worth saying
before submitting rather than discovering at finalization.
So the CLI now says how much review time the date assumes:
and creates the submission anyway. A hard rejection would be wrong here: the
submitter may well be right about how long review will take.
Details
before finalization", with no 60-day limit, so
--provisionalgets nothing.submissions updatehedges. A PATCH doesn't say which §6.2 mode thesubmission is in, so there the note adds that the cap doesn't apply under
provisional publication.
EMBARGO_CAP_DAYSand_embargo_cap_note.Verification
1795 tests pass, 5 new: inside the cap says nothing, beyond it names the
required review length, the note doesn't block creation,
--provisionalissilent, and update hedges.
Still open
The cap itself needs enforcing at finalization, in the lifecycle manager,
where
finalized_atexists andembargo_date <= finalized_at + 60 daysis adecidable question. Nothing does that today. Separate piece of work.
🤖 Generated with Claude Code