Define governed human-approval transaction and consumption protocol

[samovers]

Related to #10 and #11. This is a separate prerequisite before machine materialization or runtime implementation of interactive human approval.

Outcome

Define a governed transaction and consumption protocol that reconciles interactive human approval with transaction-bound, single-use authorization decisions without assuming an open database transaction across human think time.

Primary trust boundary

Runtime transaction coordination and consumption integrity: reservation/finalization boundaries, current-state revalidation, atomic decision/effect/evidence commit, concurrency, retry, and recovery.

Intended PR boundary

A separate non-authoritative Phase A runtime-integration candidate. It may consume the approved authorization semantics from #11 but must not change authorization eligibility, principal resolution, protected-effect domain mappings, database roles, transport-release authority, retention/key custody, or active/current schemas.

Acceptance criteria

• Define where the approval challenge, explicit human act, final authority re-evaluation, decision creation, single-use consumption, protected-effect validation, and final commit occur.
• Decide explicitly whether the lifecycle uses a two-phase reservation/finalization protocol or another bounded mechanism; do not leave an interactive database transaction implicitly open.
• Define the authoritative transaction deadline and snapshot/cutoff inputs supplied to authorization without moving runtime ownership into authorization law.
• Require final current-state revalidation after the human act and before effect commit, including principal/session, representation, grant, delegation, revocation, resource, evidence, policy, and approval state.
• Define reservation ownership, expiry, cancellation, duplicate acts, concurrent consumers, idempotency, retry, crash recovery, and orphan cleanup.
• Preserve atomic visibility of the protected effect, authorization evidence, finalization evidence, consumption record, and governed-effect receipt.
• Define failure behavior for state drift, expired approval/decision, validation failure, persistence failure, and uncertain commit outcome without fabricating or rewriting an authorization result.
• Identify the exact interface dependency on each separately owned protected-effect contract under Define protected-effect contracts for authorization-bound state changes #12 and Define final ReviewDecision protected-effect contract #15.
• Add production-reachable hostile cases for concurrent approval/consumption, crash boundaries, retry after uncertain commit, and state change between challenge and finalization.

Non-goals

• No change to authorization action meanings, outcome lattice, reason codes, or approver eligibility.
• No protected-effect result mapping, Event Grammar classification, transport-release decision, retention/encryption/key-custody policy, database-role design, deployment, or production-readiness claim.
• No implementation in OFARM2 until the governing contracts are accepted, promoted, and extracted.

Scope-expansion rule

If the protocol cannot close without changing authorization law or a protected-effect domain contract, stop before editing that boundary and open a linked prerequisite or amendment.

What is next: review the Phase A protocol boundary after #11's exact-head semantics are approved and before draft machine materialization.

[samovers]

Phase A implementation is ready for steward review in draft PR #20 at exact head 1bfbb25.

The candidate preserves both approved PR #11 human-finalization modes: fresh approval uses a two-stage reservation/challenge and later finalization protocol, while direct human action uses one short finalization transaction without fresh-approval artifacts. The exact PR #17 ReviewDecision handoff follows HUMAN_ONLY and DIRECT_HUMAN_ACTION_REQUIRED.

The primary trust boundary is runtime transaction coordination and single-use consumption integrity. Scope stayed inside one non-authoritative historical candidate file; authorization semantics, protected-effect mappings, schemas, database authority, runtime, currentness, transport release, retention, and key custody remain unchanged.

The full repository validation suite and generated-currentness check pass. Issue #19 remains open pending exact-head semantic review and explicit approval.

What is next: review section 23 of draft PR #20 at the exact submitted head.

[samovers]

PR #20 has been revised at exact head e6b344c to close all three bounded findings from review 5099202189.

The candidate now constructs uncommitted prospective finalization evidence before final authorization evaluation, keeps the policy-selected mode in the operation digest but outside the authoritative idempotency tuple, and makes reservation terminal states generation-specific while deriving logical-operation commitment from the unique receipt. The three requested hostile cases and corresponding approval-card decisions are included.

The full repository validation suite and generated-currentness check pass. The primary trust boundary remains runtime transaction coordination and single-use consumption integrity, and scope remains one non-authoritative historical candidate file with no adjacent-boundary change.

Issue #19 remains open pending exact-head semantic re-review and explicit approval.

What is next: re-review draft PR #20 at e6b344c.

[samovers]

PR #20 has been revised at exact head 98f8c4f to close the remaining finding from re-review 5099495857.

The fresh-approval sequence now determines the canonical candidate requester and approver paths, collects the PR #11 cutoff inputs, and computes approvalExpiresAt and decisionValidUntil before hashing the prospective approval. The sole authoritative final evaluation must select the same requester basis and return the identical validity window; any mismatch discards the candidate and commits no effect or consumption.

The requested hostile case, evidence-ownership row, and approval-card decision are present. Full repository validation and generated currentness pass. The primary trust boundary remains runtime transaction coordination and single-use consumption integrity, with one non-authoritative candidate file and no adjacent-boundary change.

Issue #19 remains open pending exact-head semantic re-review and explicit approval.

What is next: re-review draft PR #20 at 98f8c4f.

[samovers]

Phase A transaction candidate completed

Issue #19 is completed by the one-file governed human-approval transaction and single-use consumption candidate on draft PR #20 at exact head 98f8c4fafbae42c8f7fd931f43f53adcb4733713.

The exact-head re-review found no blocking findings, no scope drift, and no new over-design. The source-verified review also gave an Approve disposition with four non-blocking materialization or conformance notes. Steward semantic approval is recorded for the exact head.

The completed work remains inside runtime transaction coordination and single-use consumption integrity. It changes one non-authoritative candidate file and does not merge or promote RFC law, create schemas, change currentness, authorize database or OFARM2 runtime work, or absorb authorization, protected-effect, transport, retention, encryption, or key-custody boundaries.

The non-blocking notes remain explicit downstream guards: preserve the OUTCOME_UNKNOWN cancellation/expiry block, enforce and test PR #11's authorization-evaluation time floor, wait for a production-reachable fresh-approval protected-effect family before claiming hostile conformance for that mode, and disambiguate the reservation-consequence vocabulary during evidence-package materialization.

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

What is next: preserve this exact approved candidate and select the next separately governed prerequisite or materialization boundary.