RFC candidate: governed human-finalization transaction protocol

[samovers]

Closes #19

Outcome

Adds one non-authoritative Phase A candidate for the shared transaction and single-use consumption boundary used by human-finalized protected effects.

Primary trust boundary

Runtime transaction coordination and single-use consumption integrity: mode-correct entry, reservation/finalization boundaries, current-state revalidation, atomic effect/evidence/consumption commit, concurrency, retry, crash recovery, and uncertain-commit reconciliation.

Intended PR boundary

One historical candidate file only. It creates no accepted law, schema, database role or migration, runtime code, currentness change, transport-release rule, retention or key-custody rule, or production claim.

Exact approved dependencies:

• authorization candidate PR RFC candidate: executable authorization evidence v0.2 #11 at 03a21f6;
• final ReviewDecision protected-effect candidate PR RFC candidate: final ReviewDecision protected-effect contract #17 / issue Define final ReviewDecision protected-effect contract #15 at 9ef0803.

Bounded decisions

• Fresh human approval uses two short durable stages with no database transaction or lock held during human think time.
• Direct human action uses one short finalization transaction and creates no challenge, separate approver, approval record, approval consumption, or reservation.
• A reservation is non-authoritative and non-exclusive.
• Finalization re-evaluates current authority and every applicable gate under trusted time, snapshot, cutoff, and commit guards.
• For fresh approval, transaction-local preparation determines the canonical candidate requester and approver paths and all required cutoffs without emitting a second authorization result.
• The exact candidate decisionValidUntil is bound before prospective approval evidence is hashed; final evaluation must select the same requester basis and return the same validity window.
• Prospective finalization evidence remains uncommitted and non-portable until atomic success.
• The authoritative caller-key tuple excludes the policy-selected human-finalization mode, while the operation digest retains it so a mode change is a conflicting replay rather than a second namespace.
• Reservation terminal states are generation-specific; only the generation bound to the successful receipt is FINALIZED, while the unique receipt separately makes the logical operation committed.
• Protected effect, decision/finalization evidence, mode-applicable consumption, validation traces, and governed-effect receipt become visible in one atomic commit.
• The first concrete handoff is the exact PR RFC candidate: final ReviewDecision protected-effect contract #17 ReviewDecision contract and its PR RFC candidate: executable authorization evidence v0.2 #11 HUMAN_ONLY / DIRECT_HUMAN_ACTION_REQUIRED posture.
• NOT_REQUIRED actions and unapproved protected-effect families remain outside this candidate.

Review revisions

• Exact-head review 5099202189 requested three bounded corrections. Head e6b344c closed the prospective-evidence placement, mode-change idempotency, and exact-generation finality findings.
• Exact-head re-review 5099495857 confirmed those closures and requested the missing prospective approval decisionValidUntil binding. Head 98f8c4f closes that ordering contract, adds the requested hostile case, and updates the evidence-ownership and approval-card text.

Drift and over-design check

Scope stayed inside the declared transaction boundary. The candidate does not reinterpret authorization, duplicate ReviewDecision mappings, create a generic workflow engine or second authorization evaluator, select database technology, define transport, or absorb retention and custody.

Validation

• Full repository validation suite: PASS
• Generated currentness: PASS
• Repository hygiene, cross-reference, and steward guardrails: PASS
• CP10, CP12, CP13, CP14, and CP15 conformance runners: PASS
• Markdown structure: 10 tables, zero inconsistent rows, 24 main sections
• Diff hygiene and targeted validity-window assertions: PASS; one file only

Exact head submitted for re-review: 98f8c4f.

Please re-review the remaining bounded correction and section 23 against this exact head.

What is next: perform exact-head semantic re-review of the prospective approval validity-window binding.

[samovers]

Review disposition: Request three bounded changes

Reviewed PR #20 at exact head 1bfbb25c56d11e41930b927005cdeac556b7013e.

The PR is correctly shaped as a draft, one-file, non-authoritative Phase A candidate for issue #19. It changes no active law, machine schema, database implementation, runtime code, transport-release policy, custody policy, or currentness. Its dependency pins are valid: PR #11 has exact-head semantic approval at 03a21f6, and PR #17 has exact-head semantic approval at 9ef0803.

The overall architecture is sound. Three local executable contradictions remain.

1. Blocker — fresh approval is constructed after the authorization result that requires it

PR #11 defines fresh human approval as a trusted, immutable approval record bound to the final snapshot, exact effect intent, approver authority, display evidence, and expiry. Its lifecycle re-evaluates current state, computes the final relevant-state digest, binds the approval to that final snapshot, and then consumes the approval and authorization decision atomically with the protected effect.

PR #20 instead orders successful finalization as follows:

1. revalidate current state and compare relevant-state digests;
2. create the final authorization request/result/trace;
3. require the final authority and human-finalization outcome;
4. validate the protected effect;
5. only then construct the mode-correct finalization evidence and fresh-approval consumption.

The candidate also correctly says that the raw human act is not authority and that a consumable human-approval/finalization profile is created from that act inside the finalization transaction. The problem is that this profile is constructed after the final authorization result has already been required.

This creates a circular implementation choice:

• If the evaluator receives only the raw act, it violates the rule that the raw act is not authority.
• If it requires the trusted approval record defined by PR #11, the record does not yet exist at the point where authorization is evaluated.
• If it leaves the approval requirement outstanding, the path remains REQUIRE_HUMAN_APPROVAL and cannot reach the required final ALLOW.

Smallest patch: within the finalization transaction, after revalidation and relevant-state comparison but before final authorization evaluation:

1. Construct a prospective immutable human-approval/finalization evidence object from the exact act.
2. Bind it to the final authority snapshot, relevant-state digest, approver path, challenge, display, effect intent, policy/rule, and approvalExpiresAt.
3. Assign its deterministic ID and digest, but do not expose or durably commit it yet.
4. Supply that candidate evidence to the PR #11 authorization evaluator.
5. Require the resulting final authorization outcome.
6. Validate the protected effect.
7. Atomically commit the approval/finalization evidence, approval and decision consumption, effect, traces, reservation terminal record, and receipt.

A failure or rollback must leave no consumable approval record. Durable failure-attempt evidence may state that a candidate approval was constructed and rejected, but it must not turn that candidate into portable authority.

Add a hostile case where fresh-approval finalization reaches authorization ALLOW using only the raw human act, without a candidate approval record bound to the final snapshot. Required result: protocol conformance failure and no effect.

This changes only section 13’s ordering and the corresponding evidence/hostile-case text. It does not require an authorization amendment.

2. Blocker — a policy-derived mode change escapes the idempotency conflict boundary

The candidate defines the authoritative idempotency tuple as:

(operationBoundaryKind,
 operationBoundaryRef,
 authenticatedRequestingPrincipalRef,
 representedPartyRef-or-null,
 actionClass,
 humanFinalizationRequirement,
 operationIdempotencyKey)

The complete operation digest also contains humanFinalizationRequirement. A matching tuple plus digest retrieves the existing lifecycle; a matching tuple with a different digest is a conflicting replay.

The problem is that humanFinalizationRequirement is rule-selected policy, not caller-owned operation identity. Suppose:

1. An operation starts under FRESH_HUMAN_APPROVAL_REQUIRED.
2. Its response or commit status becomes uncertain, or it commits and the response is lost.
3. The action rule later changes to DIRECT_HUMAN_ACTION_REQUIRED.
4. The caller retries the same action, effect intent, and idempotency key.

Because the mode is part of the tuple itself, the retry now enters a different idempotency namespace. It does not necessarily discover or reconcile the previous operation. That contradicts the candidate’s stronger claim that the scoped key can never be reused for different operation bytes or a second protected effect.

Prospective result-ID uniqueness may catch some duplicates, but result IDs are not a substitute for the operation’s primary idempotency boundary. Other protected-effect families may also have different result-set structures.

Smallest patch: remove humanFinalizationRequirement from the authoritative idempotency-scope tuple, but retain it in operationBindingDigest.

The tuple becomes:

(operationBoundaryKind,
 operationBoundaryRef,
 authenticatedRequestingPrincipalRef,
 representedPartyRef-or-null,
 actionClass,
 operationIdempotencyKey)

The digest continues to bind the human-finalization requirement, effect-intent schema, effect-intent digest, and full principal and representation bindings.

The resulting behavior is:

same tuple + same digest
→ exact retry / lifecycle retrieval

same tuple + changed rule-selected mode or other operation bytes
→ conflicting replay

intentionally new operation
→ new idempotency key

Add a hostile case where the action’s human-finalization mode changes between the first attempt and retry. The retry must retrieve/reconcile the earlier lifecycle or fail as a conflicting replay; it must not create a second logical operation under the same caller key.

No new idempotency service or cross-version compatibility engine is needed.

3. Blocker — reservation-generation state becomes ambiguous when a later generation succeeds

The candidate says that one reservation generation has exactly one derived state:

• OPEN
• FINALIZED
• INVALIDATED
• CANCELLED
• EXPIRED

It defines FINALIZED as “the logical operation committed successfully,” while also allowing a terminal non-success generation to be followed by a new sequential generation. It further says that FINALIZED is terminal for the logical operation, not only the generation.

Consider this valid lifecycle:

generation 1 → EXPIRED
generation 2 → successful commit

After generation 2 commits, generation 1 satisfies two descriptions:

• it remains the generation that expired;
• the logical operation has now committed successfully, which is the current definition of FINALIZED.

Without a precedence rule, generation 1 either has two derived states or silently changes from EXPIRED to FINALIZED. The latter conflicts with the candidate’s append-only terminal-history posture.

Smallest patch: make reservation state generation-specific:

• FINALIZED means the successful receipt and reservation-success terminal record bind that exact reservation generation.
• INVALIDATED, CANCELLED, and EXPIRED remain permanent terminal states of their respective generations.
• A successful receipt separately makes the logical operation terminal, preventing further generations.

A separate machine-contract family is unnecessary. Operation-level finality can be derived from the existence of the unique governed-effect receipt:

generation 1 = EXPIRED
generation 2 = FINALIZED
logical operation = committed because the unique receipt exists

Add a hostile case for exactly that sequence and require all three conclusions above.

What is already sound

The following design choices should remain:

• no long-lived transaction during human think time;
• reservation is non-authoritative and non-exclusive;
• finalization is the sole protected-effect linearization point;
• direct-human and fresh-approval modes stay separate;
• final current-state revalidation is mandatory;
• a read snapshot alone is insufficient, including for negative facts and changing sets;
• the transaction gate consumes a protected-effect handoff without reimplementing domain mappings;
• the complete success set is atomically visible;
• consumption linearizes only with successful commit;
• EFFECT_COMMITTED, NO_EFFECT, and OUTCOME_UNKNOWN remain transaction results rather than authorization outcomes;
• uncertain commit blocks reapplication until authoritative reconciliation;
• a partial atomic set is quarantined rather than automatically repaired or replayed;
• external byte release remains under issue #13, while retention and key custody remain under issue #14; and
• mutable coordination rows remain derived from immutable evidence rather than becoming hidden truth.

Drift and over-design assessment

No broad scope drift. The candidate stays inside issue #19’s declared runtime transaction and consumption boundary: reservation/finalization placement, current-state revalidation, atomic commit, concurrency, retry, and recovery.

The document is long, but most of that length is justified because concurrency and uncertain-commit rules become dangerous when left implicit. It does not introduce a generic workflow language, distributed XA, a second authorization evaluator, duplicate ReviewDecision mappings, a new truth store, a database-vendor mandate, transport-release or custody semantics, or a new event family or commit class.

The three requested changes reduce ambiguity without adding architecture.

Final assessment

• Transaction architecture: sound
• PR #11 dependency: valid
• PR #17 dependency: valid
• Fresh-approval final authorization ordering: must fix
• Idempotency across rule-selected mode changes: must fix
• Replacement-generation state determinism: must fix
• Scope drift: none
• Architectural over-design: none
• Phase A disposition: not yet ready for steward approval

Keep PR #20 in draft and do not approve section 23 until these three bounded changes are closed.

[samovers]

The three blockers from exact-head review 5099202189 are resolved at e6b344c.

1. Fresh-approval finalization now constructs deterministic prospective approval/finalization evidence after current-state revalidation and before final authorization evaluation. The evaluator receives that candidate, while it remains transaction-local, uncommitted, and non-portable until the complete atomic success commit. Failure or rollback leaves no consumable approval.
2. The authoritative idempotency tuple no longer includes the policy-selected human-finalization requirement. The operation digest still includes it, so a mode change under the same caller key retrieves or reconciles the earlier lifecycle and then conflicts instead of creating a second namespace.
3. Reservation states are generation-specific. A prior EXPIRED, INVALIDATED, or CANCELLED generation remains permanently terminal; only the generation bound by the successful receipt becomes FINALIZED, and the unique receipt separately makes the logical operation committed.

The requested hostile cases and approval-card decisions were added. The full repository validation suite, generated currentness, Markdown structure, diff hygiene, and targeted semantic assertions pass.

Primary trust boundary remains runtime transaction coordination and single-use consumption integrity. Scope stayed inside the existing one-file non-authoritative candidate; authorization, ReviewDecision mappings, schemas, database authority, runtime, currentness, transport, retention, and custody are unchanged.

Re-review is requested against exact head e6b344c.

What is next: perform exact-head semantic re-review of PR #20.

[samovers]

Re-review disposition: Request one bounded change

Reviewed PR #20 at current head e6b344cb3a8ae0f03cb43d3e87f6daaf1739a917 against the previously reviewed head 1bfbb25c56d11e41930b927005cdeac556b7013e.

The delta is one commit modifying only the existing non-authoritative candidate document. PR #20 remains open, draft, mergeable, and limited to one changed file. The PR description is current and accurately identifies the three attempted corrections. Both current-head repository workflows completed successfully.

Previous findings

1. Prospective finalization evidence: substantively closed

The finalization order now constructs deterministic, immutable, prospective finalization evidence before the final authorization evaluation. That evidence remains uncommitted and non-portable until the complete success transaction commits.

The finalization sequence now correctly does the following:

1. Revalidates current state.
2. Constructs prospective mode-correct finalization evidence with an identity and digest.
3. Supplies that evidence to the PR #11 evaluator.
4. Creates the final authorization bundle.
5. Validates the protected effect.
6. Atomically commits the evidence, effect, consumptions, traces, terminal record, and receipt.

Failure discards the prospective evidence rather than leaving behind a reusable approval. The requested hostile case also now prevents raw human-act evidence from satisfying fresh approval by itself.

2. Idempotency across mode changes: closed

The authoritative caller-key tuple now excludes the policy-selected humanFinalizationRequirement:

(operationBoundaryKind,
 operationBoundaryRef,
 authenticatedRequestingPrincipalRef,
 representedPartyRef-or-null,
 actionClass,
 operationIdempotencyKey)

The complete operationBindingDigest still contains the human-finalization mode. Consequently:

same tuple + same digest
→ retrieve or reconcile the existing operation

same tuple + changed mode or other operation bytes
→ conflicting replay

intentionally new operation
→ new idempotency key

The stage-one path, retry rules, hostile cases, and approval card were updated consistently.

3. Reservation-generation finality: closed

FINALIZED now belongs only to the exact reservation generation bound by the successful receipt and reservation-success terminal record. The unique receipt separately makes the logical operation committed.

The corrected result is deterministic:

generation 1 = EXPIRED
generation 2 = FINALIZED
logical operation = committed

Later operation history cannot rewrite generation 1 from EXPIRED to FINALIZED, and the committed-operation receipt prevents further generations. The requested hostile case is present.

Remaining blocker — the prospective approval still lacks its required decisionValidUntil binding

PR #11 requires a fresh human-approval record to bind all of the following, including:

• effect-intent schema and digest;
• derived target, typed inputs, and effect subject;
• policy digest;
• challenge and final authority snapshots;
• equal authorityRelevantStateDigest values;
• represented Party and representation basis where applicable;
• decisionValidUntil.

It also explicitly says that approval for a different validity window is not reusable.

PR #11 computes decisionValidUntil as the earliest relevant instant among:

1. the protected-effect transaction deadline;
2. principal and session validity;
3. the validity ends of the representation, role, grants, delegation, sharing, and revocation inputs used by the selected path;
4. policy, rule, and authority-snapshot cutoffs;
5. resource, evidence, and sovereignty cutoffs; and
6. approvalExpiresAt.

PR #20’s revised sequence currently does this:

• step 4 constructs and hashes the prospective approval/finalization evidence, explicitly binding approvalExpiresAt but not decisionValidUntil;
• step 5 gives that already-hashed evidence to the authorization evaluator;
• step 9 merely rechecks the decisionValidUntil produced by the authorization result.

That leaves two invalid implementation choices.

Invalid choice A: omit decisionValidUntil

The prospective approval does not satisfy the exact PR #11 approval profile, so it cannot complete the human-finalization requirement.

Invalid choice B: add it after authorization evaluation

Adding the value after step 5 changes the prospective approval bytes and digest. The authorization evaluator would then have admitted one evidence object while the transaction committed another.

The core cycle is:

approval evidence must bind decisionValidUntil
decisionValidUntil depends on the selected authorization path
current sequence hashes approval evidence before final path selection

Rechecking the value immediately before commit does not repair the missing binding in the evidence object consumed by the evaluator.

Smallest required patch

For fresh approval only, revise the step 3–5 boundary as follows:

1. Evaluate every non-finalization condition under the final transaction snapshot.
2. Determine the canonical requester authority path from paths that satisfy every condition except the still-outstanding fresh approval.
3. Determine the exact approver path and all applicable cutoff inputs.
4. Compute approvalExpiresAt.
5. Compute the candidate decisionValidUntil using PR #11’s exact cutoff function and the canonical requester path.
6. Put that exact value into the prospective approval/finalization evidence before computing its identity and digest.
7. Supply the completed prospective evidence to the final PR #11 evaluation.
8. Require the final evaluator to select the same requester authority basis and return exactly the prebound decisionValidUntil.
9. Treat any path, cutoff, or validity-window mismatch as a failed finalization: discard the prospective evidence and commit no effect or consumption.

The protected-effect transaction still performs only one authoritative final authorization decision. The earlier calculation is a deterministic completion of the prospective evidence inputs, not a second portable authorization result.

Add one hostile case:

Prospective fresh-approval evidence omits decisionValidUntil, binds a different value, or was constructed from a different requester path than the final evaluator selects.

Required result:

no authorization ALLOW based on that approval
no protected effect
no approval or decision consumption
prospective evidence discarded

Section 18’s approval-evidence ownership row and section 23’s approval card should also name the validity-window binding explicitly.

If the intended design is instead that decisionValidUntil does not belong in the approval evidence, that requires a separately reviewed PR #11 amendment. PR #20 cannot silently weaken or reinterpret the approved dependency.

Drift and over-design check

No broad scope drift. The new commit remains within issue #19’s transaction-coordination boundary. It changes no authorization action or eligibility semantics, protected-effect domain mapping, Event Grammar, transport-release rule, evidence-retention or key-custody policy, database implementation, runtime code, or active/current machine contract.

No new architectural over-design. The corrections reuse existing operation identity, finalization evidence, path selection, transaction guards, receipts, and reservation generations. They add no workflow language, second authorization evaluator, distributed transaction protocol, compatibility engine, or new truth layer.

The remaining problem is one missing field-ordering contract at the PR #11/PR #20 boundary. It should be fixed locally rather than reopening either architecture.

Final assessment

• Prospective-evidence-before-authorization correction: substantively closed
• Mode-change idempotency correction: closed
• Exact-generation finality correction: closed
• New scope drift: none
• New over-design: none
• Remaining blocker: prospective fresh approval does not yet bind its exact decisionValidUntil
• Phase A disposition: not yet ready for steward approval

Keep PR #20 in draft and do not approve section 23 until the validity-window binding is closed at an exact new head.

[samovers]

The remaining blocker from exact-head re-review 5099495857 is resolved at 98f8c4f.

For fresh approval, the final transaction now performs the required ordering under one snapshot and guard set:

1. Revalidate current state and require challenge/final relevant-state equality.
2. Evaluate all non-finalization conditions and determine the canonical candidate requester basis and exact approver path without emitting an AuthorizationDecisionResult.
3. Collect all PR RFC candidate: executable authorization evidence v0.2 #11 cutoff inputs and compute approvalExpiresAt and the candidate decisionValidUntil with the exact PR RFC candidate: executable authorization evidence v0.2 #11 minimum-cutoff function.
4. Put that value and requester basis into the prospective approval before computing its identity and digest.
5. Run the sole authoritative PR RFC candidate: executable authorization evidence v0.2 #11 final evaluation and require it to select the same requester basis and return the identical decisionValidUntil.
6. Discard the candidate and commit no effect or consumption on any missing cutoff, path, basis, or value mismatch.

The requested hostile case, section 18 ownership text, and section 23 approval decision are included. No second authorization evaluator or result was introduced.

The full repository validation suite, generated currentness, Markdown structure, diff hygiene, and targeted validity-window assertions pass. The primary trust boundary remains runtime transaction coordination and single-use consumption integrity, and the PR remains one non-authoritative candidate file with no adjacent-boundary change.

Re-review is requested against exact head 98f8c4f.

What is next: perform exact-head semantic re-review of PR #20.

[samovers]

Review at 98f8c4f

Checked out this branch alongside pull/11/head and pull/17/head and verified every cross-document claim against those heads and against the current schemas, rather than reading the candidate on its own terms.

Dependency pins are exact and current

• PR RFC candidate: executable authorization evidence v0.2 #11 pinned at 03a21f669ee04f96d444e14f00ae7212cab04803 — matches its live head.
• PR RFC candidate: final ReviewDecision protected-effect contract #17 pinned at 9ef08030b25eb3db1c2da14d6595300198384ff2 — matches its live head ("Align ReviewDecision candidate with authorization head").

Both are exact, both are current. §24 step 1's re-open condition is stated correctly.

Verified claims

• §19 mode binding. All three final-review rows in PR RFC candidate: executable authorization evidence v0.2 #11's §7.2 matrix carry HU and DH, and §7.2's legend fixes HU = HUMAN_ONLY and DH = DIRECT_HUMAN_ACTION_REQUIRED. The claim that ReviewDecision uses direct-human finalization with no fresh-approval artifacts is correct, and the §19 prohibition on routing it through a sponsor or synthetic challenge follows from PR RFC candidate: executable authorization evidence v0.2 #11 §7.4.
• §3–§4 division of ownership. PR RFC candidate: executable authorization evidence v0.2 #11 §18.2 explicitly hands the reservation/finalization, concurrency, retry and recovery protocol to samovers/OFARM#19 and states no machine profile or runtime implementation may claim the lifecycle until it closes. The claim that PR RFC candidate: executable authorization evidence v0.2 #11 "deliberately leaves" this to Define governed human-approval transaction and consumption protocol #19 is exact, not charitable paraphrase.
• §11 cutoff collection is complete. PR RFC candidate: executable authorization evidence v0.2 #11 §18.2 defines decisionValidUntil as the earliest instant in a six-item candidate set. §11 steps 4–6 collect all six: transaction deadline, principal/session, the path-scoped grant/delegation/sharing/revocation ends, policy/rule and snapshot ends, resource/evidence/sovereignty ends, and approvalExpiresAt. Nothing is dropped.
• §4 inventory claims check out against the schemas. AuthorizationDecisionResult v0.1 does carry exactly humanApprovalRequired and finalActionPermitted. AgentRunApprovalCheckpoint v0.1 carries approvalCheckpointId, approvalRequired, approvalState, approverPartyRef, checkpointType, decisionTraceRef, expiresAt, finalActionPermitted, notes, requiredForActionClasses, schemaVersion, targetScope — no effect-intent digest, no display binding, no policy/rule digest, no relevant-state digest, no consumption record. The §4 and §21 conclusion that it cannot serve as v0.2 human approval is accurate.
• §18 package claims. AuthorizationFinalizationEvidence v0.2 is proposed in PR RFC candidate: executable authorization evidence v0.2 #11 §17.1 and §23, and PR RFC candidate: executable authorization evidence v0.2 #11 §17.2 does assign EvidenceEvent / evidence record to the decision and finalization evidence package. The conditional "only if schema review proves the new truth claims fit it" is the right posture.
• Hygiene. One file, 854 insertions, tables column-consistent, no trailing whitespace, no tabs, trailing newline present, and the embedded operationBindingDigest JSON parses.

The ordering fix in 98f8c4f is sound. Binding the candidate decisionValidUntil into the prospective evidence before its digest is computed, then requiring final evaluation to select the identical basis and return the identical value, closes the hole where approval evidence could be hashed over an incomplete object. §21's row for a mismatched or omitted value gives it teeth.

---

Findings

1. §17.2 expiry and §17.1 cancellation do not restate the OUTCOME_UNKNOWN block

§7.1 states plainly:

An unresolved OUTCOME_UNKNOWN attempt blocks any new finalization, cancellation, expiry terminalization, or replacement generation until reconciliation establishes whether that exact generation finalized or no effect committed.

§17.2 then says expiry processing may append an EXPIRED terminal record "after the exclusive cutoff when no success receipt exists." Under OUTCOME_UNKNOWN, whether a success receipt exists is precisely the unresolved question. The guard §17.2 does carry — using the same uniqueness guards as finalization "so it cannot race into a false expiry after commit" — addresses a concurrent race, not an already-unresolved attempt whose cutoff has since passed.

An implementer reading §17 on its own can terminalize an unknown-outcome generation as EXPIRED and mask a committed effect, which §16.3 otherwise treats as requiring authoritative lookup first. §17.1 cancellation has the same shape: it resolves the race against a committed receipt but never names the OUTCOME_UNKNOWN precondition.

Suggest restating the §7.1 block as an explicit precondition in both §17.1 and §17.2, or adding a §21 row for expiry or cancellation terminalizing a generation with an unresolved attempt.

2. PR #11's authorizationEvaluatedAt floor has no step and no hostile case

PR #11 §18.2 closes its decisionValidUntil rule with two failure conditions:

If the candidate set cannot be constructed, or its minimum is not later than authorizationEvaluatedAt, no consumable decision exists.

§11's preparation computes the candidate decisionValidUntil before the authoritative evaluation runs — so authorizationEvaluatedAt does not exist yet and that floor cannot be checked there. §13.1 step 9 rechecks the deadline, decisionValidUntil, the commit guard and uniqueness, but against commit time, not against authorizationEvaluatedAt.

The prospective-before-evaluation ordering is what makes this reachable: a cutoff that lapses between prospective computation and final evaluation produces a prebound value that is no longer later than the evaluation instant. The final PR #11 evaluator would presumably apply its own rule and return non-ALLOW, so this is likely handled in substance — but §21 has a row for a prospective value that is omitted, different, or built from the wrong path, and none for this. Given how exhaustive §21 is elsewhere, the omission reads as an oversight rather than a decision.

Suggest a §13.1 step-5 clause or a §21 row making the floor explicit.

3. The fresh-approval half has no executable binding in Phase A

PR #11's matrix has exactly four FA rows: ASSERT_STRUCTURE, ASSERT_COMPLIANCE, SHARE_GRANT_ACCESS, and SHARE_REVOKE_ACCESS. So the mode is real, not hypothetical — but all four belong to effect families §20 lists as blocked pending their own protected-effect contracts, and §19's only concrete handoff is the direct-human ReviewDecision path.

The consequence lands on §24 step 7: hostile conformance cannot exercise §21's fresh-approval cases — reservation lifecycle, challenge/final digest equality, generation replacement, approval consumption, cancellation races — through production-reachable paths until at least one FA family's protected-effect contract closes. §21's own closing paragraph rules out unit-only state-machine helpers for a conformance claim, which makes the sequencing constraint binding rather than incidental.

This is not an argument for cutting the fresh-approval protocol; specifying it now is the right call, and §12.3 and §20 are correct that unsupported families cannot finalize. But §1, §23, and §24 present the two modes symmetrically, and a steward approving this cannot tell from the document that half of it is unexercisable in Phase A. Worth one sentence in §24 step 7 naming the dependency.

4. NOT_APPLICABLE is reused across one evidence package

§15.1 and §15.2 use NOT_APPLICABLE as the direct-human-mode reservation consequence. PR #17 §12.2 uses NOT_APPLICABLE as a trace disposition meaning an item's contract-declared condition does not apply, now distinguished there from NOT_EVALUATED.

Separate enumerations on separate records today — but §18 proposes carrying the transaction profiles as tags inside AuthorizationFinalizationEvidence v0.2, and §24 step 4 materializes them there. That puts both meanings of the token in one package. Worth qualifying the reservation-consequence value (RESERVATION_NOT_APPLICABLE, or similar) before materialization rather than after.

---

Disposition

Approve. No blocking findings.

The document is internally consistent on the points most likely to break — mode separation is maintained cleanly through every section rather than only where it is convenient, the idempotency tuple and operation digest are correctly split so a mode change is a conflict rather than a new namespace, and §13.1's ten-step order, §14's uniqueness rules, and §16.3's partial-set quarantine hold together. Findings 1 and 2 are small edits that make already-correct behavior explicit where an implementer reading one section in isolation could get it wrong. Finding 3 is a disclosure item for the steward card. Finding 4 is best fixed before schema materialization.

[samovers]

Re-review disposition: No blocking findings

Reviewed PR #20 at current head 98f8c4fafbae42c8f7fd931f43f53adcb4733713 against the previously reviewed head e6b344cb3a8ae0f03cb43d3e87f6daaf1739a917.

The delta is one commit modifying the same non-authoritative candidate file, with 21 additions and 8 deletions. PR #20 remains open, draft, mergeable, and limited to one changed file.

Previous remaining blocker: closed

PR #11 requires the fresh human-approval record to bind its exact decisionValidUntil. That value is path-dependent: it is the minimum of the trusted transaction deadline and the applicable session, representation, authority-source, policy, snapshot, resource, evidence, sovereignty, approval, and related cutoffs associated with the selected authority path.

The revised PR #20 sequence now closes that dependency without hashing an incomplete approval record:

1. It performs final post-act revalidation and requires challenge/final relevant-state equality.
2. It evaluates all authorization conditions except the still-outstanding fresh-approval condition.
3. It applies PR #11’s total lattice and canonical path tuple to determine the exact candidate requester path and basis.
4. It independently determines the canonical eligible natural-person approver path.
5. It collects the complete requester-, approver-, transaction-, authority-, policy-, evidence-, and resource-cutoff inputs.
6. It computes approvalExpiresAt.
7. It computes the candidate decisionValidUntil using PR #11’s exact minimum-cutoff function.
8. It places that value and the candidate requester basis in the prospective approval evidence before assigning its identity and digest.
9. It runs the complete PR #11 evaluator as the sole authoritative final authorization evaluation.
10. It requires that evaluator to select the same requester basis and return exactly the prebound validity window.

Any missing cutoff, path mismatch, basis mismatch, or validity-window mismatch discards the prospective evidence and commits no effect or consumption.

Section 13 reflects the same ordering. The prospective approval evidence is complete before final authorization evaluation, while remaining transaction-local, uncommitted, and non-portable. It becomes durable only in the atomic success commit alongside the authorization bundle, protected effect, consumptions, traces, generation terminal record where applicable, and receipt.

This resolves the previous cycle:

selected path
→ exact cutoff inputs
→ approvalExpiresAt
→ candidate decisionValidUntil
→ complete prospective approval digest
→ final authorization evaluation
→ exact path and validity equality check

There is no longer a path where the evaluator admits one approval digest and the transaction later commits different approval bytes.

Supporting closure is complete

The evidence-ownership table now explicitly requires the candidate requester and approver paths, approvalExpiresAt, and decisionValidUntil to be established before the approval is hashed. It also requires final evaluation to reproduce the same requester basis and validity window.

The requested hostile case is present:

prospective approval omits decisionValidUntil, binds a different value, or was constructed from a different requester path or basis than the final evaluation selects.

The required disposition is fail-closed: no authorization ALLOW based on that evidence, no protected effect, no consumption, no success receipt, and the prospective evidence is discarded.

The section 23 approval card now makes the validity-window rule an explicit steward decision rather than leaving it implicit in the transaction sequence.

Prior findings remain closed

The earlier corrections remain intact:

• Prospective evidence placement: mode-correct finalization evidence is constructed before final authorization evaluation and remains non-portable until atomic success.
• Mode-change idempotency: the authoritative caller-key tuple excludes the policy-selected human-finalization mode, while operationBindingDigest retains it; a changed mode is therefore a conflicting replay, not a new namespace.
• Reservation-generation finality: only the exact generation named by the successful receipt is FINALIZED; earlier expired, cancelled, or invalidated generations retain their permanent states.
• Operation finality: the unique successful receipt separately makes the logical operation committed and prevents further generations.

No amendment in the latest commit weakens those closures.

Drift and over-design assessment

No material scope drift. The change remains inside issue #19’s runtime transaction-coordination boundary. It does not alter:

• authorization eligibility or action meanings;
• PR #11’s path lattice, path tuple, cutoff function, approver eligibility, or reason codes;
• PR #17’s ReviewDecision mappings or postconditions;
• Event Grammar or commit classes;
• transport-release eligibility;
• retention, deletion, encryption, or key custody;
• database implementation;
• active schemas, currentness, or OFARM2 runtime code.

No architectural over-design. The transaction-local preparation is not a second authorization decision or second source of authorization law. It emits no AuthorizationDecisionResult, consumption, effect, or portable authority claim. The complete PR #11 evaluation remains the only authoritative authorization evaluation, and exact path/value equality prevents the preparation from silently diverging.

At machine-materialization time, the preparation and final evaluation should use the same content-addressed PR #11 evaluation semantics rather than separately maintained implementations. The candidate’s same-snapshot requirement and exact equality checks already make a divergent pre-evaluator nonconforming; this does not require another Phase A amendment.

The two visible current-head GitHub workflows—repository validation and generated-currentness validation—both completed successfully.

Final assessment

• Previous validity-window blocker: closed
• Prospective approval completeness: closed
• Canonical requester-path binding: closed
• Exact final path/value reproduction: closed
• Hostile coverage: adequate
• Previous three corrections: preserved
• New semantic blockers: none
• Scope drift: none
• New over-design: none
• Phase A disposition: ready for exact-head steward semantic approval

Approval should apply specifically to 98f8c4fafbae42c8f7fd931f43f53adcb4733713. It would approve only this non-authoritative Phase A candidate and its section 23 decisions. It would not merge the PR, accept active RFC law, create or promote machine contracts, change current/default status, or authorize OFARM2 runtime implementation.

[samovers]

Steward semantic approval — granted

I explicitly grant Phase A semantic approval for the governed human-approval transaction and single-use consumption candidate at commit 98f8c4fafbae42c8f7fd931f43f53adcb4733713, following the exact-head re-review with no blocking findings and the source-verified review whose disposition is Approve.

This approval accepts the complete candidate and its section 23 decisions at that exact head, including:

• the two-stage reservation/challenge and finalization protocol for fresh human approval;
• the separate one-transaction direct-human path without fresh-approval artifacts;
• non-authoritative, non-exclusive reservation semantics and exact-generation finality;
• final current-state revalidation, transaction guards, and the challenge/final relevant-state equality rule;
• transaction-local construction of complete prospective finalization evidence before the sole authoritative final authorization evaluation;
• canonical requester- and approver-path determination, exact cutoff collection, and prebinding of approvalExpiresAt and decisionValidUntil before the prospective evidence is hashed;
• exact requester-basis and validity-window reproduction by the final evaluator;
• the split between the caller idempotency tuple and the mode-binding operation digest;
• atomic protected effect, evidence, trace, consumption, reservation-terminal, and receipt visibility;
• single-use uniqueness, retry, cancellation, expiry, crash recovery, and uncertain-outcome reconciliation; and
• the exact approved PR RFC candidate: executable authorization evidence v0.2 #11 and PR RFC candidate: final ReviewDecision protected-effect contract #17 dependency bindings.

The approved primary trust boundary is runtime transaction coordination and single-use consumption integrity. PR #20 stayed within that boundary as a one-file, draft, non-authoritative Phase A candidate. Authorization law, protected-effect mappings, schemas, database authority, runtime implementation, currentness, transport release, retention, encryption, and key custody remain separately governed.

This decision does not:

• accept, merge, or promote the RFC;
• create or promote evidence or transaction schemas;
• change active or default law or currentness;
• authorize database or OFARM2 runtime implementation;
• approve transport release, retention, deletion, encryption, or key custody; or
• reopen or alter the exact approved semantics of PR RFC candidate: executable authorization evidence v0.2 #11 or PR RFC candidate: final ReviewDecision protected-effect contract #17.

The four non-blocking review notes remain later materialization and conformance guards: unresolved OUTCOME_UNKNOWN must block cancellation and expiry terminalization; PR #11's decisionValidUntil > authorizationEvaluatedAt floor must remain executable and tested; fresh-approval hostile conformance cannot be claimed until a fresh-approval action family has a production-reachable protected-effect contract; and the reservation-consequence vocabulary must be disambiguated before it shares an evidence package with PR #17 trace dispositions. These guards do not amend the approved candidate or authorize work in an adjacent trust boundary.

Any later semantic change to PR #20 requires renewed exact-head review and approval. PR #20 remains draft as the durable candidate and approval record.

What is next: complete issue #19 while preserving this exact approved candidate, then select the next separately governed prerequisite.