Derive production authority from canonical action rules - #359
Conversation
Record the Phase A trust model, closed action policy, scope proof, outcome ordering, and hostile verification required for issue #353 before implementation.
samovers
left a comment
samovers
left a comment
There was a problem hiding this comment.
Phase A review — changes required
Phase A is not ready for semantic approval.
Reviewed at exact head 178f150ce56f1bdad96330ba845d210ee0911f2a. The overall architectural direction is sound, but the proposed contract still leaves material authority and trace semantics unresolved. I found nine Phase A blockers.
B1 — AI-assisted posture is still caller-controlled and does not satisfy CP3
Location: RFC §4.3, INV-003, §6.3–6.4.
The RFC classifies a non-software Party as AI-assisted only when the caller supplies optional ai_assistance. That preserves an omission-and-retry bypass:
- A human requests
REVIEW_ACCEPTwithai_assistance; the result isREQUIRE_HUMAN_APPROVAL. - The same caller repeats the request without the optional field.
- The evaluator now classifies it as non-assisted and may return
ALLOW.
Absence of untrusted metadata is not governed evidence that no software agent participated.
The proposed positive assistance path is also weaker than active CP3. Resolving an assistant to an active SOFTWARE_AGENT Party does not establish sponsor-bound actorship, executing agent instance, model/tool profiles, authority snapshot, revocation state, target/action posture, or result-qualification linkage.
Required patch: do not infer “non-assisted human” merely from absent metadata. Until trusted actorship provenance is integrated, known or ambiguous software-agent participation must fail closed for state-affecting and high-consequence actions. Either remove the positive AI-assisted path from this delivery or split/reapprove it as CP3 runtime integration. Add the omission-and-retry hostile case.
B2 — Role-targeted grants are not bounded by the RoleAssignment’s own scope
Location: INV-006 and §6.3.
A valid role path is described as having a current role plus a grant covering the target. The RoleAssignment’s own anchorScopes are not included in coverage.
That permits this path unless explicitly blocked:
- Party has a RoleAssignment anchored to Farm A.
- An AuthorityGrant targets that RoleAssignment ID but names Farm B as its grant scope.
- The Party requests an action on Farm B.
- The grant covers Farm B and the role is current, so the proposed algorithm may accept it.
Required patch: for a role-targeted grant, require the requested target to be covered by both (1) a current RoleAssignment anchor scope and (2) the AuthorityGrant scope under the row-capped inheritance policy. Apply the same rule when a delegation source grant targets a RoleAssignment. Add the Farm A role/Farm B grant hostile case.
B3 — Purpose, conditions, limits, and required evidence have no executable semantics
Location: INV-006, INV-008, §6.3, and use_purpose in §6.4.
The RFC retains use_purpose and says delegation cannot widen purpose, but never defines how these active fields affect candidate validity:
AuthorityGrant.purposeAuthorityGrant.conditionsDelegationGrant.purposeDelegationGrant.conditionsDelegationGrant.requiredEvidenceRefs- optional authority-family restrictions when both family and action fields exist
Silently ignoring an unknown condition is fail-open.
Required patch: define exact purpose comparison semantics; disqualify a path when a non-empty condition has no supported deterministic evaluator; require every requiredEvidenceRef to resolve through the tenant-bound Store and satisfy an explicit state/currentness rule; require any stored authority family to be consistent with the row-derived family; and trace the evaluated constraint/evidence basis through a semantically correct contract field.
B4 — Revocation narrowing modes are not defined
Location: INV-006, INV-009, §6.3, and §7.2.
The design treats a grant as live or revoked, but the active RevocationDecision contract supports:
TERMINATENARROW_SCOPENARROW_ACTIONSNARROW_TIMEtargetScopeaffectedActionClassesreplacementGrantRefs
The RFC does not define how the narrowing modes alter effective authority.
Required patch: either define deterministic semantics for all four active modes and test affected and unaffected requests, or explicitly state that any active non-TERMINATE mode makes the path unsupported and non-allow in this version. The latter must be classified as bounded debt and cannot support the current “not provisional” claim for this area.
B5 — Scope proof does not prove the actual action target
Location: §4.2, INV-004/INV-005, and §6.1–6.2.
The RFC defines target kinds including DOCUMENT_ASSEMBLY, DOSSIER_ASSEMBLY, SUBMISSION_ASSEMBLY, CURRENT_STATE_MATERIALIZATION, PASSPORT_VIEW, QUERY_EXECUTION, and PACK_ACTIVATION. But §6.2 resolves only the scope identity—FARM, FIELD, LOT, and so on.
It does not define how targetKind and targetRef resolve to the governed object being approved, reviewed, filed, read, or activated. A request could therefore supply an allowed target kind and a real scope while using a missing, forged, wrong-kind, stale, or cross-tenant target reference.
Required patch: separate target-object proof from target-scope coverage proof. Add a governed mapping from each targetKind to accepted record kinds, lifecycle/currentness rules, twin constraints, and the field binding the target to its claimed scope. Unsupported or non-persisted target forms must refuse. Add hostile cases for missing target, wrong record family, mismatched governed scope, cross-tenant target with valid local scope, and stale/superseded targets.
B6 — The required trace cannot be represented by the existing contracts
Location: INV-010 and §6.4.
The statement that dataSovereigntyBoundaryRefs can carry ordered tenant and scope-proof references is semantically invalid. That field is for governed DataSovereigntyBoundary objects, not arbitrary identity rows, lineage decisions, containment records, RuntimeBundle receipts, or other proof artifacts.
The current trace contract also cannot explicitly encode several items promised by INV-010:
- actor posture distinguishing human, AI-assisted human, and autonomous software;
- policy-table version or digest;
- target kind and target reference;
- generic scope-proof references;
- constraint or required-evidence proof.
Using dataSovereigntyBoundaryRefs as a generic bucket would be schema-valid but semantically false.
Required patch: add a controlled authorization-contract extension with fields such as authorityPolicyRef or authorityPolicyDigest, actorPosture, target, scopeProofRefs, and where needed constraintEvidenceRefs. Keep dataSovereigntyBoundaryRefs only for actual boundary objects. Update machine contracts, examples, indexes, and conformance. This changes the current “no contract field” non-effect and requires semantic reapproval.
B7 — RECEIVE_READ_DATA still has two authority paths and an incomplete trace
Location: §6.3, §6.5, INV-006, INV-010, and INV-011.
The RFC claims one evaluator and one selected authority path, but leaves the current SharingGrant check as an external overlay pending #177.
That means either:
- the evaluator can say
ALLOWbefore the sharing boundary refuses; or - the final access decision is produced by two authoritative paths while the selected evaluator trace is incomplete.
Neither matches the proposed one-evaluator contract. This does not require taking over #177’s mutation, redaction, or delivery-plan work.
Required patch: for RECEIVE_READ_DATA, compose the existing read-sharing check into the final evaluator decision and populate sharingBasisUsed, preserving existing sharing semantics. If that cannot be done without unresolved #177 decisions, mark RECEIVE_READ_DATA unsupported in this slice and split/reapprove the current-caller requirement.
B8 — Durable refusal traces need an explicit commit-before-error protocol
Location: INV-012 and §7.1–7.3.
The RFC requires request, trace, and result to be persisted before the effect, no effect for non-ALLOW, and a durable refusal trace. But the existing UnitOfWork rolls back whenever an exception escapes it.
The ordinary authorization flow can therefore lose the refusal evidence:
- evaluator appends refusal records;
- caller raises its authorization exception;
- UnitOfWork rolls back;
- the trace disappears.
Required patch: specify the control flow explicitly: the evaluator persists the decision; non-ALLOW skips the effect and returns a typed refusal value; the UnitOfWork exits normally and commits; only after commit does the outer boundary map the refusal to an HTTP error or typed exception. A persistence failure remains an infrastructure failure and must not fabricate a durable decision. Test this through actual entry points, not only returned payloads.
B9 — Six L rows are an unclassified authority expansion
Location: §4.4–4.5 and §13.
The RFC assigns lineage-capable policy L to:
OBSERVE_CREATE_OBSERVATIONOBSERVE_ATTACH_EVIDENCEASSERT_OPERATION_CLAIMOPERATE_PLAN_INTERVENTIONOPERATE_REPORT_EXECUTIONRECEIVE_READ_DATA
The accepted action matrix assigns only EXACT_ONLY and/or DESCENDANT_SCOPES defaults for these actions. Allowing a lineage-scoped grant to reach a non-descendant target is an executable authority extension, not merely an implementation choice.
Required patch: either use D/X according to the accepted matrix, or explicitly classify the six L decisions as an RFC extension affecting the Authority Action Matrix and Authority Policy Model, explain the non-descendant authority being granted, and trigger semantic reapproval.
What should remain
The overall direction should not be rewritten:
- one immutable code-owned action table;
- separation between accepted policy and runtime reachability;
- removal of caller-selected stage and revocation optionality;
- separate target/scope proof objects;
- deterministic selected authority basis;
- no compatibility evaluator;
- evaluation immediately before governed effects.
The required correction is to complete the authority path and contract semantics around that architecture.
Disposition
- Blockers: 9
- Phase A semantic approval: no
- Implementation authority: no
- Merge approval: no
The most consequential blockers are B1, B2, B5, and B6: the current design can still misclassify AI involvement, cross role scope, authorize an unproved target artifact, and emit a semantically false trace.
|
Canonical prerequisite opened:
The candidate addresses the review blockers around AI-metadata omission, role anchor scopes, exact purpose/condition/evidence semantics, narrowing revocations, target versus scope proof, trace v0.2 evidence, SharingGrant composition, refusal-trace commit ordering, and the proposed lineage expansion. This does not unblock this implementation PR yet. The required sequence remains: semantic approval, accepted RFC/action matrix, draft v0.2 source and decision contracts, hostile conformance, explicit current/default promotion, and byte-identical OFARM2 extraction. No OFARM2 runtime files were changed while preparing the prerequisite. Primary trust boundary: canonical authorization law and machine-contract governance. Scope stayed inside that boundary. What is next: review the canonical Phase A approval card in samovers/OFARM#11 before revising this implementation. |
Integrate current main and replace the unapproved legacy evaluator plan with the production authorization boundary, canonical readiness gates, explicit scope-amendment proposal, and prepared-evidence handoff to issue #178. Map the nine prior review blockers without claiming semantic approval or implementation readiness. Design-only change for Delivery #353 and draft PR #359.
samovers
changed the title
samovers
left a comment
samovers
left a comment
There was a problem hiding this comment.
Phase A revision 2 review — changes requested
Reviewed head: 1473a4c16d8e716b03a3c36c2e36114e6e9fb255
Inspected base: fcac9ba505226e7e2fa2ede0aedb7585721b1841
Scope: the current 638-line, one-file Phase A revision—not the withdrawn legacy implementation proposal. The PR remains draft and contains no runtime changes.
One substantive provider-interface gap remains before Phase A approval. It belongs within the existing G3 gate; it does not require reopening the architecture or adding transaction coordination to this PR.
B1 — The provider interface does not define the preparation handshake required for fresh human approval
Location: docs/rfcs/OFARM_Runtime_Authority_Action_Matrix_Evaluation_RFC_v0_1.md, sections 6–8, with corresponding verification and G3 changes in sections 10 and 13.
The proposed interface at this exact head accepts an immutable input containing applicable “already-governed approval evidence,” then returns a prepared decision bundle with its selected authority basis and validity window. It does not describe a separate, non-decision preparation result or how transaction-local prospective approval evidence enters the final evaluation.
That is insufficiently specified for the pinned canonical PR #20 protocol. Section 11 at 98f8c4fafbae42c8f7fd931f43f53adcb4733713 requires the following order for FRESH_HUMAN_APPROVAL_REQUIRED:
- Evaluate the non-finalization conditions and determine the canonical candidate requester path, independently eligible approver path, and exact cutoffs—without producing an authorization result or decision bundle.
- Construct and hash the prospective approval evidence, already containing the candidate requester basis and
decisionValidUntil. - Perform the final authorization evaluation, which must select the identical requester basis and return exactly the prebound validity window. A mismatch prevents successful finalization.
Why this matters: the consumer needs provider-derived values to construct the evidence that the provider subsequently verifies. The current interface does not explain how the consumer obtains those values without either calling a result-producing evaluation prematurely or duplicating authorization path selection and cutoff calculation in the coordinator.
The latter would contradict the RFC’s own EXC-001: the transaction owner must consume authorization evidence rather than implement a second policy engine. Full admitted-action coverage also means this cannot be left unresolved simply because the first operation-claim consumer uses NOT_REQUIRED.
This is a missing design contract, not a demonstrated vulnerability in existing runtime code. G3 already acknowledges unfinished interfaces; the required correction is to make this particular dependency explicit and reviewable.
Smallest controlled patch
Add a bounded provider/consumer handshake to sections 6–8:
- The same authorization implementation supplies non-authoritative preparation: candidate requester and approver bases, relevant-state bindings, and the required expiry/validity values. It emits no authorization decision, consumable evidence, or durable claim.
- The transaction consumer constructs the mode-correct, prospective and uncommitted finalization evidence. The provider must distinguish that evidence from previously persisted records and verify its exact attempt, snapshot, intent, basis, and cutoff bindings.
- Final evaluation enforces the canonical candidate/final equality checks. Preparation must not become a caller-selectable “skip human approval” mode.
Keep challenge issuance, the human ceremony, persistence, consumption, and transaction coordination outside this provider. The canonical candidate protocol already supplies the required ordering; no new authorization law is needed.
Add focused verification to section 10 and make it explicit in G3: preparation produces no decision bundle; a correctly bound prospective approval can reach final evaluation; changed requester basis or validity window cannot authorize success; and evidence from another attempt cannot be reused. These should exercise the same production-bound provider, not a coordinator-owned copy of its algorithms.
Change classification: implementation-interface/conformance correction to this RFC. No active baseline, accepted RFC, or machine-contract edits are requested.
Disposition of the earlier review
The earlier nine findings should not simply be reposted unchanged. This revision replaces their problematic design assumptions: it separates AI disclosure from authority, intersects role and grant scope, requires actual target proof, uses canonical evidence contracts, composes sharing within evaluation, and removes the unsupported lineage expansion. Those are corrected design requirements, not executed runtime fixes.
The old durable-refusal finding is handled differently: the revision proposes moving durability to the transaction consumer. That is a coherent ownership proposal, but it does not satisfy issue #353’s original durable-trace acceptance criterion until the scope amendment is explicitly accepted. The PR correctly leaves that unresolved rather than declaring the issue complete.
The production assumptions checked also support the revision: the actual application runtime exposes authentication and tenant UnitOfWork composition, while the UnitOfWork starts READ COMMITTED, rolls back escaping exceptions, and reports uncertain commit finalization separately. None of that already supplies the proposed authorization provider or its complete guard interface.
Approval and verification limits
Keep the PR draft. Resolve B1 within G3, then complete the already-declared scope, canonical-readiness, and trusted-interface gates before presenting an implementation approval card. The missing promoted contracts and unfinished production interfaces are acknowledged prerequisites—not additional newly discovered defects.
This was a static design/source review. I did not independently rerun the reported cheap checks or execute PostgreSQL/runtime tests. This review is not semantic approval, baseline admission, merge approval, or deployment authority.
Disposition: one Phase A provider-interface blocker; no zero-Blocker sign-off.
Bottom line: preserve the revised authorization/transaction split. Add the missing preparation-to-final-evaluation handshake; do not solve it by duplicating authorization inside the coordinator.
Address PR #359 revision-2 review B1 within the production authorization design. Separate non-decision preparation, consumer-built prospective evidence, and complete final evaluation with exact requester-basis and validity equality. Add AUTH-015 through AUTH-018 and make the handshake explicit in G3. Keep transaction ownership, canonical contracts, and runtime implementation unchanged for issue #353.
Revision 2 B1 correction — ready for focused re-reviewThe review covered The missing fresh-approval handshake is explicit:
Sections 6–8 define the interface and ordering; AUTH-015–018 add the positive prospective-evidence case and hostile cases through the same production-bound provider; G3 and the code-excellence mapping now include the handshake. This applies the existing pinned canonical PR #20 section 11, without adding a coordinator-owned authorization algorithm. Fresh checks: package PASS (0 failures), architecture PASS, temporal candidate PASS, decision log PASS, whitespace/scope PASS, using CPython 3.12.13 and Ruff 0.15.5. No runtime/PostgreSQL tests or expensive baselines were run; the new AUTH cases are implementation test requirements, not executed evidence. Primary trust boundary: production authorization design. Only the RFC changed—190 insertions, 28 deletions from the reviewed head. Runtime code, canonical contracts, challenge/human ceremony, persistence, consumption and transaction ownership are unchanged. The PR stays draft; G1–G3 and semantic approval remain open. No zero-Blocker sign-off is claimed. What is next: re-review B1 and its affected invariants; the earlier nine findings are not reopened without new evidence. |
PR #359 — Phase A revision 3 review ( |
Phase A revision 4 — focused review correction readyExact head: This addresses the review of revision 3 at
The earlier preparation → prospective evidence → complete final evaluation handshake and exact candidate/final basis/window equality remain intact. RFC section 11 maps these corrections to their invariants and gates. Verification on the final pre-commit content, CPython 3.12.13 / Ruff 0.15.5:
Against the reviewed head: one RFC, +249/−68. Against inspected main AUTH-015–019 are test plans, not executed production tests. No runtime/PostgreSQL tests or expensive hosted baseline were requested. No new zero-Blocker sign-off, G1–G3 closure, semantic approval, implementation approval or merge authorization is claimed. G4 requires a fresh review and the later exact decision approval. What is next: re-review this correction and its affected invariants at |
samovers
left a comment
samovers
left a comment
There was a problem hiding this comment.
PR #359 — Phase A revision 4 re-review: B1 closed; no new blockers
Reviewed head: 263cd32722ff2b482910bd7bb880f91aa8391838
Inspected base: fcac9ba505226e7e2fa2ede0aedb7585721b1841
Artifact: docs/rfcs/OFARM_Runtime_Authority_Action_Matrix_Evaluation_RFC_v0_1.md
No blocking findings in this focused re-review. The latest correction changes only the existing RFC: 249 insertions and 68 deletions relative to 4f863fa98c4407d95b06642aaf9e8487088e9d7b. The PR remains draft and design-only.
This pass covers the later revision-3 review's B1, related S1–S4, and affected invariants. That review identified a projection-ownership gap that my previous pass missed: requiring challenge/final equality was not enough without explicitly assigning its computation and verification.
B1 — Challenge/final relevant-state comparison: closed at the design level
The revised RFC at this exact head, sections 4, 6–7, now assigns the complete responsibility to the provider. It computes the final rule-selected projection from its current typed snapshot, calculates its JCS/SHA-256 digest, compares that digest with the verified immutable challenge, and returns the projection, digest, and both snapshot bindings. A consumer-supplied digest or equality flag cannot substitute for that work.
The important failure distinction is explicit:
A relevant-state change invalidates the challenged act even when the requester's authority basis and validity window would otherwise still pass. Conversely, unrelated history outside the exact projection does not invalidate the challenge merely because the full snapshot reference changed. Final evaluation recomputes the projection and checks it against both the challenge and prepared/candidate values. This matches the pinned canonical projection and approval-lifecycle requirements in OFARM PR #11 sections 16.1 and 18.3 and OFARM PR #20 section 11.
AUTH-019 now makes that distinction falsifiable: relevant change with otherwise sufficient authority, unrelated-history success, forged equality inputs, and drift between preparation and final evaluation. Preparation still emits no authorization decision; durable generation invalidation and replacement challenge issuance remain consumer-owned. That closes the identified ownership, output, and invariant gap.
Related corrections
| Item | Assessment |
|---|---|
| S1 — Incomplete approval-construction inputs | Addressed. Preparation now supplies the complete bound authorization view, including target, typed inputs, effect subject, representation, and proof bindings. The consumer constructs the candidate without a second extractor, projection implementation, or policy engine. |
| S2 — Display, separation, and act-time checks | Addressed. The contract explicitly verifies retrievable display bytes and metadata, retention binding, trusted humanActedAt, and exclusive cutoffs. It preserves SAME_PRINCIPAL_ALLOWED and does not activate reserved distinct-approver semantics or add ceremony/custody ownership. |
| S3 — Facade extension called mechanical | Classification corrected; concrete implementation remains gated. The RFC now treats the facade extension as substantive, records its current shape and constraints, and requires an explicitly reviewed interface and size-budget outcome before Phase B. It does not approve an automatic budget increase or weaker checker. |
| S4 — Exact retry versus evidence portability | Addressed. An admitted retry may reuse the original act/intent while creating fresh attempt-bound preparation and prospective evidence. Old candidates remain nonportable. A committed exact retry returns its existing receipt without another evaluation or consumption. |
| Sequence preference | Addressed. The fresh-approval handshake replaces the ordinary evaluation step; it no longer appears to precede an additional decision-producing evaluation. |
These corrections appear in RFC sections 6–8, with their verification and gate implications in sections 10–13.
The expanded AUTH-015–AUTH-019 plan retains positive cases for complete prospective approval, unchanged relevant state, and admitted retries. It therefore does not equate blanket refusal with a working provider. These are still test specifications, not executed runtime evidence.
Remaining prerequisites are not closed by this review
S3's documentation correction does not establish that the provider fits the actual facade. The architecture checker at the inspected base does enforce the stated module/group budgets, and G3 still requires the concrete constructor, slots, public surface, dependency/query edges, lifecycle, and size outcome. That work must not be presented later as already approved wiring.
The existing gates also remain: G1 for the #353 scope amendment, G2 for canonical materialization/promotion/extraction, and G3 for executable trusted interfaces and independently useful provider completion. The later decision card and task-user approval remain separate. None is satisfied by closing this review finding.
Disposition: B1 closed at the design level; related corrections addressed as qualified above; zero new blocking findings and no additional patch requested for this correction. Keep the PR draft while the declared prerequisites are resolved.
Verification limits: static source review of the changed design, comparison with the pinned canonical requirements, inspection of architecture-budget definitions, and confirmation that the live PR head remained unchanged. I did not independently rerun the reported checks, execute PostgreSQL/runtime tests, or request hosted baselines.
This is a focused design-review disposition, not semantic approval, implementation authorization, baseline admission, merge approval, canonical promotion, or deployment authority.
Advance issue #353 Phase A to revision 5 with two closed UoW operations, a trusted-source map, coherent tenant-read proposal, complete guard obligations, and explicit remaining G2/G3 gates. Preserve the reviewed handshake and applied issue amendment without authorizing runtime work. Integrate main ff092c4 without rewriting history. Only the authorization RFC differs from that main; mandatory package, architecture, temporal, and whitespace checks passed.
|
Revision 5 is ready for focused design review at The new work is the concrete UoW interface, trusted-source map, coherent tenant-read proposal, complete read-to-guard handoff and exact proposed facade shape. The revision-4 handshake is preserved. G1 is applied; G2 and G3 remain explicitly open. This is not runtime implementation or a request for baseline admission. Please review the new proposal and affected AUTH-002/003/007/009–019 and EXC invariants. Do not reopen earlier findings without new evidence, or treat missing cross-boundary producers as permission to add their authority here. In particular, inspect trusted construction, snapshot continuity, complete-set/absence protection, caught-error rollback-only behavior and the unresolved size/workload gates. Mandatory package, architecture, temporal and whitespace checks passed. Only the authorization RFC differs from integrated main What is next: focused exact-head review; then close the named G2/G3 prerequisites before a decision card or runtime edits. |
samovers
left a comment
samovers
left a comment
There was a problem hiding this comment.
PR #359 — revision 5: no new blocking findings
Reviewed head: 87584f2e368fc791f0c12e4288885dc5425ea287
Integrated main: ff092c414db9fa24dbd6ab86c7722db89e0c95b5
This review covers the new interface, trusted-source mapping, reader, guard handoff, and affected invariants. Against integrated main, the PR still changes one RFC only. The revision-4-to-5 RFC delta is 378 insertions and 111 deletions; the merged challenge/signing changes are inherited from main, not newly authored authorization scope.
Disposition: zero blocking findings in this focused re-review, with one non-blocking clarification for G3-READ. The proposal is more concrete, but it remains a provisional design—not an implementation-ready provider.
Reviewed artifact: production authorization RFC at the exact head.
S1 — Make the reader-to-evaluator failure mapping explicit
Location: RFC section 6, “Concrete tenant read plan and snapshot limits,” with corresponding verification under section 10 and G3-READ.
The reader is described as returning verified facts and a canonical snapshot binding; missing snapshot/visibility proof yields “no successful capture.” Meanwhile, EvaluationOutcome distinguishes ingress/infrastructure refusals from prepared authorization decisions. The mapping between those two interfaces is still implicit.
That distinction matters because failure to establish authority is not always an infrastructure failure. An implementation must preserve the canonical global/path evaluation rules rather than routing every unsuccessful proof through one generic read-error branch. In particular:
| Situation | Required distinction |
|---|---|
| A complete observation establishes that no applicable authority path exists | Preserve the canonical DENY / NO_AUTHORITY_BASIS result—not a database-unavailable response. |
| An authorization-global prerequisite is unavailable | Apply canonical global-failure ordering and mark dependent checks NOT_EVALUATED; do not fabricate target or tenant conclusions. |
| One path is revoked or unsupported while another is independently sufficient | Preserve path-local dispositions and canonical aggregation; the failed path must not automatically become an infrastructure refusal for the whole evaluation. |
| The database or adapter actually fails | Preserve infrastructure handling and the existing rollback-only/discard discipline; do not fabricate a decision or durable outcome. |
The first three follow pinned canonical PR #11 section 15; the fourth is already required by the proposed UoW interface.
Smallest correction: add a short reader-result classification paragraph and focused cases under the existing AUTH-007/009/010 coverage. Preserve truthful negative observations and failure dispositions without inventing a complete snapshot or new evidence schema.
I classify this as non-blocking because section 7 already requires canonical evaluation semantics and G3-READ expressly remains unfinished. It is an implementation-facing clarification, not a demonstrated runtime defect. It belongs in this RFC’s interface/conformance work; no baseline or canonical-law amendment is requested.
Assessment of the new proposal
The public interface is bounded and its lifetime rules are explicit. The two methods—prepare_authorization and evaluate_authorization—use one privately injected callable pair rather than exposing a provider or connection handle. Both must check active/rollback-only state. Unexpected failures must mark the UoW rollback-only even when consumer code catches the exception. That fits the current manager’s rollback/discard mechanism without creating a second transaction owner. These are proposed obligations, not implemented methods.
The source map does not mistake typed objects for trusted provenance. It identifies missing attempt, selection, session/act, representation, CP3, snapshot, and display-proof producers instead of allowing the evaluator to manufacture them. The distinction between credential expiry, principal validity, interactive-session expiry, and transaction deadlines is preserved. The current VerifiedIdentity indeed contains only equality policy, issuer, and subject; it does not provide the complete session proof the provider will need.
The reader proposal addresses completeness without overclaiming currentness. It requires a coherent tenant-record/reference/batch observation, verification of reference-extractor provenance and family-specific digests, inclusion of rejected/revoked paths, and explicit overflow detection. It distinguishes JSONB from original wire bytes and same-transaction rows from committed prerequisites. It also correctly leaves exact SQL, practical workload bounds, and canonical visibility/snapshot mappings unresolved.
The guard handoff preserves the authorization/transaction split. Exact record facts, absence/complete-set predicates, and external/time bindings are separately represented. A successful observation does not establish commit protection, and running the reader twice does not establish the final-snapshot continuity required by the approval handshake. The provider supplies obligations; the transaction owner must supply the actual protection mechanism.
The facade extension is now specific, but its implementation size is not approved. Section 12 proposes two additional public methods, one constructor dependency, and one slot. It still requires a measured partition and budget outcome, explicitly forbidding automatic budget increases or moving transaction code merely to hide growth. That preserves the qualification from the previous review.
The previously reviewed approval handshake remains intact: provider-owned relevant-state computation, complete prospective-evidence inputs, exact candidate/final basis and validity equality, and separation of admissible act retries from forbidden candidate reuse. The new verification plan retains positive cases alongside hostile cases; none is presented as executed provider evidence.
Readiness status has changed—but not to implementation-ready
G1 is now applied as the issue-scope amendment. I verified the amended issue #353 and its preserved amendment record. The former requirements for an independently authored matrix, legacy/SI migration, and provider-owned durability are no longer the current work definition. This scope edit does not supply the later implementation approval.
G2 and G3 remain substantive prerequisites. G3 now identifies four concrete closure areas: real input producers, the admitted reader/snapshot mapping and practical bounds, an actual complete transaction handoff, and a measured facade/module partition. Naming those interfaces is not evidence that they exist.
The newly explicit dependency-cycle warning is important: an indispensable input producer cannot be deferred until after the provider that needs it. The RFC requires resolving that with the existing owner or a separately scoped prerequisite before approval; it does not authorize fake frames, a type-only companion PR, or silent expansion of #353. That is the correct treatment of the remaining sequencing problem, not closure of it.
Bottom line: preserve the revision-5 interface direction and the settled handshake. Fold the reader-failure clarification into G3-READ, then resolve the already-named executable prerequisites. No architectural rewrite or additional review blocker is justified by this pass.
Verification and authority limits
Static review of the revised RFC, comparison with the previous head and integrated main, inspection of current authentication/UoW code, canonical evaluation semantics, and the scope-amendment record. The live PR head was rechecked. I did not independently rerun the reported checks, execute PostgreSQL/provider tests, or request hosted baselines.
This is a focused design-review disposition only. It does not close G2/G3, confer semantic or implementation approval, constitute baseline admission, authorize merge or deployment, or authorize closing #353. No baseline-admission comment or trigger is issued by this review.
Address revision-5 review S1 for issue #353 without changing the provider boundary or approved canonical semantics. Preserve complete no-path denial, canonical global ordering, path-local aggregation and separate infrastructure rollback handling. Add focused AUTH-007/009/010 verification and preserve the exact-head review history. G2/G3 and formal implementation approval remain open. The mandatory package, architecture, temporal and whitespace checks passed on final content.
|
Revision 6 is ready at This addresses non-blocking S1 from the zero-blocker revision-5 review: preserve complete no-authority denial, canonical global-failure ordering and dependent NOT_EVALUATED, path-local aggregation, and separate actual infrastructure failure. Incomplete reads or missing proof do not become fabricated complete snapshots or generic database errors. Primary boundary remains production authorization evaluation. One RFC only changes; +59/-20 against revision 5, 1,287 lines, blob Please review only the clarification and affected AUTH-007/009/010 and EXC invariants. The prior interface/handshake direction is preserved. G1 is applied; G2/G3 and formal implementation approval remain open. What is next: focused S1 review; obtain separate direction for the existing canonical prerequisites, not a fresh authorization redesign or new approval card. |
Revise Phase A for #353 in existing PR #359. Keep one production authorization evaluation boundary, full selected-rule coverage, distinct write/read inputs and explicit deferred human workflows. Preserve the open source-history and real-producer gates. Review pending; no runtime implementation or approval.
samovers
left a comment
samovers
left a comment
There was a problem hiding this comment.
PR #359 — revision 7 review
No blocking findings. No additional corrective patch requested for this revision. The revised scope is coherent, but the provider is not ready for implementation approval.
Reviewed head: feffb585ec569c6aaa8b5d085e94583d1eb9aeca, confirmed unchanged before posting.
Inspected/integrated runtime base: ff092c414db9fa24dbd6ab86c7722db89e0c95b5.
The revision changes only docs/rfcs/OFARM_Runtime_Authority_Action_Matrix_Evaluation_RFC_v0_1.md: 380 additions and 413 deletions relative to revision 6. It introduces no runtime changes.
Reviewed RFC at the exact head · Revision-6-to-7 diff
Assessment of the changed design
1. The two-action scope preserves complete rules rather than creating a partial evaluator.
RFC §2 requires exactly ASSERT_OPERATION_CLAIM and RECEIVE_READ_DATA, with membership derived from the verified canonical manifest. Missing, duplicate, extra or invalid rules cannot be repaired by evaluating a subset. Read coverage remains all selected resource alternatives and authority paths—not just reading back an operation claim. This matches canonical PR #11 §7.2.1 at its approved head and the amended delivery issue #353.
2. Removing the human-preparation API is consistent with the newly selected scope.
Both selected canonical rules use NOT_REQUIRED. The proposed single evaluate_authorization(call) operation therefore does not need the previous preparation/prospective-finalization handshake. The RFC explicitly defers that execution, preserves its design history and accounts for the affected AUTH invariants without claiming they pass. Crucially, it does not defer current identity, representation, CP3, session-validity or source-proof requirements merely because human finalization is absent.
3. Write and read inputs remain separate, and prepared authorization remains non-durable.
RFC §§6–8 distinguish owner-issued write attempts from governed-read attempts. Neither may substitute for the other. The provider supplies complete prepared evidence and record/set/absence/external/time obligations; transaction consumers retain protection, persistence, consumption and release.
The read path also requires continuity between authority observation and buffered retrieval. A coherent SELECT is not presented as sufficient commit protection, and canonical PR #26's write-only protocol is not stretched to cover reads. These are necessary distinctions, especially because the existing UoW at the reviewed head still starts READ COMMITTED and has no authorization entry point.
4. Committed-write recovery is correctly separated from current disclosure permission.
An exact committed retry must recover the verified original outcome without repeating or reauthorizing the original write or consumption. That does not guarantee disclosure of protected saved information today: a fresh governed-read evaluation may refuse it after permission loss.
RFC §8 and AUTH-018 make this distinction explicit, and amended issue #178 now states the same requirement. The original caller projection, bind-once intent and original assertedAt remain stable; a new attempt timestamp cannot manufacture a retry conflict.
5. The earlier reader-failure clarification remains intact.
The revised reader contract still distinguishes a completeness-proven absence of authority, an unproved global prerequisite, a failed individual path and an actual adapter/database failure. It does not turn every unsuccessful proof into infrastructure failure, infer absence from truncated results, or manufacture a valid snapshot to complete refusal evidence. The focused verification retains those distinctions.
What remains unresolved
G2 — Executable canonical dependencies. The complete selected dependency closure still needs the required materialization, binding review, promotion and byte-identical extraction. Source-history completeness and historical admission remain genuinely unresolved. Neither an inactive qualifying-record writer nor an empty lookup closes that gap. The RFC preserves this limitation rather than claiming that two actions are already sufficient for delivery. See canonical PR #11 §§24–24.1 at the approved head.
G3 — Real production interfaces and a measured implementation. Genuine input producers, compatible selection, canonical snapshot/visibility proof, bounded usable reads, and both write/read guard interfaces must exist before the provider can be demonstrated through production composition. The final facade/module partition also remains unmeasured; the RFC explicitly records zero UoW line-budget headroom and does not authorize automatic budget increases or relocation merely to hide growth. These are still substantive implementation prerequisites.
G4 — Fresh OFARM2 approval. Canonical scope approval does not authorize this implementation. The complete OFARM2 decision card and required later task-user approval remain outstanding under the repository's development procedure.
These gates prevent implementation approval; they are not additional defects introduced by revision 7.
Verification and disposition
This was a static design/source review covering the revised RFC, revision delta, review history, canonical scope requirements, amended issues #353/#178 and the existing UoW. I did not independently rerun the reported local checks or execute provider/PostgreSQL tests, and I requested no hosted baselines.
Disposition: zero blocking findings for revision 7's scope and affected design. Keep PR #359 draft while G2/G3 are resolved; no implementation, merge or issue-closure authorization follows from this review.
This is a design-review disposition only—not semantic approval, baseline admission, canonical promotion or deployment authority. No baseline-admission comment or trigger is issued by this review.
samovers
left a comment
samovers
left a comment
There was a problem hiding this comment.
PR #359 — revision 7, independent second pass at feffb585
Reviewed head: feffb585ec569c6aaa8b5d085e94583d1eb9aeca
Inspected/integrated runtime base: ff092c414db9fa24dbd6ab86c7722db89e0c95b5
Artifact: docs/rfcs/OFARM_Runtime_Authority_Action_Matrix_Evaluation_RFC_v0_1.md,
1,254 lines, 97,010 bytes, blob 6c02a3f1170ae8052ff8faaf5117a554f9d2d36b,
sha256:1ad64925eccb3e0e3a249cb62c7150d5c4d086e0650935d20f60e49412693b46.
One file changed against base (+1254/−0); against revision 6 725df163, +380/−413,
exactly as the PR description and the standing review state.
Position of this pass. Five reviews are on record on #359 (5065359533 at 178f150,
5125869052 at 1473a4c, 5126174929 at 263cd32, 5132918721 at 87584f2, 5187397905
at feffb585); a sixth pass of mine at 4f863fa exists only as a local file and was never
posted. This is the second pass at this head.
Review 5187397905 was posted at feffb585 on 2026-09-12T17:47:27Z with zero blocking
findings. It states plainly: "This was a static design/source review... I did not
independently rerun the reported local checks." This pass is the empirical complement —
I reran all four gates on the exact pinned interpreter, reproduced every count in the PR
description, measured the proposed facade against the real architecture checker, and
compared the RFC row-by-row against the canonical action matrix at the approved head.
Most of what follows confirms the standing review. One finding does not.
I extracted the head independently (anonymous clone, refs/pull/359/head) rather than
reading the branch in the workspace, whose local clone is at 58d2323 with unstaged changes.
- Blockers: 1 (B1)
- Follow-ups: 2 (F1, F2)
- Preferences: 0
Classification follows repo AGENTS.md "Review classifications" (Blocker / Follow-up /
Preference). This revision's RFC has no classification section of its own; §13's review
disposition only sets posture. B1 carries the six high-risk Blocker fields AGENTS.md
requires.
Revision of my own earlier call
My local revision-3 review at 4f863fa (still an ancestor of this head; never posted to
GitHub) raised one Blocker: "the challenge/final authorityRelevantStateDigest comparison
has no owner and no invariant."
That finding is dissolved, not answered, and I am withdrawing it. The reasoning:
canonical PR #11 §7.2 at the approved head 4494924 gives both first-release rules human
finalization NR = NOT_REQUIRED (lines 352 and 368 of the candidate file; the legend is
at line 343). With no fresh-approval flow in the selected scope there is no challenge
digest to compare, so the mechanism I said had no owner is correctly out of first-release
scope rather than unassigned. Revision 7 §10 disposes AUTH-015–017 and AUTH-019 as deferred
under #175 with the detailed design retained at revision 6, which is the honest way to park
it. I verified the two matrix rows myself rather than accepting the RFC's assertion at
line 98 that "Both selected rules retain NOT_REQUIRED."
B1 — Blocker: the rule-selected CP2 read-qualification evidence profile has no owner
Violated invariant. RFC §2 line 84: the provider "covers every selected resource
alternative and authority path"; line 9: "Neither selected rule is weakened." §4's owner
table (line 176) assigns the provider "Execute every projection/comparison required by the
selected rules and complete evidence closure." AUTH-001 requires full selected
evaluation coverage of both complete rules.
The canonical requirement. In the approved candidate at 4494924, §7.8's closed
rule-extension matrix binds an evidence profile per action:
| `ASSERT_OPERATION_CLAIM` | `EI_OPERATION_ASSERTION_V0_2` | ... | `EP_NONE` | SU | NA | (line 579)
| `RECEIVE_READ_DATA` | `EI_DATA_READ_V0_2` | ... | `EP_CP2_READ_QUALIFICATION_V0_2` | SU | NA | (line 595)
So of the two first-release rules, exactly one carries a non-EP_NONE evidence profile,
and it is the rule revision 7 newly makes executable. Canonical §7.7 line 555: "Each evidence
profile is itself an immutable policy binding in the final action rule. EP_NONE is an
explicit empty requirement, not a missing field." Line 1370 is explicit about who owns it:
Every actual read also requires the CP2 read-qualification evidence profile selected in
section 7.8; this is an authorization-rule requirement and does not redefine a CP3
posture value.
And the canonical hostile-case table makes its absence an authorization outcome, not a
release refusal (line 1722):
| Actual agent read lacks the rule-selected CP2 qualification evidence |
DENY;
PREFLIGHT_ONLYis not used to authorize the read |
Canonical also keeps the two senses of "qualification" apart, so this is not a conflation on
my side (line 1393): "CP2 qualification and lineage describe the result; they do not create
missing read authority."
What the RFC does with it. Nothing. Measured on the exact head:
$ grep -c "EP_\|evidence profile" rfc7.md
0
The RFC never names EP_CP2_READ_QUALIFICATION_V0_2, never names any evidence profile, and
never states that either selected rule binds one. Meanwhile it assigns "qualification" to the
read consumer in four places, none of which carves out the rule-bound evidence:
- line 502 — "the read consumer owns payload coverage, qualification, receipt/evidence persistence and release"
- line 752 — the governed-read consumer's protocol includes "full result-coverage/redaction/qualification"
- line 919 — "coverage, qualification, receipt and release still need their owners' tests"
- line 1185 (G3-HANDOFF) — "read coverage/qualification/receipts/release stay with their owners"
Nor does the obligation appear anywhere an implementer would look for an input. §6's
AuthorizationCall has three closed roles — attempt, selection, effect_intent — and
none of the three admits qualification evidence. §6's trusted-source map has no row for it.
The §6 reader plan's six steps mention "condition/evidence/purpose" generically at step 5 and
name nothing further. §10's nineteen AUTH rows contain no case for a read lacking it, and the
"Focused verification for the revision 7 selected interface" list — the section written
specifically for this revision's new scope — does not mention it either.
Production entry point. TenantUnitOfWork.evaluate_authorization(call) as proposed in
§6, reached through ApplicationRuntime.tenant_unit_of_work and the manager-created active
UoW.
In-scope actor. Any authenticated tenant principal, including a software agent: the
RECEIVE_READ_DATA row's agent posture is PC = AGENT_ALLOWED_WITH_POLICY_CHECK
(canonical line 368), and canonical line 1370 attaches the CP2 evidence requirement to
exactly that posture.
Exact path. Steps 1–15 of canonical §15.1 complete over a governed-read attempt whose
selection resolves RECEIVE_READ_DATA; one direct, role-targeted, delegated or SharingGrant
path is independently sufficient for the read target; §15.3 aggregation yields ALLOW;
§7's "Final decision evidence" builds the bundle; the handoff in §8 passes prepared ALLOW
to the read consumer.
Required preconditions. The caller supplies no CP2 read-qualification evidence, and every
other global and path check passes. Nothing else is needed — the RFC nowhere requires that
evidence, so the absence is not observed.
Material consequence. The provider prepares ALLOW where canonical requires DENY. The
consumer cannot repair it: canonical line 1393 says CP2 qualification "do[es] not create
missing read authority," so a consumer-side qualification step is by construction incapable of
supplying the authority the evaluator failed to require. The result is a prepared ALLOW for a
protected disclosure that never met one of its rule-bound requirements — precisely the
"complete selected coverage" claim §2 makes and canonical line 1825 names as a conformance
failure ("A claim-only RP_READ_TARGET_ONE implementation is presented as complete
RECEIVE_READ_DATA coverage → conformance failure; all unchanged selected resource
alternatives and authority paths remain required").
Minimal counterexample. This is a design document, so the counterexample is textual and
reproducible with two greps against the exact head:
$ grep -c "EP_\|evidence profile" <rfc at feffb585> → 0
$ grep -n "qualification" <rfc at feffb585> | grep -i consumer|owner
502, 752, 919, 1185 (all four assign it to the consumer)
versus canonical at 4494924: line 595 (the binding), 555 (it is a rule binding), 1370 (it is
an authorization-rule requirement), 1722 (its absence is DENY).
Smallest acceptable fix. One sentence in §7's "Complete source paths" or "Ingress and
policy" stating that RECEIVE_READ_DATA binds EP_CP2_READ_QUALIFICATION_V0_2, that
evaluating it is the provider's obligation, and that its absence yields canonical DENY; one
row in §6's trusted-source map naming where that evidence is read from and which producer
still owes it; one qualifying clause on the four consumer-ownership sentences distinguishing
rule-bound qualification evidence (provider) from result qualification/redaction
(consumer); and one negative case under AUTH-006 or AUTH-008. If the intent is instead that
this evidence is a G2/G3 dependency not yet mappable, §5's readiness inventory needs an
explicit row saying so — today it has none, and its nearest row (line 295) describes
"CP2 result/reasons," i.e. the output side.
Counter-argument, stated because the call is close. The RFC has generic clauses that a
charitable implementer could read as covering this: §4's "complete evidence closure" (line
176), §7's "Validate the policy bundle and every required per-action semantic-closure
binding," the reader's "condition/evidence/purpose" inputs at step 5, and AUTH-006's
"unresolved required evidence cannot be ignored" (line 835). If those are taken to control,
this is a Follow-up rather than a Blocker. I do not think they control, for two reasons.
First, the specific beats the generic in implementation: four unqualified sentences assigning
"qualification" to the consumer are what an implementer of §6 and §8 will build to, and there
is no text anywhere pulling the rule-bound half back. Second, revision 7 is the revision that
narrows scope to these two rules and adds a section of focused verification for exactly that
change; the single per-rule obligation unique to the newly selected read rule is the one thing
that scope narrowing was supposed to make concrete, and it is the one thing the revision does
not mention. A design whose stated claim is "neither selected rule is weakened" should name it.
F1 — Follow-up: AUTHORIZATION_TRACE as a read target is never acknowledged
Canonical line 485 fixes RP_READ_TARGET_ONE as "exactly 1 closed scope kind or exactly 1 of
OBSERVATION … PASSPORT_VIEW, or AUTHORIZATION_TRACE". Line 1397 makes the
self-referential case explicit: "Reading the full trace requires a separate
RECEIVE_READ_DATA decision over the exact AUTHORIZATION_TRACE target."
The RFC contains zero occurrences of AUTHORIZATION_TRACE (grep -c → 0), while §8 line 749
says "Full internal traces are not exposed by this provider" and §4 line 402 says "the provider
does not classify public history or release traces." Both statements are correct about the
provider's own output, and neither is the obligation: the provider must be able to authorize
a read whose target is an AUTHORIZATION_TRACE, produced by an earlier decision.
This is a Follow-up rather than a Blocker because AUTH-001 does generically require "every
branch of both complete selected rules, including all read-resource alternatives" (line
830), and §10 line 859 repeats it. The trace target is nonetheless the one alternative whose
handling is not obvious from that generic sentence — it interacts with the RFC's own
trace-internality language and invites an implementer to conclude it is out of scope. Naming
it once in §7 or §10 costs a line and removes the ambiguity. Worth recording against #175 or
the G3-READ item rather than expanding this PR.
F2 — Follow-up: §12's facade arithmetic is honest, but the measured minimum is twice its illustration
§12 says: "Adding eight lines to the UoW without removing others would mean 528/520 and
940/940 for its group; nine would also exceed the group. This arithmetic is not a size
estimate for a fully typed implementation."
That is arithmetically correct and properly disclaimed, and the §12 budget table reproduces
exactly at this head, which I verified rather than assumed:
| File/group | RFC §12 claims | Measured at feffb585 |
|---|---|---|
kernel/tenant_uow.py |
520 / 520 | 520 / 520 |
kernel/tenant_command_runtime_bundle_selector.py |
412 / 420 | 412 / 420 |
| tenant transaction group | 932 / 940 | 932 / 940 |
kernel/application_runtime.py |
221 / 230 | 221 / 230 |
| application runtime group | 420 / 500 | 420 / 500 |
So I am confirming §12, not refuting it. What I can add is a measured number where the RFC
offers an illustration. I wrote revision 7's exact proposed shape into kernel/tenant_uow.py
the way the repo already does injected callables (the resolve_bundle precedent), doing only
the four things §6 itself requires of the method — lifetime check, rollback-only check,
_finish sealing with a closed sentinel, and marking __rollback_only before re-raising —
with untyped object placeholders standing in for AuthorizationCall / EvaluationOutcome.
Then I ran the real checker on CPython 3.12.13 with the repository-pinned Ruff 0.15.5.
A faithful version is 20 lines. Golfed to the absolute minimum that still satisfies all
four requirements (inlined Callable annotation, one-line construction-site lambda, slot
appended to the existing tuple line), it is 17 lines:
FAIL kernel/tenant_uow.py:269: TenantUnitOfWork public surface is ['batch', 'begin_batch',
'binding', 'evaluate_authorization', 'resolve_commit_operation_claim_draft_runtime_bundle']
FAIL kernel/tenant_uow.py:269: TenantUnitOfWork slots differ
FAIL kernel/tenant_uow.py:276: TenantUnitOfWork accepts a non-facade dependency
FAIL kernel/tenant_uow.py: 537 lines exceeds 520
FAIL tenant transaction: 949 production lines exceeds group budget 940
Because object -> object placeholders are a lower bound and not an estimate, the real typed
hook is larger. The consequence for G3-SHAPE: §12's illustration lands the group at exactly
940/940 — i.e. reads as "just fits" — whereas the measured floor overshoots the group by 9
lines, and the selector's 8 lines of headroom cannot absorb it. Three of the five failures
are shape failures that no line-budget work fixes at all; §12 already says an added method,
dependency or slot needs explicit review of the new accepted shape, and this is what that
review will be looking at. I would state the 17-line floor and the five named failures in §12
instead of the eight-line illustration, so the G3 implementation plan starts from a measured
number. Not a Blocker: §12 disclaims the arithmetic as an illustration and correctly records
zero headroom, and no design decision in this revision depends on the difference.
Verification performed
All four gates reproduce, on CPython 3.12.13 built from the v3.12.13 tag (the checkers
refuse any other version via UNSUPPORTED_PYTHON_VERSION) with
requirements-review-baseline.lock and requirements-review-tools.lock installed
(--require-hashes), giving the repository-pinned Ruff 0.15.5 the architecture check demands:
$ PYTHONDONTWRITEBYTECODE=1 python conformance/ofarm_pkg_contract_check.py
parse check done / digest check done / instance validation done
TEMPORAL CANDIDATE PASS: CONFORMANT_CLASSIFIED
TEMPORAL DECISION LOG PASS
rewrite architecture constraints: PASS
RESULT: PASS (0 failures)
$ python conformance/rewrite_architecture_check.py → rewrite architecture constraints: PASS
$ python conformance/temporal_contract_candidate_check.py → TEMPORAL CANDIDATE PASS: CONFORMANT_CLASSIFIED
$ python conformance/temporal_decision_log_check.py → TEMPORAL DECISION LOG PASS
Every count in the PR description's "Verification of this head" reproduces exactly:
| PR claim | Measured |
|---|---|
| 380 additions / 413 deletions from revision 6 | git diff --stat 725df163 feffb585 → 380 / 413 |
| one RFC only; no runtime change | git diff --name-only ff092c4 feffb585 → 1 path, the RFC |
| whitespace check | git diff --check → clean |
| 14 numbered sections | grep -c '^## ' → 14 |
| 16 Markdown tables | grep -c '^|---' → 16 |
| all 19 AUTH rows and 7 EXC rows | AUTH-001…019, EXC-001…007 |
| 17 unchanged detailed AUTH rows | per-row md5 vs 725df163: exactly AUTH-002–017 and AUTH-019 identical; only AUTH-001 and AUTH-018 changed |
| unchanged reader-failure mapping | reader-failure table md5-identical to revision 6 |
| UoW has zero line-budget headroom | 520/520, group 932/940 (table above) |
EXC-007 is new in this revision (revision 6 had EXC-001–006); the PR description says
"EXC-001–007 remain," which understates it as retention rather than an addition. Trivial, not
worth a finding — noting it so the next reviewer does not re-check.
§9's pinned selector digest is correct and not an error:
sha256:6dad47b8…30309da1 is the canonical content digest of
ofarm.temporal-governed-command.commit-operation-claim-draft.v0.1, matching
conformance/temporal_contract_candidate_check.py:607 and the repo's own RuntimeBundle
Carrier RFC; the raw-file sha256 is the distinct instance digest
sha256:0909ec65…4b8f2e, also recorded there. The RFC quotes the right one.
Checked and decided were not findings
So the next reviewer does not re-spend these:
- Both selected rules are
NR. Verified at canonical §7.2 lines 352 and 368 against the
legend at line 344. Removingprepare_authorization,ProspectiveFinalizationand
PreparationOutcomeis consistent with the selected scope; §6 correctly refuses to replace
them with empty methods or success stubs, and §7 correctly forbids inventing an
approvalExpiresAtor human-approval requirement for aNOT_REQUIREDrule. - Agent posture is
PCfor both rows, notHA, so there is no human-approval path being
quietly skipped alongside the finalization deferral. - The AUTH-015/016/017/019 detailed rows still say "the same provider's bound preparation
operation" — a method this revision deletes. I checked whether that orphans them. It does
not: §10's applicability ledger dispositions them as deferred and says the exact detailed
design remains at revision 6, and the prose after the table repeats that the retained rows
"describe future obligations, not methods to expose or tests to mark passed in this release."
Retaining stale mechanism text under an explicit deferral disposition is the honest option,
not an inconsistency. - SharingGrant composition for
RECEIVE_READ_DATAis inside the final algorithm (§7,
"Evaluate the applicable SharingGrant composition inside the final authorization algorithm.
There is no later hidden sharing overlay"), matching canonical §13 and line 1889. AUTH-008
covers it. CURRENT_REPORT_AUTHORITY_ONLYvsCURRENT_ONLY. §9 correctly keeps the submitter's
current path from becoming historical performer authority, matching canonical line 617.- Committed-write retry versus current disclosure (§8, AUTH-018). Correct and correctly
separated; the standing review's point 4 holds. - Full-trace exposure. §8 line 749 ("Full internal traces are not exposed by this
provider") is consistent with canonical line 1397. The gap there is the read target, not
the output — see F1. - Architecture-checker shape pin. §12 quotes
_TENANT_UOW_PUBLIC_SURFACE,
_TENANT_UOW_INIT_PARAMETERSand_TENANT_UOW_SLOTScorrectly against
conformance/rewrite_architecture_check.pyat this head.
What could not be checked, and why
- No executable canonical bytes exist, so every claim about rule interpretation is a claim
about prose. I compared the RFC against the approved PR #11 candidate file at4494924;
that is semantic planning source, not the promoted contract the provider will load. B1 is a
design-document finding and will need re-verification against the actual promoted rule. - No runtime, PostgreSQL, or consumer-integration evidence. Nothing in this PR is
executable; the reader plan, guard handoff and evidence construction are all unimplemented.
I did not stand up a database, because there is no code to point one at. - The facade probe is a lower bound, not an implementation. My
object -> object
placeholders carry no real types, no imports and no reader; the third failure ("accepts a
non-facade dependency") is provoked by my untypedCallableparameter and would need the
reviewed shape extension regardless, so I count it as the design's, not my fixture's — but a
real implementation could trip different additional rules I did not exercise. - I did not verify the referenced GitHub comment bodies (#353's amendment comment, PR
#11's renewed approval comment, #178's amendment) beyond the review and PR metadata the API
returned. The scope-alignment claims that rest on them are taken as stated.
What my method made easier than production
- The greps prove absence in one document, not absence of the obligation from the delivered
system. If the CP2 read-qualification requirement is carried in a machine binding, a
consumer contract, or an issue thread I did not read, B1 is a documentation gap rather than a
design gap. I looked in the RFC, which is the artifact under review and the one that claims
complete coverage; I did not audit every adjacent OFARM2 document for a compensating
statement. - Reproducing the four gates proves the head is clean against the checks the repo already
runs. It proves nothing about the design, because a design-only RFC change cannot fail an
architecture or temporal checker. The PASS results are evidence of scope hygiene only, and
the standing review's decision not to run them cost it nothing on the substance. - The per-row md5 comparison detects changed rows, not changed meaning. AUTH-002–017 and
AUTH-019 are byte-identical, which is what "unchanged" should mean; but a row can be
byte-identical and semantically stale relative to a deleted mechanism, which is exactly the
AUTH-015 situation above. Byte equality was the cheap check; the disposition reading was the
real one. - Building 3.12.13 from source satisfies the checker's version gate exactly, by design.
The gate issys.version_info[:3] == (3,12,13)plus posix/filesystem-encoding facts. My
interpreter is a plain./configure && makebuild with no optimizations, so it is not the
same binary the author used; identical gate results do not prove identical interpreters.
Review-gate note
All six reviews on this PR, including the standing revision-7 review, are authored by
samovers, who is also the PR author. GitHub refuses APPROVE and REQUEST_CHANGES from the
author (422), so every one is a COMMENT. This pass is no different — it is another
samovers-authored review. G4 requires "review this corrected Phase A to zero Blockers" before
the decision card; a self-review almost certainly does not satisfy an independence requirement,
and the record should not be read as though it does. Worth saying plainly rather than letting
the zero-Blocker disposition at this head look like an independent clearance.
Disposition
One Blocker (B1), two Follow-ups (F1, F2). Revision 7's scope reduction is coherent, its
deferral of the human-approval programme is legitimate and correctly grounded in the NR
rows, and its self-reported verification is accurate in every count I could reproduce — the
standing review is right about all of that. The gap is one rule-bound obligation on the newly
concrete read rule. Keep #359 draft. No implementation, merge, promotion, issue closure or
deployment authorization follows from this review, and it is not semantic approval, baseline
admission or canonical promotion.
What is next: correct B1 in §§6–7 and §10, record F1 and F2 against G3-READ / G3-SHAPE, then
close the standing G2/G3 owner dependencies before presenting the fresh #353 decision card.
Address revision 7 review B1 for #353 in existing PR #359. Keep evaluation of the exact read evidence profile inside production authorization and result qualification with its consumer. Name the closed input role, real producer dependencies and focused cases; retain F1/F2 under G3. Phase A only, review pending; no runtime or canonical changes.
samovers
left a comment
samovers
left a comment
There was a problem hiding this comment.
PR #359 — revision 8, focused re-review of the B1 correction at f97fe8f7
Reviewed head: f97fe8f73d956d2dd6c0f82f133d6800b71055fe
Inspected/integrated runtime base: ff092c414db9fa24dbd6ab86c7722db89e0c95b5
Artifact: docs/rfcs/OFARM_Runtime_Authority_Action_Matrix_Evaluation_RFC_v0_1.md,
1,368 lines, 106,710 bytes, blob fc259dd664d6e2e076ad07b7a3b546905500b1b9,
sha256:d29d9e5cf431cba391631ce2d70c758708197c610960504987ff5b2a83370a0d.
One file changed against base (+1368/−0); against revision 7 feffb585, +144/−30,
exactly as the PR description states. One commit: f97fe8f "Clarify rule-bound read
qualification evidence ownership".
Position and scope. This is the first review at this head. Both AGENTS.md ("after a fix,
review only the fix and affected invariants unless new evidence demonstrates that the original
scope is unsafe") and the RFC's own §11 restrict this pass to B1's correction, the affected
failure/handoff invariants and the follow-up records. I accept that restriction, and everything
below sits inside it — both findings are on text this revision added.
- Blockers: 1 (B2)
- Follow-ups: 1 (F3)
- Preferences: 0
Classification follows repo AGENTS.md. B2 carries the six high-risk Blocker fields.
The correction is real, and it lands in the right places
My revision-7 B1 said the rule-bound CP2 read-qualification evidence profile had no owner.
Revision 8 fixes that at every site I named, plus two I did not:
| Where | What landed |
|---|---|
| §4 owner table, line 183 | New row: evaluation of the selected action-level evidence policy, including CP2 read-qualification, is this provider's; "Neither ownership substitutes for the other." |
| §5 readiness inventory, line 304 | New row naming EP_CP2_READ_QUALIFICATION_V0_2 and keeping its policy bytes/schemas at G2, its producer at G3 |
§6 attempt role, line 365 |
Read form now carries the rule-bound qualification-evidence observation |
| §6 trusted-source map, line 429 | New row: the provider evaluates the profile and records individual evidence dispositions before ALLOW |
| §6 reader plan step 5 | Now derives "the referenced evidence for the selected action-level read-qualification profile" |
| §6 line 533 | "qualification" → "result qualification", with an explicit carve-out that this "does not move evaluation of rule-bound qualification evidence out of this provider" |
| §7, new subsection at line 624 | "Rule-bound action-level evidence" — the substantive fix |
| §8 line 820 | Carve-out repeated through the handoff: "a later consumer check cannot retrospectively make an incomplete ALLOW valid" |
| §10 AUTH-006, line 901 | Negative case added: omit the evidence on an otherwise sufficient read → canonical DENY, never prepared ALLOW |
| §10 focused verification | New AUTH-006/008/010/013 bullet covering all four path forms, the software-agent case, substituted proof, and a fully proved positive case |
| §13 G3-READ / G3-HANDOFF | Producer and ordering obligations recorded without inventing a source |
The measurable shift: EP_/"evidence profile" mentions went 0 → 7, AUTHORIZATION_TRACE
0 → 2. The correction is also properly contained — exactly one detailed AUTH row changed
(AUTH-006, verified by per-row md5 against feffb585), the reader-failure mapping is
byte-identical, and the section/table/AUTH/EXC structure is unchanged at 14/16/19/7.
Three substantive things the revision got right that it did not have to:
- §7 line 626 names the real canonical field,
evidenceRequirementPolicyRefs. I checked: it
exists, at canonical §12.3 line 855, and it is the onlyevidence*field name in the
document. The RFC did not invent a plausible-looking field. - The cumulative rule is stated correctly — "Every selected action-level policy and every
source-path evidence requirement must pass cumulatively… One sufficient grant cannot replace
the read evidence" — matching canonical §12.4 line 869 ("a sharing path must pass the action
rule and SharingGrant groups… No source or policy overrides, erases, or weakens another"). EP_NONEis handled as "an explicit empty action-level requirement, not missing policy and
not a waiver of source evidence groups," matching canonical §7.7 line 555.
Every canonical section the correction cites checks out: §7.7 (555), §7.8 (579/595), §12
"Conditions, limits, and required evidence" (822), §18.5 "Governed reads and protected
disclosure" (1368), §22 "Production-reachable hostile cases" (1695, with the agent-read DENY
case at 1722).
B1 is closed except for one thing: the carrier the correction proposes.
B2 — Blocker: the attempt-carried "immutable proof values" mode has no canonical admission path
Violated invariant. The RFC's own AUTH-002 (line 897): "callers cannot choose restrictions
or mirrored proof." And canonical §12.5's resolution contract.
The new text. §6 lines 401–408:
The proposed carrier for read-qualification proof is the closed governed-read
attemptrole,
supplied by its separately owned read/evidence producer before final authorization evaluation.
It carries immutable proof values or exact revision/digest references and truthful
missing/invalid observations, not a caller-setqualifiedflag or an asserted prior ALLOW.
Referenced governed records are resolved through the provider's typed tenant reader.
The §6 source-map row at line 429 repeats it: "supplies immutable proof values/refs".
So the carrier has two modes. The reference mode is correct and canonical-compatible — the
typed reader resolves the governed record. The value mode is not.
Why canonical does not admit it. Canonical's evidence model is reference-resolution only,
end to end:
- §12.3 line 855 fixes the only two origins of evidence requirements: the action rule's
evidenceRequirementPolicyRefs, and typedrequiredEvidencegroups on AuthorityGrant /
DelegationGrant / SharingGrant. Each group isrequiredEvidencePolicyRefplus a
"requiredEvidenceRefsarray whose members also bind immutable revisions or content
digests", and "No v0.2 source may carry unqualified evidence references." - §12.5 line 884, the first requirement on every piece of evidence: "Every required evidence
reference must: resolve to the exact immutable revision or content digest recorded by the
decision" — then family, subject-time/authorization-time validity, staleness, dispute/
withdrawal/supersession state, tenant and sovereignty boundary, binding to target/subject/
intent/scope, and purpose eligibility. Every one of those eight checks is a property of the
resolved record. A value handed in by a frame resolves nothing, so none of the eight can be
performed against it. - §12.5 line 895 closes: "Opaque existence of a logical reference is not evidence eligibility."
- Canonical line 1637: "The validated effect intent is the only caller-authored source of
operation facts; mirrored resource, subject, scope, time, purpose, grantee, destination,
rights, or payload fields are prohibited." Line 160 says the same for authoritative copies. - Canonical line 993: "No later step may repair missing proof from an earlier step by trusting
a caller assertion."
Production entry point. TenantUnitOfWork.evaluate_authorization(call) with a governed-read
attempt whose qualification-evidence observation is populated in value mode.
In-scope actor. The separately owned read/evidence producer — and, through it, anything that
can influence what that producer emits. The RFC's own §6 warns that "Production composition must
obtain attempt and selection from their reviewed owning factories," but the value mode makes
the frame itself authoritative rather than a pointer into governed storage, so the trust question
moves from "is this reference resolvable and eligible" to "do we trust this frame's contents" —
which is the question AUTH-002 exists to keep closed.
Exact path. Canonical §15.1 steps 1–11 evaluate the read; at step 11 ("cumulative evidence
requirements per path") the evaluator must apply EP_CP2_READ_QUALIFICATION_V0_2 under §12.5.
With a value-mode observation there is no resolved immutable revision, so the evaluator either
(a) accepts the carried value and marks the requirement satisfied — a mirrored authoritative
fact, or (b) cannot evaluate it at all. Path (a) reaches §15.3 aggregation as ALLOW and §8's
handoff as prepared ALLOW.
Required preconditions. A governed-read attempt where the producer emits qualification proof
as values rather than references, and every other check passes.
Material consequence. Prepared ALLOW for a protected disclosure resting on a fact the
provider asserted rather than resolved. This is the same failure class B1 named — authority that
was never actually proven — relocated from "nobody checks it" to "it is checked against
something unverifiable." Because the RFC's §7 subsection promises the provider "verifies the
exact eligible evidence, intent/target/scope/tenant/sovereignty/purpose bindings, time and state"
(line 636), the value mode also makes that promise unkeepable: those are precisely §12.5's
record properties.
Minimal counterexample. Textual and reproducible:
rfc8.md:403 "It carries immutable proof values or exact revision/digest references"
rfc8.md:429 "supplies immutable proof values/refs or explicit missing/invalid observations"
versus
canon.md:855 evidence requirements originate only from rule policy refs and typed grant groups
canon.md:861 "requiredEvidenceRefs array whose members also bind immutable revisions or digests"
canon.md:884 "resolve to the exact immutable revision or content digest recorded by the decision"
canon.md:895 "Opaque existence of a logical reference is not evidence eligibility"
canon.md:1637 "the validated effect intent is the only caller-authored source of operation facts"
Smallest acceptable fix. Delete "immutable proof values or" from line 403 and "values/" from
line 429, leaving the reference mode and the truthful missing/invalid observations. Add one
sentence stating that every required evidence reference is resolved by the provider's typed
reader in the bound snapshot and evaluated against canonical §12.5's eligibility list, and that
no evidence fact is accepted from the frame itself. That is a two-word deletion plus a sentence,
and it makes the §7 verification promise achievable.
Counter-argument, stated because the call is close. The attempt frame is owner-issued from
a reviewed factory inside the trust boundary, not caller-authored, so canonical's
"caller-authored" prohibitions at lines 160/1637 do not name it directly; and the RFC hedges the
whole carrier as "a local input-role proposal, not a new canonical schema, evidence kind or
producer implementation," with field mapping deferred to G3 (lines 410–417). On that reading
G3 would catch the form problem and this is a Follow-up. I do not think so. §12.5's resolution
requirement is about the evidence, not about who supplies it — a value does not resolve no
matter how trusted its producer. And the RFC is careful enough elsewhere to reject the weak
forms it anticipated (a caller-set qualified flag, an asserted prior ALLOW, an unbound later
payload, a same-read receipt); the value mode is the same pattern one step less obvious, and it
is sitting in the sentence that rejects the others. It is in-boundary text this revision
authored, so it is a Blocker or a Preference, and it is not a Preference.
F3 — Follow-up: an unretrievable evidence policy is routed to admission, where canonical gives REQUIRE_REVIEW
§7 line 645, in the new subsection: "Missing package/profile bindings still block
admission/readiness."
For a missing package that is right — canonical §7.2.1 makes a package with missing, duplicate,
extra or invalid members inadmissible, and admission "must stop before authorization evaluation."
For a missing evidence profile binding canonical says something different, at §12.4 line 878:
Until an evidence policy is active/current and its exact revision is retrievable, the
requirement isUNSUPPORTED_EVIDENCE_POLICYand cannot supportALLOW.
And §15.6's reason table at line 1566 gives that code a decision outcome:
| `UNSUPPORTED_EVIDENCE_POLICY` | `REQUIRE_REVIEW` | 240 |
So canonical routes it to a canonical REQUIRE_REVIEW decision with an individual evidence
disposition in the trace — not to an ingress/admission stop, which produces no decision evidence
at all. Canonical keeps the two surfaces explicitly separate a few lines above the table: the
INGRESS_* codes "may appear only in AuthorizationRequestRejection or runtime/security
telemetry. They must not be placed in a decision result."
This is not hypothetical for first release. The RFC's own §5 row at line 304 says the exact
policy ref/digest for EP_CP2_READ_QUALIFICATION_V0_2 remains G2 — i.e. not yet active/current
and not retrievable. So on the day this ships, canonical's disposition for every actual read is
exactly this branch, and the RFC currently describes it as an admission block.
Why Follow-up and not Blocker. The same subsection carries a catch-all one sentence earlier
(line 642): "Other invalid or unsupported evidence follows its exact canonical disposition, not a
newly invented reason or an indiscriminate infrastructure exception." An unretrievable policy is
fairly read as "unsupported evidence," so the catch-all probably rescues the outcome, and the
error direction is fail-closed — blocking is stricter than REQUIRE_REVIEW, so nothing is let
through. It is an ambiguity in new text rather than a demonstrated wrong outcome. Without that
catch-all I would have called it a Blocker. The fix is one clause on line 645 distinguishing a
missing package (admission) from an unretrievable evidence policy (UNSUPPORTED_EVIDENCE_POLICY
→ REQUIRE_REVIEW, rank 240).
How my revision-7 follow-ups were handled
- F1 (
AUTHORIZATION_TRACE) — recorded under G3-READ in §13, correctly and without
narrowing the release scope: "fullRP_READ_TARGET_ONEcoverage includes an existing
AUTHORIZATION_TRACEtarget and a separateRECEIVE_READ_DATAdecision for that read," with
eligible-trace-read and refusal cases assigned to eventual AUTH-001/006 coverage, and an
explicit statement that this neither exposes the provider's own internal output nor activates
an endpoint. That is the right disposition. Closed. - F2 (facade probe) — recorded in §12, and I checked the transcription against my own
measurements: "20 added lines in a straightforward version and 17 in a compressed version. The
latter reached 537/520 UoW lines and 949/940 group lines; the existing checker also rejected
its public surface, slots and non-facade dependency." All five numbers and all three shape
failures are accurate. The qualification — "the reviewer's specific experiments, not a
universal minimum, a typed implementation estimate or an approved budget" — is also correct
and is exactly how I framed it; untypedobjectplaceholders are a lower bound. Closed.
Both were carried without being used to expand the PR, which is what AGENTS.md asks of a
Follow-up.
Verification performed
All four gates rerun at this head on CPython 3.12.13 built from the v3.12.13 tag, with
requirements-review-baseline.lock and requirements-review-tools.lock installed
(--require-hashes), supplying the repository-pinned Ruff 0.15.5:
$ PYTHONDONTWRITEBYTECODE=1 python conformance/ofarm_pkg_contract_check.py → RESULT: PASS (0 failures)
$ python conformance/rewrite_architecture_check.py → rewrite architecture constraints: PASS
$ python conformance/temporal_contract_candidate_check.py → TEMPORAL CANDIDATE PASS: CONFORMANT_CLASSIFIED
$ python conformance/temporal_decision_log_check.py → TEMPORAL DECISION LOG PASS
$ git diff --check ff092c4 f97fe8f7 → clean
| PR claim | Measured |
|---|---|
144 additions / 30 deletions vs feffb585 |
144 / 30 |
| one RFC only; no runtime/checker/contract change | git diff --name-only ff092c4 f97fe8f7 → 1 path |
| correction confined to the B1 ownership split | exactly one detailed AUTH row changed (AUTH-006), per-row md5 |
| reader-failure mapping preserved | md5-identical to revision 7 |
| structure unchanged | 14 sections, 16 tables, AUTH-001…019, EXC-001…007 — all unchanged |
| budgets unchanged | tenant_uow 520/520, selector 412/420, application_runtime 221/230 |
| F2 probe figures | 537/520, 949/940, 20 and 17 lines, three shape failures — all match my measurements |
Checked and decided were not findings
evidenceRequirementPolicyRefsis a real canonical field (§12.3 line 855), not invented.- The cumulative-evidence statement matches §12.4 exactly, including that a sharing path must
pass both the action rule and the SharingGrant groups. EP_NONEon the claim rule is correctly described as an explicit empty requirement that
does not waive source evidence groups, and the new focused-verification bullet tests exactly
that ("EP_NONEon a claim must not bypass required source evidence").- The ordering / chicken-and-egg problem — whether qualification proof about a read result
can exist before the read is authorized. The RFC anticipates it (lines 413–417) and refuses
every escape: "no unbound payload supplied after evaluation, completed receipt from the same
read, synthetic proof or premature disclosure can fill the gap," leaving the gate open under
G3 rather than closing it with a fiction. Canonical §12.3 line 865 permits derivation from the
exacteffectIntentDigest, which is a legitimate pre-read route. Correctly handled. - §18.5's one-snapshot requirement ("One governed read snapshot must cover authorization,
retrieval, redaction, qualification, coverage proof, and payload construction") is carried by
the RFC's same-snapshot/protection-context language in §6 and §8. - AUTH-006's "canonical DENY" for absent evidence is right; §12.5 line 893 makes missing
evidence produce non-ALLOWwith an individual disposition, and §22 line 1722 makes the
agent-read caseDENYspecifically. - §11's account of the two revision-7 reviews is accurate, including that the earlier
zero-Blocker disposition "does not override" the later finding.
What could not be checked, and why
- Still no executable canonical bytes. Every judgement here compares prose to prose. B2 will
need re-verification against the promoted evidence-policy contract when G2 supplies it — and
it is possible that contract admits a value form I cannot see from the candidate. - No runtime, PostgreSQL or producer evidence, because none exists. The read/evidence
producer B2 concerns is explicitly unbuilt; I am reviewing a proposed input role, not a seam. - I did not re-run the facade probe at this head. The budgets are byte-identical to
revision 7 and the revision changes no Python, so the revision-7 measurement carries; I
verified the three file line counts rather than assuming. - I did not re-audit the unaffected parts of the RFC, per the scope restriction. The
two-action scope, human-workflow deferral, write/read separation and handoff forms were
reviewed atfeffb585and are unchanged here.
What my method made easier than production
- Both findings are "canonical says X, the RFC says Y" comparisons. That is only as good as
my reading of which canonical clause governs. On B2 the governing clause is §12.5's resolution
requirement; if the promoted policy or a reviewer with more context reads the evidence model as
admitting producer-supplied values, B2 collapses to a wording preference. - The gates passing proves scope hygiene, not design correctness. A documentation-only change
cannot fail an architecture or temporal checker. Their PASS is evidence that nothing else moved. - Per-row md5 detects changed rows, not changed meaning — the same caveat as last pass. It
told me AUTH-006 was the only detailed row touched; reading the ledger dispositions was the
real check. - I verified the F2 transcription against my own numbers, which is a check that the revision
copied me accurately, not that my numbers were right. They were untyped lower-bound probes and
remain so.
Review-gate note
Unchanged from last pass and still worth stating: all seven reviews on #359, including both at
feffb585 and this one, are authored by samovers, who is also the PR author. GitHub refuses
APPROVE and REQUEST_CHANGES from the author (422), so every one is a COMMENT. G4 requires review
to zero Blockers before the decision card; a self-review very likely does not satisfy an
independence requirement, and the record should not be read as though it does.
Disposition
One Blocker (B2), one Follow-up (F3). The B1 correction is well-targeted, well-contained and
in most respects better than the minimum I asked for — it names the profile, splits the two
senses of qualification through four sections, keeps the missing producer honest as a G2/G3 gate,
and records both follow-ups accurately without expanding the PR. The single defect is in the
carrier it proposes: two words admit an evidence form canonical's §12.5 cannot evaluate. Keep
#359 draft. No implementation, merge, promotion, issue closure or deployment authorization
follows from this review, and it is not semantic approval, baseline admission or canonical
promotion.
What is next: delete the value mode from §6 lines 403 and 429 and add the §12.5 resolution
sentence; add the one-clause package-versus-policy distinction on line 645; then close the
standing G2/G3 owner dependencies before presenting the fresh #353 decision card.
Address review B2 and F3 on PR #359. Require snapshot-bound reference resolution instead of frame-carried proof values, and distinguish package admission from canonical unsupported-evidence-policy handling. Preserve the two-action scope and open G2/G3/G4 gates. Design-only correction for #353; no runtime or canonical changes.
samovers
left a comment
samovers
left a comment
There was a problem hiding this comment.
PR #359 — revision 9, focused re-review of the B2/F3 corrections at 7de8a2c4
Reviewed head: 7de8a2c4cf6eb1f293560af67e69565122c42f25
Inspected/integrated runtime base: ff092c414db9fa24dbd6ab86c7722db89e0c95b5
Artifact: docs/rfcs/OFARM_Runtime_Authority_Action_Matrix_Evaluation_RFC_v0_1.md,
1,404 lines, 109,251 bytes, blob d59f68f29e071904bb89d3822f05afda914e22f9,
sha256:dfb458275114a543f04cb23eb55c0bd6804b4cc16d562c8bc37b890c04b1a123.
One file changed against base (+1404/−0); against revision 8 f97fe8f7, +62/−26,
exactly as the PR description states. One commit: 7de8a2c "Require resolved read evidence
and canonical policy failures".
Position and scope. First review at this head, and the third consecutive pass by me on this
series. Both AGENTS.md and the RFC's §11 restrict it to B2, F3 and affected invariants, and
I have kept to that.
- Blockers: 0
- Follow-ups: 1 (F4)
- Preferences: 0
Both findings from the revision-8 review are closed. I went looking for a defect introduced
by this fix, as I did on revision 8 where the correction carried one. This time I did not find
one, and I would rather say that plainly than manufacture a third Blocker to justify the pass.
B2 — closed
The two-word deletion landed, and so did the sentence I asked for. §6 lines 404–414 now read:
It carries exact immutable revision/digest references and truthful missing/invalid
observations, not a caller-setqualifiedflag or an asserted prior ALLOW. Every required
evidence reference must resolve through the provider's typed tenant reader in the bound
snapshot to the exact revision/digest recorded by the decision and satisfy canonical section
12.5's full eligibility checks under the selected policy. No evidence fact is accepted from
the frame itself. The provider verifies the resolved evidence's exact effect-intent binding
and the same governed snapshot/protection context.
The trusted-source row at line 435 carries the same rule and states the prohibition directly:
"exact immutable revision/digest references or explicit missing/invalid observations, never
authoritative proof values… the provider applies canonical section 12.5 eligibility."
I checked for residue. grep -n -i "proof value" on the head returns four hits and every one is
a prohibition or a negative test case — the revision header (line 8, "not accepted as proof
values from an attempt frame"), line 435's "never authoritative proof values", the new
verification bullet at line 976, and one unrelated use in §12's module description
("selected-proof values" describing the evaluator's immutable output). The admitted form is
gone.
This matches canonical exactly: §12.5 line 884 ("resolve to the exact immutable revision or
content digest recorded by the decision") and its eight eligibility checks, line 895 ("Opaque
existence of a logical reference is not evidence eligibility"), §12.3 line 861 (every
requiredEvidenceRefs member binds immutable revisions or content digests), and lines 160/1637
on mirrored authoritative facts.
The reference-carrying route that remains is admissible, and I want to be explicit about why,
since it is the obvious next question. A reference supplied by the read/evidence producer is a
retrieval hint, not an authority fact: canonical line 160 permits a caller to "provide retrieval
hints," and every property that could grant authority — family, subject-time and
authorization-time validity, staleness, dispute/withdrawal/supersession state, tenant and
sovereignty boundary, binding to target/subject/intent/scope, purpose eligibility — is checked
against the resolved record under §12.5. A forged or substituted reference fails those checks.
Completeness is anchored in the policy rather than the frame, so omitting a reference cannot
satisfy a requirement; the focused verification tests exactly that.
F3 — closed
§7 lines 651–657 now separate the two failure surfaces, with the canonical reason code, default
outcome and rank:
Missing or invalid executable-package bindings still block admission/readiness; malformed
ingress does not become fabricated decision evidence. In an otherwise admitted evaluation,
an evidence policy that is not active/current or whose exact revision is not retrievable has
canonicalUNSUPPORTED_EVIDENCE_POLICY(defaultREQUIRE_REVIEW, rank 240), with individual
evidence dispositions and the canonical aggregation rules, not an ingress rejection. This
distinction does not close the outstanding G2 readiness gate.
Verified against canonical: §12.4 line 878 is the "not active/current… exact revision
retrievable" condition and the UNSUPPORTED_EVIDENCE_POLICY disposition; §15.6's reason table
at line 1566 gives REQUIRE_REVIEW and rank 240; §7.7 line 568 ("Every non-NONE profile
must have a content-addressed policy ref/digest in the binding manifest before accepted
promotion") is what makes the package half an admission matter. The last clause is the right
instinct — the distinction is about failure shape, and it does not make the missing G2 bytes any
less missing.
Both corrections also got matching negative cases. The new focused-verification bullet at line
976 covers AUTH-002/006/009/010/013: proof values in an owner-issued frame without resolvable
references cannot satisfy the policy; the existing positive case must use evidence resolved in
the bound snapshot; and invalid package admission (no decision) is contrasted with an admitted
evaluation whose evidence policy is unretrievable, requiring UNSUPPORTED_EVIDENCE_POLICY /
REQUIRE_REVIEW and individual dispositions rather than an ingress refusal.
F4 — Follow-up: canonical's own derivation route for action-level evidence is never mentioned
§6 line 404 opens: "The proposed carrier for read-qualification proof is the closed
governed-read attempt role, supplied by its separately owned read/evidence producer." That is
stated as the route, singular. Canonical names a different one for action-level policies, at
§12.3 line 865:
An action-rule policy may derive required evidence from the exact
effectIntentDigest; it
cannot depend on an unbound payload supplied after evaluation.
The RFC contains zero occurrences of effectIntentDigest or any equivalent phrasing. This
matters because of the RFC's own honesty elsewhere: §5 line 307 keeps the exact policy
ref/digest for EP_CP2_READ_QUALIFICATION_V0_2 at G2, so nobody yet knows what the policy
requires or how it derives it. If the promoted policy derives its required evidence from the
effect intent, the evaluator computes the required references itself and the producer/carrier
in §6 is unnecessary — and G3-READ and G3-HANDOFF currently commission that producer as
required closure evidence ("the exact rule-bound qualification-evidence source/producer",
"prove read-qualification inputs reach final evaluation in the required context/order").
Nothing here is unsafe: the derivation question changes who supplies references, not whether
they are resolved and eligibility-checked, and §12.5 gates the outcome either way. It is a
sequencing risk — potentially commissioning a producer that the policy makes redundant, and a
G3 gate that cannot be closed as written if no carrier is needed.
Suggested handling. One clause in §6 noting that canonical §12.3 permits an action-level
policy to derive required evidence from the exact effectIntentDigest, and that whether a
carrier is needed at all is settled when G2 supplies the policy; and one clause on the G3-READ
row making the producer conditional on that answer. Recorded as a Follow-up rather than a
Blocker because the work it implies — reading the promoted policy — is G2 work outside this PR,
and because the RFC already hedges the whole carrier as "a local input-role proposal" whose
"field mapping, pre-evaluation availability" G3 must settle.
Verification performed
All four gates rerun at this head on CPython 3.12.13 built from the v3.12.13 tag, with
requirements-review-baseline.lock and requirements-review-tools.lock installed
(--require-hashes), supplying the repository-pinned Ruff 0.15.5:
$ PYTHONDONTWRITEBYTECODE=1 python conformance/ofarm_pkg_contract_check.py → RESULT: PASS (0 failures)
$ python conformance/rewrite_architecture_check.py → rewrite architecture constraints: PASS
$ python conformance/temporal_contract_candidate_check.py → TEMPORAL CANDIDATE PASS: CONFORMANT_CLASSIFIED
$ python conformance/temporal_decision_log_check.py → TEMPORAL DECISION LOG PASS
$ git diff --check ff092c4 7de8a2c4 → clean
Every count in the PR description reproduces, including the unusually specific one:
| PR claim | Measured |
|---|---|
| 62 additions / 26 deletions vs revision 8 | 62 / 26 |
| one RFC only, against both prior head and base | git diff --name-only → 1 path |
| 14 numbered sections, 16 tables | 14, 16 |
| "16 tables (15 byte-identical; only the evidence-source table changed)" | per-table md5: 15 of 16 identical; the one that changed is the trusted-source map, header | Required fact | Existing source and provider use | Remaining owner dependency | — exactly as claimed |
| all 19 AUTH rows, all 7 EXC rows | AUTH-001…019, EXC-001…007 |
| all code blocks preserved | 6 fences at both heads |
| reader-failure mapping unchanged | md5-identical to revisions 7 and 8 |
| budgets untouched | tenant_uow 520/520, selector 412/420, application_runtime 221/230 |
Containment is tighter than the previous correction: no detailed AUTH row changed at all
this time (per-row md5 across all nineteen against f97fe8f7), because the fix lands in §6/§7
prose and the focused-verification list rather than the invariant ledger.
Checked and decided were not findings
- Whether
UNSUPPORTED_EVIDENCE_POLICYon the action-level policy is a global or a path-local
failure. This was my strongest candidate for a new Blocker and it does not survive. Canonical
line 1037 is emphatic that "when any global failure exists, candidate paths are not aggregated
and no selected path is required," and the action-level evidence policy is decision-wide, so
the new §7 paragraph's "with individual evidence dispositions and the canonical aggregation
rules" could be read as implying path aggregation where canonical suppresses it. Two things
defeat the reading. "Individual evidence dispositions" is lifted verbatim from canonical
§12.5 line 893, which attaches them to evidence failures generally, not to path aggregation.
And the very next subsection, at line 667, already states the rule correctly: "give established
global DENY precedence over global REQUIRE_REVIEW. Global failure prevents path
aggregation." The new paragraph is read in that context. Not a finding. - The other non-default per-rule cells. I re-ran the column sweep that produced B1. The
selected rules' remaining cells areEI_OPERATION_ASSERTION_V0_2/EI_DATA_READ_V0_2
(intent profiles),RP_SCOPE_ONE/RP_READ_TARGET_ONE,TX(TRANSACTION_BOUND_V0_2),
CR/C,SU,NA. The RFC names almost none of those tokens — but unlike the evidence
profile, every one is described functionally with a correct owner: the rule-selected
effect-intent schema the caller cannot choose (§7 ingress),decisionValidUntilvia PR #11
§18.2 (§7, §8), single-use enforcement assigned to the consumer's transaction profile (§8),
the report-authority posture (§9). A missing token is not a missing obligation. B1 was a
finding because that profile had no functional description and was assigned to the wrong
owner; these are neither. - Whether the frame can suppress evidence by reporting it missing/invalid. It can, and the
effect is denial — fail-closed, and it cannot improve an outcome under §15.5's lattice. - Whether the typed reader can actually reach CP2 qualification evidence. Unknown, and the
RFC says so rather than assuming: line 435 states that "No existing table, CP2 public-result
implementation or PR #34 writer is presumed to supply them." Correct handling of an open gate. - §11's account of my revision-8 review (line 1154 onward) is accurate: it records that the
review "accepted the ownership correction and F1/F2 records, while reporting B2… and F3," and
that accepting those records "did not close the underlying G3 work or approve implementation."
That is what the review said.
What could not be checked, and why
- Still prose against prose. No executable canonical bytes exist; B2's closure is verified
against the approved candidate, not the promoted contract. If the eventual policy admits a
form I cannot see from the candidate, this reading moves. - F4 cannot be resolved from here. Whether the policy derives evidence from the effect
intent is a property of bytes that do not exist yet. I am flagging the omission, not
predicting the answer. - No runtime, PostgreSQL or producer evidence, because none exists. Every case in §10
remains a test specification. - I did not re-run the facade probe or re-audit unaffected sections, per the scope
restriction. Budgets are byte-identical and no Python changed.
What my method made easier than production
- Closing a finding is easier than finding one, and I closed two. Verifying that a two-word
deletion happened is a grep; verifying that the deletion was the right fix required only
re-reading the canonical clause I had already located last pass. The work that justified this
pass was the search for a new defect, and that search came back empty — which is a weaker
result than a confirmed absence. - "I looked and found nothing" is bounded by where I looked. I swept the per-rule columns,
the new text's canonical citations, the global-versus-path question, and residue of the
removed mode. I did not re-derive the whole evidence chapter or audit sections this revision
did not touch. - The table-level md5 comparison confirms the PR's containment claim, not its meaning. It
proves fifteen tables are byte-identical; it says nothing about whether the sixteenth changed
correctly, which I read by hand. - Reproducing the four gates again proves only that nothing else moved. A prose-only change
cannot fail them, and their PASS has never been evidence about this design.
Review-gate note
Unchanged and still worth stating: all eight reviews on #359 — the two at feffb585, the one at
f97fe8f7 and this one — are authored by samovers, who is also the PR author. GitHub refuses
APPROVE and REQUEST_CHANGES from the author (422), so every one is a COMMENT. This matters more
now than it did at the previous heads: revision 9 is the first head in this series where I have
no Blocker, and G4 requires review to zero Blockers before the decision card. A zero-Blocker
disposition from the author's own account should not be read as satisfying an independence
requirement. The gate needs a reviewer who is not samovers.
Disposition
Zero Blockers, one Follow-up (F4). B2 and F3 are both properly closed — the value mode is
gone rather than hedged, the §12.5 resolution requirement is stated explicitly, the
package-versus-policy failure distinction carries the right canonical reason code, default
outcome and rank, and both corrections came with matching negative cases. The correction is the
most contained of the three: no invariant row changed, fifteen of sixteen tables byte-identical.
Keep #359 draft — not because of this review's findings, but because G2, G3 and G4 remain open
and unaffected by it. This is not semantic approval, baseline admission, canonical promotion, an
implementation card or merge authorization.
What is next: record F4 against G2/G3-READ; then close the standing G2/G3 owner dependencies
before presenting the fresh #353 decision card — and obtain the independent review that G4's
zero-Blocker condition actually requires.
samovers
left a comment
samovers
left a comment
There was a problem hiding this comment.
PR #359 — revision 9 re-review
B2 is closed at the design level. F3 is addressed. No new blocking findings and no additional corrective patch requested.
Reviewed head: 7de8a2c4cf6eb1f293560af67e69565122c42f25, confirmed unchanged at the end of the review and rechecked before posting.
This is a focused review of the revision-8-to-9 correction and affected evidence, failure-handling and verification requirements. The change remains one RFC only: 62 additions and 26 deletions, with no runtime implementation.
Reviewed artifact: revision-9 authorization RFC.
My earlier revision-7 review missed the distinction between provider-owned authorization evidence evaluation and consumer-owned result qualification. The later B1 finding was valid. Revision 8 made that ownership explicit; this review checks the remaining proof-carrier and failure-classification corrections from the revision-8 review, rather than treating my earlier zero-blocker assessment as controlling.
B2 — Frame-carried proof values: closed
Location: RFC §6, the governed-read attempt description and corresponding trusted-source table.
The revised contract removes the alternative that allowed the attempt frame to supply authoritative proof values. It now requires every required evidence reference to resolve through the provider’s typed tenant reader, in the bound snapshot, to the exact immutable revision or digest recorded by the decision. Both the prose and source table explicitly prohibit accepting an evidence fact from the frame itself.
That addresses the actual defect—not merely its terminology. An owner-issued or immutable frame no longer suffices to establish evidence eligibility. The provider must evaluate the resolved evidence against canonical §12.5 at the pinned approved head, including its family, time and lifecycle state, tenant/sovereignty boundary, target/subject/intent/scope bindings and applicable purpose restrictions.
The focused verification also covers the counterexample directly: proof values placed in an otherwise owner-issued frame, without resolvable exact references, cannot satisfy the policy. Conversely, the positive case must use evidence resolved in the bound snapshot. The correction preserves a legitimate success path rather than treating universal refusal as completion. These remain planned cases, not executed tests.
F3 — Package admission versus unavailable evidence policy: addressed
Location: RFC §7, “Rule-bound action-level evidence,” and the corresponding focused verification.
The revised wording now distinguishes the relevant situations:
| Situation | Required treatment |
|---|---|
| Missing or invalid executable-package bindings, or malformed ingress | Stop admission; do not fabricate a canonical authorization decision. |
| An otherwise admitted evaluation encounters an evidence policy that is not active/current or whose exact revision cannot be retrieved | Record UNSUPPORTED_EVIDENCE_POLICY, with default REQUIRE_REVIEW, rank 240, and individual evidence dispositions. |
| Other failures are also established | Apply canonical aggregation; do not force REQUIRE_REVIEW over an independently established global DENY. |
This distinction is explicit in the new text and matches the pinned canonical evidence-policy rule in §12.4 and reason table in §20. The rank is not a replacement for outcome/path selection.
The test plan now contrasts invalid-package admission with unavailable-policy evaluation, requires the review outcome only when the other checks are satisfied, and retains global-DENY precedence for combined failures. Missing required qualification evidence in an otherwise valid actual read remains a separate denial case; it is not silently reclassified as policy unavailability.
Importantly, this runtime failure distinction does not make an incomplete package ready to ship. The correction expressly leaves G2 open. It does not authorize deployment with missing policy bindings on the theory that every read can simply return REQUIRE_REVIEW.
Preserved boundaries and remaining prerequisites
The correction keeps rule-bound evidence evaluation inside the provider while leaving result coverage, redaction, qualification, persistence and release with the read consumer. Later consumer checks cannot retrospectively repair an authorization decision that lacked its required evidence.
The unresolved work remains substantive:
G2 still requires the complete selected canonical dependency closure, source-history/historical-admission proof, and exact promoted/extracted bindings. G3 still requires genuine input and evidence producers, pre-evaluation availability in the required snapshot/context, usable readers, both consumer guard interfaces, and a measured facade/module-size outcome. G4 still requires the fresh decision card and exact task-user approval. The AUTHORIZATION_TRACE coverage and facade-probe follow-ups remain recorded obligations—not completed runtime capabilities. These remain explicit in RFC §13.
Those are acknowledged implementation gates, not new defects introduced by revision 9. No baseline-law amendment, additional action, new evidence producer or broader architectural rewrite is requested by this review.
Verification and disposition
I inspected the complete revision-8-to-9 commit diff, the changed sections and surrounding contracts, the preceding review, the pinned canonical evidence and reason-code requirements, and the live head. I also confirmed the change remains confined to the RFC.
I did not independently rerun the reported local checks, reproduce the facade probes, or execute provider/PostgreSQL tests. No hosted baseline or admission was requested.
Disposition: zero blocking findings in this focused revision-9 re-review; B2 closed and F3 addressed at the design level. Keep PR #359 draft while the existing G2/G3 prerequisites are resolved. This is not implementation approval, baseline admission, merge authorization or permission to close #353.
1 participant
Delivery issue: #353. Tracking epic: #175. Existing draft PR; no issue closure.
Status — revision 9, focused reviews report zero Blockers
Exact head:
7de8a2c4cf6eb1f293560af67e69565122c42f25.Bounded revision-8-to-9 diff.
Complete revision-9 RFC.
This remains implementation-side Phase A design only. The focused review and the second re-review both cover exact head
7de8a2c4cf6eb1f293560af67e69565122c42f25: zero Blockers, B2 closed and F3 addressed. The first records non-blocking F4; the second requests no additional corrective patch. G2/G3 and the later G4 card/approval remain open. The RFC's in-file REVIEW_PENDING label records its pre-review publication state; these linked exact-head reviews provide the later disposition. No repository bytes or approval changed in this follow-up recording.Primary trust boundary and exact change
Primary trust boundary: production authorization evaluation. Scope stayed inside it.
Only
docs/rfcs/OFARM_Runtime_Authority_Action_Matrix_Evaluation_RFC_v0_1.mdchanges: 62 additions / 26 deletions relative to revision 8. The correction narrows the proposed evidence carrier and clarifies existing canonical failure handling; the remaining edits are focused verification and revision/review navigation.UNSUPPORTED_EVIDENCE_POLICY, defaultREQUIRE_REVIEW, rank 240, with individual evidence dispositions and canonical aggregation—not an ingress rejection. This does not waive G2 readiness or override other established failures.Canonical source remains approved PR #11 at
4494924998183fe3fa7bc1b63b76a85893335044, especially sections 7.2.1, 12.3–12.5 and the reason table. No canonical file or approval changes.Preserved scope and non-effects
Both complete selected rules, all read targets and authority paths, the single evaluation method, separate write/read roles, evidence-ownership split, prepared-only handoff, current disclosure checks on retry and human-workflow deferrals are unchanged.
All 19 detailed AUTH rows, all 7 EXC rows, exact facade/signature, reader-failure mapping, canonical aggregation/validity/digest rules and the existing G2/G3 dependencies remain intact. Prior F1 trace-read coverage and F2 attributed facade-probe records remain under G3-READ/G3-SHAPE; acceptance of those records did not complete their implementation.
No runtime code, checker, schema, canonical candidate, evidence/source producer, classifier/writer, transaction/disclosure implementation, identity/selection authority, permission, budget, workflow gate, currentness, promotion, extraction, deployment or new issue/PR is included. This draft remains unmerged and supplies no semantic or merge approval.
Verification
All four cheap local checks passed using the existing pinned Python 3.12.13 / Ruff 0.15.5 environment:
PYTHONDONTWRITEBYTECODE=1 .review-tools-venv/bin/python conformance/ofarm_pkg_contract_check.py— PASS, 0 failures.conformance/rewrite_architecture_check.py— PASS.conformance/temporal_contract_candidate_check.py— PASS, CONFORMANT_CLASSIFIED.conformance/temporal_decision_log_check.py— PASS.Whitespace, staged-byte and exact path checks passed: one RFC only against both the prior head and inspected base
ff092c414db9fa24dbd6ab86c7722db89e0c95b5. Static comparison preserved 14 numbered sections, 16 tables (15 byte-identical; only the evidence-source table changed), all 19 AUTH rows, all 7 EXC rows and all code blocks. The existing reader-failure mapping is unchanged.These checks establish design/package hygiene, not executed authorization, PostgreSQL races, source-history completeness or producer/consumer integration. No expensive hosted baseline, admission or publication was requested or monitored; automatic jobs are not implementation evidence.
Remaining gates and next step
G1 remains applied issue-scope alignment only. G2 still requires the complete selected canonical dependency closure, source-history/historical-admission proof and exact materialized, promoted and extracted bindings. G3 still requires real trusted factories, write/read protocols, pre-evaluation evidence availability, coherent readers, guard interfaces and measured typed facade/size evidence. G4 requires the later complete named-PR decision card and exact task-user approval.
The CP2A-DEP01 history question remains unresolved in both directions. This correction does not approve PR #34's writer, add an action, request the same canonical scope approval again or create a new prerequisite.
F4 — non-blocking dependency question under existing G2/G3-READ
Revision 9's focused review records F4 as a Follow-up, not a Blocker. Canonical PR #11 section 12.3 permits an action-level policy to derive required evidence from the exact
effectIntentDigest. G2 must supply the actual rule-selected policy before G3 decides whether an additional attempt-carried reference input is needed.Closure evidence belongs to the existing work: exact admitted policy ref/digest, the rule for identifying required evidence, eligible evidence kinds and source bindings, and the actual same-snapshot/order mapping. If the policy derives the required references, do not commission an extra reference carrier solely to populate the provisional frame. If it needs owner-supplied references, identify and verify that real input producer. Either way, required evidence must exist through its governed sources and be resolved and eligibility-checked by the provider; deriving references does not manufacture proof or eliminate the underlying evidence producer.
This records a conditional interface question, not a new canonical rule, producer, Delivery issue or approval gate. F4 remains open with G2/G3-READ. It does not reopen B2/F3, narrow the two complete selected rules or waive the source-history checkpoint. The reviewed RFC bytes and head are unchanged.
Previous PR description — revision 8 and earlier, historical only
The following is preserved verbatim as history. Its status, carrier proposal, review request and check claims belong to those earlier heads, not revision 9.
Delivery issue: #353. Tracking epic: #175. Existing draft PR; no issue closure.
Status — revision 8, REVIEW_PENDING
Exact head:
f97fe8f73d956d2dd6c0f82f133d6800b71055fe.Bounded revision-7-to-8 diff.
Complete revision-8 RFC.
This is implementation-side Phase A design only. The user directed the bounded correction after reading both reviews of revision 7. It is ready for focused re-review, not a claim that the reviewer has closed B1. G2/G3 and the later G4 decision card and exact user approval remain open.
Primary trust boundary and exact change
Primary trust boundary: production authorization evaluation.
Only
docs/rfcs/OFARM_Runtime_Authority_Action_Matrix_Evaluation_RFC_v0_1.mdchanges: 144 additions / 30 deletions relative tofeffb585ec569c6aaa8b5d085e94583d1eb9aeca. Scope stayed inside this authorization-design boundary.The first-release set is still the two complete rules, ASSERT_OPERATION_CLAIM and RECEIVE_READ_DATA, with all read targets and authority paths. The one-method facade, write/read separation, prepared-only outputs, current disclosure checks on retry, exact rule/digest semantics and human-workflow deferrals are unchanged.
No runtime code, checker, canonical candidate, schema, source/evidence producer, classifier/writer, transaction/disclosure implementation, permission, identity/selection authority, budget, currentness, promotion, extraction, deployment or new issue/PR is included.
B1 correction — rule-bound evidence is not result qualification
The later revision-7 review identified an ownership ambiguity that the earlier review did not flag. Both cover exact head
feffb585ec569c6aaa8b5d085e94583d1eb9aeca.The correction follows unchanged canonical PR #11 at approved
4494924998183fe3fa7bc1b63b76a85893335044, sections 7.7–7.8, 12, 15, 18.5 and 22:EP_CP2_READ_QUALIFICATION_V0_2before ALLOW. An otherwise valid actual read missing its required proof yields canonical DENY; malformed ingress and missing executable bindings remain distinct.EP_NONEis the claim rule's explicit empty action-level requirement, not a waiver of cumulative source-path evidence.Follow-ups retained under existing gates
F1 — G3-READ: complete read coverage includes the existing
AUTHORIZATION_TRACEtarget and its separate RECEIVE_READ_DATA decision. The future positive/negative coverage is explicit. This neither releases this provider's internal trace nor activates an endpoint; implementation remains open.F2 — G3-SHAPE: section 12 records the reviewer's 20-line and 17-line untyped probes. The latter reported 537/520 UoW lines, 949/940 group lines and three shape/dependency failures. These are attributed experiments, not a universal minimum, an approved budget or a measured typed implementation. This correction did not reproduce or adopt the probe code. Actual shape, partition and size still require review.
Previous human-handshake corrections and exact-head review closure remain history; revision 7 deferred their execution rather than erasing their safeguards. No review-account or other new workflow gate is introduced.
Verification
Using the existing pinned Python 3.12.13 and Ruff 0.15.5 environment:
PYTHONDONTWRITEBYTECODE=1 .review-tools-venv/bin/python conformance/ofarm_pkg_contract_check.py— PASS, 0 failures.conformance/rewrite_architecture_check.py— PASS.conformance/temporal_contract_candidate_check.py— PASS, CONFORMANT_CLASSIFIED.conformance/temporal_decision_log_check.py— PASS.These checks establish design/package hygiene, not executed authorization, PostgreSQL-race, source-history, evidence-producer or consumer integration behavior. No expensive hosted baseline, admission or publication was requested or monitored; automatic jobs are not implementation evidence.
Remaining gates
G1 remains applied issue-scope alignment only. G2 includes complete selected canonical dependency closure, source-history/historical-admission proof, materialization, reviewed bindings, promotion and extraction. G3 includes real trusted factories, distinct write/read protocols and guard interfaces, usable coherent reads and actual interface/size evidence. G4 requires the later complete named-PR decision card and exact task-user approval.
The CP2A-DEP01 history question remains unresolved in both directions. This correction does not approve the PR #34 qualifying writer or add an action. It does not reopen canonical scope approval or weaken the two selected rules.
Previous PR description — revision 7 and earlier, historical only
The following statuses, reviews, verification and next-step statements belong to their named earlier heads. They neither close the new B1 review nor approve revision 8.
Delivery issue: #353. Tracking epic: #175. The existing draft PR and branch are retained; no issue is closed.
Status — revision 7, REVIEW_PENDING
Exact head:
feffb585ec569c6aaa8b5d085e94583d1eb9aeca.Inspected/integrated runtime base:
ff092c414db9fa24dbd6ab86c7722db89e0c95b5.One-commit revision diff.
Complete revision-7 RFC.
This is implementation-side Phase A design, not runtime implementation. G1's issue-scope alignment is applied. G2 canonical readiness, G3 real inputs/read/guard interfaces and size, and G4 a fresh OFARM2 decision card and exact task-user approval remain open. Previous exact-head reviews do not transfer.
The user directed this revision after renewed canonical PR #11 semantic approval at
4494924998183fe3fa7bc1b63b76a85893335044. That approval covers the canonical scope model, not this OFARM2 design or proof that the two-action release is deliverable.Capability, primary trust boundary and PR boundary
Primary trust boundary: production authorization evaluation.
Deliver one real tenant-bound provider that interprets the exact admitted canonical rules and returns complete prepared decision evidence and guard obligations. It owns no protected effect, evidence commit, consumption, durable receipt, retry coordinator or disclosure release.
Only
docs/rfcs/OFARM_Runtime_Authority_Action_Matrix_Evaluation_RFC_v0_1.mdchanges: 380 additions and 413 deletions from revision 6. Scope stayed within the authorization design. No runtime, checker, contract, reference, schema, migration, permission, identity/CP3 issuer, selection authority, key custody, source writer/classifier, transaction protocol or public route changed.What changed
evaluate_authorization(call)operation. Human preparation and prospective-finalization inputs are absent, not empty methods or success stubs. Their full previous design remains at revision 6.Applied scope records and retained delivery goal
OFARM #10, OFARM #21, and OFARM2 #353, #178, #175, #167, #176 are aligned. Previous issue bodies are preserved; epic scope additions do not mark work complete.
The obsolete native whole-#175 blocker was removed from #178 without adding a blanket #353 cycle. Concrete first-consumer prerequisites and producer ordering still govern.
The destination remains a working pending-review claim, truthful saved-result recovery and currently authorized readback, followed by the separately selected true temporal delivery under #176. Record lookup or idempotent retry does not establish independent valid-time/knowledge-position querying. Consumer authorities and implementation PRs remain separate.
Unresolved dependencies — no approval transfer
Canonical PR #11 section 24.1 leaves open whether complete history classification and historical-admission verification can work while qualifying-record authoring is non-executable. Neither answer is established. CP2A-DEP01 / #32 and #33 / PR #34 / QG-DEP01 remain open; an inactive writer, empty lookup, valid individual qualifier or permanently unavailable classifier is not closure. No extra action or writer is admitted here.
All eleven delivery stages still apply to the full selected dependency closure. The pre-runtime stages, exact binding review, promotion and byte-identical extraction precede runtime work; stage 11 is not a prerequisite to its own implementation approval. Approved candidates are not promoted/extracted executable bytes.
PR #26 remains write-only. Real governed-read coverage, qualification, receipt/evidence and release need their own admitted protocol. The incompatible old command binding and actual trusted input producers also remain separately owned prerequisites.
Verification of this head
Using the existing local Python 3.12.13 environment and repository-pinned Ruff 0.15.5:
PYTHONDONTWRITEBYTECODE=1 .review-tools-venv/bin/python conformance/ofarm_pkg_contract_check.py— PASS, 0 failures.conformance/rewrite_architecture_check.py— PASS.conformance/temporal_contract_candidate_check.py— PASS, CONFORMANT_CLASSIFIED.conformance/temporal_decision_log_check.py— PASS.The initial system-
python3check refused its unsupported version. It was rerun successfully with the existing exact pinned environment; no checker or environment was changed to suppress that refusal.These are local design/package checks, not runtime, PostgreSQL-race or consumer integration evidence. No expensive hosted baseline/admission/publication was requested or monitored. Proposed positive and hostile cases are not claimed as executed.
Previous PR description — revision 6 and earlier, historical only
All status, interface, review and next-step statements below belong to the previous exact heads. The current revision above controls; this history neither exposes a first-release human API nor transfers approval.
Delivery issue: #353. Tracking epic: #175. The existing draft PR and branch are retained; completion and issue closure remain pending.
Status
Draft Phase A, design revision 6. REVIEW_PENDING for the bounded S1 reader-failure clarification. Revision 5 had zero blocking findings. G1 is applied; G2/G3 prerequisites and later OFARM2 implementation approval remain open.
Exact head:
725df163ddcd4f93b4675a3041724b1f59ab8151.Inspected/integrated main:
ff092c414db9fa24dbd6ab86c7722db89e0c95b5.The full risk-shaped contract, invariant inventory and ownership map are in the revision-6 production authorization RFC. This is implementation-side design, not a canonical document or runtime implementation. No semantic approval, baseline admission, merge, canonical promotion or deployment is claimed.
Capability and primary trust boundary
Primary trust boundary: production authorization evaluation.
Deliver one production provider that obtains a rule-derived evaluation, complete prepared request/result/full-trace evidence and complete guard obligations through the real tenant-bound runtime. It executes exact admitted canonical rules; callers cannot select weaker policy, tenant, actor posture, scope proof or deadlines.
The destination remains #353 authorization → #178 command identity/atomic coordination → a separately selected temporal Delivery under #176. ASSERT_OPERATION_CLAIM is the first concrete consumer, producing one pending-review AssertionRecord under its separately owned effect/transaction contracts. It is not the provider's entire rule coverage, and the recent canonical revocation approval does not select a revocation runtime command.
The scope amendment is already applied: canonical rules rather than a second code-owned matrix; real production wiring rather than legacy/SI migration; prepared evidence and typed handoff rather than provider-owned durability; full admitted action/evaluation coverage. An RFC, types alone, one working action or blanket refusal cannot close #353. The later formal decision card must include this scope.
Revision 6: bounded reader-failure clarification
The revision-5 review at
87584f2e368fc791f0c12e4288885dc5425ea287found zero blockers and one non-blocking S1 clarification. This revision makes that mapping explicit in the existing reader plan and AUTH-007/009/010 cases:Incomplete/overflowed reads cannot prove absence of authority. Malformed source evidence is not automatically an adapter fault. All failure evidence must remain truthful under the admitted contracts; no placeholder snapshot, new schema/reason/outcome or second engine is introduced.
The exact failure encoding remains G3-READ work when canonical machine bindings exist. This clarification does not close the producer, snapshot, guard, workload or size gates.
Preserved revision-5 interface and explicit owner gaps
prepare_authorization(call)andevaluate_authorization(call, finalization=None). One private frozen pair of typed callables is injected by the existing manager against its principal, binding and connection. No provider/SQL/connection handle escapes. Both methods check lifetime and rollback-only; unexpected errors mark rollback-only before re-raising, even if consumer code catches them.Only the authorization design changes. New authentication/session, transaction/guard, selection or snapshot authority must be separately scoped and authorized before editing that boundary.
Authority, risk, effects and non-effects
Canonical OFARM owns exact rules, actor/finalization semantics, paths/outcomes, evidence schemas and hash projections. Authentication/principal/binder/KMS owners retain identity and tenant custody. The provider owns evaluation, rule-selected extraction and relevant-state comparison, complete prepared evidence and read obligations. Transaction owners retain isolation, guards, persistence, consumption and authoritative commit-status reconciliation. Domain owners retain protected-effect validation and result mapping.
Protected assets are allow/refuse integrity, tenant/scope containment, attribution, effective revocation and truthful evidence. Caller hints and stale, malformed, foreign or incomplete proof are untrusted; legitimate concurrent changes are in scope. Arbitrary trusted-process/deployment/database-superuser, credential/KMS or host-clock compromise is excluded, not purportedly repaired here. Containment is one exact rule source, complete current proof, deterministic evaluation, attempt/cutoff binding and a non-durable handoff without effect authority.
After valid approval and prerequisite closure, the intended slice contains one production evaluator, narrow same-connection reader, exact typed UoW/composition/architecture extension and focused verification. No legacy/SI migration, domain writer, retry or evidence ledger, receipt/consumption writer, isolation/lock/permission/migration change, identity or CP3 issuance change, grant mutation, selector authority, readiness/audit/key-custody change, public action activation, canonical edit or deployment travels here.
AUTH-001–019 and EXC-001–006 in the RFC remain the single invariant inventory. The two closed calls isolate the current approval handshake; they do not introduce a framework or second policy engine. A legacy table cannot satisfy production isolation, and a pure helper alone cannot prove bound production reads.
Readiness gates
The old fixed command still forbids ASSERTION_RECORD. Its successor/selection compatibility belongs to its owning boundary, not reinterpretation inside this evaluator. Consumer durability remains separate; its later delivery cannot excuse an unusable provider.
This is a provisional design, not a temporary runtime. Contradictory admitted bindings, missing authority, inability to deliver full coverage or renewed provider-owned durability require a reviewed redesign; no fallback or cross-boundary repair is implied.
Change and cheap verification
Revision 5 integrated main normally without rewriting history. Revision 6 adds only the S1 clarification and its review/status/test-plan wording. Against that integrated main, one file only differs:
docs/rfcs/OFARM_Runtime_Authority_Action_Matrix_Evaluation_RFC_v0_1.mdRevision-5-to-6 RFC delta: 59 insertions, 20 deletions.
Final file: 1,287 lines; blob
2f0b422e61871873794e52c63e0cfff2dd382b6c.Main's already merged challenge/signing work is inherited unchanged, not newly authored scope in this PR.
Checks on the final pre-commit content using the existing CPython 3.12.13 environment:
Revision 5's live source checks remain historical evidence. This pass inspected the current #12/#14/#21 prerequisite records, their open issue/PR inventory, #178's unchanged transaction scope and the exact canonical action matrix. No canonical bytes or currentness were changed.
No runtime/PostgreSQL provider tests, expensive hosted baseline, admission or publication were requested. These are design-hygiene checks, not proof that the provider or its consumer exists.
Prerequisite audit — no new issue or canonical change
The existing #12 inventory predates the approved PR #11 head. Compared with its current 20-row semantic source, the approved assertion, final-review and revocation candidates cover seven state-changing rows at design level. Twelve other state-changing rows still need their effect-family contracts; RECEIVE_READ_DATA uses NO_STATE_EFFECT. This is planning coverage, not executable readiness: machine bindings, conformance, promotion and extraction remain outstanding.
Existing #14 has no design PR or inventory comment yet and remains a required retention/proof-strength predecessor under #21. Recommended next separately scoped work is its existing-contract inventory and bounded Phase A design for approval-display/governed-read proof. It changes canonical retention/evidence-custody semantics, so user direction is required before that work leaves this authorization-design boundary. No new issue, canonical edit or authority change is made here.
#178 still has its older broad command-idempotency criteria; it does not supply an implemented attempt/deadline/guard factory. Preserve the explicit dependency-cycle check and do not fabricate input frames to start provider code.
Review handoff
The revision-5 focused review at
87584f2e368fc791f0c12e4288885dc5425ea287reports zero blocking findings and non-blocking S1. Its review remains attached to that exact head.Revision 6 is REVIEW_PENDING. Review only S1's reader-failure mapping and affected AUTH-007/009/010 and EXC invariants. Preserve the reviewed interface and handshake; do not reopen earlier findings without new evidence. No baseline-admission comment, implementation approval or merge authorization is issued.
What is next: focused review of the clarification; separately obtain direction for existing canonical #14's retention-proof work while G2/G3 and formal OFARM2 implementation approval remain open.
What is next: exact-head review of revision 7's selected scope, one-entry facade, write/read handoff and AUTH/EXC ledger. Then close the existing G2/G3 owner dependencies before presenting the fresh OFARM2 decision card. No implementation, new issue, merge, promotion or deployment is authorized by this draft.
What is next: focused review of revision 8 at
f97fe8f73d956d2dd6c0f82f133d6800b71055fefor B1's evidence ownership, closed input role, canonical failure/positive cases and F1/F2 records. Then close the existing G2/G3 owner dependencies before the fresh OFARM2 decision card. No runtime implementation, merge, promotion or deployment is authorized by this draft.What is next: resolve the existing canonical source-history/admission checkpoint and exact selected policy bindings, using F4 to avoid an unnecessary reference carrier. Keep the two-action scope and separate producer/transaction owners intact; obtain the later #353/#359 decision card and exact approval before runtime work. No new blocking provider patch, baseline admission or merge is authorized by these reviews.