Skip to content

Say when an embargo date assumes a long review - #141

Closed
arav-agarwal2 wants to merge 1 commit into
mainfrom
feat/embargo-validation
Closed

arav-agarwal2 wants to merge 1 commit into
mainfrom
feat/embargo-validation

Conversation

@arav-agarwal2

Copy link
Copy Markdown
Collaborator

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-date
went 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:

Note: §4.2 allows an embargo up to 60 days after the completion of review.
This date is 200 days out, so it stays within the cap only if review takes
more than 139 days to complete. MLCommons applies the cap at finalization,
when the completion date is known.

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

  • Provisional submissions are exempt. §6.2.3 caps its embargo at "any date
    before finalization", with no 60-day limit, so --provisional gets nothing.
  • submissions update hedges. A PATCH doesn't say which §6.2 mode the
    submission is in, so there the note adds that the cap doesn't apply under
    provisional publication.
  • Threshold and wording live in EMBARGO_CAP_DAYS and _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, --provisional is
silent, and update hedges.

Still open

The cap itself needs enforcing at finalization, in the lifecycle manager,
where finalized_at exists and embargo_date <= finalized_at + 60 days is a
decidable question. Nothing does that today. Separate piece of work.

🤖 Generated with Claude Code

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>
@github-actions

Copy link
Copy Markdown

MLCommons CLA bot All contributors have signed the MLCommons CLA ✍️ ✅

@arav-agarwal2

Copy link
Copy Markdown
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.

@arav-agarwal2
arav-agarwal2 deleted the feat/embargo-validation branch October 27, 2026 16:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant