Define the NOT_REQUIRED atomic transaction and single-use consumption profile

[samovers]

Parent: #10
Related: #12, #21, #22
Downstream runtime work: samovers/OFARM2#353, samovers/OFARM2#178, samovers/OFARM2#176
Runtime UnitOfWork foundation: samovers/OFARM2#173

1. Outcome

Define the canonical transaction protocol for a state-affecting action whose immutable action rule selects humanFinalizationRequirement = NOT_REQUIRED.

The first concrete handoff is ASSERT_OPERATION_CLAIM: one eligible submission creates exactly one immutable PENDING_REVIEW AssertionRecord, together with its complete authorization, transaction, validation, consumption, and receipt evidence, in one short guarded protected-effect transaction.

An exact retry must discover the original operation rather than create another claim. Lost responses and concurrent duplicates must not cause another protected effect or another consumption of the write decision. A conclusively rolled-back attempt may proceed only through fresh current evaluation. An uncertain commit blocks reapplication until authoritative reconciliation resolves it.

Atomicity applies to the successful effect set, not to the erasure of failure evidence. The complete successful set commits together or none of its successful components becomes visible. Truthful ingress-rejection, authorization-refusal, and non-consumable failure-attempt evidence follow their separately defined persistence rules.

No human approval step is fabricated. No successful submission becomes accepted execution, a ReviewDecision, current state, or another implied domain effect.

2. Exact Phase A dependencies

These candidates have semantic approval at the following exact heads but remain draft and non-authoritative:

Owner	Exact approved head	Relevant closure
Authorization PR #11	03a21f669ee04f96d444e14f00ae7212cab04803	rule selection, principal/representation and CP3 posture, authority evaluation, NOT_REQUIRED, TRANSACTION_BOUND_V0_2, SINGLE_USE, decisionValidUntil, refusal evidence, and disclosure limits
Human-finalization transaction PR #20	98f8c4fafbae42c8f7fd931f43f53adcb4733713	compatible transaction, idempotency, consumption, and reconciliation concepts; its applicability remains limited to fresh approval and direct human action
AssertionRecord protected-effect PR #23	622376e2998cf8b3954ca19e81d2cce6fd57e5fe	assertion-submission mappings, trusted assertion-act time/provenance, postconditions, and exact result/trace handoff

The exact-head steward semantic approval records are:

• PR #11 at 03a21f669ee04f96d444e14f00ae7212cab04803;
• PR #20 at 98f8c4fafbae42c8f7fd931f43f53adcb4733713; and
• PR #23 exact-head re-review plus steward semantic approval at 622376e2998cf8b3954ca19e81d2cce6fd57e5fe.

These are explicit PR comments rather than formal APPROVED review objects and are the exact-head steward approval records in the current project history.

PR #20 explicitly excludes NOT_REQUIRED. PR #23 therefore leaves operation-claim execution blocked on this separate transaction profile.

Any semantic change to a pinned dependency requires renewed dependency review. Neither the pins nor this issue override active authority. Apply the repository order: 00_active_baseline/, then 02_accepted_rfcs/, then 01_companion_artifacts/, then 03_machine_contracts/.

3. Primary trust boundary and Phase A PR boundary

Primary trust boundary: transaction admission, guarded ordering, atomic success, single-use consumption, retry identity, and authoritative outcome reconciliation for NOT_REQUIRED state-affecting actions.

Create one non-authoritative candidate file:

package_meta/history/clean_baseline_migration/phase_reports/not_required_transaction_and_consumption_protocol_rfc_candidate_v0_1.md

The candidate must contain the proposed protocol, exact operation-binding rules, compatibility ledger, failure matrix, first operation-claim handoff, falsifiable cases, traceability, and steward approval card.

Change classification: proposed RFC extension, with later machine-contract and implementation/conformance implications. No active-baseline file is affected by this Phase A PR. In particular, do not edit the Constitution or Platform Runtime architecture.

This PR changes no accepted RFC, companion policy, machine schema, current/default selection, runtime code, database implementation, or readiness claim.

4. Ownership and compatibility ledger

PR #11 remains the owner of authorization meaning. PR #23 remains the owner of AssertionRecord meaning. This issue coordinates their exact handoffs; it does not create a second authorization evaluator or duplicate domain mappings.

Include an explicit compatibility ledger against PR #20, distinguishing:

• compatible concepts adopted here: stable idempotency lookup scope, operation-digest conflict detection, trusted transaction inputs, complete commit guards, successful-consumption uniqueness, truthful failure outcomes, and uncertain-commit reconciliation;
• mode-specific concepts not applicable here: approval reservation/generation, challenge, intended approver, human-finalization act, approval, approval consumption, and direct-human finalization evidence; and
• the new NOT_REQUIRED transaction/evidence profile and its exact relationship to the shared evidence package.

Adoption of compatible concepts does not widen PR #20's applicability. Its existing human-finalization profiles remain unchanged.

The candidate must also include an evidence-profile ownership table shaped like PR #20 §18. For the operation binding, transaction attempt, mode-correct NOT_REQUIRED evidence, authorization request/result/internal trace, decision consumption, protected result, gate traces, governed-effect receipt, refusal evidence, and non-consumable failure-attempt evidence, the table must name the semantic owner, proposed package/profile, exact truth claim, success-set placement, and failure/retry posture.

The NOT_REQUIRED transaction-attempt and evidence profiles are owned by #25. They may be proposed as tagged additions within the already proposed AuthorizationFinalizationEvidence v0.2 package using PR #20 §18's mechanism, without widening #19. If exact machine-schema review later proves that package cannot represent the distinct truth claims, stop and split the schema decision. This Phase A issue defines ownership and semantics only; it does not materialize schema bytes.

OFARM2 #173 owns runtime UnitOfWork foundations, #178 owns command-idempotency implementation, and #353 owns authorization-evaluator implementation. Those issues must consume promoted canonical meaning rather than invent it.

5. Required semantic closure

A. Rule-selected admission and mode-correct evidence

Admit a new execution attempt only when the immutable current action rule selects NOT_REQUIRED, the action is state-affecting, and the exact protected-effect contract and transaction profile are validly bound. RECEIVE_READ_DATA is not admitted merely because it also uses NOT_REQUIRED; its separately owned governed-read protocol remains unchanged.

A caller cannot select, downgrade, or substitute the mode. Missing, mutable, unsupported, or digest-invalid bindings fail closed.

Create no approval reservation, challenge, intended-approver record, human-finalization-act record, approval, approval consumption, reservation terminal record, or direct-human finalization evidence. Inapplicable fields are absent, not synthetic values, empty objects, or fabricated proof.

This restriction does not prohibit natural-person submission or erase AssertionRecord-domain assertion-act provenance. In particular, PR #23's VERIFIED_OFFLINE_SUBMISSION may require immutable assertion-act evidence even though no human approval is required for transaction finalization. Preserve that distinction explicitly.

Define the exact NOT_REQUIRED evidence truth claim, its placement in the transaction sequence, its immutable bindings, and its owner within the proposed shared AuthorizationFinalizationEvidence v0.2 package. It must record the rule-selected absence of a human-finalization requirement without pretending that an approval occurred.

B. Separate the lookup key from the operation digest

Use this authoritative idempotency lookup scope, compatible with PR #20 §6.2:

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

The rule-selected mode, effect-intent schema, effect-intent digest, result digest, and transaction-profile version must not create extra lookup namespaces that allow the same tuple to evade its earlier operation.

Separately define the exact canonical operationBindingDigest over the complete logical-operation binding, including the tuple, immutable requester and applicable representation bindings, rule-selected mode, effect-intent schema binding, and exact effectIntentDigest. Close the object shape, required absence/null posture, canonicalization, and digest construction in the candidate; do not leave them to runtime authors.

For retry and conflict detection, the authoritative comparison oracle is the exact caller-owned submission projection required by section 5C, not a newly recomputed full operationBindingDigest. The full operationBindingDigest is fixed exactly once when the first durable logical-operation binding is admitted and is recovered thereafter. The candidate must define the exact admission point at which that binding first exists, the atomic winner rule for concurrent first admissions, and the treatment of failures before and after that point.

The same tuple identifies one logical operation. The same tuple with changed bound operation content is a conflict, not a second operation. Result substitution must also be detected against the exact admitted or committed result binding; result digests are not lookup-key dimensions.

If an existing logical operation has a durable NO_EFFECT attempt under NOT_REQUIRED and the current rule later selects a different human-finalization mode, the same-key retry is TERMINAL_REQUIRES_NEW_OPERATION_KEY. It cannot enter this profile or borrow another profile under the old key. A genuinely new submission requires a new caller key and follows the newly selected mode.

Lookup and conflict detection must work across relevant transaction handlers/profiles. A later governed mode or schema change cannot hide an earlier success or unresolved attempt. Discover/reconcile the earlier operation before deciding whether the retry conflicts. A deliberately new operation requires a new caller key.

The Phase A candidate must either bind an accepted canonical identifier profile for operationIdempotencyKey or define its exact grammar and equality semantics. It must state whether equality is byte-exact or code-point-exact and explicitly address trimming, case folding, Unicode normalization, collation, and punctuation reinterpretation. It must not silently import an OFARM2 implementation convention as canonical law.

Retention or governed deletion may remove bulky evidence only when separately permitted, but it must not make a caller-key tuple reusable while a committed effect, receipt, unresolved attempt, replay obligation, or authoritative historical operation binding remains reachable. A durable binding or tombstone must preserve conflict detection. This issue does not select a retention duration, encryption mechanism, or storage table.

C. Preserve trusted intent enrichment across retries

Close the admission order between stable-key lookup, comparison of caller-owned submission content, trusted runtime completion of the intent, intent validation/digest calculation, and current execution evaluation.

For TRUSTED_ONLINE_SUBMISSION, the assertion act of a logical operation is its first admitted submission at the durable binding point defined in section 5B. The runtime supplies and binds assertedAt once before the full intent digest is fixed. Every later attempt under that logical operation recovers the same authoritative assertion-act binding; its later receipt, retry, authorization, or commit time is not a new assertion act. If no durable operation binding was ever admitted, the candidate must not claim that an earlier assertion-act binding survives.

PR #23 §6.2 requires the runtime to supply assertedAt for TRUSTED_ONLINE_SUBMISSION before intent validation and hashing. Therefore:

• for an existing committed or unresolved operation, recover its authoritative runtime-completed intent and trusted timestamp binding before comparing retry digests; do not generate a new timestamp and misclassify the identical caller submission as changed intent;
• a caller-provided timestamp, digest, receipt, or cached response cannot substitute for authoritative stored evidence;
• define an exact comparison/projection for the retried caller-owned content and its relationship to the full immutable intent; this comparison cannot omit a caller field that changes the operation, weaken full-intent hashing, or become a second source of authorization facts;
• concurrent identical submissions must resolve to one authoritative operation binding; independently generated timestamps must not turn identical submissions into artificial payload conflicts; and
• after conclusive rollback, state exactly what binding evidence survives, how any originally trusted fields are recovered, and what happens when no original binding is durably provable. Never reconstruct a trusted timestamp from caller memory or claim an original digest that cannot be proven.

The candidate must choose and document these rules, not defer them to schema or database implementation. Solve them without introducing an approval reservation, a portable precommitted authorization decision, or a second authoritative effect intent. Preserve PR #23's distinction between assertion time, receipt/synchronization time, authorization time, and commit time.

D. One short guarded protected-effect transaction

Bind the exact immutable transaction-policy identity/digest and its trusted time source, deadline calculation, atomic persistence boundary, snapshot proof, isolation/commit-guard mode, and authoritative status-lookup mechanism. The caller cannot choose or extend these values.

Within the transaction, re-resolve current principal/session, representation, applicable CP3 evidence, authority sources, revocations, policy/rule bindings, resources, evidence, scope, sovereignty, target and protected-effect state, and every other applicable EnforcementChain input.

A read snapshot alone is insufficient. Guard the complete relevant read/write set, including negative and set-valued facts such as absence of revocation and absence of an existing prospective result. Guard coverage must be explicit; locking only positive grant records is insufficient.

Compute decisionValidUntil using PR #11's exact cutoff function, including the trusted transaction deadline. Enforce the exclusive cutoffs through successful commit. Do not invent a universal wall-clock duration or claim that an undocumented isolation level satisfies the guard.

The ordered protocol must obtain the truthful final authorization result, validate all applicable non-authorization gates, validate the exact domain handoff, construct the complete success set, and recheck deadlines, uniqueness, and state guards before atomic commit. Inapplicable gates must not be reported as passed.

E. Exact handoff and atomic success set

Require the rule-bound protected-effect contract identity/version/digest, contract-owned result-schema binding, complete proposed result bytes/digest, mapping/postcondition trace, required immutable state inputs, absence guards, and overall passing disposition.

The transaction coordinator verifies that handoff and commits the validated bytes. It does not reinterpret AssertionRecord fields or create unbound companion effects.

The successful commit atomically includes the operation binding and required transaction evidence, final authorization request/result/full internal trace and bundle digest, mode-correct NOT_REQUIRED evidence, exactly one decision-consumption record, the exact protected result, protected-effect and other applicable gate traces, and exactly one governed-effect receipt identifying the complete set.

No protected effect becomes visible without all required matching success evidence. Consumption becomes durable only with successful commit. Mutable coordination rows may support the protocol but cannot replace immutable operation, attempt, consumption, or receipt evidence as the surviving audit account.

F. Failure evidence is not successful effect evidence

Define EFFECT_COMMITTED, NO_EFFECT, and OUTCOME_UNKNOWN as transaction outcomes through the compatibility ledger, not authorization outcomes or new public RuntimeProblem codes.

The candidate must state the exact PR #11 §18.1/admission step at which a durable logical-operation binding first exists. An ingress rejection before that point may lack the authenticated principal, action class, or complete idempotency tuple and therefore has no logical-operation lifecycle consequence.

Condition	Required posture	Required lifecycle consequence
Malformed request, invalid intent, or invalid ingress binding	Follow PR #11's ingress-rejection rules; do not fabricate a validated authorization result. No protected effect or consumption.	Before the durable operation-binding point, NO_OPERATION_CONSEQUENCE. After that point, the candidate must assign the exact conclusive attempt consequence or unresolved posture supported by the evidence.
Schema-valid non-ALLOW authorization	Preserve the truthful request/result/internal-trace refusal bundle under PR #11 §18.7. No protected effect, successful finalization evidence, consumption, or success receipt.	A conclusively committed refusal is NO_EFFECT and receives exactly one immutable attempt consequence from the lifecycle matrix.
Authorization ALLOW, followed by domain or another gate failure	Preserve the authority-gate conclusion. No protected effect or consumption. Any durably retained failure-attempt evidence is explicitly non-consumable and cannot later be upgraded in place.	A conclusively committed no-effect failure receives exactly one immutable attempt consequence from the lifecycle matrix.
Transaction failure with proven rollback	NO_EFFECT; any later execution attempt obtains a new transaction-bound evaluation and repeats all current checks. Do not reuse the failed attempt's decision as authority.	If no durable attempt consequence committed, the prior authoritative operation state controls. If conclusive no-effect evidence committed separately, it receives exactly one immutable attempt consequence.
Failure-evidence persistence fails	Fail closed without claiming a durable rejection, refusal, or attempt record that did not commit.	NO_NEW_CONSEQUENCE; prior authoritative operation evidence controls. If no durable operation binding exists, no logical-operation retry claim exists.
Commit outcome is uncertain	OUTCOME_UNKNOWN; block reapplication pending authoritative reconciliation.	No NO_EFFECT consequence is recorded for that attempt. The derived operation state is BLOCKED_PENDING_RECONCILIATION and names the exact unresolved attempt or fact.
Only part of the required success set exists	Invariant breach; quarantine for separately governed repair. No automatic evidence synthesis, deletion, or effect replay.	No fabricated NO_EFFECT consequence. The operation is quarantined and blocked under the exact partial-set evidence.

Every conclusively proven durable NO_EFFECT attempt under an existing logical operation records exactly one immutable attempt consequence:

• RETRYABLE_SAME_OPERATION; or
• TERMINAL_REQUIRES_NEW_OPERATION_KEY.

Equivalent final names are acceptable, but the candidate must assign exact semantics and one consequence to every durable failure class. An OUTCOME_UNKNOWN attempt records neither value. BLOCKED_PENDING_RECONCILIATION is a separately derived operation-level reapplication state, not an immutable NO_EFFECT attempt consequence.

For RETRYABLE_SAME_OPERATION, the earlier attempt and evidence remain immutable, the operation binding and original trusted intent facts remain fixed, a new transaction attempt obtains a fresh current authorization decision, the earlier decision is never reused or consumed, and at most one attempt may eventually commit the protected effect.

For TERMINAL_REQUIRES_NEW_OPERATION_KEY, a later submission requires a new caller key and cannot masquerade as a retry. A mode change away from the operation's bound NOT_REQUIRED value always has this terminal consequence.

The candidate must define immutable attempt ordering and one deterministic admission view when attempts disagree. At minimum: an existing matching successful receipt makes the operation complete; a partial success set quarantines it; any unresolved attempt blocks reapplication while naming that attempt; otherwise the most recent conclusively ordered durable NO_EFFECT consequence controls whether another attempt may begin.

The lifecycle matrix must cover at least committed DENY, committed REQUIRE_REVIEW, authorization ALLOW followed by a committed non-consumable domain failure, a deterministic invalid protected result, a transient infrastructure failure with conclusive no-effect evidence, failure-evidence persistence failure, and failures before versus after durable operation admission.

Absence of a receipt from a cache, replica, timed-out lookup, or incomplete result is not proof of rollback. A failure to write audit evidence does not establish that an earlier uncertain effect failed.

G. Retry, concurrency, and receipt disclosure

Enforce at most one successful receipt and one successful write-decision consumption per logical operation, at most one consumption of each decision, and one immutable byte sequence for every committed result identity. Application-level check-then-insert without an atomic uniqueness or commit guard is insufficient.

An exact retry after success resolves the original decision/result/receipt identities and digests without rebuilding the effect or consuming the write decision again. Matching concurrent duplicates converge on that same committed result. Conflicting operation or result content cannot borrow the winner's receipt as its own success.

Reconciliation verifies the complete matching success set and transaction status. Only authoritative complete success or conclusive rollback resolves uncertainty. A new transaction attempt may not apply the effect while an earlier attempt remains unresolved.

Receipt lookup is not blanket disclosure authority. Authenticate the requester and scope the lookup before exposing operation information. Apply PR #11's existing safe-response, trace, and disclosure rules to returned content. A caller key is not a read credential. Preserve the original historical result internally even when current permissions require withholding or redacting the response; do not re-execute the completed write to retrieve it. Any separately required read authorization remains a separate action, not another consumption of the original write decision.

6. First concrete handoff: ASSERT_OPERATION_CLAIM

Consume PR #23's exact contract ofarm.protectedeffect.assertionrecord.submit.v0.1, with the operation branch of the future ofarm.assertionrecord.v0.2 carrier.

Preserve the exact mapping:

ASSERT_OPERATION_CLAIM
  → EI_OPERATION_ASSERTION_V0_2
  → authorization effect-subject kind OPERATION_ASSERTION
  → AssertionRecord assertionType OPERATION_CLAIM_ASSERTION
  → claimState PENDING_REVIEW
  → record commit class: operation claim (OPERATION_CLAIM)

The asserted Party remains the selected authority subject. The alleged performer remains separate, and performer authority remains NOT_EVALUATED_BY_AUTHORIZATION. Preserve the contract's online/offline assertion-act rules, intended/performed subject-time profiles, exact body/evidence bindings, and conditional correction-lineage checks.

The transaction provides the trusted starting-snapshot proof and state guards required by that handoff; it does not redefine the correction predicate. Optional semantic-event association remains owned and validated as specified by PR #23 and Event Ingress. Do not derive an event family from the assertion subtype.

No accepted execution, review, current-state materialization, prior-record mutation, or implicit companion effect is admitted. Other state-affecting NOT_REQUIRED actions remain unsupported until their own approved contracts and exact transaction bindings exist.

7. Required falsifiable cases

The Phase A candidate must give an explicit expected disposition for each case. These are obligations for later executable conformance, not a claim that runtime tests ran in this documentation PR.

Case	Required result
Eligible initial operation claim	One complete atomic success set; one pending-review assertion.
Exact retry after commit, including lost response	Original authoritative IDs, digests, assertedAt, result, and receipt; no second write consumption/effect.
Identical online submissions with the same authoritative idempotency tuple arrive concurrently at different receipt times	One authoritative trusted intent binding and one success; no artificial conflict caused solely by independently generated timestamps.
Same scoped key with changed caller content, effect schema, mode, or proposed result	Earlier operation is discovered; conflict/reconciliation as applicable, never a new hidden namespace.
Durable NO_EFFECT under NOT_REQUIRED, followed by a current rule selecting FRESH_HUMAN_APPROVAL_REQUIRED or another mode, then retry with the same caller key	Discover the earlier operation and return TERMINAL_REQUIRES_NEW_OPERATION_KEY; do not enter either profile under the old key.
Retry recomputes the full operation digest from a new runtime-generated timestamp	Conflict logic uses the stored caller-owned projection and recovers the bind-once full digest and first-admitted assertedAt; no artificial conflict.
Caller supplies an online assertion timestamp or substitutes cached binding evidence	Cannot create trusted time or override the stored operation.
Verified offline assertion has distinct assertion, receipt, and commit times	Preserve each governed time and its evidence; no fabricated human-finalization artifacts.
Human-required rule is routed to this profile, or approval artifacts are inserted	Admission/profile failure; no protected effect or consumption.
Revocation is inserted after lookup, or a relevant resource/evidence/policy/state input changes before commit	Complete guard blocks stale success, including negative/set-valued facts.
Deadline or decision validity reaches its exclusive cutoff at commit	No successful commit claim.
Result bytes, result schema, contract binding, or trace are substituted	Handoff/integrity failure; no effect or consumption.
Domain validation fails after authorization ALLOW	Preserve ALLOW as the authority-gate result; truthful non-consumable failure evidence only.
Committed DENY, followed by an authority change and retry	Apply the declared durable NO_EFFECT consequence; never reuse the earlier decision or silently choose between cached denial and fresh evaluation. If retry is permitted, recover the original first-admitted assertedAt and obtain a fresh current decision.
Committed REQUIRE_REVIEW, followed by retry	Apply the declared durable NO_EFFECT consequence; no protected effect and no reuse of the earlier decision.
Authorization ALLOW plus committed non-consumable domain failure, followed by retry	Apply the declared durable NO_EFFECT consequence; preserve the earlier attempt and evidence immutably and never treat them as consumption or effect.
Deterministically invalid protected-result bytes are retried unchanged	The declared consequence prevents an indefinite retry loop; no protected effect or consumption.
Transient infrastructure failure has conclusive durable no-effect evidence	Follow the declared retryability; any permitted retry uses fresh current evaluation and never reuses the earlier decision.
Idempotency keys differ only by case, trailing space, Unicode representation, or punctuation	The bound canonical profile produces one deterministic validation and equality result without implementation-local normalization.
Retention or governed deletion removes bulky evidence while an operation, effect, receipt, unresolved attempt, replay obligation, or historical binding remains reachable	A durable binding or tombstone preserves conflict detection and the caller-key tuple cannot be rebound.
Valid request is refused, or refusal-evidence persistence fails	Required refusal evidence survives when committed; otherwise no false durable-refusal claim.
Malformed or invalid ingress fails before the durable operation-binding point	Record only the truthful ingress rejection permitted by PR #11; no logical-operation lifecycle consequence is invented.
Failure-evidence persistence fails after a proven rollback	Record no new durable consequence; prior authoritative operation evidence controls and no failed write is claimed to exist.
One attempt is conclusively NO_EFFECT while a different attempt remains unresolved	Keep the conclusive attempt's immutable consequence, derive the operation as BLOCKED_PENDING_RECONCILIATION, and identify the separate unresolved attempt.
Conclusive rollback followed by retry	Apply the explicit surviving-binding rule and repeat every current check with a new transaction-bound decision.
Commit status is ambiguous or receipt lookup is stale/incomplete	Remain blocked from reapplication.
Partial success set is visible	Quarantine; no automatic synthesis, deletion, or replay.
Receipt retry occurs after disclosure permissions change	Preserve historical success and prevent duplicate execution while applying current safe disclosure rules.
Unapproved effect family or governed-read action attempts to use this state-affecting profile	Unsupported; no inferred transaction support.

Later executable tests must enter through the real admission, authorization, protected-effect, persistence, and reconciliation paths. Helper-only tests do not establish the protocol claim.

8. Non-goals and stop conditions

No authorization-matrix/action-class change; no change to PR #20's human-finalization modes; no AssertionRecord or Event Grammar redesign; no accepted-law, schema, currentness, or runtime edits in Phase A.

No generic workflow engine, separate authorization registry, portable decision cache, new domain truth store, external dispatch, public reason-code invention, retention/encryption/key-custody policy, database authority, administrative repair, break-glass authorization, or production-readiness claim.

Outcome reconciliation belongs here. Database recovery and repair execution do not.

Stop and split before changing a pinned dependency's semantics, introducing another trust boundary, inventing missing domain/evidence/time-trust law, creating machine schemas in the candidate PR, or implementing OFARM2 behavior before canonical promotion and extraction. Exposing a missing prerequisite is acceptable; silently filling it in or marking it closed is not.

9. Staged delivery and completion gate

1. Prepare the one-file non-authoritative Phase A candidate.
2. Obtain source-verified review and explicit semantic approval at its exact head.
3. Separately materialize non-default transaction/evidence profiles and the required domain/shared-evidence prerequisites.
4. Review exact content-addressed bindings and perform any accepted-law step in the sequence governed by PR RFC candidate: executable authorization evidence v0.2 #11; the eventual accepted-law text must name Define the NOT_REQUIRED atomic transaction and single-use consumption profile #25 alongside Define governed human-approval transaction and consumption protocol #19 for the NOT_REQUIRED transaction-bound rows. Do not edit the historical approved PR RFC candidate: executable authorization evidence v0.2 #11 candidate in this Phase A PR, and candidate approval alone performs none of this step.
5. Complete the required hostile conformance and record its evidence without overstating what is exercised.
6. Change current/default selections only through a separate steward-approved promotion.
7. Extract promoted canonical bytes into OFARM2, verify digests, then undertake separately reviewable runtime work.

Phase A is complete only when every requirement above has a closed proposed disposition, the exact dependency heads remain approved, the compatibility ledger and steward approval card are explicit, and no required semantic choice is left to schema or runtime authors. Unresolved choices remain named blockers to approval.

The completion gate specifically includes the exact NO_EFFECT versus OUTCOME_UNKNOWN separation, deterministic operation-level admission precedence, the mode-change terminal rule, failure classes with no operation consequence, the caller-projection conflict oracle and bind-once full digest, first-admitted assertion-act identity, evidence-profile ownership table, idempotency-key grammar and equality, the no-unsafe-forgetting invariant, and their production-reachable cases.

10. Verification for the candidate PR

Required checks:

git diff --check
python3 package_meta/tools/run_repository_validation_suite.py

Also verify GitHub generated-currentness and repository-validation, exact dependency heads and source sections, one changed candidate file, and no active/current contract changes. Report actual results at the reviewed head; do not infer semantic correctness from a green repository suite.

Source anchors for the review-sensitive requirements:

• PR #11 pinned authorization candidate: §§7, 8, 17, 18.2, 18.4–18.8, and 24.
• PR #20 pinned transaction candidate: §§5.1, 6, 10, and 13–18; reuse only through the explicit compatibility ledger.
• PR #23 pinned AssertionRecord candidate: §§5.5, 6.2–6.5, 7–12, and 18.

Next action: draft the one-file candidate against this specification and request exact-head semantic review. Keep it non-authoritative; do not merge, promote, materialize schemas, or start OFARM2 runtime implementation on the strength of this comment.

[samovers]

Proposed replacement specification for issue #25

This is proposed issue text for Phase A drafting, incorporating the review findings. It is not semantic approval, accepted law, machine-contract materialization, current/default promotion, or authorization to implement OFARM2.

Define the NOT_REQUIRED atomic transaction and single-use consumption profile

Parent: #10
Related: #12, #21, #22
Downstream runtime work: samovers/OFARM2#353, samovers/OFARM2#178, samovers/OFARM2#176
Runtime UnitOfWork foundation: samovers/OFARM2#173

1. Outcome

Define the canonical transaction protocol for a state-affecting action whose immutable action rule selects humanFinalizationRequirement = NOT_REQUIRED.

The first concrete handoff is ASSERT_OPERATION_CLAIM: one eligible submission creates exactly one immutable PENDING_REVIEW AssertionRecord, together with its complete authorization, transaction, validation, consumption, and receipt evidence, in one short guarded protected-effect transaction.

An exact retry must discover the original operation rather than create another claim. Lost responses and concurrent duplicates must not cause another protected effect or another consumption of the write decision. A conclusively rolled-back attempt may proceed only through fresh current evaluation. An uncertain commit blocks reapplication until authoritative reconciliation resolves it.

Atomicity applies to the successful effect set, not to the erasure of failure evidence. The complete successful set commits together or none of its successful components becomes visible. Truthful ingress-rejection, authorization-refusal, and non-consumable failure-attempt evidence follow their separately defined persistence rules.

No human approval step is fabricated. No successful submission becomes accepted execution, a ReviewDecision, current state, or another implied domain effect.

2. Exact Phase A dependencies

These candidates have semantic approval at the following exact heads but remain draft and non-authoritative:

Owner	Exact approved head	Relevant closure
Authorization PR #11	03a21f669ee04f96d444e14f00ae7212cab04803	rule selection, principal/representation and CP3 posture, authority evaluation, NOT_REQUIRED, TRANSACTION_BOUND_V0_2, SINGLE_USE, decisionValidUntil, refusal evidence, and disclosure limits
Human-finalization transaction PR #20	98f8c4fafbae42c8f7fd931f43f53adcb4733713	compatible transaction, idempotency, consumption, and reconciliation concepts; its applicability remains limited to fresh approval and direct human action
AssertionRecord protected-effect PR #23	622376e2998cf8b3954ca19e81d2cce6fd57e5fe	assertion-submission mappings, trusted assertion-act time/provenance, postconditions, and exact result/trace handoff

PR #20 explicitly excludes NOT_REQUIRED. PR #23 therefore leaves operation-claim execution blocked on this separate transaction profile.

Any semantic change to a pinned dependency requires renewed dependency review. Neither the pins nor this issue override active authority. Apply the repository order: 00_active_baseline/, then 02_accepted_rfcs/, then 01_companion_artifacts/, then 03_machine_contracts/.

3. Primary trust boundary and Phase A PR boundary

Primary trust boundary: transaction admission, guarded ordering, atomic success, single-use consumption, retry identity, and authoritative outcome reconciliation for NOT_REQUIRED state-affecting actions.

Create one non-authoritative candidate file:

package_meta/history/clean_baseline_migration/phase_reports/not_required_transaction_and_consumption_protocol_rfc_candidate_v0_1.md

The candidate must contain the proposed protocol, exact operation-binding rules, compatibility ledger, failure matrix, first operation-claim handoff, falsifiable cases, traceability, and steward approval card.

Change classification: proposed RFC extension, with later machine-contract and implementation/conformance implications. No active-baseline file is affected by this Phase A PR. In particular, do not edit the Constitution or Platform Runtime architecture.

This PR changes no accepted RFC, companion policy, machine schema, current/default selection, runtime code, database implementation, or readiness claim.

4. Ownership and compatibility ledger

PR #11 remains the owner of authorization meaning. PR #23 remains the owner of AssertionRecord meaning. This issue coordinates their exact handoffs; it does not create a second authorization evaluator or duplicate domain mappings.

Include an explicit compatibility ledger against PR #20, distinguishing:

• compatible concepts adopted here: stable idempotency lookup scope, operation-digest conflict detection, trusted transaction inputs, complete commit guards, successful-consumption uniqueness, truthful failure outcomes, and uncertain-commit reconciliation;
• mode-specific concepts not applicable here: approval reservation/generation, challenge, intended approver, human-finalization act, approval, approval consumption, and direct-human finalization evidence; and
• the new NOT_REQUIRED transaction/evidence profile and its exact relationship to the shared evidence package.

Adoption of compatible concepts does not widen PR #20's applicability. Its existing human-finalization profiles remain unchanged.

OFARM2 #173 owns runtime UnitOfWork foundations, #178 owns command-idempotency implementation, and #353 owns authorization-evaluator implementation. Those issues must consume promoted canonical meaning rather than invent it.

5. Required semantic closure

A. Rule-selected admission and mode-correct evidence

Admit a new execution attempt only when the immutable current action rule selects NOT_REQUIRED, the action is state-affecting, and the exact protected-effect contract and transaction profile are validly bound. RECEIVE_READ_DATA is not admitted merely because it also uses NOT_REQUIRED; its separately owned governed-read protocol remains unchanged.

A caller cannot select, downgrade, or substitute the mode. Missing, mutable, unsupported, or digest-invalid bindings fail closed.

Create no approval reservation, challenge, intended-approver record, human-finalization-act record, approval, approval consumption, reservation terminal record, or direct-human finalization evidence. Inapplicable fields are absent, not synthetic values, empty objects, or fabricated proof.

This restriction does not prohibit natural-person submission or erase AssertionRecord-domain assertion-act provenance. In particular, PR #23's VERIFIED_OFFLINE_SUBMISSION may require immutable assertion-act evidence even though no human approval is required for transaction finalization. Preserve that distinction explicitly.

Define the exact NOT_REQUIRED evidence truth claim, its placement in the transaction sequence, its immutable bindings, and its owner within the proposed shared AuthorizationFinalizationEvidence v0.2 package. It must record the rule-selected absence of a human-finalization requirement without pretending that an approval occurred.

B. Separate the lookup key from the operation digest

Use this authoritative idempotency lookup scope, compatible with PR #20 §6.2:

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

The rule-selected mode, effect-intent schema, effect-intent digest, result digest, and transaction-profile version must not create extra lookup namespaces that allow the same tuple to evade its earlier operation.

Separately define the exact canonical operationBindingDigest over the complete logical-operation binding, including the tuple, immutable requester and applicable representation bindings, rule-selected mode, effect-intent schema binding, and exact effectIntentDigest. Close the object shape, required absence/null posture, canonicalization, and digest construction in the candidate; do not leave them to runtime authors.

The same tuple identifies one logical operation. The same tuple with changed bound operation content is a conflict, not a second operation. Result substitution must also be detected against the exact admitted or committed result binding; result digests are not lookup-key dimensions.

Lookup and conflict detection must work across relevant transaction handlers/profiles. A later governed mode or schema change cannot hide an earlier success or unresolved attempt. Discover/reconcile the earlier operation before deciding whether the retry conflicts. A deliberately new operation requires a new caller key.

C. Preserve trusted intent enrichment across retries

Close the admission order between stable-key lookup, comparison of caller-owned submission content, trusted runtime completion of the intent, intent validation/digest calculation, and current execution evaluation.

PR #23 §6.2 requires the runtime to supply assertedAt for TRUSTED_ONLINE_SUBMISSION before intent validation and hashing. Therefore:

• for an existing committed or unresolved operation, recover its authoritative runtime-completed intent and trusted timestamp binding before comparing retry digests; do not generate a new timestamp and misclassify the identical caller submission as changed intent;
• a caller-provided timestamp, digest, receipt, or cached response cannot substitute for authoritative stored evidence;
• define an exact comparison/projection for the retried caller-owned content and its relationship to the full immutable intent; this comparison cannot omit a caller field that changes the operation, weaken full-intent hashing, or become a second source of authorization facts;
• concurrent identical submissions must resolve to one authoritative operation binding; independently generated timestamps must not turn identical submissions into artificial payload conflicts; and
• after conclusive rollback, state exactly what binding evidence survives, how any originally trusted fields are recovered, and what happens when no original binding is durably provable. Never reconstruct a trusted timestamp from caller memory or claim an original digest that cannot be proven.

The candidate must choose and document these rules, not defer them to schema or database implementation. Solve them without introducing an approval reservation, a portable precommitted authorization decision, or a second authoritative effect intent. Preserve PR #23's distinction between assertion time, receipt/synchronization time, authorization time, and commit time.

D. One short guarded protected-effect transaction

Bind the exact immutable transaction-policy identity/digest and its trusted time source, deadline calculation, atomic persistence boundary, snapshot proof, isolation/commit-guard mode, and authoritative status-lookup mechanism. The caller cannot choose or extend these values.

Within the transaction, re-resolve current principal/session, representation, applicable CP3 evidence, authority sources, revocations, policy/rule bindings, resources, evidence, scope, sovereignty, target and protected-effect state, and every other applicable EnforcementChain input.

A read snapshot alone is insufficient. Guard the complete relevant read/write set, including negative and set-valued facts such as absence of revocation and absence of an existing prospective result. Guard coverage must be explicit; locking only positive grant records is insufficient.

Compute decisionValidUntil using PR #11's exact cutoff function, including the trusted transaction deadline. Enforce the exclusive cutoffs through successful commit. Do not invent a universal wall-clock duration or claim that an undocumented isolation level satisfies the guard.

The ordered protocol must obtain the truthful final authorization result, validate all applicable non-authorization gates, validate the exact domain handoff, construct the complete success set, and recheck deadlines, uniqueness, and state guards before atomic commit. Inapplicable gates must not be reported as passed.

E. Exact handoff and atomic success set

Require the rule-bound protected-effect contract identity/version/digest, contract-owned result-schema binding, complete proposed result bytes/digest, mapping/postcondition trace, required immutable state inputs, absence guards, and overall passing disposition.

The transaction coordinator verifies that handoff and commits the validated bytes. It does not reinterpret AssertionRecord fields or create unbound companion effects.

The successful commit atomically includes the operation binding and required transaction evidence, final authorization request/result/full internal trace and bundle digest, mode-correct NOT_REQUIRED evidence, exactly one decision-consumption record, the exact protected result, protected-effect and other applicable gate traces, and exactly one governed-effect receipt identifying the complete set.

No protected effect becomes visible without all required matching success evidence. Consumption becomes durable only with successful commit. Mutable coordination rows may support the protocol but cannot replace immutable operation, attempt, consumption, or receipt evidence as the surviving audit account.

F. Failure evidence is not successful effect evidence

Define EFFECT_COMMITTED, NO_EFFECT, and OUTCOME_UNKNOWN as transaction outcomes through the compatibility ledger, not authorization outcomes or new public RuntimeProblem codes.

Condition	Required posture
Malformed request, invalid intent, or invalid ingress binding	Follow PR #11's ingress-rejection rules; do not fabricate a validated authorization result. No protected effect or consumption.
Schema-valid non-ALLOW authorization	Preserve the truthful request/result/internal-trace refusal bundle under PR #11 §18.7. No protected effect, successful finalization evidence, consumption, or success receipt.
Authorization ALLOW, followed by domain or another gate failure	Preserve the authority-gate conclusion. No protected effect or consumption. Any durably retained failure-attempt evidence is explicitly non-consumable and cannot later be upgraded in place.
Transaction failure with proven rollback	NO_EFFECT; any later execution attempt obtains a new transaction-bound evaluation and repeats all current checks. Do not reuse the failed attempt's decision as authority.
Failure-evidence persistence fails	Fail closed without claiming a durable rejection, refusal, or attempt record that did not commit.
Commit outcome is uncertain	OUTCOME_UNKNOWN; block reapplication pending authoritative reconciliation.
Only part of the required success set exists	Invariant breach; quarantine for separately governed repair. No automatic evidence synthesis, deletion, or effect replay.

Absence of a receipt from a cache, replica, timed-out lookup, or incomplete result is not proof of rollback. A failure to write audit evidence does not establish that an earlier uncertain effect failed.

G. Retry, concurrency, and receipt disclosure

Enforce at most one successful receipt and one successful write-decision consumption per logical operation, at most one consumption of each decision, and one immutable byte sequence for every committed result identity. Application-level check-then-insert without an atomic uniqueness or commit guard is insufficient.

An exact retry after success resolves the original decision/result/receipt identities and digests without rebuilding the effect or consuming the write decision again. Matching concurrent duplicates converge on that same committed result. Conflicting operation or result content cannot borrow the winner's receipt as its own success.

Reconciliation verifies the complete matching success set and transaction status. Only authoritative complete success or conclusive rollback resolves uncertainty. A new transaction attempt may not apply the effect while an earlier attempt remains unresolved.

Receipt lookup is not blanket disclosure authority. Authenticate the requester and scope the lookup before exposing operation information. Apply PR #11's existing safe-response, trace, and disclosure rules to returned content. A caller key is not a read credential. Preserve the original historical result internally even when current permissions require withholding or redacting the response; do not re-execute the completed write to retrieve it. Any separately required read authorization remains a separate action, not another consumption of the original write decision.

6. First concrete handoff: ASSERT_OPERATION_CLAIM

Consume PR #23's exact contract ofarm.protectedeffect.assertionrecord.submit.v0.1, with the operation branch of the future ofarm.assertionrecord.v0.2 carrier.

Preserve the exact mapping:

ASSERT_OPERATION_CLAIM
  → EI_OPERATION_ASSERTION_V0_2
  → authorization effect-subject kind OPERATION_ASSERTION
  → AssertionRecord assertionType OPERATION_CLAIM_ASSERTION
  → claimState PENDING_REVIEW
  → record commit class: operation claim (OPERATION_CLAIM)

The asserted Party remains the selected authority subject. The alleged performer remains separate, and performer authority remains NOT_EVALUATED_BY_AUTHORIZATION. Preserve the contract's online/offline assertion-act rules, intended/performed subject-time profiles, exact body/evidence bindings, and conditional correction-lineage checks.

The transaction provides the trusted starting-snapshot proof and state guards required by that handoff; it does not redefine the correction predicate. Optional semantic-event association remains owned and validated as specified by PR #23 and Event Ingress. Do not derive an event family from the assertion subtype.

No accepted execution, review, current-state materialization, prior-record mutation, or implicit companion effect is admitted. Other state-affecting NOT_REQUIRED actions remain unsupported until their own approved contracts and exact transaction bindings exist.

7. Required falsifiable cases

The Phase A candidate must give an explicit expected disposition for each case. These are obligations for later executable conformance, not a claim that runtime tests ran in this documentation PR.

Case	Required result
Eligible initial operation claim	One complete atomic success set; one pending-review assertion.
Exact retry after commit, including lost response	Original authoritative IDs, digests, assertedAt, result, and receipt; no second write consumption/effect.
Identical online submissions arrive concurrently at different receipt times	One authoritative trusted intent binding and one success; no artificial conflict caused solely by independently generated timestamps.
Same scoped key with changed caller content, effect schema, mode, or proposed result	Earlier operation is discovered; conflict/reconciliation as applicable, never a new hidden namespace.
Caller supplies an online assertion timestamp or substitutes cached binding evidence	Cannot create trusted time or override the stored operation.
Verified offline assertion has distinct assertion, receipt, and commit times	Preserve each governed time and its evidence; no fabricated human-finalization artifacts.
Human-required rule is routed to this profile, or approval artifacts are inserted	Admission/profile failure; no protected effect or consumption.
Revocation is inserted after lookup, or a relevant resource/evidence/policy/state input changes before commit	Complete guard blocks stale success, including negative/set-valued facts.
Deadline or decision validity reaches its exclusive cutoff at commit	No successful commit claim.
Result bytes, result schema, contract binding, or trace are substituted	Handoff/integrity failure; no effect or consumption.
Domain validation fails after authorization ALLOW	Preserve ALLOW as the authority-gate result; truthful non-consumable failure evidence only.
Valid request is refused, or refusal-evidence persistence fails	Required refusal evidence survives when committed; otherwise no false durable-refusal claim.
Conclusive rollback followed by retry	Apply the explicit surviving-binding rule and repeat every current check with a new transaction-bound decision.
Commit status is ambiguous or receipt lookup is stale/incomplete	Remain blocked from reapplication.
Partial success set is visible	Quarantine; no automatic synthesis, deletion, or replay.
Receipt retry occurs after disclosure permissions change	Preserve historical success and prevent duplicate execution while applying current safe disclosure rules.
Unapproved effect family or governed-read action attempts to use this state-affecting profile	Unsupported; no inferred transaction support.

Later executable tests must enter through the real admission, authorization, protected-effect, persistence, and reconciliation paths. Helper-only tests do not establish the protocol claim.

8. Non-goals and stop conditions

No authorization-matrix/action-class change; no change to PR #20's human-finalization modes; no AssertionRecord or Event Grammar redesign; no accepted-law, schema, currentness, or runtime edits in Phase A.

No generic workflow engine, separate authorization registry, portable decision cache, new domain truth store, external dispatch, public reason-code invention, retention/encryption/key-custody policy, database authority, administrative repair, break-glass authorization, or production-readiness claim.

Outcome reconciliation belongs here. Database recovery and repair execution do not.

Stop and split before changing a pinned dependency's semantics, introducing another trust boundary, inventing missing domain/evidence/time-trust law, creating machine schemas in the candidate PR, or implementing OFARM2 behavior before canonical promotion and extraction. Exposing a missing prerequisite is acceptable; silently filling it in or marking it closed is not.

9. Staged delivery and completion gate

1. Prepare the one-file non-authoritative Phase A candidate.
2. Obtain source-verified review and explicit semantic approval at its exact head.
3. Separately materialize non-default transaction/evidence profiles and the required domain/shared-evidence prerequisites.
4. Review exact content-addressed bindings and perform any accepted-law step in the sequence governed by PR RFC candidate: executable authorization evidence v0.2 #11; candidate approval alone performs none of it.
5. Complete the required hostile conformance and record its evidence without overstating what is exercised.
6. Change current/default selections only through a separate steward-approved promotion.
7. Extract promoted canonical bytes into OFARM2, verify digests, then undertake separately reviewable runtime work.

Phase A is complete only when every requirement above has a closed proposed disposition, the exact dependency heads remain approved, the compatibility ledger and steward approval card are explicit, and no required semantic choice is left to schema or runtime authors. Unresolved choices remain named blockers to approval.

10. Verification for the candidate PR

Required checks:

git diff --check
python3 package_meta/tools/run_repository_validation_suite.py

Also verify GitHub generated-currentness and repository-validation, exact dependency heads and source sections, one changed candidate file, and no active/current contract changes. Report actual results at the reviewed head; do not infer semantic correctness from a green repository suite.

Source anchors for the review-sensitive requirements:

• PR #11 pinned authorization candidate: §§7, 8, 17, 18.2, 18.4–18.8, and 24.
• PR #20 pinned transaction candidate: §§5.1, 6, 10, and 13–18; reuse only through the explicit compatibility ledger.
• PR #23 pinned AssertionRecord candidate: §§5.5, 6.2–6.5, 7–12, and 18.

Next action: draft the one-file candidate against this specification and request exact-head semantic review. Keep it non-authoritative; do not merge, promote, materialize schemas, or start OFARM2 runtime implementation on the strength of this comment.

[samovers]

Re-review disposition: request two bounded changes

The revised issue body now incorporates the earlier review: it separates lookup identity from the operation digest, addresses trusted assertedAt handling, distinguishes successful atomicity from failure evidence, preserves disclosure controls, and correctly limits the first handoff to a pending-review operation claim. The primary boundary is now coherent.

Two executable lifecycle decisions remain insufficiently closed.

1. Blocker — retries after a durably committed NO_EFFECT attempt are undefined

The issue covers:

• retry after successful commit;
• retry after conclusive transaction rollback;
• blocking after OUTCOME_UNKNOWN; and
• persistence of non-ALLOW and domain-gate failure evidence.

It does not decide what happens after an attempt durably commits failure evidence but no effect, for example:

operation binding + authorization DENY + refusal trace committed

or:

operation binding + authorization ALLOW + domain-gate failure committed

These are not successful operations, but they are also not rolled-back attempts. The candidate therefore still has an unresolved choice:

1. Is the logical operation terminal, requiring a new caller key?
2. May the same logical operation receive another transaction attempt after current re-evaluation?
3. Which failure classes are retryable, and which are permanent conflicts?
4. If retry is permitted, are the original trusted intent and assertedAt reused, or does retry represent a new assertion act?

Leaving this implicit can produce incompatible runtimes. One may permanently cache the first denial; another may re-evaluate it. A third may generate a new assertedAt, change the operation digest, and report a retry conflict.

Smallest patch: require an immutable attempt lifecycle under the stable logical operation. For every durable NO_EFFECT class, the candidate must state one exact consequence:

RETRYABLE_SAME_OPERATION
TERMINAL_REQUIRES_NEW_OPERATION_KEY
BLOCKED_PENDING_RECONCILIATION

Equivalent names are fine. The semantics are what matter.

For a retryable same operation:

• the previous attempt and its evidence remain immutable;
• the operation binding and original trusted intent facts remain fixed;
• a new transaction attempt gets a fresh current authorization decision;
• the prior decision is never reused or consumed; and
• at most one attempt may eventually commit the protected effect.

For a terminal attempt, a later submission requires a new caller key and must not masquerade as a retry.

Add production-reachable cases for:

• committed DENY, followed by an authority change and retry;
• committed REQUIRE_REVIEW, followed by retry;
• authorization ALLOW plus committed non-consumable domain failure, followed by retry;
• deterministic invalid protected result, where retrying identical bytes must not loop indefinitely; and
• transient infrastructure failure with conclusive no-effect evidence.

PR #20 already treats attempt outcomes, successful consumption, and retry eligibility as distinct concepts; the new profile should preserve that distinction without importing its human-finalization states.

2. Blocker — idempotency-key equality and safe forgetting are not closed

The issue now defines the correct lookup tuple and says one tuple identifies one logical operation. It does not define:

• the lexical/value profile of operationIdempotencyKey;
• whether equality is byte-exact or code-point-exact;
• whether trimming, case folding, Unicode normalization, collation, or punctuation reinterpretation is forbidden;
• what identity evidence must survive retention or governed deletion; or
• whether an expired or deleted key may ever be rebound.

Without those rules, independent runtimes can disagree on whether these keys are equal:

claim-17
Claim-17
claim-17␠
Unicode-normalized variants

More seriously, deleting the operation-binding row while retaining the AssertionRecord or receipt could allow the same key to create a second effect.

Smallest patch: require the Phase A candidate to either reference an accepted canonical identifier profile or define the exact key grammar and equality semantics. Do not silently import an OFARM2 implementation convention as canonical law.

Also add this invariant:

Retention or governed deletion may remove bulky evidence only when separately permitted, but it must not make a caller-key tuple reusable while a committed effect, receipt, unresolved attempt, replay obligation, or authoritative historical operation binding remains reachable. A durable binding or tombstone must preserve conflict detection.

The candidate need not choose a retention duration, encryption mechanism, or storage table. Those remain outside scope. It must close the semantic rule that forgetting cannot silently re-arm a single-use identity.

Small case correction

Change:

Identical online submissions arrive concurrently at different receipt times

to:

Identical online submissions with the same authoritative idempotency tuple arrive concurrently at different receipt times

Without the tuple qualification, the current wording implies content-based deduplication across different caller keys. Two semantically identical submissions with deliberately different keys are not automatically the same logical operation.

Non-blocking repository-currentness note

Issue #21 currently lists the human-finalization protocol in #19 as its transaction predecessor but does not list the newly exposed NOT_REQUIRED closure in #25. Since the authorization-policy and finalization-evidence materialization cannot be complete for ASSERT_OPERATION_CLAIM without #25, update #21's predecessor list or mark #25 explicitly as blocking #21 before promotion work starts.

Final assessment

• Authority and dependency pins: sound
• Primary trust boundary: sound
• Lookup tuple versus operation digest: fixed
• Trusted online assertion-time retry problem: recognized
• Failure-evidence versus successful atomicity: fixed
• AssertionRecord handoff: sound
• Human-finalization artifact exclusion: sound
• Durable no-effect retry lifecycle: must close
• Key equality and no-unsafe-forgetting invariant: must close
• Scope drift: none
• Architectural over-design: none

After those two bounded additions, issue #25 is ready to drive the one-file Phase A candidate.

[samovers]

Re-review disposition: ready for Phase A drafting

The two previous blockers are now addressed in the issue specification. I found no remaining issue-level blocker to preparing the one-file candidate. This is review clearance for the drafting brief—not semantic approval of the transaction protocol, machine contracts, promotion, or runtime implementation.

Reviewed canonical samovers/OFARM#25 as updated on September 6, 2026, at 10:50:51 UTC, together with the updated promotion dependency in #21.

Previous findings

Finding	Current disposition
Durably committed NO_EFFECT attempts had no defined retry lifecycle	Addressed as a mandatory candidate requirement. Section 5F now requires an explicit consequence for each durable failure class, immutable earlier attempts, fixed operation/intent bindings for same-operation retries, fresh authorization decisions, and at most one eventual successful effect.
Idempotency-key equality and unsafe forgetting were unspecified	Addressed as mandatory candidate requirements. Section 5B requires an accepted canonical identifier profile or exact grammar/equality rules. It also requires a surviving binding or tombstone to prevent deletion from silently making the tuple reusable.
Concurrent identical submissions were not explicitly limited to the same key scope	Fixed. The case now specifies the same authoritative idempotency tuple, avoiding an unintended content-based deduplication requirement across different keys.
Promotion issue #21 omitted #25	Fixed. Its predecessor list now explicitly includes #25 and names the no-effect lifecycle, key equality, safe forgetting, reconciliation, and operation-claim handoff.

The corresponding failure, equality, retention, and concurrency cases are present, and the completion gate explicitly requires their resolution before Phase A can be declared complete. The promotion dependency is also now explicit rather than merely implied through the AssertionRecord work.

One drafting clarification—not another issue blocker

Section 5F includes BLOCKED_PENDING_RECONCILIATION among the possible lifecycle consequences of a durable NO_EFFECT attempt. That wording came from my previous suggested list and needs a precise distinction in the candidate.

Whether an attempt committed an effect and whether the logical operation may proceed are separate questions.

For the same attempt, an uncertain commit must remain OUTCOME_UNKNOWN; it cannot truthfully be labeled NO_EFFECT. A conclusively effect-free attempt could still leave the operation blocked because another explicitly identified attempt remains unresolved.

The candidate should therefore state:

NO_EFFECT requires conclusive evidence that the named attempt committed no protected effect or consumption. An uncertain outcome for that attempt is OUTCOME_UNKNOWN. Any operation-level reconciliation block attached to a proven NO_EFFECT attempt must identify the separate unresolved attempt or fact that causes the block.

My previous three-value suggestion was too loose about this distinction. It does not require another architectural component or another issue revision before drafting; it belongs in the exact lifecycle matrix the issue now requires.

Dependencies and scope remain intact

The three dependency heads still match the previously reviewed pins:

Dependency	Exact head
Authorization PR #11	03a21f669ee04f96d444e14f00ae7212cab04803
Human-finalization transaction PR #20	98f8c4fafbae42c8f7fd931f43f53adcb4733713
AssertionRecord protected-effect PR #23	622376e2998cf8b3954ca19e81d2cce6fd57e5fe

All three remain draft and unmerged at review time.

The revised issue still preserves the relevant boundaries: authorization remains owned by PR #11; human-finalization modes remain owned by PR #20; AssertionRecord mappings remain owned by PR #23. The new work supplies only the missing NOT_REQUIRED transaction protocol, with one pending-review operation claim as its first concrete handoff.

No active-baseline rewrite is needed. The change remains a proposed RFC extension with later machine-contract and implementation/conformance implications, not an amendment to the Constitution or Platform Runtime architecture.

Final assessment

Proceed to the one-file, non-authoritative Phase A candidate. The issue now identifies the decisions the candidate must make and prevents those decisions from being silently deferred to schema or runtime authors. Requiring the issue itself to contain every final protocol choice would duplicate the RFC it commissions.

The next substantive review should examine the candidate's actual operation-binding object, retry projection, lifecycle matrix, evidence ordering, and reconciliation rules at an exact commit—not repeat another broad issue-specification review.

No runtime tests were run. This review does not grant steward semantic approval, merge authorization, accepted-law status, schema materialization, current/default promotion, or OFARM2 runtime implementation permission.

[samovers]

Re-review: ready for the one-file Phase A candidate

Disposition remains: ready for the one-file Phase A candidate. No new issue-level blockers found.

Reviewed the issue body updated on September 6, 2026, at 11:48:45 UTC. No newer candidate PR was identified in the repository PR listing checked for this review, so this is a review of the drafting specification—not approval of a completed transaction protocol.

The previous lifecycle clarification is now resolved

Section 5F now separates the two dimensions correctly:

Dimension	Current requirement
Outcome of an individual attempt	NO_EFFECT requires conclusive evidence. An uncertain attempt remains OUTCOME_UNKNOWN.
Consequence of a proven durable NO_EFFECT attempt	Exactly one of RETRYABLE_SAME_OPERATION or TERMINAL_REQUIRES_NEW_OPERATION_KEY.
Whether the logical operation may proceed	BLOCKED_PENDING_RECONCILIATION is derived separately and identifies the unresolved attempt or fact.
Failure before a durable operation binding exists	No invented logical-operation lifecycle consequence.
Failure to persist new failure evidence	No invented durable consequence; existing authoritative evidence controls.

This closes the ambiguity in my earlier suggested three-value list. The added case—one conclusively effect-free attempt while another remains unresolved—tests the distinction directly.

The additional changes strengthen the drafting brief

Retry comparison now has an explicit basis. Sections 5B–5C require comparison of the exact caller-owned submission projection while recovering the original runtime-completed intent and bind-once operationBindingDigest. They also require the candidate to define the first durable admission point, concurrent first-admission winner, and treatment of failures on either side of admission. This addresses the timestamp-induced false-conflict problem without making a second caller-controlled intent authoritative.

Mode changes have a stated disposition. A previously admitted, effect-free NOT_REQUIRED operation cannot migrate into a human-finalized execution path under its old key. The issue requires a new operation key and the newly selected mode, while retaining the prior-success and unresolved-attempt reconciliation requirements.

Evidence ownership is more explicit. Section 4 now requires an ownership table covering operation binding, attempts, authorization evidence, consumption, domain results, traces, receipts, and failures. Placing the new transaction profiles in the proposed shared finalization-evidence package is consistent with PR #20’s pinned §18 tagged-profile approach; it does not itself extend PR #20 to another mode or authorize schema creation.

Approval provenance is now directly traceable. The issue links the exact-head steward comments and distinguishes them from formal GitHub APPROVED review objects. The linked PR #23 approval explicitly approves the pinned candidate while withholding acceptance, promotion, runtime authorization, and approval of the still-missing NOT_REQUIRED path.

Two interpretation constraints to preserve in the candidate

These are not requests for another issue revision. They are checks on how the candidate implements the existing requirements.

Durable admission must preserve the assertion timestamp, not redefine its source. “First-admitted assertion act” should identify the submission whose trusted timestamp is retained for the logical operation. It must not become assertedAt = operation-binding commit time or assertedAt = effectCommittedAt. PR #23’s pinned §6.2 requires the runtime-observed assertion timestamp before intent validation and hashing and explicitly separates it from commit time. The current issue also requires that separation.

Admission precedence must operate on verified evidence. An “existing matching successful receipt” must mean a receipt whose complete matching success set has been verified—not merely a row containing a success label. Likewise, a mode-change terminal response must not bypass an unresolved earlier attempt and encourage a new-key submission while the earlier effect may still commit. Sections 5F–5G already require complete-set verification and uncertainty blocking; the candidate’s algorithm must preserve those requirements in its actual ordering.

Final assessment

The issue now provides enough direction to commission the RFC without duplicating the RFC itself. It requires the candidate to make the remaining exact choices—operation-binding shape, caller projection, admission sequence, failure-class mapping, key grammar, and evidence placement—and prohibits leaving those choices to schema or runtime authors. Its scope remains a proposed transaction RFC extension, with no active-baseline amendment or immediate OFARM2 implementation change.

Proceed to drafting and exact-head candidate review. No further expansion of issue #25 is warranted by this review.

No tests were run. This comment records the drafting-brief review only; it is not steward semantic approval of a transaction candidate, acceptance of law, schema materialization, current/default promotion, or authorization for runtime implementation.