Finalization Decision Analysis

Finalization Decision Analysis

The following is an engineering recommendation for operator review, not an accepted trust model or release policy. It does not authorize an implementation, prototype, policy change, or live operation.

Trust recommendation: trust GitHub's service and the explicitly identified GitHub principals capable of changing the managed workflow, its permissions, or its enforcement policy to preserve those controls during an in-scope finalization. Treat ordinary writers and runner-host processes without that authority as untrusted; their ability to race a tag, draft, or evidence must be prevented or leave the result UNKNOWN. Identify the actual privileged principals and the independent evidence authority before relying on this assumption. This does not claim that a trusted principal cannot publish outside the managed workflow, which remains outside the guarantee. Host root's previously selected trust is a separate assumption. Treating a GitHub administrator who can change the enforcement itself as adversarial would require an independently proven boundary not yet identified; it is not shown to be impossible.

Ordering recommendation: prefer a strict, evidence-first policy: an applicable revocation committed before a managed side effect must prevent that effect, even if an earlier verification or authorization succeeded. If the necessary ordering and exclusion cannot be proven, the operation remains UNKNOWN and does not start. This is stronger than a permit cutoff that allows an effect after revocation and is not yet selected or shown feasible.

Freshness recommendation: require the applicable LUnit run to be no older than 90 days at the actual managed side effect, not merely when an earlier verifier runs. This strengthens the accepted ADR-0006 rule and therefore needs an explicit successor decision and a proven mechanism; without them, this recommendation is not an implemented requirement.

Incident-resolution recommendation: keep the release block until an authenticated, authorized operator records a disposition and explicitly approves clearing each affected incident; an acknowledgement alone is not an unblock. Before another release, also require current authority state and all proofs for that new release to pass. A disposition must not make revoked evidence valid again. Give each release, proof, and revocation combination a stable incident identity so redelivery of the same event does not silently clear or recreate a resolved incident; a new revocation or affected proof needs its own disposition. This policy and its operator authorization remain unselected.

For the following cases, V is successful verification, K is a possible durable authorization cutoff, R is a committed revocation, E is the actual GitHub commit of one draft, tag, or publication effect, and X is the point at which the applicable LUnit run exceeds the 90-day limit. Ordering these events across authorities itself requires evidence; client response order or unrelated wall clocks do not establish it. Where a rule requires preventing E, a history in which E actually occurs is a violation of that rule, not a successful example.

Sequence	Policy consequence or outstanding decision
R before V	Both approaches reject known-revoked evidence before the effect.
V, then R, then E	Under the recommended strict rule, the effect must not occur. A cutoff policy must distinguish R before K from K, then R, then E; the latter is a separate operator decision, not a post-publication event.
V, then X, then E	The accepted ADR-0006 rejects a run older than 90 days when its verifier evaluates it. Requiring it to remain within that age at the actual effect is a stronger, unselected policy and needs enforceable timing; a pre-effect check alone does not establish it.
V, then a draft or tag E, then R, before publication	A later managed publication must revalidate and reject the known-revoked proof. The earlier draft or tag is not a published release.
V, then publication E, then R	Apply the selected post-publication incident response; do not automatically withdraw the release.
Request for revocation arrives while E may be in flight	A request is not the same event as a committed revocation. The proposed design records and signals the pending request, does not send new dependent effects while it is pending, and does not infer that an already submitted effect was canceled. Reconcile its actual outcome and ordering.

For example, after V the client can observe a revocation and then receive a delayed success response in either order of the underlying R and E commits. Without trustworthy cross-authority ordering those histories are indistinguishable to that observer and must remain UNKNOWN; a later readback cannot prevent an earlier unsafe effect.

One possible strict-policy design would serialize revocation commits and effect authorization in a durable independent authority. It must also make pending revocation requests visible, avoid dispatching another effect while one is pending, and retain exclusion until any already sent GitHub request is terminal or safely fenced. A lease that simply expires while a request might still commit does not establish safety. Queuing a request is not the same as committing revocation; its latency and operator response require an explicit policy. No such mechanism is selected or proven.

Time expiry is independent of revocation serialization: a lock cannot pause the 90-day clock. A client timeout, measured typical latency, or arbitrary safety margin does not prove that a remote side effect cannot commit after X. The inspected documentation does not establish a conditional GitHub publication tied to an evidence revision or expiry; this is missing evidence, not proof that no suitable mechanism exists. Define the clock, precision, and exact age boundary in a reviewed successor, and separately decide whether the stronger effect-time rule is required. Artifact availability must be checked; being less than 90 days old alone does not prove that the artifact is downloadable.