ADR-034: Embargoed work is a private mirror of the repo, not an exemption from R3


Status	Accepted
Date	2026-08-06
Author	bodurkalukasz
Tags	security, knowledge

Context

The standard had no word for work that is real, recorded, and not yet publishable. R3 says project knowledge MUST live in the repo; R11 says a capability's code and its spec land in the same pull request; R15 says the backlog holds the intents. Followed literally in a public repo, those three publish an unfixed vulnerability at the moment somebody starts fixing it - and the same reading publishes a customer's confidential detail and an unannounced commercial move.

That is not a hypothetical reading. Validation case SEC-02 executed it: no rule carried an embargo or confidentiality clause, and the manifest's exceptions mechanism has four kinds (file, section, content, key) and no embargo among them.

The failure mode a rule like this actually has is not that teams argue with it. It is that they quietly break it - the fix gets developed in a private fork with no spec, no record and no backlog item, and none of that is ever written, because the standard only offered "publish it" or "you are non-compliant". A rule that forces disclosure teaches people to work outside the standard exactly when the work is most sensitive.

Options considered

An embargo exception on R3, R11 and R15 - each rule gains an "unless confidential" clause. Rejected: three separate holes, each readable on its own as a general licence to keep knowledge out of the repo, and none of them says anything about the material coming back. It concedes the premise - that the standard's problem is requiring too much - when the real problem is that it conflated the repo with the public.
A new embargo kind in the manifest's exceptions - the repo records its embargoed material as a recorded deviation. Rejected on what exceptions is: a repo's structural, standing deviation from the standard, read by self-verify at drift time, and one that deliberately lowers the adoption percentage. An embargo is a temporary state of one piece of work inside a repo that is otherwise fully aligned. Encoding it there would penalise the correct behaviour and leave a permanent artifact of a temporary condition.
A private mirror of the repo, for a bounded period, rejoining the mainline (chosen).

Decision

We will treat embargoed work as deferred publication of repo content, not knowledge kept outside a repo. Material whose publication is the harm may be held in a private mirror of the repo - the hosting platform's private security-advisory fork is the paved road - and MUST rejoin the mainline when the embargo lifts.

R3 carries the normative wording and is the only place it is stated. Three properties in it are what make this an embargo rather than a hiding place, and each was chosen against a specific way this could be abused: every rule binds inside the mirror (so nothing is deferred except the moment the world can read it, and nothing is reconstructed from memory at disclosure); the embargo is bounded at the start, by a lifting condition and an owner (so a permanent private home is the R3 violation it always was); and the near misses are named out loud, because a clause like this is read by someone looking for permission.

R19's recorded security baseline gains the matching axis in docs/method/security-baseline.md, so each repo answers where its embargoed work lives and who lifts it, rather than deciding it under pressure during an incident.

Consequences

Positive: only one rule moved. Once "the repo" may temporarily be a private mirror, R11 and R15 need no exception - they are satisfied inside it. Three holes became one clause.
Positive: the disclosure moment stops being a writing exercise. The spec, the record and the backlog item already exist; publishing them is a merge.
Negative / cost we accept: a private mirror is real overhead - a second remote, and a merge back that can conflict with what the mainline did meanwhile. That cost is paid only by public repos, and only while an embargo is live.
Negative / cost we accept: nothing mechanical can check that an embargo lifted. The lifting condition and its owner are prose, and the only guard against a permanent private home is review reading R3.
Follow-ups: none. The clause is normative in R3; the axis is the menu entry R19 already requires an answer to.

Confirmation

Validation case SEC-02 re-runs the same procedure against R3 and the exceptions schema. Beyond that this is review's call, deliberately: whether a given embargo is legitimate and whether it lifted on time is a judgment, and a guard that pretended to check it would be theatre. What is now checkable is that the vocabulary exists, which is what was missing.

Revisit when

An adopting repo reports having used the private-mirror path and the merge back proved impractical - a conflicted rejoin, or a platform whose private fork cannot host the tooling the standard requires. That is the assumption this rests on, and it is the one that would break first.

R3 (the clause), R11, R15, R19 and the security baseline's embargo axis; validation case SEC-02.