Conversation
samovers
left a comment
samovers
left a comment
There was a problem hiding this comment.
Review disposition: request bounded changes
Reviewed exact head eb2ea5c0470e3f60ee6a6368625039be9621ba1b. At review time, the PR remained draft and changed one candidate document only. Its scope is appropriate, but two protocol defects and one delivery-order mismatch should be corrected before semantic approval.
All findings concern:
package_meta/history/clean_baseline_migration/phase_reports/not_required_transaction_and_consumption_protocol_rfc_candidate_v0_1.md
1. Blocker — consumption and receipt digests form a circular dependency
Locations: §§9.4, 12.1, and 13.3.
Section 9.4 requires the governed-effect receipt to bind the decision-consumption reference and digest. Section 13.3 requires the consumption record to bind the receipt reference and digest. Section 12.1 removes only each record’s own top-level self-digest, while leaving other members covered.
That creates this dependency:
consumption digest depends on receipt digest
receipt digest depends on consumption digest
Neither final digest can be constructed first using the stated ordinary hashing procedure. Hashing a provisional receipt, constructing consumption, and then replacing the receipt digest changes bytes already covered by the other digest.
Removing each record’s own self-digest does not remove this cross-record cycle. The candidate needs an explicit construction order rather than leaving schema authors to invent exclusions or interpret refs/digests differently.
Smallest patch
Preallocate the immutable receipt identifier. Let consumption contain that identifier without the receipt digest, and let the receipt contain the finalized consumption reference and digest:
allocate receipt ID
↓
construct and hash consumption, including receipt ID
↓
construct and hash receipt, including consumption digest
↓
commit both atomically and enforce their linkage
This preserves the bidirectional relationship without requiring bidirectional hashing. State the distinction explicitly in both sections and in the evidence-profile contract.
The same review should cover receipt membership: naming the receipt itself in the complete atomic set must not insert another copy of its own digest into a nested member that remains hashed. Later reconciliation evidence should point back to the original receipt; it must not require changing a receipt already committed.
Required conformance case: construct a complete success set in the declared order, verify every final digest independently, and prove that no provisional sentinel, post-hash mutation, or undocumented digest exclusion remains.
This is an executable evidence-contract defect, not a cosmetic naming issue.
2. Blocker — reconciliation does not close the committed-NO_EFFECT case
Locations: §§6.1, 10.3, 11.1–11.4.
The candidate permits a logical operation to be admitted through a committed no-effect record set. Its lifecycle matrix expressly permits committed authorization refusals and committed non-consumable domain-failure evidence.
However, §10.3 allows an uncertain attempt to be resolved only through a verified complete success set or proof that the transaction rolled back. It then describes recording NO_EFFECT after rollback. There is no explicit reconciliation branch for a transaction that committed a valid no-effect evidence set.
The missing case is:
A valid request receives DENY.
The operation binding, refusal bundle, and NO_EFFECT attempt evidence commit.
The commit response is lost.
Reconciliation finds the committed no-effect evidence and no protected effect.
The database commit succeeded, but the protected operation did not. It would be false to describe that evidence transaction as rolled back, and it does not contain a successful protected-effect set.
Where failure evidence is written in a separate transaction after the effect transaction rolled back, the protocol must also distinguish those two transaction identities. A lost acknowledgement for the failure-evidence commit is not resolved by pretending that evidence commit rolled back.
Smallest patch
Make reconciliation distinguish these outcomes explicitly:
| Authoritatively verified condition | Resolution |
|---|---|
| Complete matching protected-effect success set committed | EFFECT_COMMITTED; return or reconcile the original receipt. |
| Complete matching no-effect evidence set committed, with no protected effect or consumption for that attempt | NO_EFFECT; preserve its recorded consequence and immutable binding. |
| Effect transaction conclusively rolled back | NO_EFFECT; apply the existing surviving-binding and failure-evidence rules without inventing a committed record. |
| Evidence remains incomplete or contradictory | Continue blocking, or quarantine a proven invariant breach. |
Define which transaction each status proof names: the protected-effect transaction, first-admission evidence commit, or later failure-evidence commit. Verification must be attempt-specific; pre-existing operation bindings are not evidence that a rolled-back attempt partially succeeded.
Add lost-response cases for a committed DENY, a committed ALLOW plus domain-gate failure, and a separate first-admission failure-evidence commit.
The distinction is between database commit outcome and protected-effect outcome. Resolving it requires no new authorization outcome or domain state. The brief’s “success or rollback” shorthand is insufficient once durable no-effect commits are admitted.
3. Required correction — §21 reverses the agreed materialization/acceptance order
Location: §21, steps 3–6.
The candidate’s required sequence currently puts:
3. Accepted semantic promotion
4. Non-default transaction/evidence materialization
5. Domain/shared-evidence prerequisites
6. Authorization policy-bundle binding
That accepts the RFC before the relevant machine profiles and exact bindings exist.
Issue #25 instead requires non-default materialization and exact binding review before the accepted-law step in the sequence governed by PR #11. The pinned authorization candidate, §24 likewise separates semantic approval from accepted law and places exact schema/manifest review before acceptance.
Smallest patch: retain exact-head Phase A semantic approval, then materialize the required non-default profiles and prerequisites, review the exact bindings, and only then perform the applicable accepted-law promotion. Current/default promotion and OFARM2 extraction remain later, separately governed steps.
This is a correction to the candidate’s delivery instructions—not a reason to amend the historical approved PR #11 or redesign the promotion process.
What is already sound
The candidate implements the important distinctions established during issue review:
| Area | Assessment |
|---|---|
| Retry identity | The shared tuple is separate from caller-content comparison and the bind-once full operation digest. |
| Trusted assertion time | The winning runtime-observed pre-validation assertedAt is preserved rather than replaced with commit or retry time. |
| Failure lifecycle | Attempt outcomes, immutable no-effect consequences, and operation-level reconciliation blocks are distinct. |
| Mode correctness | NOT_REQUIRED does not fabricate approval artifacts, weaken agent authority checks, or absorb governed reads. |
| Domain boundary | The first handoff remains one pending-review operation claim, without accepted execution, review, current state, or implicit companion effects. |
Those choices are supported by the candidate’s actual rules, not only its PR description.
The admitted-result trace is not an independent blocker
I examined whether §5.6 accidentally freezes validation across retries. There is a valid distinction here: the original admission trace may remain immutable historical provenance, while the current attempt supplies its own fresh validation trace. The candidate separately requires current re-evaluation and handoff validation.
Preserve that distinction explicitly during materialization. PR #23’s pinned validation-trace contract, §11.2 binds the authorization result and, for corrections, the transaction snapshot; a prior trace cannot serve as the current attempt’s proof merely because the proposed result bytes are unchanged. I would not require removing the historical trace from the admission record.
Verification and change impact
GitHub reported successful repository-validation and generated-currentness checks at the reviewed head:
I verified those check results but did not run the repository suite locally. The PR introduces no executable runtime implementation, so the transaction scenarios above are semantic counterexamples, not claims of reproduced runtime failures.
No active-baseline file needs amendment. The smallest correction remains inside this candidate: close the evidence-reference construction, complete no-effect reconciliation, and restore the agreed delivery order. These are proposed RFC and later machine-contract/conformance changes, not Constitution or Platform architecture changes.
Keep PR #26 draft and withhold semantic approval until those three bounded corrections are made. The overall transaction design does not need a rewrite.
|
The three bounded corrections from the review are pushed at e042efa.
Local Scope stayed inside the transaction-and-evidence trust boundary: one non-authoritative candidate document and PR metadata. No schemas, active rules, runtime code, or OFARM2 files changed. The added transaction cases are future conformance obligations, not runtime tests executed in this PR. What is next: fresh source-verified review of this exact head. PR #26 remains draft; no semantic approval, merge, or promotion is claimed. |
samovers
left a comment
samovers
left a comment
There was a problem hiding this comment.
Re-review disposition: no blocking findings
All three findings from the previous review are closed. The candidate is ready for exact-head steward semantic approval. I found no new blocking regression in the revised transaction and evidence rules.
Reviewed e042efa2911b2ef0a61603b8e0adaa6911c03ac0, compared with the previously reviewed eb2ea5c0470e3f60ee6a6368625039be9621ba1b. At review time, the PR remained draft, unmerged, and limited to one historical candidate document.
1. Consumption/receipt digest cycle — closed
Sections 9.4, 12.1–12.2, and 13.3 now define a constructible order:
Preallocate immutable receipt ID
↓
Finalize prerequisite evidence
↓
Hash consumption with receipt ID only
↓
Hash the transaction-attempt record
↓
Hash the receipt with finalized consumption and attempt digests
↓
Verify all digests and links, then commit atomically
Consumption has no receipt-digest field. The receipt binds the finalized consumption digest, while its own membership entry contains only its identifier and role. The rules also prevent the attempt’s admitted-result subobject from introducing a nested reference to its containing attempt’s digest.
This is an actual removal of the circular dependency—not an undocumented hashing exclusion. Later reconciliation points back to the original finalized records and cannot mutate their bytes or membership.
Section 16 adds the requested construction and rejection cases: independently verify final digests, reject future-digest references and nested receipt self-digests, and preserve the original receipt during later reconciliation. These are stated as future executable conformance obligations, not tests already performed by this documentation PR.
2. Committed-NO_EFFECT reconciliation — closed
Sections 6.1, 6.4, 10.3, and 11 now distinguish the protected-effect outcome from the database transaction’s commit status.
The revised reconciliation rules cover all relevant branches:
| Authoritative evidence | Resolution |
|---|---|
| Complete protected-effect success set committed | Recover EFFECT_COMMITTED and the original receipt. |
| Complete no-effect evidence set committed | Recover NO_EFFECT, the original binding, and its recorded consequence. Do not call the database commit a rollback. |
| Protected-effect transaction rolled back | Preserve the proven no-effect fact and independently resolve any separate failure-evidence commit. |
| Relevant commit status or required evidence remains unresolved | Keep the operation blocked; quarantine a proven invariant breach. |
The status evidence identifies the protected-effect transaction, first-admission commit, and separate failure-evidence commit, using distinct transaction keys when they are distinct commits. That removes the previous ambiguity around a lost acknowledgement for a successfully committed refusal or failure record.
Section 11.4 also defines what constitutes a complete no-effect set. It requires the attempt, binding, stage-required evidence, exact membership, committed evidence-transaction status, and proof that the protected effect cannot still commit. A refusal bundle or an old operation binding alone is insufficient.
The added cases cover lost responses after committed DENY, committed ALLOW plus domain failure, and a separate first-admission failure-evidence commit. They also cover the important intermediate condition: effect rollback is proven, but the evidence commit remains uncertain. In that condition, the effect fact stays NO_EFFECT while the operation remains blocked.
3. Materialization and accepted-law ordering — closed
Section 21 now places the stages in the required order:
Exact-head Phase A semantic approval
↓
Non-default transaction/evidence materialization
↓
Domain and shared-evidence prerequisites
↓
Non-default policy-bundle binding
↓
Exact schema/profile/manifest review
↓
Separate accepted-law promotion
Hostile conformance, current/default promotion, extraction, and runtime implementation remain subsequent, separately governed steps. The candidate also explicitly requires completion of the applicable prerequisites under PR #11 §24 before accepted-law work.
This resolves the previous mismatch without editing the historical authorization candidate or changing the promotion model.
Regression checks
The amendment preserves the distinction between historical admission evidence and current validation evidence. The original admitted-result trace remains provenance, but every later successful attempt must supply a fresh passing trace with current authorization and snapshot bindings. The prior trace cannot substitute for current validation merely because the proposed result bytes are unchanged. Section 12.2 now states this explicitly.
The revised reconciliation does not weaken uncertainty blocking, permit a mode change to bypass an unresolved attempt, or turn failure evidence into consumption. The original operation claim remains pending review, and every effect-capable attempt still requires fresh authorization and the applicable gates.
Verification and final decision
At review time, the live dependency heads still matched the pinned inputs:
- PR #11:
03a21f669ee04f96d444e14f00ae7212cab04803; - PR #20:
98f8c4fafbae42c8f7fd931f43f53adcb4733713; and - PR #23:
622376e2998cf8b3954ca19e81d2cce6fd57e5fe.
GitHub reported successful checks at e042efa:
I verified the check results and job steps; I did not run the suite locally or execute runtime conformance tests.
No additional candidate revision is requested. The next governance action is explicit steward Phase A semantic approval for this exact head. This review is not that steward approval. It does not merge the PR, accept active law, materialize schemas, change current/default selections, or authorize OFARM2 runtime implementation. Those remain separate stages.
Phase A semantic approval — exact head e042efaRecorded on behalf of the steward from the user's explicit message in this task:
The approval applies to the NOT_REQUIRED transaction and consumption protocol v0.1 candidate and its steward approval card at e042efa, including the three corrections described in the exact-head review handoff. The live PR head was verified unchanged. PR #11, PR #20, and PR #23 still match the candidate's approved dependency pins, and both GitHub checks pass at the approved head. This is steward Phase A semantic approval recorded from the conversation, not an independent AI review or a formal GitHub APPROVED review object. The trust boundary remains the one-document transaction-and-evidence proposal; scope stayed inside it. No candidate bytes were changed to record approval. PR #26 remains draft and unmerged. This approval does not authorize merging, accepted-law promotion, schema materialization, current/default changes, or OFARM2 runtime implementation. Any semantic change to the approved head requires renewed review and approval. What is next: prepare the next separately scoped non-default materialization step under section 21, for its own authorization. |
1 participant
Summary
Trust boundary
Primary trust boundary: canonical transaction admission, guarded ordering, atomic success, single-use consumption, retry identity, and authoritative outcome reconciliation for state-affecting NOT_REQUIRED actions.
The PR boundary stayed inside that trust boundary: one historical Phase A Markdown candidate plus PR metadata. It changes no authorization meaning, human-finalization mode, AssertionRecord mapping, Event Grammar, accepted law, machine schema, currentness, runtime, database authority, retention or key custody, or OFARM2 implementation.
Exact dependency pins
All three live heads were rechecked before drafting and still matched their approved pins.
Review-sensitive closure
Review corrections at head e042efa
Addresses the review of the previous head:
Adds the corresponding falsifiable cases, invariants, traceability, and approval-card items in the same candidate. Historical admission traces remain provenance; each later successful attempt still requires its own fresh validation trace.
The steward reported no additional findings or blockers and gave Phase A semantic approval at this exact head, recorded from the user's explicit message in the task. The PR remains draft and unmerged. Semantic approval does not authorize merging, accepted-law promotion, schema materialization, currentness changes, or runtime implementation. Any semantic change requires renewed review and approval.
Verification at head e042efa
These checks establish repository consistency only. They are not semantic approval, accepted law, schema materialization, promotion, conformance evidence, or runtime authorization.
Closes #25