From b36907a1fb2eb486b461c49a378d78ad96ee38b6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Samo=20A=C4=8Dko?= Date: Mon, 31 Aug 2026 11:11:07 +0200 Subject: [PATCH 1/8] Define runtime authority matrix evaluation Record the Phase A trust model, closed action policy, scope proof, outcome ordering, and hostile verification required for issue #353 before implementation. --- ...ority_Action_Matrix_Evaluation_RFC_v0_1.md | 883 ++++++++++++++++++ 1 file changed, 883 insertions(+) create mode 100644 docs/rfcs/OFARM_Runtime_Authority_Action_Matrix_Evaluation_RFC_v0_1.md diff --git a/docs/rfcs/OFARM_Runtime_Authority_Action_Matrix_Evaluation_RFC_v0_1.md b/docs/rfcs/OFARM_Runtime_Authority_Action_Matrix_Evaluation_RFC_v0_1.md new file mode 100644 index 00000000..625e5ecd --- /dev/null +++ b/docs/rfcs/OFARM_Runtime_Authority_Action_Matrix_Evaluation_RFC_v0_1.md @@ -0,0 +1,883 @@ +# OFARM Runtime Authority Action-Matrix Evaluation RFC v0.1 + +Date: 2026-08-31 + +Status: proposed Phase A design; no implementation authority + +Delivery issue: samovers/OFARM2#353 + +Tracking epic: samovers/OFARM2#175 + +Repository base: samovers/OFARM2 at +88b10a5acac466a1ea3ee85c3006f919c3f97327 + +## 1. Problem and capability + +The current runtime authority evaluator accepts an action stage from its +caller, infers software posture partly from caller-supplied fields, treats some +scope relationships as true without durable proof, and lets each caller choose +an incomplete target shape. A caller can therefore ask the evaluator to reason +inside a weaker authority context than the accepted action requires. + +This Delivery issue adds one independently reviewable capability: every +supported runtime authority decision selects one immutable action-class rule, +derives the action stage and actor posture, validates the target against that +rule, proves scope from tenant-bound governed data, and applies grants, +delegations, inheritance, and revocations through one fail-closed evaluator. + +The system-visible outcome is that a caller supplies an authenticated Party, +an action class, and target facts. It cannot supply an authoritative stage, +posture, inheritance rule, or delegability decision. Every final allow has one +selected matrix rule, one proved scope path, and one durable decision trace. + +The learning value is direct: hostile evidence will show which decisions were +previously dependent on caller-controlled stage or unproved scope. The same +closed interface then becomes the stable input for the later grant-mutation +and bootstrap Delivery issues under #175. + +## 2. Primary boundary and effects + +### Primary trust boundary + +The only primary trust boundary changed by this pull request is runtime +authority evaluation: the boundary that turns an authenticated principal, a +governed action class, target facts, live authority records, and durable scope +evidence into an ALLOW or non-allow decision. + +### Permitted effects + +This pull request may: + +- replace caller-selected action stage and software posture with values derived + by one executable action-class matrix and governed Party evidence; +- validate the action target against the selected row; +- require tenant-bound durable proof for exact, descendant, and derived-lineage + scope coverage; +- cap grant inheritance and delegation by the selected row; +- select one deterministic live authority path; +- refuse unknown, incomplete, unsupported, stale, revoked, cross-tenant, or + ambiguous cases before ALLOW; +- persist the selected rule, derived values, selected authority basis, and + scope-evidence references through the existing authorization contracts; +- migrate current callers with no compatibility overload; and +- move evaluation inside a caller's already-owned serialized write transaction + when necessary to keep the check before its governed side effect. + +### Non-effects and adjacent boundaries + +This pull request must not: + +- create, narrow, revoke, rotate, recover, or bootstrap an AuthorityGrant or + DelegationGrant; +- change authentication, credential verification, principal resolution, + TenantBinding, database roles, schema, migration, isolation level, advisory + lock ownership, or transaction ownership; +- add a new action class, contract field, schema, profile, RuntimeBundle + component, active capability, law statement, or deployment claim; +- implement sponsor-bound software-agent actorship contracts; +- implement sharing-grant mutation, output redaction, output delivery + permission, or the complete sharing/output permission plan owned by #177; +- change signing, key custody, evidence custody, production bootstrap, + recovery, or break-glass authority; or +- make production-readiness, legal, certification, or current-compliance + claims. + +Moving an evaluator call inside an existing serialized transaction is +mechanical integration for this authorization boundary. If implementation +would require a new transaction, lock, database role, mutation command, or +isolation rule, work stops and that change becomes separate Delivery work. + +### Authority map + +| Fact or decision | Authority owner | +|---|---| +| Accepted action vocabulary and semantics | Digest-pinned accepted OFARM Authority Policy Model and Authority Action Matrix in reference | +| One row per accepted action, derived stage, targets, posture, inheritance, and delegability | New immutable kernel action-policy table | +| Current runtime reachability | Existing commit-to-action bindings and non-commit action inventory in kernel policy; the full matrix does not activate an unwired action | +| Authenticated human Party | Existing authentication and principal-resolution boundary, unchanged | +| Party class, lifecycle, and agent-instance reference | Tenant-bound governed Party record | +| Tenant observation and RuntimeBundle receipt | Existing ready Store binding | +| Target containment and lineage | Tenant-filtered, current governed IdentityRecord data and its persisted record row | +| Grant, role, delegation, time, and revocation facts | Existing validated governed records | +| Rule selection, scope proof, path selection, outcome, and trace | AuthorityEvaluator | +| Requested action and target facts | Caller; never authority over derived restrictions | +| Commit, review, evidence, output, and read effects | Existing callers after an ALLOW; unchanged except for the new derived evaluator interface | +| Sharing overlay and output permission plan | #177, not this pull request | +| Grant mutation and production bootstrap | Later #175 Delivery issues | + +## 3. Trust model + +### Protected assets + +- the integrity of every ALLOW or refusal; +- tenant isolation and farm/descendant containment; +- the effective power of live grants and delegations; +- human accountability and the distinction between human, AI-assisted human, + and autonomous software action; +- revocation effectiveness at the final authority check; +- the integrity of authorization request, result, and trace records; and +- downstream governed truth, evidence, materialization, read, and output + effects that depend on an ALLOW. + +### Trusted sides and components + +- the exact source and digest-pinned accepted reference artifacts; +- the reviewed immutable action table after its construction checks pass; +- the existing authenticated principal and tenant binding supplied by upstream + boundaries; +- a ready Store whose tenant and RuntimeBundle binding already passed startup; +- schema-validated, tenant-filtered governed records returned by that Store; +- the existing append-only store and serialized transaction owner; and +- the process clock under the repository's present time model. + +### Untrusted actors, sides, and inputs + +- public request bodies and all action, target, target-kind, target-ref, and + AI-assistance values carried by them; +- internal callers attempting to pass old stage or posture fields; +- unknown action strings and malformed enum-shaped values; +- a Party reference that is missing, inactive, cross-tenant, or of a different + class from the claimed posture; +- grants, roles, delegations, revocations, target records, anchor scopes, and + lineage that are missing, expired, revoked, malformed, stale, ambiguous, or + unrelated to the request; +- a broad tenant or farm grant presented without durable membership evidence; + and +- extra caller-authored anchors, role IDs, grant IDs, inheritance modes, or + alleged scope evidence. + +### Explicitly excluded attacker capabilities + +This boundary does not claim to withstand: + +- arbitrary code execution or object mutation inside the trusted Python + process; +- substitution of reviewed source code, the accepted reference snapshot, or a + dependency after startup; +- direct database-superuser mutation that bypasses the Store, constraints, and + append-only controls; +- compromise of credential verification, principal resolution, TenantBinding, + the host clock, operating system, filesystem, or RuntimeBundle custody; or +- a production authority-mutation writer that ignores the existing serialized + write discipline. No such supported writer is introduced here. + +Those are separate trust boundaries. Excluding them does not make request +fields, caller posture, or unresolved scope evidence trusted. + +### Primary risk and containment + +The primary risk is an ALLOW reached by selecting a weaker stage or posture, or +by treating an asserted tenant/farm relationship as proof. + +Containment is one closed immutable action table, no stage or posture parameter +on the evaluator, posture derived from governed Party evidence, target rules +selected from the action row, durable tenant-filtered scope proof, row-capped +inheritance and delegation, mandatory revocation evaluation, and an outcome +order in which no missing or ambiguous prerequisite can reach ALLOW. + +## 4. Executable action-policy contract + +### 4.1 Construction + +The production source is one tuple of frozen AuthorityActionRule values in a +small authority-policy module. Each accepted action string appears once in +that tuple. The builder returns a read-only mapping and rejects duplicate +keys, missing fields, empty target or posture sets, invalid enums, internally +inconsistent inheritance/delegation combinations, or a row count other than +the accepted twenty. + +Repository conformance parses the accepted reference matrix and proves exact +set equality with the code table. The runtime does not parse Markdown and does +not accept an injected table from a caller. If table construction fails, +authority evaluation is unavailable and startup/import refuses. If a runtime +request names no row, it receives a typed input refusal and cannot create an +ALLOW or a fabricated schema-valid decision. + +The full twenty-row table describes accepted policy but does not activate +unwired runtime behavior. The existing runtime-supported action inventory +remains a separate reachability fact and must be a subset of the full table. +An accepted but currently unwired action selects its row and returns an +explicit unsupported non-allow. + +### 4.2 Target policies + +The table uses the existing AuthorizationDecisionRequest target-kind and scope +vocabularies. No parallel contract vocabulary is added. + +Target policy O permits CANONICAL_TRUTH at FARM, SITE, FIELD, ZONE, +CROP_CYCLE, LOT, or FACILITY. + +Target policy E permits CANONICAL_TRUTH or SUBMISSION_ASSEMBLY at every O scope +and OPERATION. + +Target policy S permits CANONICAL_TRUTH at FARM, SITE, FIELD, ZONE, or +FACILITY. + +Target policy C permits CANONICAL_TRUTH or SUBMISSION_ASSEMBLY at FIELD, +CROP_CYCLE, or LOT. + +Target policy P permits CANONICAL_TRUTH at FIELD, ZONE, CROP_CYCLE, or +OPERATION. + +Target policy R permits CANONICAL_TRUTH or CURRENT_STATE_MATERIALIZATION at +FARM, SITE, FIELD, ZONE, CROP_CYCLE, LOT, FACILITY, or OPERATION. + +Target policy PI permits PACK_ACTIVATION at FARM, SITE, FIELD, or CROP_CYCLE. + +Target policy PA permits PACK_ACTIVATION at FARM, SITE, FIELD, CROP_CYCLE, LOT, +or OPERATION. + +Target policy OD permits DOCUMENT_ASSEMBLY, DOSSIER_ASSEMBLY, or +SUBMISSION_ASSEMBLY at FARM, SITE, FIELD, CROP_CYCLE, or LOT. + +Target policy OS permits SUBMISSION_ASSEMBLY at FARM, SITE, FIELD, +CROP_CYCLE, or LOT. + +Target policy SH permits CANONICAL_TRUTH, PASSPORT_VIEW, DOCUMENT_ASSEMBLY, +DOSSIER_ASSEMBLY, SUBMISSION_ASSEMBLY, or +CURRENT_STATE_MATERIALIZATION at any governed scope except DEPLOYMENT. + +Target policy RD permits every SH target plus QUERY_EXECUTION at any governed +scope except DEPLOYMENT. + +Permitting a kind/scope pair is not proof that the target exists or belongs to +the grant scope. Scope proof remains mandatory. OPERATION is therefore +refused until its supplied reference resolves through an existing governed +record shape that this implementation can prove; no operation-shaped string is +treated as proof. + +### 4.3 Posture policies + +Posture H means: + +- an active non-SOFTWARE_AGENT Party with no valid AI-assistance facts is an + accountable human or organization; +- an active non-SOFTWARE_AGENT Party with valid AI-assistance facts is an + AI-assisted accountable human; +- the AI-assisted posture may ALLOW only after the ordinary live authority + path succeeds; and +- autonomous software is unsupported and DENY. + +Posture HA is the same except a valid AI-assisted human path returns +REQUIRE_HUMAN_APPROVAL, never ALLOW. The later final action must be made under a +fresh accountable-human decision. A missing grant still returns DENY rather +than manufacturing an approval route. + +AI-assistance metadata never supplies authority. When present it must name an +active SOFTWARE_AGENT Party consistently with the existing governed Party +record and is traced. A SOFTWARE_AGENT acting Party remains autonomous even if +the caller omits or forges assistant fields. This pull request expressly +enables no autonomous action because the implementation lacks the complete +sponsor, agent-instance, actorship-basis, authority-snapshot, and result +qualification proof required by the active CP3 law. + +### 4.4 Inheritance policies + +Inheritance policy X permits only an exact target. No descendant or lineage +expansion occurs. + +Inheritance policy D permits exact or proven descendant containment. A grant's +stored DESCENDANT_SCOPES value does not bypass target proof. + +Inheritance policy L permits exact, proven descendant containment, or an +explicit unique DERIVED_FROM lineage path when the stored grant mode selects +the matching mechanism. + +Inheritance policy N applies the action as NO_INHERIT. An exact grant target +can still authorize that exact target even if an older broad grant stores a +more permissive inheritance mode; the selected rule caps the effective mode to +NO_INHERIT and never uses the broader setting. This preserves exact existing +authority while preventing it from flowing. + +No policy permits upward inheritance. No policy treats DESCENDANT_SCOPES and +DERIVED_LINEAGE_SCOPES as interchangeable. + +### 4.5 Complete row set + +Runtime support below means reachable through current production code. A +known but unwired row remains explicit non-allow until a separate approved +caller activates it. + +| Action class | Family | Derived stage | Target | Posture | Inheritance | Delegable | Runtime support | +|---|---|---|---|---|---|---|---| +| OBSERVE_CREATE_OBSERVATION | OBSERVE_REPORT | DRAFT_PREPARATION | O | H | L | yes | yes | +| OBSERVE_ATTACH_EVIDENCE | OBSERVE_REPORT | DRAFT_PREPARATION | E | H | L | yes | yes | +| ASSERT_STRUCTURE | ASSERT_SUBMIT | DRAFT_PREPARATION | S | HA | X | yes | yes | +| ASSERT_OPERATION_CLAIM | ASSERT_SUBMIT | DRAFT_PREPARATION | P | H | L | yes | yes | +| ASSERT_COMPLIANCE | ASSERT_SUBMIT | DRAFT_PREPARATION | C | HA | X | yes | yes | +| OPERATE_PLAN_INTERVENTION | OPERATE_INTERVENE | DRAFT_PREPARATION | P | H | L | yes | no | +| OPERATE_REPORT_EXECUTION | OPERATE_INTERVENE | DRAFT_PREPARATION | P | H | L | yes | no | +| REVIEW_REQUEST | REVIEW | DRAFT_PREPARATION | R | H | X | yes | no | +| REVIEW_ACCEPT | GOVERN_DECIDE | PROMOTION | R | HA | N | no | yes | +| REVIEW_REJECT_OR_CONTEST | GOVERN_DECIDE | PROMOTION | R | HA | N | no | yes | +| REVIEW_SUPERSEDE | GOVERN_DECIDE | PROMOTION | R | HA | N | no | no | +| CONTEXT_INSTALL_PACK | CONTEXT_GOVERNANCE | CONTEXT_ACTIVATION | PI | HA | N | no | no | +| CONTEXT_ACTIVATE_PACK | CONTEXT_GOVERNANCE | CONTEXT_ACTIVATION | PA | HA | N | no | no | +| CONTEXT_DEACTIVATE_PACK | CONTEXT_GOVERNANCE | CONTEXT_ACTIVATION | PA | HA | N | no | no | +| OUTPUT_APPROVE_DOCUMENT_ASSEMBLY | ATTEST_SIGN | PUBLICATION | OD | HA | N | no | yes | +| OUTPUT_ATTEST_DOCUMENT_ASSEMBLY | ATTEST_SIGN | ATTESTATION | OD | HA | N | no | no | +| OUTPUT_FILE_SUBMISSION_ASSEMBLY | ATTEST_SIGN | PUBLICATION | OS | HA | N | yes | yes | +| SHARE_GRANT_ACCESS | SHARE_REVOKE | PROMOTION | SH | HA | X | yes | no | +| SHARE_REVOKE_ACCESS | SHARE_REVOKE | PROMOTION | SH | HA | X | yes | no | +| RECEIVE_READ_DATA | RECEIVE_USE | QUERY_READ | RD | H | L | yes | yes | + +ATTEST_SIGN is deliberately selected for +OUTPUT_FILE_SUBMISSION_ASSEMBLY. The accepted source permits attest/sign or +assert/submit depending on governance; the stricter existing output-governance +family prevents this implementation from silently widening filing authority. + +## 5. Falsifiable invariants and acceptance criteria + +### INV-001 — one complete immutable matrix + +Exactly the twenty accepted action classes have exactly one complete frozen +row. Duplicate, incomplete, invalid, mutable, or missing construction input +cannot produce a usable evaluator. Unknown and currently unwired action +classes cannot ALLOW. + +Production-reachable negative cases: start the production builder with a +duplicate, incomplete, or invalid row and observe startup refusal; invoke the +supported evaluator boundary with an unknown or accepted-but-unwired action +and observe no governed effect. + +### INV-002 — callers cannot choose derived restrictions + +The evaluator interface has no action-stage, actor-posture, inheritance, +delegability, revocation-check-required, or caller-scope-evidence parameter. +Request and result stages, authority family, posture, effective inheritance, +and delegation eligibility come only from the selected row and governed +records. No compatibility overload remains. + +Production-reachable negative cases: send an API request containing a forged +stage or posture field and observe ingress refusal; call the internal +production interface with an old keyword and observe a pre-evaluation type +refusal; compare a valid call's persisted stage with its matrix row. + +### INV-003 — posture is governed and cannot create authority + +Unknown or inactive Parties refuse. Party class and agent instance come from +the governed Party record. Valid AI assistance preserves the authenticated +human as accountable actor and can only retain or narrow the outcome. +Autonomous software never ALLOWs in this version. REQUIRE_HUMAN_APPROVAL is +possible only after a valid live human-side authority path exists. + +Production-reachable negative cases: evaluate an inactive Party, a +SOFTWARE_AGENT Party with omitted or forged human metadata, mismatched +assistant evidence, an AI-assisted high-governance action with a live grant, +and the same action without a grant. Outcomes are respectively non-allow, +non-allow, non-allow, REQUIRE_HUMAN_APPROVAL, and DENY. + +### INV-004 — target policy is selected by the action + +Every known action accepts only the target kinds and scope types in its row. +Malformed refs, absent required target facts, wrong kinds, DEPLOYMENT, and +unsupported kind/scope combinations refuse before grant matching. + +Production-reachable negative cases: request REVIEW_ACCEPT on PACK_ACTIVATION, +OUTPUT_FILE_SUBMISSION_ASSEMBLY on DOCUMENT_ASSEMBLY, an observe action at +DEPLOYMENT, and a malformed target ref. None reaches ALLOW. + +### INV-005 — scope coverage requires current durable proof + +An exact target must itself resolve as a current governed target. A tenant +grant covers only a target returned under the same tenant-bound Store. A farm +grant covers a descendant or derived target only through one complete, +same-tenant, active, acyclic, unambiguous containment or lineage path. +Missing, wrong-kind, inactive, stale, cross-tenant, cyclic, or multiply +anchored evidence refuses. Caller-authored anchors are ignored. + +Production-reachable negative cases: use a missing target, an ended IdentityRecord, +a FIELD ref that resolves to a Party, a target stored only in another tenant, +a target with two farm anchors, a cyclic lineage, and a same-shaped caller +anchor with no stored record. None reaches ALLOW. + +### INV-006 — every ALLOW has one live grant path + +The selected path has an active Party, a current role when used, an active and +time-valid grant for the exact action, target coverage under the row, and no +effective revocation. Revocation checking is mandatory. Missing or revoked +only paths refuse. + +Production-reachable negative cases: evaluate with no grant, an expired grant, +an inactive grant, a grant for a different action, an expired role-targeted +grant, and a revoked grant. None reaches ALLOW. + +### INV-007 — inheritance never widens the row + +The row caps the stored inheritance mode. Exact, descendant, and derived +lineage remain distinct; upward inheritance never occurs. An invalid mode, +unsupported mode/action pair, absent containment proof, or ambiguous lineage +refuses. + +Production-reachable negative cases: use a FIELD grant for a FARM target, a +NO_INHERIT farm grant for a field, DERIVED_LINEAGE_SCOPES with no DERIVED_FROM +path, and a broad review grant against a child target. None reaches ALLOW. + +### INV-008 — delegation cannot manufacture or widen authority + +A delegated path exists only when the row permits delegation, the delegation +is active and time-valid for the action and target, and every named source +grant is still controlled by the delegator, live, unrevoked, and independently +covers both the delegation scope and the requested target. Delegation cannot +widen action, time, target, inheritance, posture, or purpose. + +Production-reachable negative cases: delegate REVIEW_ACCEPT, use a missing +source grant, revoke the source, expire the delegation, change the delegated +action, request beyond either scope, and use lineage inheritance forbidden by +the row. None reaches ALLOW. + +### INV-009 — outcome ordering is fail closed + +Input, matrix, actor, target, scope, grant, source authority, and revocation +validation all precede posture disposition. Human approval cannot resurrect a +missing or revoked path. Only outcome ALLOW permits the caller's governed +effect. + +Production-reachable negative cases: request an autonomous output action with +no grant and an AI-assisted output action backed only by a revoked grant. +Both DENY; neither returns a misleading approval route or writes the output. + +### INV-010 — the durable trace contains only derived proof + +For a known action the persisted request, result, and trace identify the exact +action-row key, derived stage and authority family, target scope/time, selected +role/grant/delegation basis, effective inheritance, revocation result, actor +classification, and the durable tenant/containment/lineage record refs used. +Only one deterministic least-authority path is recorded as used. Caller- +authored authority facts never appear as proof. + +Production-reachable negative cases: submit fake role, grant, anchor, and +inheritance facts alongside a valid request; create two live candidate paths +in opposite insertion orders. The fake facts are absent and both orders select +the same proved path and decision. + +### INV-011 — all callers use one interface without capability expansion + +Every current evaluator call names only the authenticated Party, action, +typed target facts, and non-authoritative purpose/assistance facts. Old stage +and acting-agent authority arguments are deleted. The manifest's supported +action set remains unchanged and is proven to be a subset of the complete +table. Existing accepted SI outcomes remain assertion-equivalent except where +the old outcome depended on caller stage/posture or unproved scope; those +become explicit refusals. + +Production-reachable negative cases: repository search and architecture tests +find an old argument or alternate evaluator path; manifest grounding detects a +newly activated action; existing SI conformance detects any unapproved outcome +change. + +### INV-012 — check, trace, and effect stay ordered + +Every write-capable current caller evaluates and persists the authorization +request, trace, and result inside its already-owned serialized transaction +before its governed effect. A non-ALLOW writes no governed effect. Read access +is re-evaluated on each request. No new lock, transaction owner, database role, +or mutation path is added. + +Production-reachable negative cases: exercise commit, actor attribution, +FFSNaprave evidence attachment, document freeze, submission freeze, and read +through their supported entry points while observing transaction state and +record order. Inject each non-allow condition before the final evaluation and +prove the governed effect is absent while the refusal trace is durable. + +## 6. Proposed architecture and data flow + +### 6.1 Small policy module + +A new kernel/authority_policy.py owns only frozen policy values: + +- closed enums for stage, authority family, target kind, scope type, actor + posture, posture disposition, and inheritance policy; +- a frozen AuthorityTarget value that binds target kind, scope type, scope ref, + and optional governed target ref; +- a frozen AuthorityActionRule value; +- the single twenty-row source tuple; +- strict construction into a read-only action-to-rule mapping; and +- a lookup that returns a rule or a typed refusal, never a fallback row. + +It does not read the database, mutate grants, parse Markdown, know SI profile +content, or dispatch effects. + +### 6.2 Scope proof + +A focused resolver inside the authority boundary accepts the selected rule, +the target, a candidate grant scope and mode, the evaluation time, and the +tenant-bound Store. + +It: + +1. validates the target against the row; +2. confirms the grant's tenant/farm anchor is itself valid; +3. loads the target only through tenant-filtered Store methods; +4. validates record kind, IdentityRecord type, lifecycle state, and row tenant; +5. walks only explicit anchor scopes for descendant containment; +6. walks only explicit DERIVED_FROM edges for lineage mode; +7. bounds traversal, detects cycles, and requires one unambiguous path; +8. refuses unsupported OPERATION proof rather than guessing; and +9. returns a frozen ScopeProof containing the effective inheritance mode and + ordered durable evidence refs. + +FARM, SITE, FIELD, CROP_CYCLE, LOT, and FACILITY map to the corresponding +active IdentityRecord type. ZONE maps only to active MANAGEMENT_ZONE or +MICROCLIMATE_ZONE. TENANT proof uses the Store's persisted RuntimeBundle tenant +selection plus the target record's tenant-filtered row. DEPLOYMENT is +unsupported. No identifier prefix is evidence. + +### 6.3 Actor and authority paths + +AuthorityEvaluator resolves the active Party and derives: + +- accountable human/organization from a non-SOFTWARE_AGENT Party; +- AI-assisted accountable human only from consistent assistance facts whose + assistant resolves to an active SOFTWARE_AGENT Party; or +- autonomous software from a SOFTWARE_AGENT acting Party and its governed + agent-instance reference. + +It gathers validated roles, direct grants, delegations, source grants, and +revocations. Each candidate becomes an immutable AuthorityPath only after its +own scope proof succeeds. A delegated path contains both source and delegation +proof. + +When more than one live path exists, the evaluator selects deterministically: +exact before inherited, direct before delegated, shorter scope proof before +longer proof, then stable record IDs. It records only the selected path as +used. Other candidates do not create ambiguity because they are independent +ways to prove the same authority; ambiguous scope evidence inside any selected +path still refuses that path. + +### 6.4 Decision interface + +The replacement interface is conceptually: + + evaluate( + acting_party_ref, + action_class, + target, + ai_assistance=None, + use_purpose=None, + refusal_context=None, + ) + +There is no action_stage, acting_agent_ref, actor_posture, inheritance_mode, +delegable, revocation_check_required, role basis, grant basis, anchor scope, or +scope-evidence argument. + +refusal_context may carry an existing non-authoritative routing fact such as +offline replay. It may choose only between non-allow dispositions already +permitted by policy and can never produce ALLOW or REQUIRE_HUMAN_APPROVAL. + +The evaluator populates the existing AuthorizationDecisionRequest, +AuthorizationDecisionResult, and AuthorizationDecisionTrace shapes. The +requestedActionClass is the unique selected matrix-row key. The request carries +the derived actionStage and requiredAuthorityFamily. Existing trace basis +fields carry only the selected path. Existing +dataSovereigntyBoundaryRefs carries the ordered durable tenant and scope proof +refs. No contract edit is required. + +Malformed input for which no honest contract stage or rule exists returns a +typed boundary refusal rather than minting a misleading authorization +envelope. + +### 6.5 Caller composition + +- GatePipeline derives the target from normalized governed submission facts. + Operation claims use their governed execution target rather than a blanket + farm string. Structure and review cases use their governed case/anchor scope. +- ActorAttributionValidator evaluates the same ASSERT_OPERATION_CLAIM row and + governed operation target; it cannot select DRAFT_PREPARATION separately. +- FFSNaprave evidence attachment uses the E target and evaluates inside its + existing serialized transaction before evidence insertion. +- SI output freeze uses DOCUMENT_ASSEMBLY or SUBMISSION_ASSEMBLY and evaluates + inside its existing serialized transaction before publication records or + frozen output. +- evaluate_read uses the RD target and re-evaluates on each request. Its + existing SharingGrant overlay remains bounded pending #177 and receives no + new mutation, redaction, or delivery authority here. +- Runtime manifest construction keeps the current reachable action inventory + and proves it is a subset of the complete matrix. + +No adapter preserves the old evaluator signature. + +## 7. State and ordering + +### 7.1 Evaluation state machine + + REQUEST_FACTS + -> RULE_SELECTED + -> ACTOR_RESOLVED + -> TARGET_VALIDATED + -> SCOPE_PROVED + -> AUTHORITY_PATHS_EVALUATED + -> LIVE_PATH_SELECTED + -> POSTURE_APPLIED + -> DECISION_MINTED + -> DECISION_PERSISTED + -> EFFECT_PERMITTED only when outcome is ALLOW + +Any failed transition goes to REFUSED. There is no transition from REFUSED, +REQUIRE_REVIEW, or REQUIRE_HUMAN_APPROVAL to EFFECT_PERMITTED. + +Forbidden orderings include: + +- grant matching before a complete rule and target exist; +- posture selection from a caller enum or stage; +- human-approval routing before a live path exists; +- descendant or lineage inheritance before durable proof; +- delegation before source authority is proved; +- an effect before the decision records are persisted; and +- reuse of a decision across a later final action or read request. + +### 7.2 Time-of-check/time-of-use boundary + +Authority is re-evaluated at the final supported gate. Existing commit and +review work already runs under the Store's serialized transaction. The +FFSNaprave and output callers move the evaluation into their existing +serialized transaction so target evidence and authority are checked before the +same transaction's effect. + +This issue does not invent a grant-mutation control plane. A later governed +mutation command must use the same serialization and force a fresh evaluation; +that is separate #175 Delivery work. Complete sharing/output atomic permission +planning remains #177. + +### 7.3 Durability, rollback, and recovery + +No schema, migration, or stored-record shape changes. Decision envelopes and +effects continue to commit or roll back under their current transaction owner. +The new table and proof objects are derived, immutable process values and need +no recovery. Rollback is code rollback before deployment; there is no data +rewrite. Existing historical traces remain truthful records of the evaluator +version that produced them and are not rewritten. + +## 8. Expected areas and complete-slice companions + +Expected production areas: + +- kernel/authority_policy.py — new immutable table and bound value types; +- kernel/authority.py — derived evaluator, scope proof, deterministic path, + outcome ordering, and trace population; +- kernel/policy.py — retain caller reachability and routing facts while + deleting duplicated authority semantics; +- kernel/stages.py and kernel/validators.py — migrated generic callers; +- kernel/profiles/si_ffs/ffsnaprave_adapter.py and + kernel/profiles/si_ffs/outputs.py — migrated profile callers and check/effect + ordering; +- kernel/manifest.py — grounding only if needed to prove current supported + actions remain a subset; and +- kernel/legacy_m1/api.py only if the supported public boundary needs an + explicit old-field refusal beyond its existing closed request schema. + +Expected tests and fixtures: + +- a focused kernel/tests/test_authority_action_matrix.py; +- focused updates in kernel/tests/test_stages.py, + kernel/tests/test_conformance.py, and + kernel/tests/test_runtime_bundle_receipts.py; +- affected SI FFSNaprave and output tests; +- gate fixture expectations only where a formerly caller-controlled stage or + unproved scope becomes an explicit refusal; and +- conformance/review_baseline_test_inventory.json regenerated only because the + canonical collected node inventory changes. + +Expected documentation and mechanical evidence: + +- this durable RFC in the same implementation pull request; +- the draft pull request Phase A and later compact approval navigation; +- conformance/rewrite_architecture_check.py only if its existing exact source + inventory requires mechanical registration of the new module or deleted + path; and +- no reference, contract, profile descriptor, RuntimeBundle component, + migration, claim, or deployment file. + +Complete prerequisites: #172, #173, and #174 are merged. No additional +prerequisite is required. + +The expected path list is a scope prediction, not approval authority. A newly +discovered test, fixture, documentation, or mechanical inventory file may +travel only when it proves this same evaluator boundary and adds no authority, +effect, capability, or trust boundary. + +## 9. Smallest coherent change and code excellence + +This is the smallest complete vertical slice because a table without evaluator +enforcement leaves caller authority intact; evaluator changes without scope +proof still permit unproved targets; scope proof without caller migration +leaves the bypass; and behavior without focused hostile tests and durable +design evidence is not independently reviewable. + +### EXC-001 — one authoritative path + +There is one code-owned action-rule table, one rule lookup, one target/scope +proof path, one grant/delegation evaluator, and one decision constructor. +Current runtime reachability remains a distinct fact, not a second semantic +matrix. + +### EXC-002 — no avoidable duplication + +Stage, posture, target rules, inheritance, and delegability disappear from +callers. The production table does not parse or copy the reference Markdown at +runtime. Tests compare the table keys to the reference artifact rather than +maintaining another handwritten expected action list. + +### EXC-003 — direct invariant trace + +Each invariant below maps directly to the table builder, target/scope resolver, +path evaluator, outcome ladder, decision constructor, migrated callers, and +focused hostile evidence. There is no permissive fallback. + +### EXC-004 — delete superseded paths + +Delete the old action_stage, acting_agent_ref, and +revocation_check_required authority parameters; the stage-sensitive software +branch; blanket tenant/farm scope assumptions; all-candidate trace basis; and +every old caller argument. No compatibility shim, feature flag, or alternate +evaluator remains. + +### EXC-005 — abstractions pay rent now + +AuthorityActionRule isolates the accepted row and removes five correlated +caller decisions. AuthorityTarget binds target facts now used by all current +callers. ScopeProof prevents repeated or guessed containment logic. AuthorityPath +binds the selected direct or delegated proof and prevents mismatched trace +lists. No generic policy framework, plugin registry, dependency injection, or +future action dispatcher is added. + +### EXC-006 — simplest credible alternative + +The simplest alternative is a dictionary added directly to authority.py plus a +few conditional checks. It is rejected because it leaves correlated raw +dictionaries mutable, mixes policy construction with database evaluation, and +cannot give one bound target, scope proof, or selected path to the trace without +duplicated validation. The proposed single small policy module and focused +immutable values are the minimum additional concepts that directly enforce +INV-001, INV-004, INV-005, and INV-010. + +### Elegance audit + +- semantic sources of truth added: one action table; +- runtime reachability sources retained: one existing caller inventory; +- authoritative decision transition points after the change: one evaluator; +- compatibility paths retained: zero; +- durable state added: zero; +- migrations added: zero; +- abstractions added: four small immutable values plus one strict builder; +- superseded authority inputs deleted: stage, agent-posture proxy, optional + revocation check, caller inheritance, caller delegability, and caller scope + proof; +- rewrite decision: a focused evaluator rewrite is safer and smaller than + layering row lookups over the current first-candidate and blanket-scope + branches. + +## 10. Verification and traceability + +| Invariant | Owning implementation | Smallest hostile evidence | Final verification | +|---|---|---|---| +| INV-001 | authority_policy builder and lookup | duplicate, missing, invalid, unknown, and unwired action cases | focused pure tests plus exact reference/table set comparison | +| INV-002 | evaluator signature and decision constructor | forged stage/posture public input and old internal keywords | API, signature, repository-search, and architecture checks | +| INV-003 | actor resolver and posture map | inactive Party, forged assistant, autonomous Party, assisted high action with/without grant | focused PostgreSQL authority tests | +| INV-004 | AuthorityTarget and row target policy | wrong target kinds, DEPLOYMENT, malformed refs | focused pure and PostgreSQL tests | +| INV-005 | scope resolver | missing, wrong-kind, inactive, foreign-tenant, multi-anchor, cyclic-lineage targets | two-tenant and hostile containment tests | +| INV-006 | direct path evaluator | absent, expired, inactive, wrong-action, role-expired, revoked grants | focused authority tests | +| INV-007 | scope resolver plus row cap | upward, no-inherit descendant, missing-lineage, broad review descendant | focused inheritance tests | +| INV-008 | delegated path evaluator | nondelegable action, missing/revoked source, expiry, action/scope/mode widening | focused delegation tests | +| INV-009 | outcome ladder | no-grant autonomous output and revoked assisted output | outcome-order tests plus absent-effect assertions | +| INV-010 | path selector and trace builder | caller fake bases and reversed insertion order | exact request/result/trace assertions and contract validation | +| INV-011 | all evaluator callers and manifest grounding | old signature scan, new action claim, SI outcome drift | caller tests, manifest tests, SI conformance | +| INV-012 | GatePipeline and profile caller composition | non-allow at each write entry point with transaction/order observation | commit, FFSNaprave, output, read, rollback, and record-order tests | + +Required cheap local checks after implementation: + +1. focused pure action-table tests; +2. focused authority, caller, SI FFSNaprave, output, and runtime-receipt tests; +3. the full PostgreSQL-backed test suite; +4. python3 conformance/ofarm_pkg_contract_check.py; +5. the standalone architecture check at the repository-pinned Python and Ruff + versions; +6. canonical test-inventory verification after mechanical regeneration; +7. Ruff over every changed Python file; +8. git diff --check; and +9. an exact base-to-head scope and forbidden-area inspection. + +Final hosted evidence after implementation requires the repository's normal +lightweight checks, exact-head zero-Blocker content review, baseline admission, +required hosted baselines and publication, and final receipt. Phase A alone +does not request expensive baselines. + +The design-only baseline observation was limited and honest: three pure tests +in kernel/tests/test_stages.py passed at the exact base. Seven database-backed +tests did not execute because the isolated Phase A snapshot had no PostgreSQL +socket. That is environment absence, not passing database evidence. + +## 11. Non-goals and follow-ups + +Non-goals are the non-effects in section 2, especially grant/delegation +mutation, production bootstrap/recovery/break-glass, complete sharing/output +authorization, new actorship contracts, new actions, law/contracts, schema, +profiles, capabilities, deployment, and production-readiness. + +Follow-ups: + +- after #353 settles the interface, #175 may create one Delivery child for + governed grant/delegation creation, narrowing, and revocation; +- a separate later #175 child owns production bootstrap, recovery, and + break-glass custody; +- #177 owns complete sharing and output permission plans, redaction, and + delivery authorization; and +- positive autonomous-software support requires separate Delivery work that + implements and proves the accepted CP3 sponsor-bound actorship evidence. + +No follow-up is a prerequisite for this evaluator slice. None may be appended +to this pull request merely to clear review. + +## 12. Provisional posture + +Not provisional. + +The implementation remains pre-deployment and does not authorize deployment, +but the evaluator design itself is not a temporary semantic compromise. It is +the conservative implementation of the currently accepted action vocabulary: +unknown and autonomous cases refuse, current runtime reachability does not +expand, and later mutation or actorship work must consume this interface rather +than replace its fail-closed ownership. + +## 13. Open decisions and review disposition + +Resolved design decisions: + +- ASSERT_OPERATION_CLAIM derives DRAFT_PREPARATION, matching the accepted + temporal governed-command requirement and the fact that assertion is + distinct from REVIEW_ACCEPT promotion. +- all observation, assertion, operation-report, and review-request preparation + rows derive DRAFT_PREPARATION; governance review rows own PROMOTION. +- OUTPUT_FILE_SUBMISSION_ASSEMBLY uses the conservative ATTEST_SIGN family. +- no autonomous software posture is enabled. +- DERIVED_LINEAGE_SCOPES is accepted only where row policy L permits it and + only with a unique durable DERIVED_FROM path. +- accepted-but-unwired rows are known policy and explicit non-allow, not new + runtime capability. +- exact high-governance use may be preserved while its effective inheritance is + capped to NO_INHERIT. + +Open decisions: none that materially change this design. + +Review disposition: + +- Blockers: none found in Phase A review. +- Follow-ups: the separate Delivery work listed in section 11. +- Preferences: exact private helper names and test-file partitioning may change + without changing the approved architecture or invariants. + +## 14. PR boundary confirmation + +The intended pull request changes one primary trust boundary: runtime authority +evaluation. Its complete slice is the immutable matrix, derived evaluator, +durable scope proof, migrated callers, check/effect ordering inside existing +transactions, decision trace, focused hostile tests, durable RFC, and +mechanical evidence. + +Scope remains inside that boundary. If implementation requires principal +resolution, database role/schema/migration/transaction ownership, grant +mutation, bootstrap/key custody, complete sharing/output permission, new +actorship contracts, new actions, law, profile activation, deployment, or +another authority owner, implementation stops before editing that boundary and +the work is split. From 178f150ce56f1bdad96330ba845d210ee0911f2a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Samo=20A=C4=8Dko?= Date: Mon, 31 Aug 2026 11:12:41 +0200 Subject: [PATCH 2/8] Bind authority Phase A to draft PR Name PR #359 in the durable issue #353 design contract so the approval envelope cannot transfer to another pull request. --- ...OFARM_Runtime_Authority_Action_Matrix_Evaluation_RFC_v0_1.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/rfcs/OFARM_Runtime_Authority_Action_Matrix_Evaluation_RFC_v0_1.md b/docs/rfcs/OFARM_Runtime_Authority_Action_Matrix_Evaluation_RFC_v0_1.md index 625e5ecd..ccf0c159 100644 --- a/docs/rfcs/OFARM_Runtime_Authority_Action_Matrix_Evaluation_RFC_v0_1.md +++ b/docs/rfcs/OFARM_Runtime_Authority_Action_Matrix_Evaluation_RFC_v0_1.md @@ -8,6 +8,8 @@ Delivery issue: samovers/OFARM2#353 Tracking epic: samovers/OFARM2#175 +Draft implementation pull request: samovers/OFARM2#359 + Repository base: samovers/OFARM2 at 88b10a5acac466a1ea3ee85c3006f919c3f97327 From 4f863fa98c4407d95b06642aaf9e8487088e9d7b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Samo=20A=C4=8Dko?= Date: Sun, 6 Sep 2026 18:05:43 +0200 Subject: [PATCH 3/8] Define the fresh-approval provider handshake 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. --- ...ority_Action_Matrix_Evaluation_RFC_v0_1.md | 218 +++++++++++++++--- 1 file changed, 190 insertions(+), 28 deletions(-) diff --git a/docs/rfcs/OFARM_Runtime_Authority_Action_Matrix_Evaluation_RFC_v0_1.md b/docs/rfcs/OFARM_Runtime_Authority_Action_Matrix_Evaluation_RFC_v0_1.md index b3386d70..b12e69e7 100644 --- a/docs/rfcs/OFARM_Runtime_Authority_Action_Matrix_Evaluation_RFC_v0_1.md +++ b/docs/rfcs/OFARM_Runtime_Authority_Action_Matrix_Evaluation_RFC_v0_1.md @@ -2,8 +2,10 @@ Date: 2026-09-06 -Design revision: 2. This replaces the unapproved implementation proposal at -`178f150ce56f1bdad96330ba845d210ee0911f2a`, not accepted OFARM law. +Design revision: 3. This corrects the fresh-approval interface in revision 2 at +`1473a4c16d8e716b03a3c36c2e36114e6e9fb255`. The unapproved legacy proposal at +`178f150ce56f1bdad96330ba845d210ee0911f2a` remains superseded. No accepted OFARM +law changes. Status: design review pending; scope amendment and implementation prerequisites remain open. No OFARM2 semantic approval, runtime implementation, baseline @@ -234,11 +236,12 @@ Use one small production-only provider and a narrow tenant read adapter. Private names below describe ownership; they are not new machine contracts or a frozen API while the exact source bindings remain absent. -The intended entry point is a typed authorization operation on the active +The intended entry point is a typed authorization provider on the active `TenantUnitOfWork`, reached through `ApplicationRuntime.tenant_unit_of_work`. Composition constructs its private dependencies from the same connection. It must be exercised through that actual composition, not only by importing -a pure helper. +a pure helper. Its bounded preparation and final-evaluation operations share +one implementation of the canonical policy, path selection and cutoff rules. The trusted input binds, as one immutable value: @@ -246,8 +249,13 @@ The trusted input binds, as one immutable value: - the selected command/action and exact current policy/rule/binding manifest; - the schema-valid full effect intent and canonical digest; - current trusted attempt identity, time, exclusive deadline and snapshot - provenance from the transaction-policy owner; and -- any applicable already-governed approval evidence for verification. + provenance from the transaction-policy owner; +- applicable persisted prerequisites with exact immutable record/digest and + snapshot-visibility proof, including challenge/display evidence for fresh + approval; and +- for final evaluation, the separately typed, mode-correct prospective + finalization evidence described below, constructed by the transaction + consumer but not yet committed. A request cannot construct that value by supplying a tenant, deadline, stage, posture, policy URL, grant dictionary, or snapshot label. The provider applies @@ -277,12 +285,58 @@ READ COMMITTED queries or caller-authored proof objects does not satisfy it. A coherent single-statement read may help capture a snapshot, but is not by itself a commit guard or authority to introduce a new snapshot contract. -The result is either a truthful ingress/infrastructure refusal or a prepared -decision bundle with its immutable basis and guard obligations. A local typed -envelope distinguishes prepared evidence from any later durable receipt; -that status is not inserted as an invented field in canonical records. -Prepared bytes remain internal. They confer no portable capability and cannot -be returned as a durable public decision. +### Preparation is distinct from a prepared decision + +For the post-act `FRESH_HUMAN_APPROVAL_REQUIRED` protocol, the same provider +offers a bounded non-authoritative preparation operation before the consumer +can construct prospective approval evidence. It requires the trusted +rule-selected mode, admitted operation/generation and exact authenticated +human act, challenge/display bindings, final snapshot and complete guards. +It is not challenge issuance or a token retained across human think time. + +Its immutable local preparation result binds the tenant, operation/generation, +attempt, requester and intended approver, human act, intent, policy/rule, +challenge/final snapshots and their equal authority-relevant-state digests. +It supplies the canonical candidate requester path and basis, independently +eligible natural-person approver path, complete cutoff inputs, +`approvalExpiresAt` and candidate `decisionValidUntil`, computed in section 7. +These values are inputs to evidence construction, not an authorization +outcome. Preparation emits no decision result, decision trace, decision-bundle +digest, consumption, effect, durable claim or portable path outcome. Failure +returns a typed preparation refusal, never a successful candidate with missing +proof or an invented authorization result. + +The consumer uses those provider-derived values to construct and hash the +complete mode-correct finalization-evidence candidate. It does not duplicate +path selection or expiry calculation. The provider accepts that candidate +through a distinct prospective-evidence input bound to the same preparation +and attempt, not by pretending to load an already-persisted approval record. +The input carries the complete candidate bytes, deterministic identity and +digest, and their exact act, snapshot, intent, basis and cutoff bindings. + +Persisted prerequisites and prospective finalization evidence are different +typed inputs with different verification rules. Neither a caller label nor +schema validity establishes their provenance. The prospective input is usable +only in its rule-selected finalization-evidence role; it cannot stand in for a +missing persisted grant, role, CP3 record or snapshot. Prior committed evidence +is not portable approval for another attempt. The local type distinction adds +no field or contract to canonical records and claims no persistence. + +The final-evaluation operation returns a truthful ingress/infrastructure +refusal or, when canonical evaluation is possible, a prepared decision bundle +with its immutable basis and guard obligations. This is a different result +type from non-decision preparation. Both stay internal and non-durable; only +the final evaluation can construct the decision bundle. The consumer cannot +pass a preparation result as a decision or choose a generic “skip approval” +flag. Successful fresh-approval finalization requires the full handshake and +equality checks below, irrespective of which operation a caller invokes. + +`DIRECT_HUMAN_ACTION_REQUIRED` instead supplies its exact prospective +direct-principal act/representation evidence to final evaluation. It creates +no synthetic challenge, separate approver or fresh-approval preparation. +`NOT_REQUIRED` follows its own bound protocol without human-finalization +evidence. Only the trusted rule selects these modes; a request cannot switch +modes to bypass approval. Do not finalize an implementation card until this interface has a concrete production-path test and an independently usable provider completion @@ -371,8 +425,68 @@ Use the selected path's outcome-specific reason ranking. Preserve all other evaluated paths as ordered diagnostics, not authority combined with that path. Outstanding human approval can be reported only for an otherwise sufficient -path. Verify applicable governed approval evidence and cutoffs; this provider -does not run the human ceremony, reserve authority, or consume approval. +path. A truthful non-ALLOW decision is not a substitute for the non-decision +post-act preparation below. Verify applicable persisted prerequisites and +prospective finalization evidence and cutoffs; this provider does not run the +human ceremony, reserve authority, or consume approval. + +### Fresh-approval preparation and final equality + +The interface follows [canonical PR #20 section 11 at its pinned head](https://github.com/samovers/OFARM/blob/98f8c4fafbae42c8f7fd931f43f53adcb4733713/package_meta/history/clean_baseline_migration/phase_reports/governed_human_approval_transaction_and_consumption_protocol_rfc_candidate_v0_1.md#11-required-post-act-revalidation). +After post-act revalidation and the exact challenge/final relevant-state +comparison pass, preparation performs this sequence under the same final +snapshot and guards: + +1. Use the shared authorization implementation to evaluate every global and + per-path condition except the still-outstanding fresh-approval condition. + No authorization result or decision bundle is emitted. +2. Require global preconditions to pass and apply the canonical lattice and + path tuple to otherwise-sufficient requester paths. Determine the candidate + requester path and basis that would otherwise require fresh human approval. +3. Independently determine the canonical natural-person approver path that + satisfies every non-finalization condition for the same action, target, + effect subject, scope, purpose, Party posture and intent. Sponsor status + alone remains insufficient. +4. Collect all rule-required cutoffs, including the trusted transaction and + session deadlines, candidate requester and applicable approver paths, + representation, sources, policy/snapshot, resources, evidence and + sovereignty inputs. A required missing cutoff fails preparation. +5. Compute `approvalExpiresAt` under the exact approval profile, then compute + candidate `decisionValidUntil` with the canonical minimum-cutoff function + using that requester path and `approvalExpiresAt`. + +The consumer binds the full preparation values into the prospective approval +profile before computing its identity and digest. The candidate is still +uncommitted and non-consumable. Raw human-act metadata or an approval ID alone +cannot replace the complete candidate. + +Final evaluation verifies the candidate's schema, identity/digest and exact +tenant, operation/generation, attempt, authenticated act, principal and +representation, challenge/display, policy/rule, intent, snapshot/relevant-state, +requester/approver basis and expiry bindings. It then performs the complete +canonical evaluation, including fresh-approval validity, over the complete +current evidence. The candidate basis is a binding to verify, not a filter +that forces path selection or exempts any check. Invalid prospective evidence +cannot satisfy fresh approval or support ALLOW; it follows the canonical +refusal/failure protocol, not an ALLOW that the coordinator must overrule. + +Successful finalization requires the final selected requester path and basis +to be identical to the preparation and hashed candidate, and returned +`decisionValidUntil` to equal the prebound value exactly. No different basis, +shorter or longer validity window, missing cutoff, or other-attempt evidence +can satisfy this equality. Do not repair a mismatch by choosing another path, +rewriting/re-hashing the approval or silently adopting a new window. It fails +finalization: no successful finalization handoff, effect or consumption is +permitted, and the consumer discards the prospective evidence. Any truthful +failure evidence belongs to the canonical failure protocol; it cannot turn +that candidate into a committed approval or authority token. + +Preparation and final evaluation share the policy/path/cutoff implementation; +they differ in allowed outputs and the explicit protocol point at which the +prospective approval can be checked. No coordinator-owned policy engine or +caller-selectable condition mask is introduced. + +### Final decision evidence Build complete request/result/full-trace records and snapshot/basis bindings. The decision-bundle projection removes only @@ -383,15 +497,26 @@ reuse v0.1 evidence fields to simulate v0.2 meaning. ## 8. Evaluation lifetime and transaction handoff -The provider's state sequence is: +The ordinary decision-evaluation sequence is: `BOUND_INPUT -> INGRESS_VALID -> CURRENT_FACTS_PROVEN -> EVALUATED -> PREPARED_EVIDENCE -> HANDED_TO_OWNING_TRANSACTION`. +For post-act fresh-approval finalization, insert the explicit handshake before +EVALUATED: `CURRENT_FACTS_PROVEN -> NON_DECISION_PREPARATION -> +CONSUMER_BOUND_PROSPECTIVE_EVIDENCE -> FINAL_EVALUATION_AND_EQUALITY_CHECK`. +Only that final operation may construct the decision bundle; only a valid +ALLOW satisfying the equality checks is eligible for successful finalization. +The consumer-owned middle step constructs/hashes evidence; it does not persist +it, select authority or calculate a competing validity window. +NON_DECISION_PREPARATION is never interchangeable with PREPARED_EVIDENCE. + Ingress/infrastructure failure does not invent a valid authorization result. A valid non-ALLOW result can reach PREPARED_EVIDENCE, but never an effect or consumption transition. Closing/refusing the UnitOfWork invalidates further -provider use. There is no provider-owned COMMITTED state. +provider use, including its preparation and prospective-evidence bindings. +There is no provider-owned COMMITTED state. Rollback discards prospective +evidence; a new attempt cannot reuse it even if its old expiry has not passed. Every prepared decision binds the current transaction attempt and full intent. Compute decisionValidUntil as the canonical minimum of the trusted @@ -437,14 +562,23 @@ For the future NOT_REQUIRED operation-claim consumer: 7. Public results use the separately admitted CP2 surface and current disclosure policy. Full internal traces are not exposed by this provider. -Human-finalization actions consume their own PR #20 protocol. Governed reads -use their separately owned buffered evidence/disclosure protocol. PR #26 -cannot be used as a universal coordinator for those modes. +Human-finalization actions consume their own PR #20 protocol. For fresh +approval, its consumer owns admission of the exact act/open generation and +the guarded final transaction, uses this provider's non-decision preparation, +constructs the prospective approval, and returns it to the same provider for +the complete final evaluation and exact basis/window equality checks. The +consumer then owns the remaining gates and atomic success set; the candidate +becomes durable only with that complete successful commit. Challenge issuance, +the human ceremony, persistence, approval/decision consumption and transaction +coordination remain outside this provider. Governed reads use their separately +owned buffered evidence/disclosure protocol. PR #26 cannot be used as a +universal coordinator for those modes. This is an interface obligation for those later owners, not their implementation or verification in #359. Provider tests can prove exact -prepared evidence, transaction binding and no owned writes. Durable refusal, -lost-acknowledgement recovery, atomic effects and consumption require +non-decision preparation, prospective-evidence validation, final basis/window +equality, prepared evidence, transaction binding and no owned writes. Durable +refusal, lost-acknowledgement recovery, atomic effects and consumption require consumer-owned integration tests; they cannot be reported as #353 evidence. ## 9. First consumer and the incompatible old command binding @@ -505,6 +639,10 @@ created through production composition, not an HTTP route opened by this PR. | AUTH-012: prepared is not durable; no effect/commit authority | Provider result envelope and composition | Inject read/hash failure or roll back the enclosing UnitOfWork; no durable receipt, evidence-commit claim, domain write or consumption is produced by the provider. | | AUTH-013: complete guard obligations cannot be omitted | Read-footprint output and consumer contract | Drop a negative/set-valued obligation or alter a captured revision; the handoff fails its exact contract. Commit-race enforcement remains consumer-owned and cannot be claimed from this test alone. | | AUTH-014: production is legacy-free and commands remain closed | Application/UoW composition and architecture checker | Exercise real composition and all governed route closures; a legacy import, public authority dependency/SQL escape, or newly enabled command fails verification. | +| AUTH-015: fresh-approval preparation is non-authoritative | Same provider's bound preparation operation and shared policy/path/cutoff implementation | With valid post-act inputs, obtain exact candidate requester/approver bases and expiry values, but no decision result/trace/bundle, consumption, effect or durable claim. Fail a global/path condition or omit a cutoff: no successful preparation. Passing preparation as a decision or requesting an approval-skip flag cannot authorize anything. | +| AUTH-016: prospective finalization evidence has an explicit, restricted input role | Same provider's final-evaluation input and evidence verifier | A correctly bound, hashed prospective approval not yet stored in the database reaches full final evaluation and can produce prepared ALLOW when every check passes, without a durable claim. Wrong bytes/digest, act, snapshot, intent or approver binding cannot support ALLOW. A prospective grant or caller assertion of persistence cannot replace governed prerequisite proof. | +| AUTH-017: candidate and final requester basis/window must match exactly | Shared canonical selection/cutoff logic and final equality checks | Substitute a different otherwise-eligible requester basis, or shorten/extend the prospective decisionValidUntil even within the transaction deadline. Final evaluation cannot force selection, rewrite the candidate or accept a different returned window; no ALLOW based on that candidate or successful finalization handoff. | +| AUTH-018: preparation and prospective evidence are attempt- and mode-bound | Bound provider lifetime, trusted mode and candidate admission | Reuse the same intent/preparation/approval in another attempt or after rollback, even before expiry; reject reuse as authority. Substitute NOT_REQUIRED or DIRECT_HUMAN_ACTION_REQUIRED, or supply a synthetic challenge/separate approver to direct-human mode; no bypass. | Test setup uses fictional data and the existing separately owned provisioning path. No production bootstrap or grant mutation is added to make fixtures @@ -512,6 +650,14 @@ work. Relevant cases require real PostgreSQL tenant binding, two-tenant isolation, exact currentness inputs and recorded read provenance; a pure function fed caller-authored grant dictionaries is insufficient. +AUTH-015–018 exercise preparation and final evaluation through the same +production-bound provider and guarded attempt fixture. The fixture supplies +the transaction owner's trusted inputs and constructs prospective evidence +from the provider's output; it must not implement its own path-selection or +cutoff algorithm. Assertions inspect both returned types/bytes and the absence +of provider-owned writes. The valid prospective-approval case proves the +handshake is usable, not merely that every attempt can be refused. + The exact source schemas and trusted input/read interface must exist before these proposed cases can count as implemented evidence. Consumer race tests must additionally cover revocation/set changes between evaluation and commit, @@ -541,6 +687,22 @@ Fresh review must evaluate these corrections and the production/interface changes. It must not treat the old review's recommendation to retain a code-owned table as authority over the later canonical bundle ownership. +### Revision 2 review: bounded B1 correction + +The [revision 2 review](https://github.com/samovers/OFARM2/pull/359#pullrequestreview-5125869052) +at `1473a4c16d8e716b03a3c36c2e36114e6e9fb255` identified one missing +fresh-approval provider handshake within G3. Sections 6–8 now distinguish +non-decision preparation, consumer-built uncommitted finalization evidence, +and complete final evaluation with exact requester-basis/window equality. +AUTH-015–018 specify focused verification through the same production-bound +provider. This is an interface/conformance correction to the existing pinned +PR #20 protocol, not new law or transaction-coordination ownership. + +Re-review is limited to that fix and affected invariants unless new evidence +demonstrates a broader defect. The earlier nine findings are not reopened. +The scope, canonical-readiness and concrete-interface gates remain open; this +correction does not claim a new zero-Blocker review or implementation approval. + ## 12. Expected implementation areas and code excellence Only this existing RFC changes in the current design revision. It remains @@ -565,11 +727,11 @@ inside the approved boundary can travel; discovery of a new authority cannot. | Code-excellence invariant | Planned assessment | |---|---| -| EXC-001 — one authoritative path | One canonical semantic source, one production evaluator; the transaction owner consumes its evidence rather than re-evaluating policy in a second engine. | +| EXC-001 — one authoritative path | One canonical semantic source and one production authorization implementation shared by non-decision preparation and final evaluation; the transaction owner constructs evidence from those values, not a second path-selection/cutoff engine. | | EXC-002 — no avoidable duplication | No handwritten second matrix, compatibility authority API, extra durable decision store, retry ledger, or copied schema inventory. | -| EXC-003 — direct invariant trace | AUTH-001–014 map the typed entry, bound reader, evaluator and evidence constructor to focused tests. Missing real reachability blocks completion. | +| EXC-003 — direct invariant trace | AUTH-001–018 map the typed entry, bound reader, preparation/final-evaluation handshake and evidence constructor to focused tests. Missing real reachability blocks completion. | | EXC-004 — delete superseded owned paths | Withdraw the old plan; introduce no legacy compatibility path. The quarantined legacy system is not an owned production path and is not deleted as an unrelated migration. | -| EXC-005 — abstractions pay rent now | Bound input/output prevent mixed tenant/rule/attempt facts; a narrow reader contains existing connection authority. No generic policy engine, plugin registry, public SQL facade or future dispatcher. | +| EXC-005 — abstractions pay rent now | Bound input/output prevent mixed tenant/rule/attempt facts; distinct preparation, prospective-evidence and prepared-decision values prevent authority/persistence confusion in the required fresh-approval handshake. A narrow reader contains existing connection authority. No generic policy engine, plugin registry, public SQL facade or future dispatcher. | | EXC-006 — simpler credible alternative | Adding a table to kernel.authority fails production isolation and canonical ownership. A pure helper alone fails the bound production-read outcome. A new transaction owner is unnecessary and crosses into #178. The proposed provider plus typed reader is the smallest plausible slice, subject to gate G3. | ## 13. Gates, provisional posture, and review state @@ -584,7 +746,7 @@ path is authorized. |---|---| | G1 — Delivery scope | Steward explicitly accepts the issue amendments in section 2, including prepared-versus-durable evidence and production-only callers; full evaluation coverage remains explicit. | | G2 — Canonical readiness | Complete the governing staged sequence and replace missing entries in section 5 with reviewed exact promoted/extracted bytes and provenance. Semantic approval alone is insufficient. | -| G3 — Concrete trusted interface | Close the production principal/representation/CP3 input mapping, policy selection compatibility, coherent typed read/snapshot plan, deadline source and complete guard handoff. Demonstrate a production-path test design and independently useful provider completion without inventing another authority owner. Split any demonstrated new boundary before editing it. | +| G3 — Concrete trusted interface | Close the production principal/representation/CP3 input mapping, policy selection compatibility, coherent typed read/snapshot plan, deadline source and complete guard handoff. Include the sections 6–8 fresh-approval handshake: non-decision preparation, distinct prospective uncommitted evidence, exact candidate/final requester-basis and validity equality, and cross-attempt/mode refusal, verified by AUTH-015–018 through the same provider. Demonstrate independently useful production-provider completion without inventing another authority owner. Split any demonstrated new boundary before editing it. | | G4 — Fresh OFARM2 approval | Review this corrected Phase A to zero Blockers, then present a complete decision card naming existing PR #359 and obtain the required exact later task-user approval. No such card is issued by this revision. | Evidence requiring redesign: a machine binding contradicts the approved @@ -633,6 +795,6 @@ transaction coordination, protected effects, selection authority and temporal persistence with their own owners. No cross-boundary implementation is hidden in this plan. -What is next: review this revised Phase A and its explicit issue-scope -amendments, resolve G1–G3, then obtain a fresh #359 decision approval before -runtime edits. +What is next: re-review the revision 2 B1 correction and affected invariants; +resolve the still-open scope, canonical-readiness and concrete-interface gates +before a fresh #359 decision approval and runtime edits. From 263cd32722ff2b482910bd7bb880f91aa8391838 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Samo=20A=C4=8Dko?= Date: Sun, 6 Sep 2026 19:37:58 +0200 Subject: [PATCH 4/8] docs: bind approval preparation to current governed state --- ...ority_Action_Matrix_Evaluation_RFC_v0_1.md | 317 ++++++++++++++---- 1 file changed, 249 insertions(+), 68 deletions(-) diff --git a/docs/rfcs/OFARM_Runtime_Authority_Action_Matrix_Evaluation_RFC_v0_1.md b/docs/rfcs/OFARM_Runtime_Authority_Action_Matrix_Evaluation_RFC_v0_1.md index b12e69e7..e98ee74b 100644 --- a/docs/rfcs/OFARM_Runtime_Authority_Action_Matrix_Evaluation_RFC_v0_1.md +++ b/docs/rfcs/OFARM_Runtime_Authority_Action_Matrix_Evaluation_RFC_v0_1.md @@ -2,8 +2,10 @@ Date: 2026-09-06 -Design revision: 3. This corrects the fresh-approval interface in revision 2 at -`1473a4c16d8e716b03a3c36c2e36114e6e9fb255`. The unapproved legacy proposal at +Design revision: 4. This addresses the focused review of revision 3 at +`4f863fa98c4407d95b06642aaf9e8487088e9d7b`: provider-owned challenge-state +comparison, complete approval inputs, exact retry semantics and the reviewed +facade-extension gate. The unapproved legacy proposal at `178f150ce56f1bdad96330ba845d210ee0911f2a` remains superseded. No accepted OFARM law changes. @@ -111,9 +113,10 @@ reviews, decisions, and evidence are not rewritten. Primary trust boundary: **production authorization evaluation**. Intended PR boundary: one evaluator, exact rule interpretation, narrow typed -authority reads, prepared evidence construction, and mechanical production -composition/tests needed to prove that capability. No independent authority, -custody, persistence, or command-execution capability travels with it. +authority reads, prepared evidence construction, a reviewed typed facade and +architecture-contract extension, and production composition/tests needed to +prove that capability. No independent authority, custody, persistence, or +command-execution capability travels with it. | Owned fact or operation | Owner | |---|---| @@ -123,6 +126,8 @@ custody, persistence, or command-execution capability travels with it. | Policy/command selection and immutable runtime component identity | Existing separately reviewed selection/RuntimeBundle owners | | Database session, transaction identity/finalization, isolation, complete commit guard and uncertainty reconciliation | Existing transaction owners and later #178 work; no new owner here | | One current evaluation, selected sufficient path, complete prepared decision evidence and read obligations | This provider | +| Execute the rule-selected final authority-relevant projection, compute its JCS/SHA-256 digest, and compare it with the verified challenge digest | This provider, using its current typed authority snapshot; canonical OFARM owns the projection and JSON Pointer semantics | +| Capture the authenticated human act; render/retain its display; persist generation invalidation and issue a replacement challenge | Existing human-act, display/retention and transaction owners; the provider verifies their bound proof and reports invalidity, but does not perform these operations | | Protected-effect schema, mapping, gate PASS, assertion state and temporal mapping | Separately owned domain/temporal validators and command binding | | Durable request/result/trace, consumption, attempt/receipt, original-result recovery and safe response after commit | Command/evidence coordinator; #178 and the applicable consumer | | Requests, optional AI metadata, schema hints, candidate references | Caller-owned claims, never authoritative restrictions | @@ -169,8 +174,8 @@ Permitted future effects, only after the gates in section 13: exposing SQL or connection control; - prepare exact request/result/full-trace evidence and bindings for the owning transaction consumer; and -- add the production composition hook, architecture registration, tests, - documentation and mechanically necessary inventory changes. +- add the reviewed typed facade/architecture-contract extension and production + composition hook, tests, documentation and mechanical inventory changes. Non-effects and non-goals: @@ -191,6 +196,12 @@ snapshot/guard authority, or selector decision is not “just wiring.” Stop before editing that boundary and identify separately reviewable Delivery work. No such issue or exception is created by this design revision. +Extending the checker's exact TenantUnitOfWork facade is also substantive, +not mechanical registration. It may remain inside this authorization boundary +only if it exposes the bounded provider without adding connection, tenant, +persistence or selection authority. Section 12 records the current shape and +size constraints; G3 requires a reviewed concrete extension before Phase B. + ## 5. Canonical sources and readiness inventory The following are exact semantic planning sources, **not executable authority**: @@ -241,7 +252,8 @@ The intended entry point is a typed authorization provider on the active Composition constructs its private dependencies from the same connection. It must be exercised through that actual composition, not only by importing a pure helper. Its bounded preparation and final-evaluation operations share -one implementation of the canonical policy, path selection and cutoff rules. +one implementation of the canonical policy, authorization-view extraction, +relevant-state projection/comparison, path selection and cutoff rules. The trusted input binds, as one immutable value: @@ -251,8 +263,11 @@ The trusted input binds, as one immutable value: - current trusted attempt identity, time, exclusive deadline and snapshot provenance from the transaction-policy owner; - applicable persisted prerequisites with exact immutable record/digest and - snapshot-visibility proof, including challenge/display evidence for fresh - approval; and + snapshot-visibility proof, including the exact challenge revision, display + bytes/retrievability proof, renderer/display-policy metadata and retention + binding for fresh approval; +- the exact authenticated human act where required, including server-observed + `humanActedAt` from its trusted boundary, never client time as authority; and - for final evaluation, the separately typed, mode-correct prospective finalization evidence described below, constructed by the transaction consumer but not yet committed. @@ -271,12 +286,15 @@ visibility and relevant reference bindings. It does not accept a connection, SQL expression, table name, transaction callback, or caller-filtered candidate list. Existing Row-Level Security remains an independent backstop. -The read footprint includes principal/representation/CP3 evidence, target and -typed inputs, role/grant/delegation/sharing candidates, source records, -revocations, purpose/condition evidence, sovereignty, applicable policy and -currentness facts. It must cover absence and complete sets as well as positive -rows. Bounds may reject an oversized/incomplete evaluation; they may not -truncate a set and call the result complete. +The read footprint includes principal/representation/CP3 evidence, target, +typed inputs and effect subject, role/grant/delegation/sharing candidates, +source records, revocations, purpose/condition evidence, sovereignty, +applicable policy and currentness facts. For fresh approval it includes every +input selected by the rule-owned relevant-state projection and its exact JSON +Pointers, including eligible authority paths and approver-separation facts, +plus the challenge/display and act-validity proof required below. It must +cover absence and complete sets as well as positive rows. Bounds may reject an +oversized/incomplete evaluation; they may not truncate a set and call it complete. The concrete PostgreSQL read plan, immutable snapshot representation, transaction-policy input factory, and complete read/guard interface are a @@ -294,20 +312,39 @@ rule-selected mode, admitted operation/generation and exact authenticated human act, challenge/display bindings, final snapshot and complete guards. It is not challenge issuance or a token retained across human think time. -Its immutable local preparation result binds the tenant, operation/generation, -attempt, requester and intended approver, human act, intent, policy/rule, -challenge/final snapshots and their equal authority-relevant-state digests. -It supplies the canonical candidate requester path and basis, independently -eligible natural-person approver path, complete cutoff inputs, -`approvalExpiresAt` and candidate `decisionValidUntil`, computed in section 7. -These values are inputs to evidence construction, not an authorization -outcome. Preparation emits no decision result, decision trace, decision-bundle -digest, consumption, effect, durable claim or portable path outcome. Failure -returns a typed preparation refusal, never a successful candidate with missing -proof or an invented authorization result. +Its immutable local preparation result supplies one bound authorization view +and all provider-derived bindings needed by the complete approval profile in +canonical PR #20 section 9.1 and PR #11 section 18.3: + +- tenant, operation/generation, attempt, action/finalization mode, exact human + act, effect-intent schema/ref/digest, extractor and policy/rule bindings; +- derived authority target, typed inputs, effect subject and extracted + scope/twin/time/purpose, with their exact resource revisions/proof bindings + and derived-view digest; +- requester and intended natural-person approver identities, represented Party + and immutable representation basis where applicable, canonical candidate + requester path/basis and independently eligible same-action approver path; +- the provider-computed final rule-selected relevant-state projection and + `authorityRelevantStateDigest`, verified challenge digest, and both complete + challenge/final snapshot refs and proof bindings; +- verified exact challenge/display/act and rule-selected separation bindings; + and +- complete cutoff inputs, `approvalExpiresAt` and candidate + `decisionValidUntil`, computed in section 7. + +This is a typed view of the exact canonical profile requirements, not a second +handwritten schema or permission to omit any canonical field. A successful +preparation proves the required digest equality; it never copies a consumer's +assertion that the two projections match. These values are evidence-construction +inputs, not an authorization outcome. Preparation emits no decision result, +decision trace, decision-bundle digest, consumption, effect, durable claim or +portable path outcome. Failure returns a typed preparation refusal, never a +successful candidate with missing proof or an invented authorization result. The consumer uses those provider-derived values to construct and hash the -complete mode-correct finalization-evidence candidate. It does not duplicate +complete mode-correct finalization-evidence candidate together with the exact +act/display/transaction prerequisites supplied by their owners. It does not +duplicate authorization-view extraction, relevant-state projection/comparison, path selection or expiry calculation. The provider accepts that candidate through a distinct prospective-evidence input bound to the same preparation and attempt, not by pretending to load an already-persisted approval record. @@ -432,29 +469,76 @@ human ceremony, reserve authority, or consume approval. ### Fresh-approval preparation and final equality -The interface follows [canonical PR #20 section 11 at its pinned head](https://github.com/samovers/OFARM/blob/98f8c4fafbae42c8f7fd931f43f53adcb4733713/package_meta/history/clean_baseline_migration/phase_reports/governed_human_approval_transaction_and_consumption_protocol_rfc_candidate_v0_1.md#11-required-post-act-revalidation). -After post-act revalidation and the exact challenge/final relevant-state -comparison pass, preparation performs this sequence under the same final -snapshot and guards: - -1. Use the shared authorization implementation to evaluate every global and +The interface follows [canonical PR #20 section 11 at its pinned head](https://github.com/samovers/OFARM/blob/98f8c4fafbae42c8f7fd931f43f53adcb4733713/package_meta/history/clean_baseline_migration/phase_reports/governed_human_approval_transaction_and_consumption_protocol_rfc_candidate_v0_1.md#11-required-post-act-revalidation) +and [PR #11 sections 16.1 and 18.3](https://github.com/samovers/OFARM/blob/03a21f669ee04f96d444e14f00ae7212cab04803/package_meta/history/clean_baseline_migration/phase_reports/authorization_constraints_and_decision_evidence_rfc_candidate_v0_2.md#161-authority-evaluation-snapshot). +With a verified rule and complete current authority facts, the provider +performs this post-act sequence under the same final snapshot and guards: + +1. Revalidate the exact authenticated act/session, requester and intended + natural-person approver, representation, immutable challenge and + rule-selected separation/eligibility bindings. Verify the acknowledged + display's exact retrievable bytes, ref/digest and media type, renderer + identifier/version/digest, display-policy ref/digest, locale, timezone and + evidence-retention policy binding. Unavailable or changed bytes, renderer + or display metadata cannot support successful preparation. Verify trusted + `humanActedAt` precedes the exclusive challenge and reservation cutoffs, + and check all applicable current session/transaction validity. Client time + cannot establish timeliness. This verifies owners' proof; it does not add + rendering, act capture, storage, retention policy or key-custody operations. +2. Compute the final authority-relevant projection from the provider's current + typed snapshot using the exact rule-owned projection/JSON Pointers, then + compute JCS/SHA-256 and compare with the verified immutable challenge + `authorityRelevantStateDigest`. Include every rule-selected authority-path + and separation fact through the shared rule/path implementation, not a + coordinator-supplied projection, digest or equality flag. Record the final + projection/digest and both full snapshot refs. This comparison must pass + before continuing to candidate requester/approver selection below. +3. Use the shared authorization implementation to evaluate every global and per-path condition except the still-outstanding fresh-approval condition. No authorization result or decision bundle is emitted. -2. Require global preconditions to pass and apply the canonical lattice and +4. Require global preconditions to pass and apply the canonical lattice and path tuple to otherwise-sufficient requester paths. Determine the candidate requester path and basis that would otherwise require fresh human approval. -3. Independently determine the canonical natural-person approver path that +5. Independently determine the canonical natural-person approver path that satisfies every non-finalization condition for the same action, target, - effect subject, scope, purpose, Party posture and intent. Sponsor status - alone remains insufficient. -4. Collect all rule-required cutoffs, including the trusted transaction and + typed inputs, effect subject, scope, twin, purpose, tenant/sovereignty, Party + posture and intent/derived-view digests. Enforce the exact + `approvalSeparationPolicy`; sponsor status alone remains insufficient. +6. Collect all rule-required cutoffs, including the trusted transaction and session deadlines, candidate requester and applicable approver paths, representation, sources, policy/snapshot, resources, evidence and sovereignty inputs. A required missing cutoff fails preparation. -5. Compute `approvalExpiresAt` under the exact approval profile, then compute +7. Compute `approvalExpiresAt` under the exact approval profile, then compute candidate `decisionValidUntil` with the canonical minimum-cutoff function using that requester path and `approvalExpiresAt`. +A relevant-state digest mismatch returns a typed stale-challenge preparation +refusal: no successful preparation, prospective approval admission or ALLOW +from that act. This holds even if the requester basis and validity window +would otherwise remain sufficient. The transaction owner must invalidate the +act/generation through PR #20's failure protocol; only after the required +terminal record is durable may it issue an eligible replacement generation, +new challenge and new human act. The provider does not persist that transition. +Unrelated history outside the exact rule-owned projection does not invalidate +the challenge: full snapshot refs may differ while the relevant digests match, +provided every other final check, cutoff and commit guard passes. + +`APPROVAL_CHALLENGE_STALE` identifies the canonical lifecycle diagnostic, not a +new authorization outcome or a decision emitted by preparation. If complete +canonical evaluation produces refusal evidence for an otherwise sufficient +path lacking approval, `HUMAN_FINAL_ACTION_REQUIRED` remains the sole primary +reason for `REQUIRE_HUMAN_APPROVAL`; stale-challenge detail is diagnostic only. +Other independently established failures still follow canonical aggregation. + +Every current fresh-approval row selects `SAME_PRINCIPAL_ALLOWED`: the same +natural person may perform the challenged act if independently eligible under +the full lifecycle. `DISTINCT_APPROVER_REQUIRED` and its +`APPROVAL_SEPARATION_UNSATISFIED` diagnostic remain reserved; this plan neither +activates them nor requires an extra person for current rows. Direct-human +finalization instead verifies its exact direct-principal act and trusted +`humanActedAt` within the applicable session and final transaction cutoffs; +it gains no synthetic challenge, reservation or separate approver. + The consumer binds the full preparation values into the prospective approval profile before computing its identity and digest. The candidate is still uncommitted and non-consumable. Raw human-act metadata or an approval ID alone @@ -463,9 +547,14 @@ cannot replace the complete candidate. Final evaluation verifies the candidate's schema, identity/digest and exact tenant, operation/generation, attempt, authenticated act, principal and representation, challenge/display, policy/rule, intent, snapshot/relevant-state, -requester/approver basis and expiry bindings. It then performs the complete -canonical evaluation, including fresh-approval validity, over the complete -current evidence. The candidate basis is a binding to verify, not a filter +requester/approver basis and expiry bindings. The provider itself recomputes +the final rule-selected projection/digest from complete current facts and +requires equality with both the challenge and prepared/candidate values; +verifying consumer-recorded equality alone is insufficient. It revalidates +act timeliness, display and separation proof and performs the complete +canonical evaluation, including fresh-approval validity. Relevant drift +cannot be repaired by rehashing the candidate; it follows the stale-challenge +failure above. The candidate basis is a binding to verify, not a filter that forces path selection or exempts any check. Invalid prospective evidence cannot satisfy fresh approval or support ALLOW; it follows the canonical refusal/failure protocol, not an ALLOW that the coordinator must overrule. @@ -481,10 +570,11 @@ permitted, and the consumer discards the prospective evidence. Any truthful failure evidence belongs to the canonical failure protocol; it cannot turn that candidate into a committed approval or authority token. -Preparation and final evaluation share the policy/path/cutoff implementation; -they differ in allowed outputs and the explicit protocol point at which the -prospective approval can be checked. No coordinator-owned policy engine or -caller-selectable condition mask is introduced. +Preparation and final evaluation share one implementation for policy, +extraction, projection, paths and cutoffs. They differ in allowed outputs and +the explicit protocol point at which prospective approval can be checked. +No coordinator-owned policy engine or caller-selectable condition mask is +introduced. ### Final decision evidence @@ -502,13 +592,15 @@ The ordinary decision-evaluation sequence is: `BOUND_INPUT -> INGRESS_VALID -> CURRENT_FACTS_PROVEN -> EVALUATED -> PREPARED_EVIDENCE -> HANDED_TO_OWNING_TRANSACTION`. -For post-act fresh-approval finalization, insert the explicit handshake before -EVALUATED: `CURRENT_FACTS_PROVEN -> NON_DECISION_PREPARATION -> -CONSUMER_BOUND_PROSPECTIVE_EVIDENCE -> FINAL_EVALUATION_AND_EQUALITY_CHECK`. +For post-act fresh-approval finalization, replace the ordinary EVALUATED step +with the handshake: `CURRENT_FACTS_PROVEN -> NON_DECISION_PREPARATION -> +CONSUMER_BOUND_PROSPECTIVE_EVIDENCE -> FINAL_EVALUATION_AND_EQUALITY_CHECK +-> PREPARED_EVIDENCE -> HANDED_TO_OWNING_TRANSACTION`. Only that final operation may construct the decision bundle; only a valid ALLOW satisfying the equality checks is eligible for successful finalization. The consumer-owned middle step constructs/hashes evidence; it does not persist -it, select authority or calculate a competing validity window. +it, derive another authorization view/projection, select authority or calculate +a competing validity window. NON_DECISION_PREPARATION is never interchangeable with PREPARED_EVIDENCE. Ingress/infrastructure failure does not invent a valid authorization result. @@ -518,13 +610,27 @@ provider use, including its preparation and prospective-evidence bindings. There is no provider-owned COMMITTED state. Rollback discards prospective evidence; a new attempt cannot reuse it even if its old expiry has not passed. +That lifetime rule does not forbid an exact retry of the original human act +and intent when the consumer admits it under PR #20 sections 9.1, 9.2 and 16. +The same `humanActSubmissionId` must retain the same complete act bytes/digest +within the logical operation/generation. The consumer first looks up the +authoritative outcome: an already committed exact retry returns the stored +receipt without new evaluation, effect or consumption; an unresolved attempt +blocks reapplication. After conclusive rollback, an eligible retry repeats all +current checks and creates fresh attempt-bound preparation and prospective +evidence. It may reuse the original act only while its challenge/generation +and session remain eligible (or the direct-human session where applicable). +An invalidated challenge cannot be rescued by exact retry. Admission, lookup, +invalidation and persistence remain consumer-owned, not provider operations. + Every prepared decision binds the current transaction attempt and full intent. Compute decisionValidUntil as the canonical minimum of the trusted transaction deadline, session/principal, applicable source/representation, policy/snapshot, resource/evidence/sovereignty and approval cutoffs. Ends are exclusive. Required missing/unparseable ends or a minimum not later than the -evaluation time produce no consumable decision. A later retry needs a fresh -evaluation; retrieval of old evidence is not another use of old authority. +evaluation time produce no consumable decision. A newly admitted attempt needs +a fresh evaluation; returning an existing committed receipt is not another use +of old authority and does not require another evaluation. The provider describes every authority fact and absence/set predicate that must remain valid. The transaction owner must protect and recheck that @@ -638,11 +744,12 @@ created through production composition, not an HTTP route opened by this PR. | AUTH-011: current attempt and exclusive validity only | Bound input/lifetime and cutoff computation | Reach a cutoff exactly, extend a caller deadline, change intent or move evidence to another/closed UnitOfWork; no consumable handoff. | | AUTH-012: prepared is not durable; no effect/commit authority | Provider result envelope and composition | Inject read/hash failure or roll back the enclosing UnitOfWork; no durable receipt, evidence-commit claim, domain write or consumption is produced by the provider. | | AUTH-013: complete guard obligations cannot be omitted | Read-footprint output and consumer contract | Drop a negative/set-valued obligation or alter a captured revision; the handoff fails its exact contract. Commit-race enforcement remains consumer-owned and cannot be claimed from this test alone. | -| AUTH-014: production is legacy-free and commands remain closed | Application/UoW composition and architecture checker | Exercise real composition and all governed route closures; a legacy import, public authority dependency/SQL escape, or newly enabled command fails verification. | -| AUTH-015: fresh-approval preparation is non-authoritative | Same provider's bound preparation operation and shared policy/path/cutoff implementation | With valid post-act inputs, obtain exact candidate requester/approver bases and expiry values, but no decision result/trace/bundle, consumption, effect or durable claim. Fail a global/path condition or omit a cutoff: no successful preparation. Passing preparation as a decision or requesting an approval-skip flag cannot authorize anything. | -| AUTH-016: prospective finalization evidence has an explicit, restricted input role | Same provider's final-evaluation input and evidence verifier | A correctly bound, hashed prospective approval not yet stored in the database reaches full final evaluation and can produce prepared ALLOW when every check passes, without a durable claim. Wrong bytes/digest, act, snapshot, intent or approver binding cannot support ALLOW. A prospective grant or caller assertion of persistence cannot replace governed prerequisite proof. | +| AUTH-014: production is legacy-free and commands remain closed | Application/UoW composition and architecture checker | Exercise real composition and all governed route closures; a legacy import, unreviewed facade shape/dependency, raw-handle/SQL escape or newly enabled command fails verification. Verify the exact reviewed facade and module/group budgets without weakening tenant containment. | +| AUTH-015: fresh-approval preparation is non-authoritative | Same provider's bound preparation operation and shared rule/extraction/projection/path/cutoff implementation | With valid post-act inputs, obtain the complete bound view, projection/digest, candidate bases and expiry values, but no decision result/trace/bundle, consumption, effect or durable claim. Fail a global/path condition or omit a cutoff: no successful preparation. Passing preparation as a decision or requesting an approval-skip flag cannot authorize anything. | +| AUTH-016: prospective finalization evidence has an explicit, restricted input role and complete verified bindings | Same provider's preparation output, final-evaluation input and evidence verifier | Build the full canonical approval solely from provider-derived authority fields and exact owner-supplied act/display/transaction prerequisites; schema-check and hash it without a second extractor/projection/path/cutoff engine. The valid uncommitted candidate can produce prepared ALLOW when every check passes, with no durable claim. Wrong target/input/subject, representation, bytes/digest, act, snapshot, intent or approver cannot support ALLOW. Unavailable/changed display bytes, renderer/version/digest, display policy, locale/timezone or retention binding fail preparation/final validity. A trusted act at an exclusive cutoff fails; a client timestamp cannot repair it. A same-person independently eligible challenged act succeeds under SAME_PRINCIPAL_ALLOWED; omitting separation proof or activating the reserved DISTINCT_APPROVER_REQUIRED posture fails. A prospective grant cannot replace governed prerequisite proof. | | AUTH-017: candidate and final requester basis/window must match exactly | Shared canonical selection/cutoff logic and final equality checks | Substitute a different otherwise-eligible requester basis, or shorten/extend the prospective decisionValidUntil even within the transaction deadline. Final evaluation cannot force selection, rewrite the candidate or accept a different returned window; no ALLOW based on that candidate or successful finalization handoff. | -| AUTH-018: preparation and prospective evidence are attempt- and mode-bound | Bound provider lifetime, trusted mode and candidate admission | Reuse the same intent/preparation/approval in another attempt or after rollback, even before expiry; reject reuse as authority. Substitute NOT_REQUIRED or DIRECT_HUMAN_ACTION_REQUIRED, or supply a synthetic challenge/separate approver to direct-human mode; no bypass. | +| AUTH-018: preparation and prospective evidence are attempt- and mode-bound, without prohibiting canonical exact retries | Bound provider lifetime, trusted mode and candidate admission; consumer owns retry/receipt handling | Reuse an old preparation or prospective candidate in another attempt or after rollback, even before expiry: reject it as authority. In an admitted exact-retry fixture, keep the same original intent and humanActSubmissionId/act bytes but use a fresh attempt, current preparation and candidate; allow completion when every check still passes. Changed bytes under the same act ID cannot pass admission. Substitute NOT_REQUIRED or DIRECT_HUMAN_ACTION_REQUIRED, or supply a synthetic challenge/separate approver to direct-human mode: no bypass. Direct-human act time must meet its trusted session/transaction cutoffs. Consumer integration must separately prove that a committed exact retry returns its stored receipt with no provider call or second consumption. | +| AUTH-019: provider-owned challenge/final relevant-state equality | Same provider's typed read footprint, rule-selected projection/JCS digest, preparation refusal and final recheck | Change a rule-relevant target revision or representation fact between challenge and act while keeping an otherwise sufficient requester basis/window: no successful preparation or ALLOW from that act. Advance unrelated history outside the projection, changing only the full snapshot ref: preparation/final ALLOW remain possible if all other checks and guards pass. Verify exact provider-produced projection/digest; forged consumer digests or an equality flag cannot bypass recomputation. Relevant drift between preparation and final evaluation also fails. Preparation emits no decision; any canonical REQUIRE_HUMAN_APPROVAL refusal keeps HUMAN_FINAL_ACTION_REQUIRED primary and APPROVAL_CHALLENGE_STALE diagnostic. Consumer integration separately proves durable generation invalidation and a new challenge/act before retry after drift. | Test setup uses fictional data and the existing separately owned provisioning path. No production bootstrap or grant mutation is added to make fixtures @@ -650,13 +757,17 @@ work. Relevant cases require real PostgreSQL tenant binding, two-tenant isolation, exact currentness inputs and recorded read provenance; a pure function fed caller-authored grant dictionaries is insufficient. -AUTH-015–018 exercise preparation and final evaluation through the same +AUTH-015–019 exercise preparation and final evaluation through the same production-bound provider and guarded attempt fixture. The fixture supplies the transaction owner's trusted inputs and constructs prospective evidence -from the provider's output; it must not implement its own path-selection or -cutoff algorithm. Assertions inspect both returned types/bytes and the absence -of provider-owned writes. The valid prospective-approval case proves the -handshake is usable, not merely that every attempt can be refused. +from the complete provider-derived view and owner-supplied prerequisites; it +must not implement its own extraction, relevant-state projection, path-selection +or cutoff algorithm. Inspect the schema-complete candidate and its derived +target/inputs/subject/representation bindings, not only a mocked approval ID. +Assertions inspect returned types/bytes and the absence of provider-owned +writes. The valid prospective-approval, unchanged-projection and admitted-retry +cases prove usability, not merely that every attempt can be refused. Fixture +admission does not prove the consumer's durable retry/invalidation protocol. The exact source schemas and trusted input/read interface must exist before these proposed cases can count as implemented evidence. Consumer race tests @@ -703,6 +814,27 @@ demonstrates a broader defect. The earlier nine findings are not reopened. The scope, canonical-readiness and concrete-interface gates remain open; this correction does not claim a new zero-Blocker review or implementation approval. +### Revision 3 review: bounded B1 and related corrections + +The [revision 3 review](https://github.com/samovers/OFARM2/pull/359#issuecomment-5560915672) +at `4f863fa98c4407d95b06642aaf9e8487088e9d7b` found one Blocker and four +related “Should fix” items, plus a state-sequence Preference. This revision +preserves the earlier handshake and addresses that focused review: + +| Finding | Revision 4 correction | Required verification/gate | +|---|---|---| +| B1: challenge/final relevant-state comparison has no owner, output or invariant | Sections 4, 6 and 7 assign execution/recomputation to the provider, include its full projection/digest output and require typed stale-challenge refusal; unrelated history alone does not invalidate. | AUTH-019 and G3; no decision from preparation or invented primary reason. | +| S1: approval construction lacks provider-derived fields | Section 6 supplies the complete bound authorization view, including target, typed inputs, effect subject and representation, without a second consumer extractor. | AUTH-016 constructs a complete valid candidate solely from the provider view and exact owner-supplied prerequisites. | +| S2: separation, display and timely-act revalidation under-specified | Sections 6–7 name exact display/renderer/policy/locale/timezone/retention proof, trusted humanActedAt and current SAME_PRINCIPAL_ALLOWED posture; DISTINCT_APPROVER_REQUIRED remains reserved. | AUTH-016/018/019 and G3; no ceremony or retention/custody implementation. | +| S3: facade extension incorrectly called mechanical | Sections 4 and 12 name the exact current architecture shape and module/group budget constraints, and require a reviewed concrete extension and size outcome. | G3 and AUTH-014; no checker or automatic budget change in this revision. | +| S4: exact act retry confused with candidate portability | Section 8 and AUTH-018 distinguish admissible original-act reuse from forbidden old preparation/candidate reuse; committed retries return the existing receipt. | Provider fixture plus separately owned consumer retry/receipt tests. | +| Preference: final evaluation appears before EVALUATED | Section 8 replaces the ordinary evaluation step with the fresh-approval handshake. | One final decision-producing operation, with no extra evaluation step. | + +These are proposed design corrections, not reviewer sign-off. Re-review is +limited to this fix and affected invariants unless new evidence demonstrates +a broader defect. The old nine findings stay closed to reopening without such +evidence; G1–G4 remain open and no implementation approval is claimed. + ## 12. Expected implementation areas and code excellence Only this existing RFC changes in the current design revision. It remains @@ -715,8 +847,9 @@ Expected later areas, not a path allowlist: bound input/output and selected-proof values; - a narrow production tenant authority-read adapter, plus the necessary typed hook in `kernel/tenant_uow.py`; -- mechanical composition in `kernel/application_runtime.py`, and exact - architecture registration without weakening its legacy/SQL firewall; +- production composition in `kernel/application_runtime.py`, and a reviewed + exact facade/architecture-contract extension without weakening its + legacy/SQL firewall; - focused evaluator, PostgreSQL, composition, route-closure and UoW tests; - Kernel navigation, this RFC, and mechanical test inventory changes. @@ -725,11 +858,58 @@ command writer, runtime selector adaptation, principal/authentication edit, audit-custody change or profile activation is included. Discovery of a file inside the approved boundary can travel; discovery of a new authority cannot. +### Facade shape and size are a concrete-interface gate + +At the inspected base and reviewed revision 3, the architecture checker pins +the TenantUnitOfWork shape exactly, not merely by convention: + +```text +public surface = {binding, batch, begin_batch, + resolve_commit_operation_claim_draft_runtime_bundle} +constructor = (self, binding, allocate_batch, resolve_bundle) +slots = {__binding, __active, __allocate_batch, __batch, __resolve_bundle, + __selector_state, __selected_bundle, __rollback_only} +``` + +`_TENANT_UOW_PUBLIC_SURFACE`, `_TENANT_UOW_INIT_PARAMETERS` and +`_TENANT_UOW_SLOTS` in `conformance/rewrite_architecture_check.py` enforce +those values. Any additional method, dependency or slot needs explicit review +of the new accepted shape. The existing `_LEGACY_TENANT_UOW_SHAPE` and +`_TENANT_UOW_SHAPE` show a reviewed extension is possible; they do not approve +this extension. Even private raw connection/cursor/pool handles are prohibited. + +The same checker's physical-line counts and budgets are: + +| File/group | Current / limit | Remaining lines | +|---|---:|---:| +| `kernel/tenant_uow.py` | 520 / 520 | 0 | +| `kernel/tenant_command_runtime_bundle_selector.py` | 412 / 420 | 8 | +| tenant transaction group (the two files above) | 932 / 940 | 8 | +| `kernel/application_runtime.py` | 221 / 230 | 9 | +| application runtime group (runtime_config + application_runtime + deployment_identity) | 179 + 221 + 20 = 420 / 500 | 80 | + +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. Moving work to another +module does not alone solve the facade's exact shape or its zero headroom. + +Before Phase B, G3 must settle the exact typed provider entry, injected +dependency, constructor/slot/public-surface delta, lifecycle and permitted +import/query edges. The implementation plan must show the module/group size +outcome: either a reviewed simplification within this same boundary that fits +the existing budgets, or a specifically justified and reviewed budget change. +No automatic budget increase, generic facade escape or weakened raw-handle, +SQL, legacy-import or tenant-containment check is approved. A new module is not +automatically budgeted: MODULE_BUDGETS applies only to listed keys, so the plan +must explicitly settle its coverage and size bound and register focused test +coverage (the default covered test-module limit is 800 lines). Re-measure at +the implementation base. This design revision edits no checker or runtime. + | Code-excellence invariant | Planned assessment | |---|---| -| EXC-001 — one authoritative path | One canonical semantic source and one production authorization implementation shared by non-decision preparation and final evaluation; the transaction owner constructs evidence from those values, not a second path-selection/cutoff engine. | +| EXC-001 — one authoritative path | One canonical semantic source and one production authorization implementation shared by non-decision preparation and final evaluation; the transaction owner constructs evidence from those values, not a second extractor, relevant-state projection/comparison, path-selection or cutoff engine. | | EXC-002 — no avoidable duplication | No handwritten second matrix, compatibility authority API, extra durable decision store, retry ledger, or copied schema inventory. | -| EXC-003 — direct invariant trace | AUTH-001–018 map the typed entry, bound reader, preparation/final-evaluation handshake and evidence constructor to focused tests. Missing real reachability blocks completion. | +| EXC-003 — direct invariant trace | AUTH-001–019 map the typed entry, bound reader, preparation/final-evaluation handshake, relevant-state comparison and evidence constructor to focused tests. Missing real reachability blocks completion. | | EXC-004 — delete superseded owned paths | Withdraw the old plan; introduce no legacy compatibility path. The quarantined legacy system is not an owned production path and is not deleted as an unrelated migration. | | EXC-005 — abstractions pay rent now | Bound input/output prevent mixed tenant/rule/attempt facts; distinct preparation, prospective-evidence and prepared-decision values prevent authority/persistence confusion in the required fresh-approval handshake. A narrow reader contains existing connection authority. No generic policy engine, plugin registry, public SQL facade or future dispatcher. | | EXC-006 — simpler credible alternative | Adding a table to kernel.authority fails production isolation and canonical ownership. A pure helper alone fails the bound production-read outcome. A new transaction owner is unnecessary and crosses into #178. The proposed provider plus typed reader is the smallest plausible slice, subject to gate G3. | @@ -746,7 +926,7 @@ path is authorized. |---|---| | G1 — Delivery scope | Steward explicitly accepts the issue amendments in section 2, including prepared-versus-durable evidence and production-only callers; full evaluation coverage remains explicit. | | G2 — Canonical readiness | Complete the governing staged sequence and replace missing entries in section 5 with reviewed exact promoted/extracted bytes and provenance. Semantic approval alone is insufficient. | -| G3 — Concrete trusted interface | Close the production principal/representation/CP3 input mapping, policy selection compatibility, coherent typed read/snapshot plan, deadline source and complete guard handoff. Include the sections 6–8 fresh-approval handshake: non-decision preparation, distinct prospective uncommitted evidence, exact candidate/final requester-basis and validity equality, and cross-attempt/mode refusal, verified by AUTH-015–018 through the same provider. Demonstrate independently useful production-provider completion without inventing another authority owner. Split any demonstrated new boundary before editing it. | +| G3 — Concrete trusted interface | Close the production principal/representation/CP3 input mapping, policy selection compatibility, coherent typed read/snapshot plan, deadline source and complete guard handoff. Settle section 12's exact facade dependency/constructor/slots/public surface, architecture proof and module/group budget outcome before Phase B. Include the sections 6–8 handshake: provider-owned current relevant-state projection/digest and challenge comparison; complete bound authorization view; display/separation/trusted-act revalidation; distinct prospective uncommitted evidence; exact candidate/final basis/window equality; and nonportable preparation/candidates without prohibiting admitted exact act retries. Verify AUTH-015–019 through the same provider, including relevant-change refusal and unrelated-history success. Demonstrate independently useful production-provider completion without inventing another authority owner. Split any demonstrated new boundary before editing it. | | G4 — Fresh OFARM2 approval | Review this corrected Phase A to zero Blockers, then present a complete decision card naming existing PR #359 and obtain the required exact later task-user approval. No such card is issued by this revision. | Evidence requiring redesign: a machine binding contradicts the approved @@ -795,6 +975,7 @@ transaction coordination, protected effects, selection authority and temporal persistence with their own owners. No cross-boundary implementation is hidden in this plan. -What is next: re-review the revision 2 B1 correction and affected invariants; +What is next: re-review the revision 3 B1 and related corrections at the new +head, limited to the fix and affected invariants; resolve the still-open scope, canonical-readiness and concrete-interface gates before a fresh #359 decision approval and runtime edits. From 725df163ddcd4f93b4675a3041724b1f59ab8151 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Samo=20A=C4=8Dko?= Date: Mon, 7 Sep 2026 16:22:04 +0200 Subject: [PATCH 5/8] Clarify authorization reader failure dispositions 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. --- ...ority_Action_Matrix_Evaluation_RFC_v0_1.md | 79 ++++++++++++++----- 1 file changed, 59 insertions(+), 20 deletions(-) diff --git a/docs/rfcs/OFARM_Runtime_Authority_Action_Matrix_Evaluation_RFC_v0_1.md b/docs/rfcs/OFARM_Runtime_Authority_Action_Matrix_Evaluation_RFC_v0_1.md index 0f4876f1..2f0b422e 100644 --- a/docs/rfcs/OFARM_Runtime_Authority_Action_Matrix_Evaluation_RFC_v0_1.md +++ b/docs/rfcs/OFARM_Runtime_Authority_Action_Matrix_Evaluation_RFC_v0_1.md @@ -2,16 +2,17 @@ Date: 2026-09-07 -Design revision: 5. This develops G3's production interface, trusted-source -mapping, tenant read plan and transaction handoff. It preserves the revision 4 -handshake reviewed at `263cd32722ff2b482910bd7bb880f91aa8391838` and records -the subsequently applied issue-scope amendment. It does not claim that the -missing source factories, machine contracts or commit guards now exist. +Design revision: 6. This addresses the non-blocking reader-failure +clarification in the focused revision 5 review at +`87584f2e368fc791f0c12e4288885dc5425ea287`. The proposed interface, trusted-source +map and transaction handoff remain intact, including the earlier reviewed +approval handshake. Missing source factories, machine contracts and commit +guards remain prerequisites, not newly supplied infrastructure. The unapproved legacy proposal at `178f150ce56f1bdad96330ba845d210ee0911f2a` remains superseded. No accepted OFARM law changes. -Status: revision 5 design review pending; G1 scope amendment applied; +Status: revision 6 clarification review pending; G1 scope amendment applied; G2 canonical readiness and G3 implementation prerequisites remain open. No OFARM2 semantic approval, runtime implementation, baseline admission, merge, current/default promotion, or deployment is authorized. @@ -399,10 +400,35 @@ simple plan avoids depending on an unproven authority search index: prospective finalization input only in its admitted role. An MVCC label, maximum knowledge position or immutable row alone is not the governed `authorityEvaluationSnapshotRef` required by PR #11 section 16.1. -7. Return immutable verified facts, their canonical snapshot binding and the - complete local read footprint. Missing canonical snapshot/visibility proof - returns no successful capture, even when the SQL rows are internally - consistent. No standalone canonical snapshot record family is invented. +7. Return an immutable observation containing proved facts, explicit missing + or invalid proof with its affected roles, and the actual read footprint. + Assert snapshot availability, visibility and complete sets only where + proven. Missing canonical proof is not a successful complete snapshot, + even when SQL rows are internally consistent; preserve the failure facts + for canonical evaluation rather than inventing snapshot evidence or a + standalone canonical snapshot record family. + +The reader distinguishes an observation from an operational failure; it does +not reduce every missing proof to a database error. The evaluator owns the +disposition under pinned PR #11 section 15: + +| Observed situation | Reader-to-evaluator mapping | +|---|---| +| Global prerequisites pass and a completeness-proven observation contains no applicable path, including all candidates being inapplicable | Produce canonical `DENY` / `NO_AUTHORITY_BASIS`, with no selected path; not an infrastructure refusal. | +| An authorization-global prerequisite, such as authority-snapshot availability, is unproven | Preserve every independently established failure; apply canonical global DENY-before-REQUIRE_REVIEW ordering and mark dependent checks `NOT_EVALUATED`. Do not infer target or tenant failure from a prerequisite that was never proved. | +| One path is revoked, unsupported or otherwise fails while another is independently sufficient | Preserve the exact per-path dispositions and aggregate canonically. A path-local failure cannot become a whole-read infrastructure refusal or override another sufficient path. | +| The database or adapter actually fails to perform the observation | Preserve infrastructure failure and the existing rollback-only/discard discipline. Do not fabricate a canonical decision or durable result. | + +An empty result without completeness proof, or an incomplete/overflowed read, +is not proof that no authority exists. +Likewise, malformed source evidence is not automatically a failed adapter: +report the affected fact/role and let its exact canonical binding determine +whether the failure is global or path-local. Ingress failures remain outside +this lattice as section 7 specifies. Any prepared non-ALLOW decision must +still meet its admitted failure-evidence contract truthfully; missing evidence +cannot be repaired with a placeholder snapshot. G3-READ must settle that exact +failure encoding when G2 supplies the machine bindings. These distinctions +add no reason code, schema, outcome or alternative authorization engine. The statement must have deterministic ordering and server-side row/byte/work bounds with explicit overflow detection. Overflow refuses the whole capture; @@ -950,6 +976,13 @@ claims of executed tests: row/byte over the bound. Exact-bound complete data remains usable; overflow yields no partial complete-set claim. Demonstrate usable representative tenant sizes, not just refusal of every realistic capture. +- AUTH-007/009/010: contrast a complete no-path observation (`DENY` / + `NO_AUTHORITY_BASIS`) with an incomplete read, a missing global snapshot + prerequisite (canonical global ordering and dependent `NOT_EVALUATED`), + and a revoked/unsupported path alongside a sufficient path (canonical + aggregation). A real adapter/database fault follows infrastructure handling. + Inspect truthful failure evidence without inventing a snapshot, suppressing + path diagnostics or treating every failed authority proof as an exception. - AUTH-011/012/014: retain both bound methods after closure and call them in a rollback-only UoW; no reader runs. Inject a database failure and verify the existing rollback/discard path, including a consumer that catches the error; @@ -1035,11 +1068,17 @@ three read/guard obligation forms and focused verification. It identifies missing producers instead of creating them in this boundary. It also records G1's applied issue amendment and the later canonical planning sources. -Review the new interface/source/read/handoff proposal and affected -AUTH-002/003/007/009–019 and EXC invariants. Do not reopen the earlier nine -findings or the settled revision 4 handshake without new evidence of a -defect. G2/G3 remain open; the new head starts REVIEW_PENDING and carries no -new zero-Blocker sign-off or implementation approval. +The [focused revision 5 review](https://github.com/samovers/OFARM2/pull/359#pullrequestreview-5132918721) +at `87584f2e368fc791f0c12e4288885dc5425ea287` reported zero blocking findings +and one non-blocking S1 clarification: make the reader-to-evaluator failure +mapping explicit. It preserved the interface direction and prior handshake, +and did not close G2/G3 or approve implementation. + +Revision 6 addresses S1 in the reader plan and AUTH-007/009/010 cases above. +Review only that clarification and its affected invariants; do not reopen the +earlier findings or architecture without new evidence of a defect. The +revision 5 zero-Blocker disposition remains historical, not review of this new +head. No new source producer, guard, runtime behavior or canonical law is added. ## 12. Expected implementation areas and code excellence @@ -1181,7 +1220,7 @@ The remaining G3 work is bounded, not a request to restart canonical design: | Item | Required closure evidence | Boundary and sequencing | |---|---|---| | G3-INPUT | Exact mappings and real producers for principal/representation/CP3, session/act, attempt/deadline and compatible selection; reject forged/mixed frames through production composition | Consume existing accepted producers where sufficient. Any new authentication/session, selection or transaction authority needs separately scoped work and user direction before edits; do not mint proof in this provider. | -| G3-READ | Exact admitted schema/hash/extractor mapping, coherent SQL, source visibility/currentness and canonical snapshot proof, bounded representative workload, same final-snapshot/protection context for the handshake | Reader/projection implementation belongs here after G2. Missing storage, permission, snapshot authority or transaction protection belongs to its owner, not a database change hidden in the reader. | +| G3-READ | Exact admitted schema/hash/extractor mapping, coherent SQL, source visibility/currentness and canonical snapshot proof, truthful global/path/infrastructure failure encoding, bounded representative workload, same final-snapshot/protection context for the handshake | Reader/projection implementation belongs here after G2. Missing storage, permission, snapshot authority or transaction protection belongs to its owner, not a database change hidden in the reader. | | G3-HANDOFF | Actual typed transaction interface covering every record/set/absence/external/time obligation and attempt-bound prepared evidence, with an independently usable provider completion test | Settle the interface with #178's design before approving provider code. Durable command coordination, guards and consumer race/recovery tests remain #178/applicable consumer work. Their later delivery cannot excuse a provider that only accepts invented fixtures. | | G3-SHAPE | Review the exact facade proposal and architecture edges in section 12, then a measured final partition/size and focused production-path test plan against the admitted bindings | One authorization boundary. Existing zero headroom is explicit; no automatic checker relaxation or budget increase. | @@ -1208,8 +1247,8 @@ disaster/store-loss recovery. The old command successor is a compatibility gate for its consumer, not a reason to amend approved canonical PR #26. No new Delivery issue is created in this revision. -Review disposition: revision 5 is REVIEW_PENDING. G1 is applied; G2/G3 and the -later G4 card/approval remain outstanding. The revision 4 review stays attached +Review disposition: revision 6 is REVIEW_PENDING. G1 is applied; G2/G3 and the +later G4 card/approval remain outstanding. The revision 5 review stays attached to its exact historical head and is not transferred to this revision. Exact private names and test-file partitioning are Preferences only after the substantive interface is settled. @@ -1241,8 +1280,8 @@ transaction coordination, protected effects, selection authority and temporal persistence with their own owners. No cross-boundary implementation is hidden in this plan. -What is next: review revision 5's concrete interface/source/read/handoff -proposal and affected invariants at its new head; close the listed G2/G3 +What is next: review revision 6's bounded reader-failure clarification and +affected AUTH-007/009/010 invariants at its new head; close the listed G2/G3 prerequisites with their existing owners before presenting the fresh #359 decision card. No runtime edits, new Delivery issue, baseline or merge are authorized by this design revision. From feffb585ec569c6aaa8b5d085e94583d1eb9aeca Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Samo=20A=C4=8Dko?= Date: Fri, 11 Sep 2026 14:42:08 +0200 Subject: [PATCH 6/8] Align authorization design with initial claim and read scope 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. --- ...ority_Action_Matrix_Evaluation_RFC_v0_1.md | 793 +++++++++--------- 1 file changed, 380 insertions(+), 413 deletions(-) diff --git a/docs/rfcs/OFARM_Runtime_Authority_Action_Matrix_Evaluation_RFC_v0_1.md b/docs/rfcs/OFARM_Runtime_Authority_Action_Matrix_Evaluation_RFC_v0_1.md index 2f0b422e..6c02a3f1 100644 --- a/docs/rfcs/OFARM_Runtime_Authority_Action_Matrix_Evaluation_RFC_v0_1.md +++ b/docs/rfcs/OFARM_Runtime_Authority_Action_Matrix_Evaluation_RFC_v0_1.md @@ -1,19 +1,27 @@ # OFARM Production Authorization Provider — Phase A RFC v0.1 -Date: 2026-09-07 - -Design revision: 6. This addresses the non-blocking reader-failure -clarification in the focused revision 5 review at -`87584f2e368fc791f0c12e4288885dc5425ea287`. The proposed interface, trusted-source -map and transaction handoff remain intact, including the earlier reviewed -approval handshake. Missing source factories, machine contracts and commit -guards remain prerequisites, not newly supplied infrastructure. +Date: 2026-09-11 + +Design revision: 7 — first-release scope alignment. This consumes renewed +canonical Phase A approval at PR #11 head +`4494924998183fe3fa7bc1b63b76a85893335044` and the aligned #353 scope. It proposes +complete evaluation of ASSERT_OPERATION_CLAIM and RECEIVE_READ_DATA through +one evaluation-only facade. Neither selected rule is weakened. The other +eighteen action evaluations and human-finalization execution remain explicit +later work under #175, not passed or implemented. + +Revision 6 at `725df163ddcd4f93b4675a3041724b1f59ab8151` preserves the previous +full-programme design, human-approval handshake and reader-failure correction +as history. Their reviews do not transfer to this new scope/interface. +Missing source factories, machine contracts, read protocols and commit guards +remain prerequisites, not newly supplied infrastructure. The unapproved legacy proposal at `178f150ce56f1bdad96330ba845d210ee0911f2a` remains superseded. No accepted OFARM law changes. -Status: revision 6 clarification review pending; G1 scope amendment applied; -G2 canonical readiness and G3 implementation prerequisites remain open. +Status: revision 7 is REVIEW_PENDING; G1 first-release scope alignment applied; +G2 canonical readiness, including source-history closure, and G3 implementation +prerequisites remain open. The sufficiency of two executable actions is unproved. No OFARM2 semantic approval, runtime implementation, baseline admission, merge, current/default promotion, or deployment is authorized. @@ -34,23 +42,30 @@ the rule by choosing stage, actor posture, scope proof, or revocation inputs. This is a system-facing capability, not an endpoint activation. The first concrete consumer is the operation-claim path that motivated canonical OFARM #25 / PR #26: one pending-review AssertionRecord, with atomic evidence -and truthful retry handling. The delivery order remains authorization #353, -command idempotency/coordination #178, then a separately selected temporal +and truthful retry handling, plus currently authorized readback through its +separately owned read/disclosure protocol. The delivery order remains +authorization #353, command idempotency/coordination #178, then a separately selected temporal Delivery under #176. Interface design for those consumers must happen before this provider's implementation is approved; it does not authorize their code inside this PR. +That order names completed capabilities, not permission to postpone a real +write/read attempt producer until after its evaluator. G3 must settle both +consumer interfaces and their actual production ordering before implementation. +Ordinary saved-result retrieval or exact retry is not the independent +valid-time/knowledge-position capability required by the later #176 child. + Authorization is necessary but insufficient for a write. This provider does not validate the protected result, consume a decision, commit evidence, or promise a durable outcome. Issue #353 now explicitly distinguishes these owners, while retaining full admitted action/evaluation coverage. -## 2. Applied amendment to issue #353 +## 2. Applied amendments to issue #353 The task user directed applying the four-point scope amendment. The [issue amendment record](https://github.com/samovers/OFARM2/issues/353#issuecomment-5566519997) preserves the original issue text and that limited instruction. This is the -current work definition, not formal implementation approval: +retained ownership definition, not formal implementation approval: | Superseded requirement | Applied replacement and consequence | |---|---| @@ -59,18 +74,33 @@ current work definition, not formal implementation approval: | Provider delivers a durable decision trace | Provider delivers complete, schema-checked, digest-verifiable **prepared** evidence and explicit guard obligations. The consumer's transaction boundary owns persistence, complete-set atomicity, successful single use, and durable response. | | Existing SI decisions remain equivalent | No SI behavior change in this PR. New production decisions follow the separately promoted canonical version; no compatibility interpretation of v0.1 evidence as v0.2. | -Full action-rule coverage is **not** narrowed to one operation-claim row. The -provider must cover the entire admitted canonical action set and all its -specified evaluation branches. It must not report completion because one row -works or because an unsupported implementation returns non-ALLOW everywhere. -The currently approved canonical candidate has twenty rows; the eventual -machine artifact, not a second handwritten count/list, supplies the exact set. +The 2026-09-11 first-release alignment in [issue #353](https://github.com/samovers/OFARM2/issues/353) +consumes [renewed canonical scope approval](https://github.com/samovers/OFARM/pull/11#issuecomment-5634389303) +at `4494924998183fe3fa7bc1b63b76a85893335044`. Its previous body is preserved as +history. The full catalogue still has twenty unchanged rows; the proposed +initial executable package admits exactly ASSERT_OPERATION_CLAIM and +RECEIVE_READ_DATA. The eventual verified manifest, not a second handwritten +runtime matrix, supplies that set. The provider verifies exact admitted-set +and resolved-rule equality and covers every selected resource alternative +and authority path. A missing, duplicate, extra or invalid member cannot be +repaired by evaluating a working subset. + +A claim-only read evaluator, one successful row or blanket non-ALLOW is not +completion. The other eighteen evaluations and their applicable human-approval +flows remain open under #175. This scope does not remove sharing, delegation, +representation, CP3, revocation, evidence or disclosure obligations needed by +the two complete selected rules. Unknown/excluded actions stop before the +authorization outcome lattice; no caller-selected bundle, old schema or +full-policy fallback is permitted. Keep policy coverage, provider implementation coverage, and enabled public commands separate. No row becomes publicly executable merely because the -provider understands it. Applicable sharing and human-finalization checks are -part of evaluation coverage; creating sharing grants, running an approval -ceremony, disclosure, and protected effects remain separate capabilities. +provider understands it. Both selected rules retain NOT_REQUIRED. The first +facade has no preparation operation or prospective-human input; it does not +implement empty methods or synthetic approval evidence. Selected read sharing +and current source checks remain full evaluation requirements; creating grants, +running an approval ceremony, disclosure and protected effects remain separate +capabilities. Section 10 explicitly disposes every AUTH invariant. G1 is satisfied as an issue-scope editing step. The later complete #353 decision card must include this amended scope and receive its own exact @@ -80,6 +110,12 @@ with the complete admitted coverage. Any later request for provider-owned durability changes this boundary and requires re-planning, not a second transaction owner or quiet absorption of #178. +The full dependency closure is not yet established. In particular, canonical +PR #11 section 24.1 leaves open whether complete history classification and +historical-admission verification can work without executable qualifying-record +authoring. Scope approval neither answers that question nor admits an extra +action. No dependency or approval transfers automatically to another candidate. + ## 3. Current production facts that change the old design At the inspected base: @@ -135,10 +171,10 @@ command-execution capability travels with it. | Credential verification, identity binding, tenant capability, key custody | Existing authentication, principal, binder, and KMS boundaries; unchanged | | Party classification and authority/representation/CP3 proof evaluation | This provider applies the bound contracts to trusted identity and governed evidence; it cannot mint missing identity/actorship authority | | Policy/command selection and immutable runtime component identity | Existing separately reviewed selection/RuntimeBundle owners | -| Database session, transaction identity/finalization, isolation, complete commit guard and uncertainty reconciliation | Existing transaction owners and later #178 work; no new owner here | +| Database session, transaction identity/finalization, isolation, complete commit guard and uncertainty reconciliation | Existing transaction owners, later #178 write work and the separately owned governed-read protocol; no new owner here | | One current evaluation, selected sufficient path, complete prepared decision evidence and read obligations | This provider | -| Execute the rule-selected final authority-relevant projection, compute its JCS/SHA-256 digest, and compare it with the verified challenge digest | This provider, using its current typed authority snapshot; canonical OFARM owns the projection and JSON Pointer semantics | -| Capture the authenticated human act; render/retain its display; persist generation invalidation and issue a replacement challenge | Existing human-act, display/retention and transaction owners; the provider verifies their bound proof and reports invalidity, but does not perform these operations | +| Execute every projection/comparison required by the selected rules and complete evidence closure | This provider, using its current typed authority observation; canonical OFARM owns projection and JSON Pointer semantics. Human challenge/final equality execution is deferred, not a first-release API. | +| Human-act capture, display/retention, generation invalidation and challenge replacement | Separate human/transaction owners; their runtime workflows and the provider's corresponding future handshake remain deferred under #175, with revision 6 preserved as history. | | Protected-effect schema, mapping, gate PASS, assertion state and temporal mapping | Separately owned domain/temporal validators and command binding | | Durable request/result/trace, consumption, attempt/receipt, original-result recovery and safe response after commit | Command/evidence coordinator; #178 and the applicable consumer | | Requests, optional AI metadata, schema hints, candidate references | Caller-owned claims, never authoritative restrictions | @@ -179,8 +215,8 @@ that confers neither durable status nor independent effect authority. Permitted future effects, only after the gates in section 13: - construct one immutable verified rule view from the selected canonical bytes; -- evaluate actor, resource, scope, source, sharing, revocation, purpose, - evidence and finalization constraints through one deterministic path; +- evaluate all selected actor, resource, scope, source, sharing, revocation, + purpose, evidence and NOT_REQUIRED rule obligations through one deterministic path; - read through a typed facade on the existing bound connection, without exposing SQL or connection control; - prepare exact request/result/full-trace evidence and bindings for the owning @@ -193,6 +229,8 @@ Non-effects and non-goals: - no domain writes, durable authorization ledger, operation/idempotency table, decision consumption, receipt writer, commit/retry/reconciliation engine, or temporal query implementation; +- no first-release human-preparation API, prospective-human-finalization input, + approval ceremony, synthetic approval evidence or successful deferred stub; - no grant/delegation/sharing creation, narrowing, revocation, bootstrap or break-glass command; - no authentication/principal-binding semantics, CP3 schema or actorship @@ -217,14 +255,23 @@ size constraints; G3 requires a reviewed concrete extension before Phase B. The following are exact semantic planning sources, **not executable authority**: -| Candidate | Exact reviewed source head | Relevance | +| Candidate | Exact planning source head | Relevance | |---|---|---| -| [OFARM PR #11](https://github.com/samovers/OFARM/pull/11) | `03a21f669ee04f96d444e14f00ae7212cab04803` | Complete action rules, principal/CP3/finalization axes, paths, snapshot, v0.2 evidence and staged delivery | -| [OFARM PR #17](https://github.com/samovers/OFARM/pull/17) | `9ef08030b25eb3db1c2da14d6595300198384ff2` | Human final-review protected-effect planning source | -| [OFARM PR #20](https://github.com/samovers/OFARM/pull/20) | `98f8c4fafbae42c8f7fd931f43f53adcb4733713` | Human-finalization transaction protocol; excludes NOT_REQUIRED | +| [OFARM PR #11](https://github.com/samovers/OFARM/pull/11) | `4494924998183fe3fa7bc1b63b76a85893335044` | Approved complete catalogue and exact initial release-scope semantics, paths, snapshot/evidence, scoped staging and open history checkpoint | +| [OFARM PR #17](https://github.com/samovers/OFARM/pull/17) | `9ef08030b25eb3db1c2da14d6595300198384ff2` | Retained human final-review programme source; not a declared first-release effect | +| [OFARM PR #20](https://github.com/samovers/OFARM/pull/20) | `98f8c4fafbae42c8f7fd931f43f53adcb4733713` | Retained human-finalization programme source; excludes NOT_REQUIRED and does not supply the selected write/read protocols | | [OFARM PR #23](https://github.com/samovers/OFARM/pull/23) | `622376e2998cf8b3954ca19e81d2cce6fd57e5fe` | AssertionRecord submission protected-effect contract | | [OFARM PR #26](https://github.com/samovers/OFARM/pull/26) | `e042efa2911b2ef0a61603b8e0adaa6911c03ac0` | NOT_REQUIRED atomic protocol and first operation-claim handoff | | [OFARM PR #28](https://github.com/samovers/OFARM/pull/28) | `4e186aab5c238215906fcf9b24ce74443abb6f72` | Exact SharingGrant TERMINATE protected-effect planning source; not a revocation command in this PR | +| [OFARM PR #29](https://github.com/samovers/OFARM/pull/29) | `8e0994cae5610ac9c0d2652e02c8a8a2dd7b45c5` | Retention and honest retained-versus-digest-only proof; no custody implementation here | +| [OFARM PR #31](https://github.com/samovers/OFARM/pull/31) | `092be94f3a67497ba619295932cd0b2b1e9443f3` | Approved public-result design with CP2A-DEP01 still open; not a complete history producer | +| [OFARM PR #34](https://github.com/samovers/OFARM/pull/34) | `69682c2f918ef18756261a1186294cc3a5ebe44d` | Unapproved qualifying-record proposal with QG-DEP01; not an admitted source/writer or additional selected action | + +The [PR #11 approval](https://github.com/samovers/OFARM/pull/11#issuecomment-5634389303) +approves the release-scope model at that exact head. The previous approval at +`03a21f669ee04f96d444e14f00ae7212cab04803` remains history; this revision's +planning pin is intentionally updated, without approving any dependent candidate +or changing the complete per-rule digest/source-consent law. The [PR #26 approval](https://github.com/samovers/OFARM/pull/26#issuecomment-5560085396) closes that candidate's Phase A semantic review. It does not merge its bytes, @@ -243,9 +290,10 @@ and manifest entries for every required component: | AuthorizationPolicyBundle v0.2, resolved ActionAuthorizationRules, rule/extractor/intent schemas, relevant-state projection and immutable binding manifest | Proposed semantics; required executable bytes and extraction not ready | | AuthorityGrant, DelegationGrant, SharingGrant v0.2 | Proposed source semantics; required v0.2 packages/extraction not ready | | AuthorizationDecisionEvidence and AuthorizationFinalizationEvidence v0.2, including applicable rejection/snapshot/consumption evidence | Proposed semantics; required machine packages/extraction not ready | -| Applicable protected-effect contracts, AssertionRecord result binding and Event Grammar classifications | Approved candidates cover some families; all-row prerequisites remain open | -| Human and NOT_REQUIRED transaction profiles, deadline/guard mappings and result-complete lifecycle | Semantic candidates approved; executable profiles and production interfaces not yet proved | -| CP2 authorization result/reasons and applicable retention, sovereignty, evidence and CP3 bindings | Must be inventoried and proven at exact admitted versions; no blanket readiness claim | +| Selected protected-effect contracts, AssertionRecord result binding and Event Grammar classifications | Selected complete dependency closure still required; unselected effects may be deferred only with a reviewed closure disposition | +| NOT_REQUIRED write and separately owned governed-read transaction profiles, deadline/guard mappings and result-complete lifecycle | PR #26 is a write-only semantic candidate, not a governed-read protocol; executable profiles and real production interfaces remain unproved | +| CP2 result/reasons, retention, sovereignty, evidence and CP3 bindings | Exact selected bindings and current source checks remain required; approved designs are not promoted/extracted contracts | +| CP2A-DEP01 source-history classification, completeness and historical-admission proof | Open under #32 and its actual source dependencies; inactive writing, empty lookup or an individually valid qualifier is not complete history | Existing v0.1 schemas are not substitutes. A missing digest is recorded as missing, never filled with a placeholder that could become executable. @@ -256,7 +304,12 @@ source and bounded decision-evidence packages; exact binding review and accepted law; hostile conformance; explicit current/default promotion; byte-identical OFARM2 extraction; then OFARM2 runtime work. The older PR #359 comment's abbreviated order is not controlling. PR #26 did not complete all -of these steps. +of these steps. All stages apply to the complete selected dependency closure, +not the whole catalogue by default and not a sample of either selected rule. +No family-level currentness pointer may silently activate the other eighteen +actions or omitted profiles. If history closure requires another action, stop +for a separately reviewed scope amendment; neither a second policy nor a +permanently unavailable classifier is a workaround. ## 6. Proposed production interface and data ownership @@ -265,48 +318,44 @@ following is a concrete local interface proposal for review, not executable code or new canonical record schemas. Exact machine bindings and the named upstream factories remain G2/G3 dependencies. -### Closed entry points and trusted construction +### Closed evaluation entry and trusted construction -The public work surface gains exactly two synchronous methods: +The public work surface gains exactly one synchronous method: ```python -def prepare_authorization(self, call: AuthorizationCall) -> PreparationOutcome: - ... - -def evaluate_authorization( - self, - call: AuthorizationCall, - finalization: ProspectiveFinalization | None = None, -) -> EvaluationOutcome: +def evaluate_authorization(self, call: AuthorizationCall) -> EvaluationOutcome: ... ``` -They are reached through `ApplicationRuntime.tenant_unit_of_work`, its existing -security-audit wrapper, and the manager-created active `TenantUnitOfWork`. -The manager injects one private frozen pair of closed callables, -`_AuthorizationCalls`, bound to the authenticated principal, exact -TenantBinding and the same connection. The UoW exposes neither this pair nor -an independently usable provider handle. Both calls use the same evaluator -for policy, extraction, projection/comparison, paths and cutoffs. - -Each method checks active and not rollback-only before invoking its private -callable. `_finish` seals the new dependency as well as the existing ones. -Retaining a bound method cannot bypass those checks. Results contain immutable -data only, never callables, cursors or a connection. Unexpected database or -adapter failures mark the existing `__rollback_only` flag before re-raising -into the UoW rollback/discard path. Catching that error in consumer code cannot +It is reached through `ApplicationRuntime.tenant_unit_of_work`, its existing +security-audit wrapper and the manager-created active `TenantUnitOfWork`. +The manager injects one private closed typed evaluation callable, bound to the +authenticated principal, exact TenantBinding and same connection. The UoW +exposes neither that callable nor an independently usable provider handle. +One evaluator implements both selected rules' complete semantics. + +The method checks active and not rollback-only before invoking its private +callable. `_finish` seals that dependency with a closed sentinel as well as +the existing ones. Retaining a bound method cannot bypass those checks. +Results contain immutable data only, never callables, cursors or a connection. +Unexpected database/adapter failures mark the existing `__rollback_only` flag +before re-raising into the UoW rollback/discard path. Catching the error cannot make the UoW committable again. The provider cannot swallow a broken transaction -and report a durable refusal. -Ordinary typed preparation/ingress refusals and canonical non-ALLOW decisions -do not themselves assert rollback or durability. +and report a durable refusal. Ordinary typed ingress refusals and canonical +non-ALLOW decisions do not themselves assert rollback or durability. + +There is no `prepare_authorization` method, `ProspectiveFinalization` input or +`PreparationOutcome` in this first-release interface. Deferral removes proposed +unused surface; it does not replace it with empty methods or success stubs. +These methods do not exist in the inspected production code. `AuthorizationCall` has three closed roles, not a general proof dictionary: | Local member | Content and admission rule | |---|---| -| `attempt` | Owner-issued protected-effect attempt frame: exact operation/generation where applicable, attempt/transaction binding, fixed transaction deadline, trusted time/session/act and final-snapshot/guard inputs required by the selected protocol. It must match this bound UoW. | -| `selection` | Owner-issued exact command/action, policy/rule and binding-manifest selection. Verify its provenance, content and compatibility; a matching action string alone is insufficient. | -| `effect_intent` | Exact full intent bytes and their claimed identity/digest. The provider validates and derives its authorization view itself. Owner-completed fields must already be bound by the command protocol. | +| `attempt` | Owner-issued write or governed-read attempt frame: exact operation where applicable, protocol/attempt/transaction binding, fixed deadline and trusted time, required principal/session validity and snapshot/guard inputs. It must match this bound UoW and selected action; no human-act or approval role is admitted here. | +| `selection` | Owner-issued exact operation/action, policy/rule and binding-manifest selection. Verify its provenance, content and compatibility; a matching action string alone is insufficient. A write-command selection cannot substitute for a governed-read binding. | +| `effect_intent` | Exact full intent bytes and their claimed identity/digest. The provider validates and derives its authorization view itself. Owner-completed fields must already be bound by the admitted write or governed-read protocol. | These names describe local envelopes around admitted contracts; they do not duplicate the contracts' field inventories. Python type/frozen-object checks @@ -323,21 +372,22 @@ anchored governed Party; representation and CP3 need their own evidence. Authority subject is derived per candidate path, never selected globally before path resolution. Optional AI metadata remains authority-inert. -`ProspectiveFinalization` carries complete candidate bytes, immutable identity -and digest, plus their exact attempt and, for fresh approval, preparation -binding. It is the only prospective-proof role accepted by this API; it cannot -replace persisted authority sources. Supplying `None` never disables a rule's -human requirement. Whether an absent candidate permits a canonical -REQUIRE_HUMAN_APPROVAL decision or causes protocol refusal follows the admitted -rule/profile, not a caller-selected mode. Preparation is only for the post-act -fresh-approval handshake; direct-human and NOT_REQUIRED use final evaluation. - -`PreparationOutcome` is either the complete non-decision view described below -or a typed preparation refusal. `EvaluationOutcome` is either a truthful -ingress/infrastructure refusal or a complete prepared decision with immutable -read/guard obligations. These are disjoint types: no shared `allowed` flag, -fabricated canonical DENY on malformed ingress, or `committed` field. Neither -successful result is portable to another attempt or a closed UoW. +`EvaluationOutcome` is either a truthful ingress/infrastructure refusal or a +complete prepared decision with immutable read/guard obligations. The types +are disjoint: no shared `allowed` flag, fabricated canonical DENY on malformed +ingress or `committed` field. No successful result is portable to another +attempt or closed UoW. A complete prepared non-ALLOW still needs truthful +failure evidence under its exact admitted contract. + +The `attempt` role has two closed owner-supplied forms: a state-affecting +NOT_REQUIRED write attempt and a governed-buffered-read attempt. Each binds +its own admitted protocol, transaction identity, deadline and snapshot/protection +context. The provider verifies the form against the selected action and the +privately bound UoW. A write attempt cannot authorize a read or substitute for +its read-coverage/evidence protocol; a read attempt cannot authorize a write. +These are local envelope roles, not newly invented canonical schemas or +caller-selected approval modes. Exact machine fields and real factories +remain G2/G3 work. ### Trusted-source map and missing producers @@ -345,11 +395,11 @@ successful result is portable to another attempt or a closed UoW. |---|---|---| | Authenticated Party and tenant anchor | `AuthenticatedPrincipal` / `PrincipalAuthority`, checked against `TenantBinding` and exact Party record identity/digest | Map the admitted principal-resolution revision and its validity interval to canonical evidence; do not treat the anchor as complete representation/CP3 proof. | | Natural-person representation or software actorship | Read immutable governed evidence and apply the selected contracts; Party classification and sponsorship alone confer no representation/delegation | Inventory exact current representation/CP3 bindings and their provenance. PR #11 says the current CP3 envelope is semantically sufficient; this is not permission to change it. | -| Human session and exact act | The existing verifier establishes issuer/subject; owner-issued act proof must bind the authenticated session, act bytes and server-observed time | No complete session/act proof factory is present. Its owner must define the mapping and custody; this provider must not reparse an unverified JWT or copy verifier logic. | -| Transaction attempt, deadline, final snapshot and protection | Same bound connection supplies tenant/full-transaction identity; the protected-effect protocol owns admission and time/guard proof | Current UoW has no complete attempt/deadline/guard factory. Tenant challenge time, token lifetime, batch allocation and `bound_at` are not substitutes. #178 must resolve its transaction-side interface. | +| Required principal/session validity | Existing identity/principal bindings supply only their admitted facts; the provider applies every selected rule's required validity cutoff | Exact required mappings/producers remain open. The provider cannot reparse an unverified JWT, copy verifier logic or replace session validity with a token/challenge expiry. Human-act capture and interactive approval evidence are deferred, not substitutes for these current checks. | +| Write or read attempt, deadline, snapshot and protection | Same bound connection supplies tenant/full-transaction identity; each owning protocol supplies its admitted time/guard context | Current UoW has no complete write/read attempt/deadline/guard factories. Tenant challenge time, token lifetime, batch allocation and `bound_at` are not substitutes. Settle #178's write interface and the separately owned governed-read interface before their respective use. | | Command/action and authorization policy | Consume exact verified selections and content-addressed admitted bytes | Current fixed selector selects the incompatible old command in section 9, not a general v0.2 policy. Its owner must supply a compatible reviewed selection; this PR cannot reinterpret it. | | Canonical authority snapshot/currentness and source visibility | Provider verifies canonical proof against coherent tenant reads and exact source/batch provenance | G2 must supply exact bindings; G3 must identify how existing sources prove every required watermark/visibility fact. A SQL snapshot label does not fill this gap. | -| Challenge, display and act prerequisites | Read exact immutable references and verify owner-supplied retrievable display bytes and metadata | Human protocol/display/retention owners supply real proof and lifecycle eligibility. No ceremony, renderer, retention store or generation writer is added here. | +| Public result/read qualification and source history | Consume exact admitted evidence/history semantics where the selected closure requires them; the provider does not classify public history or release traces | CP2A-DEP01 and #32's completeness/historical-admission proof remain open; #34's proposed writer is not admitted by this plan. Required retention and disclosure bindings also remain real owner dependencies. | For time, follow PR #11 section 18.2 precisely: principal-resolution/session validity ends contribute where required; an explicitly unbounded governed @@ -396,8 +446,8 @@ simple plan avoids depending on an unproven authority search index: plus exact absence and complete-set claims, not just the winning path. 6. Verify every source's required snapshot visibility/currentness proof. READ COMMITTED sees this transaction's own writes too: a same-attempt row - cannot be labelled an already committed prerequisite. Use the separate - prospective finalization input only in its admitted role. An MVCC label, + cannot be labelled an already committed prerequisite. No prospective-human + input is accepted by this first facade. An MVCC label, maximum knowledge position or immutable row alone is not the governed `authorityEvaluationSnapshotRef` required by PR #11 section 16.1. 7. Return an immutable observation containing proved facts, explicit missing @@ -444,87 +494,28 @@ This is a concrete query shape and verification plan, not a claim of an implemented or measured reader. Sequential ordinary READ COMMITTED queries are not a substitute for one coherent observation. A coherent observation is not a commit guard: the transaction owner must protect the complete footprint. -For preparation/final evaluation, its interface must establish the same final -snapshot and protection context required by PR #20. Merely running the SELECT -twice cannot prove that continuity. Any loss of that proof prevents successful -finalization; any relevant drift follows section 7. The provider still owns -final projection recomputation, never a consumer-supplied equality assertion. - -### Preparation is distinct from a prepared decision - -For the post-act `FRESH_HUMAN_APPROVAL_REQUIRED` protocol, the same provider -offers a bounded non-authoritative preparation operation before the consumer -can construct prospective approval evidence. It requires the trusted -rule-selected mode, admitted operation/generation and exact authenticated -human act, challenge/display bindings, final snapshot and complete guards. -It is not challenge issuance or a token retained across human think time. - -Its immutable local preparation result supplies one bound authorization view -and all provider-derived bindings needed by the complete approval profile in -canonical PR #20 section 9.1 and PR #11 section 18.3: - -- tenant, operation/generation, attempt, action/finalization mode, exact human - act, effect-intent schema/ref/digest, extractor and policy/rule bindings; -- derived authority target, typed inputs, effect subject and extracted - scope/twin/time/purpose, with their exact resource revisions/proof bindings - and derived-view digest; -- requester and intended natural-person approver identities, represented Party - and immutable representation basis where applicable, canonical candidate - requester path/basis and independently eligible same-action approver path; -- the provider-computed final rule-selected relevant-state projection and - `authorityRelevantStateDigest`, verified challenge digest, and both complete - challenge/final snapshot refs and proof bindings; -- verified exact challenge/display/act and rule-selected separation bindings; - and -- complete cutoff inputs, `approvalExpiresAt` and candidate - `decisionValidUntil`, computed in section 7. - -This is a typed view of the exact canonical profile requirements, not a second -handwritten schema or permission to omit any canonical field. A successful -preparation proves the required digest equality; it never copies a consumer's -assertion that the two projections match. These values are evidence-construction -inputs, not an authorization outcome. Preparation emits no decision result, -decision trace, decision-bundle digest, consumption, effect, durable claim or -portable path outcome. Failure returns a typed preparation refusal, never a -successful candidate with missing proof or an invented authorization result. - -The consumer uses those provider-derived values to construct and hash the -complete mode-correct finalization-evidence candidate together with the exact -act/display/transaction prerequisites supplied by their owners. It does not -duplicate authorization-view extraction, relevant-state projection/comparison, -path selection or expiry calculation. The provider accepts that candidate -through a distinct prospective-evidence input bound to the same preparation -and attempt, not by pretending to load an already-persisted approval record. -The input carries the complete candidate bytes, deterministic identity and -digest, and their exact act, snapshot, intent, basis and cutoff bindings. - -Persisted prerequisites and prospective finalization evidence are different -typed inputs with different verification rules. Neither a caller label nor -schema validity establishes their provenance. The prospective input is usable -only in its rule-selected finalization-evidence role; it cannot stand in for a -missing persisted grant, role, CP3 record or snapshot. Prior committed evidence -is not portable approval for another attempt. The local type distinction adds -no field or contract to canonical records and claims no persistence. - -The final-evaluation operation returns a truthful ingress/infrastructure -refusal or, when canonical evaluation is possible, a prepared decision bundle -with its immutable basis and guard obligations. This is a different result -type from non-decision preparation. Both stay internal and non-durable; only -the final evaluation can construct the decision bundle. The consumer cannot -pass a preparation result as a decision or choose a generic “skip approval” -flag. Successful fresh-approval finalization requires the full handshake and -equality checks below, irrespective of which operation a caller invokes. - -`DIRECT_HUMAN_ACTION_REQUIRED` instead supplies its exact prospective -direct-principal act/representation evidence to final evaluation. It creates -no synthetic challenge, separate approver or fresh-approval preparation. -`NOT_REQUIRED` follows its own bound protocol without human-finalization -evidence. Only the trusted rule selects these modes; a request cannot switch -modes to bypass approval. - -Do not finalize an implementation card until this interface has a concrete -production-path test and an independently usable provider completion +For the selected write or read, the owning protocol must prove that the +authority observation and protected effect or buffered retrieval/coverage +share the required snapshot/protection context. Merely running the SELECT +twice cannot prove continuity. Loss of that proof prevents consumption or +disclosure. The provider reports its complete authority footprint; the read +consumer owns payload coverage, qualification, receipt/evidence persistence +and release, including the additional obligations introduced by its retrieval. + +### Deferred human-interface history + +Revision 6's [preparation/candidate design](https://github.com/samovers/OFARM2/blob/725df163ddcd4f93b4675a3041724b1f59ab8151/docs/rfcs/OFARM_Runtime_Authority_Action_Matrix_Evaluation_RFC_v0_1.md#6-proposed-production-interface-and-data-ownership) +and [fresh-approval equality protocol](https://github.com/samovers/OFARM2/blob/725df163ddcd4f93b4675a3041724b1f59ab8151/docs/rfcs/OFARM_Runtime_Authority_Action_Matrix_Evaluation_RFC_v0_1.md#fresh-approval-preparation-and-final-equality) +remain explicit future programme design, not implemented first-release APIs. +Their exact human-act/display, independent approver, prospective-evidence, +relevant-state and basis/window safeguards are not weakened or marked passed. +A later action/package expansion needs its own reviewed dependency closure, +facade design and approval; no generic hook activates those flows now. + +Do not finalize an implementation card until the selected interface has a +concrete production-path test plan and independently usable provider completion criterion. “A future #178 will make this work” cannot justify closing #353. +Both write and read owners must supply genuine admitted inputs first. ## 7. Evaluation contract @@ -535,10 +526,13 @@ not create a second action matrix. ### Ingress and policy Reject malformed bytes and duplicate JSON names; validate the base request; -resolve the action and complete immutable rule/manifest; validate its selected +verify the selected immutable package and exact admitted-set/resolved-rule +equality, require action membership and its complete rule; validate its selected effect-intent schema; then execute its exact authorization-view extraction. -A missing/invalid rule, incompatible schema hint, invalid intent or extraction -is ingress rejection, not fabricated DENY evidence. +A missing/duplicate/extra/invalid rule, excluded action, incompatible schema +hint, invalid intent or extraction is ingress rejection, not fabricated DENY +evidence. The runtime cannot repair an invalid package with a subset, fall back +to another bundle/old schema or admit a caller-selected policy. Validate the policy bundle and every required per-action semantic-closure binding. Code may implement algorithms, but may not author independent @@ -608,120 +602,28 @@ role-targeted, delegated, sharing path order and exact immutable source IDs. Use the selected path's outcome-specific reason ranking. Preserve all other evaluated paths as ordered diagnostics, not authority combined with that path. -Outstanding human approval can be reported only for an otherwise sufficient -path. A truthful non-ALLOW decision is not a substitute for the non-decision -post-act preparation below. Verify applicable persisted prerequisites and -prospective finalization evidence and cutoffs; this provider does not run the -human ceremony, reserve authority, or consume approval. - -### Fresh-approval preparation and final equality - -The interface follows [canonical PR #20 section 11 at its pinned head](https://github.com/samovers/OFARM/blob/98f8c4fafbae42c8f7fd931f43f53adcb4733713/package_meta/history/clean_baseline_migration/phase_reports/governed_human_approval_transaction_and_consumption_protocol_rfc_candidate_v0_1.md#11-required-post-act-revalidation) -and [PR #11 sections 16.1 and 18.3](https://github.com/samovers/OFARM/blob/03a21f669ee04f96d444e14f00ae7212cab04803/package_meta/history/clean_baseline_migration/phase_reports/authorization_constraints_and_decision_evidence_rfc_candidate_v0_2.md#161-authority-evaluation-snapshot). -With a verified rule and complete current authority facts, the provider -performs this post-act sequence under the same final snapshot and guards: - -1. Revalidate the exact authenticated act/session, requester and intended - natural-person approver, representation, immutable challenge and - rule-selected separation/eligibility bindings. Verify the acknowledged - display's exact retrievable bytes, ref/digest and media type, renderer - identifier/version/digest, display-policy ref/digest, locale, timezone and - evidence-retention policy binding. Unavailable or changed bytes, renderer - or display metadata cannot support successful preparation. Verify trusted - `humanActedAt` precedes the exclusive challenge and reservation cutoffs, - and check all applicable current session/transaction validity. Client time - cannot establish timeliness. This verifies owners' proof; it does not add - rendering, act capture, storage, retention policy or key-custody operations. -2. Compute the final authority-relevant projection from the provider's current - typed snapshot using the exact rule-owned projection/JSON Pointers, then - compute JCS/SHA-256 and compare with the verified immutable challenge - `authorityRelevantStateDigest`. Include every rule-selected authority-path - and separation fact through the shared rule/path implementation, not a - coordinator-supplied projection, digest or equality flag. Record the final - projection/digest and both full snapshot refs. This comparison must pass - before continuing to candidate requester/approver selection below. -3. Use the shared authorization implementation to evaluate every global and - per-path condition except the still-outstanding fresh-approval condition. - No authorization result or decision bundle is emitted. -4. Require global preconditions to pass and apply the canonical lattice and - path tuple to otherwise-sufficient requester paths. Determine the candidate - requester path and basis that would otherwise require fresh human approval. -5. Independently determine the canonical natural-person approver path that - satisfies every non-finalization condition for the same action, target, - typed inputs, effect subject, scope, twin, purpose, tenant/sovereignty, Party - posture and intent/derived-view digests. Enforce the exact - `approvalSeparationPolicy`; sponsor status alone remains insufficient. -6. Collect all rule-required cutoffs, including the trusted transaction and - session deadlines, candidate requester and applicable approver paths, - representation, sources, policy/snapshot, resources, evidence and - sovereignty inputs. A required missing cutoff fails preparation. -7. Compute `approvalExpiresAt` under the exact approval profile, then compute - candidate `decisionValidUntil` with the canonical minimum-cutoff function - using that requester path and `approvalExpiresAt`. - -A relevant-state digest mismatch returns a typed stale-challenge preparation -refusal: no successful preparation, prospective approval admission or ALLOW -from that act. This holds even if the requester basis and validity window -would otherwise remain sufficient. The transaction owner must invalidate the -act/generation through PR #20's failure protocol; only after the required -terminal record is durable may it issue an eligible replacement generation, -new challenge and new human act. The provider does not persist that transition. -Unrelated history outside the exact rule-owned projection does not invalidate -the challenge: full snapshot refs may differ while the relevant digests match, -provided every other final check, cutoff and commit guard passes. - -`APPROVAL_CHALLENGE_STALE` identifies the canonical lifecycle diagnostic, not a -new authorization outcome or a decision emitted by preparation. If complete -canonical evaluation produces refusal evidence for an otherwise sufficient -path lacking approval, `HUMAN_FINAL_ACTION_REQUIRED` remains the sole primary -reason for `REQUIRE_HUMAN_APPROVAL`; stale-challenge detail is diagnostic only. -Other independently established failures still follow canonical aggregation. - -Every current fresh-approval row selects `SAME_PRINCIPAL_ALLOWED`: the same -natural person may perform the challenged act if independently eligible under -the full lifecycle. `DISTINCT_APPROVER_REQUIRED` and its -`APPROVAL_SEPARATION_UNSATISFIED` diagnostic remain reserved; this plan neither -activates them nor requires an extra person for current rows. Direct-human -finalization instead verifies its exact direct-principal act and trusted -`humanActedAt` within the applicable session and final transaction cutoffs; -it gains no synthetic challenge, reservation or separate approver. - -The consumer binds the full preparation values into the prospective approval -profile before computing its identity and digest. The candidate is still -uncommitted and non-consumable. Raw human-act metadata or an approval ID alone -cannot replace the complete candidate. - -Final evaluation verifies the candidate's schema, identity/digest and exact -tenant, operation/generation, attempt, authenticated act, principal and -representation, challenge/display, policy/rule, intent, snapshot/relevant-state, -requester/approver basis and expiry bindings. The provider itself recomputes -the final rule-selected projection/digest from complete current facts and -requires equality with both the challenge and prepared/candidate values; -verifying consumer-recorded equality alone is insufficient. It revalidates -act timeliness, display and separation proof and performs the complete -canonical evaluation, including fresh-approval validity. Relevant drift -cannot be repaired by rehashing the candidate; it follows the stale-challenge -failure above. The candidate basis is a binding to verify, not a filter -that forces path selection or exempts any check. Invalid prospective evidence -cannot satisfy fresh approval or support ALLOW; it follows the canonical -refusal/failure protocol, not an ALLOW that the coordinator must overrule. - -Successful finalization requires the final selected requester path and basis -to be identical to the preparation and hashed candidate, and returned -`decisionValidUntil` to equal the prebound value exactly. No different basis, -shorter or longer validity window, missing cutoff, or other-attempt evidence -can satisfy this equality. Do not repair a mismatch by choosing another path, -rewriting/re-hashing the approval or silently adopting a new window. It fails -finalization: no successful finalization handoff, effect or consumption is -permitted, and the consumer discards the prospective evidence. Any truthful -failure evidence belongs to the canonical failure protocol; it cannot turn -that candidate into a committed approval or authority token. - -Preparation and final evaluation share one implementation for policy, -extraction, projection, paths and cutoffs. They differ in allowed outputs and -the explicit protocol point at which prospective approval can be checked. -No coordinator-owned policy engine or caller-selectable condition mask is -introduced. +The canonical outcome lattice is retained, but each reported disposition must +be justified by the complete selected rule and current facts. Both admitted +rules select NOT_REQUIRED. The implementation cannot invent a human-approval +requirement, select a deferred lifecycle or construct synthetic approval evidence +to cover missing source proof. Canonical missing-proof/global/path behavior +still applies; deferring human execution does not turn unknown facts into +authority. + +### Final validity for the selected scope + +The provider computes the canonical minimum cutoff from every required trusted +transaction, principal/session, representation/source, policy/snapshot, +resource/evidence and sovereignty validity end. Ends are exclusive. It does +not invent `approvalExpiresAt`, a challenge or a prospective human candidate +for a NOT_REQUIRED rule. Missing required time or source proof prevents a +consumable handoff under the owning contract. + +The full human-preparation, projection equality and candidate/final basis/window +protocol is retained at the revision 6 links in section 6 and the unchanged +canonical source. It is deferred, not a second path or current implementation +requirement for this first facade. Human-act-specific cases in section 10 are +explicitly not passed by selected-scope conformance. ### Final decision evidence @@ -736,49 +638,42 @@ reuse v0.1 evidence fields to simulate v0.2 meaning. The ordinary decision-evaluation sequence is: -`BOUND_INPUT -> INGRESS_VALID -> CURRENT_FACTS_PROVEN -> EVALUATED +`BOUND_INPUT -> INGRESS_VALID -> CURRENT_FACTS_OBSERVED -> EVALUATED -> PREPARED_EVIDENCE -> HANDED_TO_OWNING_TRANSACTION`. -For post-act fresh-approval finalization, replace the ordinary EVALUATED step -with the handshake: `CURRENT_FACTS_PROVEN -> NON_DECISION_PREPARATION -> -CONSUMER_BOUND_PROSPECTIVE_EVIDENCE -> FINAL_EVALUATION_AND_EQUALITY_CHECK --> PREPARED_EVIDENCE -> HANDED_TO_OWNING_TRANSACTION`. -Only that final operation may construct the decision bundle; only a valid -ALLOW satisfying the equality checks is eligible for successful finalization. -The consumer-owned middle step constructs/hashes evidence; it does not persist -it, derive another authorization view/projection, select authority or calculate -a competing validity window. -NON_DECISION_PREPARATION is never interchangeable with PREPARED_EVIDENCE. - +Only evaluation constructs a prepared decision bundle. There is no first-release +preparation/candidate handshake or provider-owned COMMITTED state. Ingress/infrastructure failure does not invent a valid authorization result. -A valid non-ALLOW result can reach PREPARED_EVIDENCE, but never an effect or -consumption transition. Closing/refusing the UnitOfWork invalidates further -provider use, including its preparation and prospective-evidence bindings. -There is no provider-owned COMMITTED state. Rollback discards prospective -evidence; a new attempt cannot reuse it even if its old expiry has not passed. - -That lifetime rule does not forbid an exact retry of the original human act -and intent when the consumer admits it under PR #20 sections 9.1, 9.2 and 16. -The same `humanActSubmissionId` must retain the same complete act bytes/digest -within the logical operation/generation. The consumer first looks up the -authoritative outcome: an already committed exact retry returns the stored -receipt without new evaluation, effect or consumption; an unresolved attempt -blocks reapplication. After conclusive rollback, an eligible retry repeats all -current checks and creates fresh attempt-bound preparation and prospective -evidence. It may reuse the original act only while its challenge/generation -and session remain eligible (or the direct-human session where applicable). -An invalidated challenge cannot be rescued by exact retry. Admission, lookup, -invalidation and persistence remain consumer-owned, not provider operations. - -Every prepared decision binds the current transaction attempt and full -intent. Compute decisionValidUntil as the canonical minimum of the trusted -transaction deadline, session/principal, applicable source/representation, -policy/snapshot, resource/evidence/sovereignty and approval cutoffs. Ends are -exclusive; explicitly unbounded governed intervals add no cutoff. Required -missing/unparseable ends or a minimum not later than the -evaluation time produce no consumable decision. A newly admitted attempt needs -a fresh evaluation; returning an existing committed receipt is not another use -of old authority and does not require another evaluation. +A valid non-ALLOW may reach PREPARED_EVIDENCE but never an effect or consumption +transition. Closing/refusing the UoW invalidates further provider use. Rollback +discards attempt-bound prepared evidence; it cannot be reused in another attempt +even when its former expiry has not passed. + +For the write consumer, logical-operation lookup and original-result recovery +precede another protected-write evaluation under PR #26's exact rules. A +committed exact retry recovers the verified original outcome without repeating +or re-authorizing that write or its successful consumption. An unresolved +outcome blocks reapplication. After conclusive rollback, a newly admitted +attempt needs fresh current evaluation under its exact protocol. Comparison +uses the original caller-submission projection and lookup tuple; the bind-once +full intent and original assertedAt stay unchanged. A fresh attempt timestamp +must not manufacture a retry conflict. + +Saved-outcome equality does not guarantee identical outward disclosure today. +Returning protected saved information requires the separately owned current +read/qualification checks, which may use a fresh governed-read attempt and +this provider's complete RECEIVE_READ_DATA evaluation. Revocation after the +original success can prevent disclosure without changing the original durable +outcome or repeating its write. “No new provider call on committed retry” +means no re-evaluation of the original protected write, not a ban on currently +required read authorization. + +Every prepared decision binds the current write or read attempt and its full +intent. Compute decisionValidUntil using PR #11 section 18.2: the canonical +minimum of all applicable trusted deadlines and validity ends, with no invented +human-approval cutoff. Required missing/unparseable ends or a minimum not later +than evaluation time produce no consumable decision. Runtime lookup, admission, +persistence and uncertainty reconciliation remain consumer-owned. The provider describes every authority fact and absence/set predicate that must remain valid. The transaction owner must protect and recheck that @@ -793,8 +688,9 @@ this PR. #178 must close its own concrete implementation design. ### Closed read-to-guard handoff -The prepared decision's local handoff is bound to the exact tenant, operation -and attempt, intent, selected command/policy, canonical snapshot, complete +The prepared decision's local handoff is bound to the exact tenant, admitted +protocol and attempt, operation/command binding where applicable, full intent, +selected action/policy, canonical snapshot, complete request/result/trace bytes and decision-bundle digest. It also carries `decisionValidUntil` and the complete provider-observed footprint. The wrapper is internal data, not another persisted ledger, a new canonical proof schema @@ -807,7 +703,7 @@ The footprint has three closed forms; none can be replaced by a boolean |---|---|---| | Exact record/content fact | Tenant, family, immutable ID/digest, relevant revision/lifecycle and source visibility; includes selected and rejected bases required by canonical evidence | The same fact remains admissible through the protected effect, or the consumer refuses/restarts under its protocol. | | Absence or complete set | The rule-selected predicate, its exact tenant/resource scope, expected complete membership and canonical currentness proof; includes applicable revocation, competing authority and prospective-subject absence | Protection against insertions and other changes to that predicate, not just locks on the rows that happened to exist. | -| External binding or time | Exact selected policy/currentness, identity/session/act/display proof and every required exclusive cutoff not established by tenant rows | Its owning authority's admitted validity/recheck mechanism and timely final consumption; a database row lock alone is insufficient. | +| External binding or time | Exact selected policy/currentness, required identity/session/representation proof and every applicable exclusive cutoff not established by tenant rows | Its owning authority's admitted validity/recheck mechanism and timely final consumption; a database row lock alone is insufficient. Deferred human-act/display evidence is not a substitute. | These forms identify obligations, not new predicate semantics or a generic query language. The bound rule/profile owns the exact predicates and canonical @@ -816,13 +712,15 @@ its observed footprint; the consumer must reject an omitted, unknown, mismatched or unprotectable obligation before consumption. No successful handoff may silently reduce this to the selected grant's ID and expiry. -Before Phase B, G3 must connect these forms to the transaction owner's actual -typed attempt/guard input and exact canonical profile. In particular it must -prove final-snapshot continuity across preparation and final evaluation, +Before Phase B, G3 must connect these forms to both owning transaction interfaces +and their exact canonical profiles. In particular they must prove the required +continuity from authority observation to protected write or buffered read, external validity and set/absence protection under concurrency. No such complete production interface exists at the inspected base. This RFC chooses the producer/consumer split and required contents; it does not select locks, -change isolation or certify a fictional guard receipt. Tests with handcrafted +change isolation or certify a fictional guard receipt. The read owner combines +this full authority footprint with its own payload/coverage obligations; the +provider does not author a redaction plan or read receipt. Tests with handcrafted frames can exercise provider logic but cannot close this source/guard gate. ### Durable outcomes belong to the consumer @@ -850,23 +748,23 @@ For the future NOT_REQUIRED operation-claim consumer: 7. Public results use the separately admitted CP2 surface and current disclosure policy. Full internal traces are not exposed by this provider. -Human-finalization actions consume their own PR #20 protocol. For fresh -approval, its consumer owns admission of the exact act/open generation and -the guarded final transaction, uses this provider's non-decision preparation, -constructs the prospective approval, and returns it to the same provider for -the complete final evaluation and exact basis/window equality checks. The -consumer then owns the remaining gates and atomic success set; the candidate -becomes durable only with that complete successful commit. Challenge issuance, -the human ceremony, persistence, approval/decision consumption and transaction -coordination remain outside this provider. Governed reads use their separately -owned buffered evidence/disclosure protocol. PR #26 cannot be used as a -universal coordinator for those modes. - -This is an interface obligation for those later owners, not their -implementation or verification in #359. Provider tests can prove exact -non-decision preparation, prospective-evidence validation, final basis/window -equality, prepared evidence, transaction binding and no owned writes. Durable -refusal, lost-acknowledgement recovery, atomic effects and consumption require +The governed-read consumer uses its own complete buffered-read protocol: +coherent authorization and retrieval, full result-coverage/redaction/qualification, +exact buffered payload and proof posture, atomic decision/consumption/read-evidence +and receipt persistence, then permitted release. PR #26 is explicitly write-only +and cannot stand in for that protocol. This provider neither retrieves a public +payload nor persists its receipt or authorizes release on the strength of a +prepared ALLOW alone. + +Human-finalization runtime flows and the provider's corresponding handshake +remain deferred under #175. Their canonical obligations and revision 6 design +are preserved, not verified by this delivery. + +These are interface obligations for separately owned consumers, not their +implementation or verification in #359. Provider tests prove complete selected +evaluation, prepared evidence, truthful failures, attempt/role binding, full +guard obligations and no owned writes. Durable refusal, lost-acknowledgement +recovery, atomic effects/consumption and current disclosure after retry require consumer-owned integration tests; they cannot be reported as #353 evidence. ## 9. First consumer and the incompatible old command binding @@ -901,8 +799,12 @@ The next #178 design must also reconcile representation in operation identity, the shared cross-handler/profile lookup, caller projection versus bind-once full intent, original timestamps, exact key equality, complete NO_EFFECT consequences, separate commit uncertainty, and original-result -recovery. Its older all-command-family criteria must not silently shrink to a -single claim example. #193 still owns disaster/store-loss recovery. +recovery with current disclosure permission. The amended #178 explicitly scopes +the first delivery to the common protocol with one real claim consumer; all +other command-family integrations remain open under #167. The whole #175 epic +is no longer its blanket predecessor, but the concrete first-consumer authority +and producer prerequisites remain. No cyclic blanket #353 replacement or fake +attempt closes that ordering. #193 still owns disaster/store-loss recovery. ## 10. Falsifiable invariants and production-path verification @@ -911,9 +813,21 @@ INV-001 through INV-012 proposals; no prior approval or passing test transfers. “Production entry” means the proposed provider on a genuinely bound UnitOfWork created through production composition, not an HTTP route opened by this PR. +The following applicability ledger controls the initial release. It preserves +every invariant's programme disposition; deferred human-specific rows below +are retained design obligations, not current executable cases or passing tests. + +| Invariants | Initial claim/read disposition | +|---|---| +| AUTH-001 | Complete coverage of the exact canonical admitted set, both full rules and all branches; exact membership equality and excluded-action rejection. The other eighteen catalogue rows are not passed. | +| AUTH-002–014 | Retained in full for the selected scope, including current representation/CP3/sharing/revocation, truthful failure evidence, attempt/guard binding, prepared-only output and closed production composition. | +| AUTH-015–017 and AUTH-019 | Human preparation, prospective-finalization and challenge/candidate equality execution is deferred under #175. No first-release API, synthetic proof, success stub or passing claim. Exact detailed design remains at revision 6. | +| AUTH-018 | Retain current attempt/protocol-role isolation and truthful original-write retry. Current disclosure authorization remains required; human-act/challenge-specific execution is deferred, not passed. | +| EXC-001–007 | Retained: one source/path, no duplicate matrix or durable state, no speculative deferred API, complete invariant evidence, no automatic size increase; taste alone is not a Blocker. | + | ID and invariant | Owning code area | Required negative case through the production entry | |---|---|---| -| AUTH-001: one exact canonical rule source; full admitted action coverage | Verified rule loader and coverage checks | Wrong digest, missing/duplicate rule, invalid closure or mismatched caller schema hint cannot produce an executable rule; test every canonical row/branch, not a copied list. | +| AUTH-001: one exact canonical rule source; full selected admission and evaluation coverage | Verified rule loader and coverage checks | Wrong digest, missing/duplicate/extra rule, altered admitted set, invalid closure, excluded action or mismatched caller schema hint cannot produce an executable rule or fallback outcome. Test every branch of both complete selected rules, including all read-resource alternatives; one claim example or blanket refusal fails completion. | | AUTH-002: callers cannot choose restrictions or mirrored proof | Bound input and rule-selected ingress/extraction | Supply forged stage/posture, tenant, schema, time, scope or policy hints; none weakens evaluation. Invalid ingress creates no fabricated decision. | | AUTH-003: identity, representation and CP3 are independently proven | Actor/path resolver | Organization without natural-person proof, sponsor without authority, missing CP3 snapshot, and AI-metadata omission/retry never manufacture an eligible path. | | AUTH-004: target, typed input, effect subject and scope are distinct | Tenant resource reader and rule interpreter | Use a wrong-kind/foreign/missing target with a valid local scope, stale revision, or unproven prospective absence; no unproved eligibility. | @@ -930,7 +844,7 @@ created through production composition, not an HTTP route opened by this PR. | AUTH-015: fresh-approval preparation is non-authoritative | Same provider's bound preparation operation and shared rule/extraction/projection/path/cutoff implementation | With valid post-act inputs, obtain the complete bound view, projection/digest, candidate bases and expiry values, but no decision result/trace/bundle, consumption, effect or durable claim. Fail a global/path condition or omit a cutoff: no successful preparation. Passing preparation as a decision or requesting an approval-skip flag cannot authorize anything. | | AUTH-016: prospective finalization evidence has an explicit, restricted input role and complete verified bindings | Same provider's preparation output, final-evaluation input and evidence verifier | Build the full canonical approval solely from provider-derived authority fields and exact owner-supplied act/display/transaction prerequisites; schema-check and hash it without a second extractor/projection/path/cutoff engine. The valid uncommitted candidate can produce prepared ALLOW when every check passes, with no durable claim. Wrong target/input/subject, representation, bytes/digest, act, snapshot, intent or approver cannot support ALLOW. Unavailable/changed display bytes, renderer/version/digest, display policy, locale/timezone or retention binding fail preparation/final validity. A trusted act at an exclusive cutoff fails; a client timestamp cannot repair it. A same-person independently eligible challenged act succeeds under SAME_PRINCIPAL_ALLOWED; omitting separation proof or activating the reserved DISTINCT_APPROVER_REQUIRED posture fails. A prospective grant cannot replace governed prerequisite proof. | | AUTH-017: candidate and final requester basis/window must match exactly | Shared canonical selection/cutoff logic and final equality checks | Substitute a different otherwise-eligible requester basis, or shorten/extend the prospective decisionValidUntil even within the transaction deadline. Final evaluation cannot force selection, rewrite the candidate or accept a different returned window; no ALLOW based on that candidate or successful finalization handoff. | -| AUTH-018: preparation and prospective evidence are attempt- and mode-bound, without prohibiting canonical exact retries | Bound provider lifetime, trusted mode and candidate admission; consumer owns retry/receipt handling | Reuse an old preparation or prospective candidate in another attempt or after rollback, even before expiry: reject it as authority. In an admitted exact-retry fixture, keep the same original intent and humanActSubmissionId/act bytes but use a fresh attempt, current preparation and candidate; allow completion when every check still passes. Changed bytes under the same act ID cannot pass admission. Substitute NOT_REQUIRED or DIRECT_HUMAN_ACTION_REQUIRED, or supply a synthetic challenge/separate approver to direct-human mode: no bypass. Direct-human act time must meet its trusted session/transaction cutoffs. Consumer integration must separately prove that a committed exact retry returns its stored receipt with no provider call or second consumption. | +| AUTH-018: evaluation evidence is attempt- and protocol-role-bound, with truthful original-write retry and current disclosure | Bound provider lifetime and write/read frame admission; consumers own lookup, retry, receipts and release | Reuse an old prepared decision in another attempt/closed UoW or substitute a write frame for a read (or the reverse): no consumable handoff. A newly admitted attempt needs fresh current proof. A committed exact retry must not re-evaluate or repeat its original write/consumption, but current protected readback may require a new read evaluation and may refuse after revocation. Consumer integration separately proves unchanged original outcome, original caller projection/bind-once intent, no second write and no forbidden disclosure. Human-act-specific variants remain deferred at revision 6. | | AUTH-019: provider-owned challenge/final relevant-state equality | Same provider's typed read footprint, rule-selected projection/JCS digest, preparation refusal and final recheck | Change a rule-relevant target revision or representation fact between challenge and act while keeping an otherwise sufficient requester basis/window: no successful preparation or ALLOW from that act. Advance unrelated history outside the projection, changing only the full snapshot ref: preparation/final ALLOW remain possible if all other checks and guards pass. Verify exact provider-produced projection/digest; forged consumer digests or an equality flag cannot bypass recomputation. Relevant drift between preparation and final evaluation also fails. Preparation emits no decision; any canonical REQUIRE_HUMAN_APPROVAL refusal keeps HUMAN_FINAL_ACTION_REQUIRED primary and APPROVAL_CHALLENGE_STALE diagnostic. Consumer integration separately proves durable generation invalidation and a new challenge/act before retry after drift. | Test setup uses fictional data and the existing separately owned provisioning @@ -939,17 +853,27 @@ work. Relevant cases require real PostgreSQL tenant binding, two-tenant isolation, exact currentness inputs and recorded read provenance; a pure function fed caller-authored grant dictionaries is insufficient. -AUTH-015–019 exercise preparation and final evaluation through the same -production-bound provider and guarded attempt fixture. The fixture supplies -the transaction owner's trusted inputs and constructs prospective evidence -from the complete provider-derived view and owner-supplied prerequisites; it -must not implement its own extraction, relevant-state projection, path-selection -or cutoff algorithm. Inspect the schema-complete candidate and its derived -target/inputs/subject/representation bindings, not only a mocked approval ID. -Assertions inspect returned types/bytes and the absence of provider-owned -writes. The valid prospective-approval, unchanged-projection and admitted-retry -cases prove usability, not merely that every attempt can be refused. Fixture -admission does not prove the consumer's durable retry/invalidation protocol. +The applicability ledger above governs these cases. The retained human-specific +rows describe future obligations, not methods to expose or tests to mark passed +in this release. Current positive cases must exercise both complete selected +rules, every admitted read-resource alternative and every applicable authority +path through the same production-bound evaluator. Excluded actions and invalid +dependencies cannot be repaired by a smaller admitted set, fabricated proof or +an always-refusing implementation. + +The fixture supplies real owner-issued write or governed-read inputs. It must +not implement a second extraction, projection, path-selection or cutoff engine, +mint an authority frame or bypass the source-history gate. An inactive writer, +empty history lookup or individually valid qualifier is not completeness proof. +Inspect returned types/bytes and the absence of provider-owned writes. Usable +selected paths must succeed when every requirement is met; missing executable +sources and trusted producers remain gates, not evidence of passing tests. + +Separate consumer integration must cover a committed write, later permission +loss and an exact retry: the stored original outcome remains unchanged, the +original write/consumption is not repeated or re-evaluated, and a fresh governed +read may refuse protected disclosure. That fresh read evaluation is not a +second authorization of the original write. The exact source schemas and trusted input/read interface must exist before these proposed cases can count as implemented evidence. Consumer race tests @@ -957,7 +881,7 @@ must additionally cover revocation/set changes between evaluation and commit, exclusive deadlines, duplicate consumption, persistence failure, committed refusal with lost response, and separately unknown evidence commits. -### Focused verification for the revision 5 interface +### Focused verification for the revision 7 selected interface These are planned cases under existing invariants, not new canonical rules or claims of executed tests: @@ -983,22 +907,32 @@ claims of executed tests: aggregation). A real adapter/database fault follows infrastructure handling. Inspect truthful failure evidence without inventing a snapshot, suppressing path diagnostics or treating every failed authority proof as an exception. -- AUTH-011/012/014: retain both bound methods after closure and call them in a - rollback-only UoW; no reader runs. Inject a database failure and verify the - existing rollback/discard path, including a consumer that catches the error; +- AUTH-011/012/014: retain the bound evaluation method after closure and call + it in a rollback-only UoW; no reader runs. Inject a database failure and verify + the existing rollback/discard path, including a consumer that catches the error; no provider commit or false durable result follows. Verify exact constructor/slots/import edges and no raw handle. -- AUTH-013/019: delete a set/absence or external obligation from the returned - handoff; completeness verification fails. Attempt the two-step approval - handshake without proof of one final snapshot/protection context; no - successful finalization. Actual race prevention still needs owner tests. -- AUTH-015–019: execute valid fresh-approval, direct-human and NOT_REQUIRED - cases through the two methods, including same-person eligibility, exact - candidate equality and admitted fresh-attempt retry. Preparation cannot - masquerade as a decision; `None` cannot bypass the rule's human requirement. +- AUTH-013: delete a set/absence or external obligation from either selected + write/read handoff; completeness verification fails. Missing proof of + continuity between the authority observation and protected write or buffered + read cannot be replaced by a context label. Actual race prevention, read + coverage, qualification, receipt and release still need their owners' tests. +- AUTH-001/018: cover every selected rule branch and read target/path, reject + excluded actions and cross-role write/read frames, and isolate attempts. + Consumer integration proves that an exact committed-write retry preserves + the original result without repeating its write or consumption, while a + required current read authorization can independently refuse disclosure. + Human preparation/finalization cases remain deferred under #175, not passed. ## 11. Disposition of the existing nine-blocker review +This section preserves revisions 2–6 and their exact-head review history. Its +older section references and human-handshake language describe those revisions, +not first-release APIs or review of revision 7. The complete previous design is +retained at `725df163ddcd4f93b4675a3041724b1f59ab8151`. The revision 7 entry +below records the new scope; prior findings are not silently erased or promoted +to approval of this changed design. + The [review at the old head](https://github.com/samovers/OFARM2/pull/359#pullrequestreview-5065359533) remains historical evidence. The old “zero Blockers” wording was contradicted by that review and is removed. This table is a correction map for re-review, @@ -1074,11 +1008,36 @@ and one non-blocking S1 clarification: make the reader-to-evaluator failure mapping explicit. It preserved the interface direction and prior handshake, and did not close G2/G3 or approve implementation. -Revision 6 addresses S1 in the reader plan and AUTH-007/009/010 cases above. -Review only that clarification and its affected invariants; do not reopen the -earlier findings or architecture without new evidence of a defect. The -revision 5 zero-Blocker disposition remains historical, not review of this new -head. No new source producer, guard, runtime behavior or canonical law is added. +Revision 6 addressed S1 in the reader plan and AUTH-007/009/010 cases. It +requested focused review of that clarification and affected invariants, with +earlier findings kept closed absent new evidence. Its source-failure mapping +is retained here. The revision 5 zero-Blocker disposition is historical, not +review of revision 7; neither revision added a producer or runtime behavior. + +### Revision 7: approved release-scope alignment, pending runtime-design review + +The task user approved canonical PR #11 at +`4494924998183fe3fa7bc1b63b76a85893335044`; the +[approval record](https://github.com/samovers/OFARM/pull/11#issuecomment-5634389303) +is semantic Phase A approval only. The subsequent issue amendments retain the +full programme while selecting exactly two complete rules for the initial +executable policy. This revision applies that scope to the existing #359 design: + +- keep the twenty-row catalogue separate from exact executable membership, + including all `RECEIVE_READ_DATA` target alternatives and authority paths; +- remove human-preparation and prospective-finalization APIs from the proposed + initial facade, retaining their complete history and deferred obligations; +- retain one evaluator, with closed and separately owned write/read input roles, + complete current proof, guard obligations and truthful prepared-only output; +- separate original-write result recovery from current disclosure permission; +- account for all AUTH-001–019 and EXC-001–007 obligations without treating + deferred execution as passed or weakening source-history completeness. + +Revision 7 is REVIEW_PENDING. Review the changed scope, selected interface, +write/read handoff and applicability ledger at its exact head; earlier review +dispositions do not transfer. G2 canonical readiness, G3 real interfaces/size +and G4 fresh OFARM2 decision-card approval remain open. This is not an issued +decision card, reviewer sign-off or authorization to implement. ## 12. Expected implementation areas and code excellence @@ -1150,33 +1109,34 @@ must explicitly settle its coverage and size bound and register focused test coverage (the default covered test-module limit is 800 lines). Re-measure at the implementation base. This design revision edits no checker or runtime. -Revision 5 proposes this exact new shape, replacing the earlier open-ended -provider-hook description: +Revision 7 proposes this exact selected-scope shape. The prior two-method +proposal remains at revision 6; it is not a speculative initial-release API: ```text public surface = {binding, batch, begin_batch, resolve_commit_operation_claim_draft_runtime_bundle, - prepare_authorization, evaluate_authorization} + evaluate_authorization} constructor = (self, binding, allocate_batch, resolve_bundle, authorization) slots = {__binding, __active, __allocate_batch, __batch, __resolve_bundle, __selector_state, __selected_bundle, __rollback_only, __authorization} -authorization = one private frozen _AuthorizationCalls pair +authorization = one private, closed typed evaluation callable ``` -The pair contains only typed preparation/evaluation callables, not a generic -executor. The manager builds it against the same connection and privately held -principal/binding; `_finish` replaces it with closed callables. Public -`ApplicationRuntime` methods and existing authentication, audit and selector -semantics do not change. The two new UoW methods check lifetime/rollback-only; -they do not allocate a batch, commit, acquire locks or choose policy. Concrete +The callable evaluates only the exact admitted selected rules; it is not a +generic executor. The manager builds it against the same connection and +privately held principal/binding; `_finish` replaces it with a closed callable. +Public `ApplicationRuntime` methods and existing authentication, audit and selector +semantics do not change. The one new UoW method checks lifetime/rollback-only; +it does not allocate a batch, commit, acquire locks or choose policy. Concrete reader SQL stays in the private tenant authority adapter, not the facade or a legacy module. Architecture verification must allow only those exact new edges and preserve the existing raw-handle, generic-SQL and legacy firewalls. Proposed implementation partition is the evaluator, narrow reader and closed -local input/output types needed by those two operations; no plugin registry, -generic policy framework or parallel authorization path. The type dependency +local input/output types needed by this one evaluation operation for both +selected rules; no plugin registry, generic policy framework or parallel +authorization path. The type dependency direction must avoid a circular import back into `tenant_uow`; place shared values separately only when the concrete implementation needs it. @@ -1193,12 +1153,13 @@ Phase B remains prohibited. | Code-excellence invariant | Planned assessment | |---|---| -| EXC-001 — one authoritative path | One canonical semantic source and one production authorization implementation shared by non-decision preparation and final evaluation; the transaction owner constructs evidence from those values, not a second extractor, relevant-state projection/comparison, path-selection or cutoff engine. | +| EXC-001 — one authoritative path | One canonical semantic source and one production authorization evaluator for both complete selected rules; no second extractor, relevant-state projection, path-selection or cutoff engine in consumers. | | EXC-002 — no avoidable duplication | No handwritten second matrix, compatibility authority API, extra durable decision store, retry ledger, or copied schema inventory. | -| EXC-003 — direct invariant trace | AUTH-001–019 map the typed entry, bound reader, preparation/final-evaluation handshake, relevant-state comparison and evidence constructor to focused tests. Missing real reachability blocks completion. | +| EXC-003 — direct invariant trace | The AUTH-001–019 ledger maps each obligation to retained selected evaluation or explicit deferred human execution. Current typed entry, bound reader, evidence and handoff require real production-path tests; deferred rows are not passing evidence. Missing real reachability blocks completion. | | EXC-004 — delete superseded owned paths | Withdraw the old plan; introduce no legacy compatibility path. The quarantined legacy system is not an owned production path and is not deleted as an unrelated migration. | -| EXC-005 — abstractions pay rent now | Bound input/output prevent mixed tenant/rule/attempt facts; distinct preparation, prospective-evidence and prepared-decision values prevent authority/persistence confusion in the required fresh-approval handshake. A narrow reader contains existing connection authority. No generic policy engine, plugin registry, public SQL facade or future dispatcher. | +| EXC-005 — abstractions pay rent now | Closed bound input/output and write/read roles prevent mixed tenant/rule/attempt facts and authority/persistence confusion. A narrow reader contains existing connection authority. No deferred preparation/prospective-evidence API, generic policy engine, plugin registry, public SQL facade or future dispatcher. | | EXC-006 — simpler credible alternative | Adding a table to kernel.authority fails production isolation and canonical ownership. A pure helper alone fails the bound production-read outcome. A new transaction owner is unnecessary and crosses into #178. The proposed provider plus typed reader is the smallest plausible slice, subject to gate G3. | +| EXC-007 — taste alone is not a Blocker | Private naming and test partitioning are Preferences after the authority, lifetime, exact surface and measured size constraints are satisfied. A demonstrable invariant failure is not dismissed as taste. | ## 13. Gates, provisional posture, and review state @@ -1210,23 +1171,24 @@ path is authorized. | Gate | Current state and what remains before implementation approval | |---|---| -| G1 — Delivery scope | Applied in issue #353 with the preserved amendment record in section 2. The later formal decision card must include this scope; full evaluation coverage remains explicit. This is not implementation approval. | -| G2 — Canonical readiness | Complete the governing staged sequence and replace missing entries in section 5 with reviewed exact promoted/extracted bytes and provenance. Semantic approval alone is insufficient. | -| G3 — Concrete trusted interface | Sections 6, 8 and 12 now propose the exact closed surface, trusted-source map, coherent read shape and guard handoff. Review those choices and close the specific unresolved items below; no production factories, canonical snapshot proof, measured query bounds or final module budget are implied. Preserve the revision 4 handshake and prove independently useful full-coverage production-provider completion. | +| G1 — Delivery scope | First-release amendment applied in issue #353 with the preserved record in section 2. The later formal decision card must include both complete selected rules and every read target/path, with eighteen evaluations and human workflows deferred. This is not implementation approval. | +| G2 — Canonical readiness | Satisfy the pre-runtime stages over the full selected transitive closure, including CP2A-DEP01 source-history/historical-admission proof, and replace missing entries in section 5 with reviewed exact promoted/extracted bytes and provenance. All eleven stages remain required: stage 11 is the later runtime work, not a prerequisite to its own approval. Whether history closure can be proved with qualifying-record authoring non-executable remains unresolved; semantic approval or an individually valid qualifier does not close it. | +| G3 — Concrete trusted interface | Sections 6, 8 and 12 propose one closed evaluation entry, distinct write/read input roles, the trusted-source map, coherent reads and complete guard handoff. Review those choices and close the items below; no production factories, snapshot proof, measured query bounds or final module budget are implied. Prove independently useful full selected coverage through real production composition, not human APIs or fabricated fixtures. | | G4 — Fresh OFARM2 approval | Review this corrected Phase A to zero Blockers, then present a complete decision card naming existing PR #359 and obtain the required exact later task-user approval. No such card is issued by this revision. | The remaining G3 work is bounded, not a request to restart canonical design: | Item | Required closure evidence | Boundary and sequencing | |---|---|---| -| G3-INPUT | Exact mappings and real producers for principal/representation/CP3, session/act, attempt/deadline and compatible selection; reject forged/mixed frames through production composition | Consume existing accepted producers where sufficient. Any new authentication/session, selection or transaction authority needs separately scoped work and user direction before edits; do not mint proof in this provider. | -| G3-READ | Exact admitted schema/hash/extractor mapping, coherent SQL, source visibility/currentness and canonical snapshot proof, truthful global/path/infrastructure failure encoding, bounded representative workload, same final-snapshot/protection context for the handshake | Reader/projection implementation belongs here after G2. Missing storage, permission, snapshot authority or transaction protection belongs to its owner, not a database change hidden in the reader. | -| G3-HANDOFF | Actual typed transaction interface covering every record/set/absence/external/time obligation and attempt-bound prepared evidence, with an independently usable provider completion test | Settle the interface with #178's design before approving provider code. Durable command coordination, guards and consumer race/recovery tests remain #178/applicable consumer work. Their later delivery cannot excuse a provider that only accepts invented fixtures. | +| G3-INPUT | Exact mappings and real producers for principal/representation/CP3, required principal/session validity, closed write/read attempts and deadlines, and compatible selection; reject forged/mixed frames through production composition | Consume existing accepted producers where sufficient. Human-act capture is deferred, not a substitute for required current validity. Any new authentication/session, selection or transaction authority needs separately scoped work and user direction before edits; do not mint proof here. | +| G3-READ | Exact admitted schema/hash/extractor mapping, coherent SQL, complete source visibility/history/currentness and canonical snapshot proof, truthful global/path/infrastructure failure encoding, bounded representative workload, and continuity from authority observation to protected write or buffered read | Reader/projection implementation belongs here after G2. Missing storage, permission, source-history/snapshot authority or transaction protection belongs to its owner, not a database change hidden in the reader. | +| G3-HANDOFF | Actual write and governed-read interfaces covering every record/set/absence/external/time obligation and attempt-bound evidence, with independently usable provider completion tests | Settle with #178 and the separately owned governed-read design before approving provider code. Durable write coordination and read coverage/qualification/receipts/release stay with their owners. Required real producers must precede their use; later consumer delivery cannot excuse invented fixtures or a type-only prerequisite. | | G3-SHAPE | Review the exact facade proposal and architecture edges in section 12, then a measured final partition/size and focused production-path test plan against the admitted bindings | One authorization boundary. Existing zero headroom is explicit; no automatic checker relaxation or budget increase. | -The #353 -> #178 -> #176 sequence describes capability completion; it cannot -postpone an indispensable input producer until after its consumer. If G3 -requires an authority producer that exists only in unfinished #178 work, that +The #353 -> #178 -> #176 sequence describes capability completion, not the +separate governed-read protocol's ownership. It cannot postpone an indispensable +write/read input producer until after its consumer. If G3 requires an authority +producer that exists only in unfinished #178 work, that is a dependency cycle to resolve before approval, not permission to use fake frames. First determine whether an already accepted interface suffices. If not, propose an independently usable prerequisite in its own boundary and @@ -1235,9 +1197,12 @@ Neither a type-only companion PR nor silently expanding #353 resolves this. Evidence requiring redesign: a machine binding contradicts the approved candidate; the exact reader/guard/proof needs a new authority; full admitted -coverage cannot be supplied by one coherent provider; or provider-owned -durability is requested again. The upgrade path is a reviewed revision with exact -bindings and concrete interfaces, and a new semantic decision version where +coverage cannot be supplied by one coherent provider; source-history closure +requires an additional executable action or writer; or provider-owned durability +is requested again. Stop and obtain a separately reviewed scope decision where +required; no extra action/writer, blanket UNAVAILABLE or weaker proof is implied. +The upgrade path is a reviewed revision with exact bindings and concrete +interfaces, and a new semantic decision version where required—not a compatibility fallback. Separate downstream work: #178 command identity/atomic consumption/results; @@ -1247,10 +1212,12 @@ disaster/store-loss recovery. The old command successor is a compatibility gate for its consumer, not a reason to amend approved canonical PR #26. No new Delivery issue is created in this revision. -Review disposition: revision 6 is REVIEW_PENDING. G1 is applied; G2/G3 and the -later G4 card/approval remain outstanding. The revision 5 review stays attached -to its exact historical head and is not transferred to this revision. Exact -private names and test-file partitioning are Preferences only after the +Review disposition: revision 7 is REVIEW_PENDING. G1 is applied; G2/G3 and the +later G4 card/approval remain outstanding. Previous reviews stay attached to +their exact historical heads and are not transferred to this revision. Review +the changed release scope and affected interface/invariants; do not restart +unaffected findings without new evidence. Exact private names and test-file +partitioning are Preferences only after the substantive interface is settled. ## 14. Verification and handoff @@ -1280,8 +1247,8 @@ transaction coordination, protected effects, selection authority and temporal persistence with their own owners. No cross-boundary implementation is hidden in this plan. -What is next: review revision 6's bounded reader-failure clarification and -affected AUTH-007/009/010 invariants at its new head; close the listed G2/G3 -prerequisites with their existing owners before presenting the fresh #359 +What is next: review revision 7's first-release scope, single evaluation +interface, write/read handoff and AUTH/EXC applicability ledger at its new head; +close the listed G2/G3 prerequisites with their existing owners before presenting the fresh #359 decision card. No runtime edits, new Delivery issue, baseline or merge are authorized by this design revision. From f97fe8f73d956d2dd6c0f82f133d6800b71055fe Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Samo=20A=C4=8Dko?= Date: Sat, 12 Sep 2026 20:23:57 +0200 Subject: [PATCH 7/8] Clarify rule-bound read qualification evidence ownership 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. --- ...ority_Action_Matrix_Evaluation_RFC_v0_1.md | 174 +++++++++++++++--- 1 file changed, 144 insertions(+), 30 deletions(-) diff --git a/docs/rfcs/OFARM_Runtime_Authority_Action_Matrix_Evaluation_RFC_v0_1.md b/docs/rfcs/OFARM_Runtime_Authority_Action_Matrix_Evaluation_RFC_v0_1.md index 6c02a3f1..fc259dd6 100644 --- a/docs/rfcs/OFARM_Runtime_Authority_Action_Matrix_Evaluation_RFC_v0_1.md +++ b/docs/rfcs/OFARM_Runtime_Authority_Action_Matrix_Evaluation_RFC_v0_1.md @@ -1,9 +1,11 @@ # OFARM Production Authorization Provider — Phase A RFC v0.1 -Date: 2026-09-11 +Date: 2026-09-12 -Design revision: 7 — first-release scope alignment. This consumes renewed -canonical Phase A approval at PR #11 head +Design revision: 8 — bounded read-qualification evidence correction. This retains +revision 7's complete two-action scope and makes the provider's rule-bound +evidence check distinct from the consumer's result qualification. It consumes +renewed canonical Phase A approval at PR #11 head `4494924998183fe3fa7bc1b63b76a85893335044` and the aligned #353 scope. It proposes complete evaluation of ASSERT_OPERATION_CLAIM and RECEIVE_READ_DATA through one evaluation-only facade. Neither selected rule is weakened. The other @@ -19,7 +21,12 @@ The unapproved legacy proposal at `178f150ce56f1bdad96330ba845d210ee0911f2a` remains superseded. No accepted OFARM law changes. -Status: revision 7 is REVIEW_PENDING; G1 first-release scope alignment applied; +Revision 7 at `feffb585ec569c6aaa8b5d085e94583d1eb9aeca` has two exact-head +reviews; the later review identified B1's read-evidence ownership ambiguity. +Section 11 records this correction and both non-blocking follow-ups. Prior +reviews do not approve this new head. + +Status: revision 8 is REVIEW_PENDING; G1 first-release scope alignment applied; G2 canonical readiness, including source-history closure, and G3 implementation prerequisites remain open. The sufficiency of two executable actions is unproved. No OFARM2 semantic approval, runtime implementation, baseline @@ -173,6 +180,7 @@ command-execution capability travels with it. | Policy/command selection and immutable runtime component identity | Existing separately reviewed selection/RuntimeBundle owners | | Database session, transaction identity/finalization, isolation, complete commit guard and uncertainty reconciliation | Existing transaction owners, later #178 write work and the separately owned governed-read protocol; no new owner here | | One current evaluation, selected sufficient path, complete prepared decision evidence and read obligations | This provider | +| Evaluation of the selected action-level evidence policy, including CP2 read-qualification evidence | This provider verifies the exact rule-bound policy and its required proof before ALLOW. The separately owned read/evidence producer supplies proof inputs; result qualification, redaction, persistence and release remain consumer-owned. Neither ownership substitutes for the other. | | Execute every projection/comparison required by the selected rules and complete evidence closure | This provider, using its current typed authority observation; canonical OFARM owns projection and JSON Pointer semantics. Human challenge/final equality execution is deferred, not a first-release API. | | Human-act capture, display/retention, generation invalidation and challenge replacement | Separate human/transaction owners; their runtime workflows and the provider's corresponding future handshake remain deferred under #175, with revision 6 preserved as history. | | Protected-effect schema, mapping, gate PASS, assertion state and temporal mapping | Separately owned domain/temporal validators and command binding | @@ -293,6 +301,7 @@ and manifest entries for every required component: | Selected protected-effect contracts, AssertionRecord result binding and Event Grammar classifications | Selected complete dependency closure still required; unselected effects may be deferred only with a reviewed closure disposition | | NOT_REQUIRED write and separately owned governed-read transaction profiles, deadline/guard mappings and result-complete lifecycle | PR #26 is a write-only semantic candidate, not a governed-read protocol; executable profiles and real production interfaces remain unproved | | CP2 result/reasons, retention, sovereignty, evidence and CP3 bindings | Exact selected bindings and current source checks remain required; approved designs are not promoted/extracted contracts | +| Rule-bound `EP_CP2_READ_QUALIFICATION_V0_2` and its required evidence | Required by PR #11 sections 7.7–7.8, 12 and 18.5, separately from CP2 result qualification. The exact policy ref/digest, evidence schemas, eligible source/producer bindings and extraction remain G2; the real pre-evaluation input producer and same-snapshot interface remain G3. No executable profile or proof source is supplied here. | | CP2A-DEP01 source-history classification, completeness and historical-admission proof | Open under #32 and its actual source dependencies; inactive writing, empty lookup or an individually valid qualifier is not complete history | Existing v0.1 schemas are not substitutes. A missing digest is recorded as @@ -353,7 +362,7 @@ These methods do not exist in the inspected production code. | Local member | Content and admission rule | |---|---| -| `attempt` | Owner-issued write or governed-read attempt frame: exact operation where applicable, protocol/attempt/transaction binding, fixed deadline and trusted time, required principal/session validity and snapshot/guard inputs. It must match this bound UoW and selected action; no human-act or approval role is admitted here. | +| `attempt` | Owner-issued write or governed-read attempt frame: exact operation where applicable, protocol/attempt/transaction binding, fixed deadline and trusted time, required principal/session validity and snapshot/guard inputs. The read form also carries the rule-bound qualification-evidence observation described below. It must match this bound UoW and selected action; no human-act or approval role is admitted here. | | `selection` | Owner-issued exact operation/action, policy/rule and binding-manifest selection. Verify its provenance, content and compatibility; a matching action string alone is insufficient. A write-command selection cannot substitute for a governed-read binding. | | `effect_intent` | Exact full intent bytes and their claimed identity/digest. The provider validates and derives its authorization view itself. Owner-completed fields must already be bound by the admitted write or governed-read protocol. | @@ -389,6 +398,24 @@ These are local envelope roles, not newly invented canonical schemas or caller-selected approval modes. Exact machine fields and real factories remain G2/G3 work. +The proposed carrier for read-qualification proof is the closed governed-read +`attempt` role, 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-set `qualified` flag or an asserted prior ALLOW. Referenced governed +records are resolved through the provider's typed tenant reader. The provider +verifies every supplied fact under the selected evidence policy, its exact +effect-intent binding and the same governed snapshot/protection context. + +This is a local input-role proposal, not a new canonical schema, evidence kind +or producer implementation. G2 must supply the exact active/current policy, +schemas and source admission; G3 must settle the real producer, field mapping, +pre-evaluation availability and truthful failure representation. If the proof +cannot be produced in the required order/context, that gate remains open: +no unbound payload supplied after evaluation, completed receipt from the same +read, synthetic proof or premature disclosure can fill the gap. Producing a +proof observation does not itself grant read authority or permission to release. + ### Trusted-source map and missing producers | Required fact | Existing source and provider use | Remaining owner dependency | @@ -399,6 +426,7 @@ remain G2/G3 work. | Write or read attempt, deadline, snapshot and protection | Same bound connection supplies tenant/full-transaction identity; each owning protocol supplies its admitted time/guard context | Current UoW has no complete write/read attempt/deadline/guard factories. Tenant challenge time, token lifetime, batch allocation and `bound_at` are not substitutes. Settle #178's write interface and the separately owned governed-read interface before their respective use. | | Command/action and authorization policy | Consume exact verified selections and content-addressed admitted bytes | Current fixed selector selects the incompatible old command in section 9, not a general v0.2 policy. Its owner must supply a compatible reviewed selection; this PR cannot reinterpret it. | | Canonical authority snapshot/currentness and source visibility | Provider verifies canonical proof against coherent tenant reads and exact source/batch provenance | G2 must supply exact bindings; G3 must identify how existing sources prove every required watermark/visibility fact. A SQL snapshot label does not fill this gap. | +| Rule-selected CP2 read-qualification evidence | The read owner's closed attempt supplies immutable proof values/refs or explicit missing/invalid observations; the typed reader resolves referenced governed evidence in the bound snapshot. The provider evaluates `EP_CP2_READ_QUALIFICATION_V0_2` and records individual evidence dispositions before ALLOW. | The separately owned read/evidence producer owes real, same-context inputs before evaluation. Its exact schema/source eligibility and policy bytes remain G2; factory/transport/order are G3. No existing table, CP2 public-result implementation or PR #34 writer is presumed to supply them. | | Public result/read qualification and source history | Consume exact admitted evidence/history semantics where the selected closure requires them; the provider does not classify public history or release traces | CP2A-DEP01 and #32's completeness/historical-admission proof remain open; #34's proposed writer is not admitted by this plan. Required retention and disclosure bindings also remain real owner dependencies. | For time, follow PR #11 section 18.2 precisely: principal-resolution/session @@ -441,7 +469,10 @@ simple plan avoids depending on an unproven authority search index: removed to make a set look complete. 5. From this coherent capture derive the complete rule-selected resource, principal/representation/CP3, role/grant/delegation/sharing, revocation, - condition/evidence/purpose and sovereignty inputs. Include all facts + condition/evidence/purpose and sovereignty inputs, including the referenced + evidence for the selected action-level read-qualification profile. For + RECEIVE_READ_DATA, bind those evidence reads to its closed read-attempt + observation; neither source replaces policy verification. Include all facts required by rejected-path diagnostics and the relevant-state projection, plus exact absence and complete-set claims, not just the winning path. 6. Verify every source's required snapshot visibility/currentness proof. @@ -499,8 +530,10 @@ authority observation and protected effect or buffered retrieval/coverage share the required snapshot/protection context. Merely running the SELECT twice cannot prove continuity. Loss of that proof prevents consumption or disclosure. The provider reports its complete authority footprint; the read -consumer owns payload coverage, qualification, receipt/evidence persistence -and release, including the additional obligations introduced by its retrieval. +consumer owns payload coverage, result qualification, receipt/evidence +persistence and release, including the additional obligations introduced by +its retrieval. That does not move evaluation of rule-bound qualification +evidence out of this provider or let result qualification repair missing authority. ### Deferred human-interface history @@ -588,6 +621,34 @@ overlay that can turn an incomplete authorization trace into a final decision. Output planning, redaction, retention custody and transport remain with their own boundaries; ALLOW does not itself disclose data. +### Rule-bound action-level evidence + +The verified selected rule supplies `evidenceRequirementPolicyRefs`; code does +not choose an evidence policy. PR #11 sections 7.7–7.8 bind +`ASSERT_OPERATION_CLAIM` to `EP_NONE` and `RECEIVE_READ_DATA` to +`EP_CP2_READ_QUALIFICATION_V0_2`. `EP_NONE` is an explicit empty action-level +requirement, not missing policy and not a waiver of source evidence groups. +Every selected action-level policy and every source-path evidence requirement +must pass cumulatively under canonical section 12, including delegated and +SharingGrant paths. One sufficient grant cannot replace the read evidence. + +This provider evaluates the read profile before preparing ALLOW. It verifies +the exact eligible evidence, intent/target/scope/tenant/sovereignty/purpose +bindings, time and state, records individual evidence dispositions, and carries +the necessary snapshot/guard obligations into its handoff. An otherwise valid +admitted actual read with the required qualification evidence absent yields +canonical DENY, including the agent-read case in PR #11 section 22; preflight +posture or later result qualification cannot bypass that requirement. Other +invalid or unsupported evidence follows its exact canonical disposition, not +a newly invented reason or an indiscriminate infrastructure exception. + +Missing package/profile bindings still block admission/readiness; malformed +ingress does not become fabricated decision evidence. The read/evidence owner +produces the proof inputs described in section 6 and the read consumer owns +result qualification/redaction/coverage and release. Neither produces authority +merely by qualifying a result. No new producer, release order or canonical +contract is implemented or approved by this clarification. + ### Deterministic outcome and evidence Implement PR #11 section 15 exactly: evaluate independent global checks under @@ -749,13 +810,18 @@ For the future NOT_REQUIRED operation-claim consumer: disclosure policy. Full internal traces are not exposed by this provider. The governed-read consumer uses its own complete buffered-read protocol: -coherent authorization and retrieval, full result-coverage/redaction/qualification, -exact buffered payload and proof posture, atomic decision/consumption/read-evidence +coherent authorization and retrieval, full result coverage, redaction and +result qualification, exact buffered payload and proof posture, atomic decision/consumption/read-evidence and receipt persistence, then permitted release. PR #26 is explicitly write-only and cannot stand in for that protocol. This provider neither retrieves a public payload nor persists its receipt or authorizes release on the strength of a prepared ALLOW alone. +That result-qualification ownership does not include this provider's check of +the rule-bound qualification evidence in section 7. Required proof must be +available to final evaluation in the admitted same-snapshot protocol; a later +consumer check cannot retrospectively make an incomplete ALLOW valid. + Human-finalization runtime flows and the provider's corresponding handshake remain deferred under #175. Their canonical obligations and revision 6 design are preserved, not verified by this delivery. @@ -832,7 +898,7 @@ are retained design obligations, not current executable cases or passing tests. | AUTH-003: identity, representation and CP3 are independently proven | Actor/path resolver | Organization without natural-person proof, sponsor without authority, missing CP3 snapshot, and AI-metadata omission/retry never manufacture an eligible path. | | AUTH-004: target, typed input, effect subject and scope are distinct | Tenant resource reader and rule interpreter | Use a wrong-kind/foreign/missing target with a valid local scope, stale revision, or unproven prospective absence; no unproved eligibility. | | AUTH-005: one independently sufficient source path | Role/grant/delegation evaluator | Role anchored to Farm A plus grant for Farm B, revoked delegation source, or two individually insufficient grants cannot authorize Farm B. | -| AUTH-006: every applicable closed constraint is evaluated | Rule/path constraint evaluation | Unsupported non-empty condition, wrong exact purpose/family token or unresolved required evidence cannot be ignored. | +| AUTH-006: every applicable closed constraint is evaluated | Rule/path and action-level evidence-policy evaluation | Unsupported non-empty condition, wrong exact purpose/family token or unresolved required evidence cannot be ignored. With valid ingress, current globals and an otherwise sufficient read path, omit the rule-selected CP2 qualification evidence: canonical DENY, never prepared ALLOW. A later result qualification, preflight posture or caller flag cannot repair it. Wrong-context or ineligible proof follows the exact canonical failure disposition. | | AUTH-007: complete current facts, revocation and rule ceilings | Typed snapshot/read footprint | Omit a revocation, truncate a grant set, widen inheritance to lineage, or present an incomplete watermark; no complete-proof claim. | | AUTH-008: sharing is composed before final authorization | Same evaluator's read-sharing branch | A scoped grant without the required sharing basis cannot ALLOW RECEIVE_READ_DATA; a later overlay is not a substitute. | | AUTH-009: deterministic canonical aggregation and selected evidence | Outcome/path/reason selection | Reverse database order; combine global failures, unrelated revoked paths and sufficient paths; result, chosen basis and reason order follow the canonical lattice. | @@ -881,11 +947,21 @@ must additionally cover revocation/set changes between evaluation and commit, exclusive deadlines, duplicate consumption, persistence failure, committed refusal with lost response, and separately unknown evidence commits. -### Focused verification for the revision 7 selected interface +### Focused verification for the selected interface, with revision 8's B1 case These are planned cases under existing invariants, not new canonical rules or claims of executed tests: +- AUTH-006/008/010/013: through the real bound read attempt, use an otherwise + sufficient direct, role-targeted, delegated or SharingGrant path but omit + `EP_CP2_READ_QUALIFICATION_V0_2` evidence; each actual read is DENY, including + the software-agent case. Substitute wrong-tenant/intent/snapshot or ineligible + evidence, or an unbound later payload/consumer `qualified` flag: no ALLOW + bypass; inspect canonical dispositions, exact refs/digests and the footprint. + With the full eligible profile proof and every other requirement met, obtain + prepared ALLOW without owned persistence or release. `EP_NONE` on a claim + must not bypass required source evidence. These cases require the actual + G2/G3 producer/bindings; a mock qualified flag proves nothing. - AUTH-002/003/011: through the real runtime/UoW, substitute a frame from another tenant/attempt, a handler-constructed selection, a caller deadline, or a JWT cache/challenge expiry for required session proof. None becomes a @@ -916,7 +992,8 @@ claims of executed tests: write/read handoff; completeness verification fails. Missing proof of continuity between the authority observation and protected write or buffered read cannot be replaced by a context label. Actual race prevention, read - coverage, qualification, receipt and release still need their owners' tests. + coverage, result qualification, receipt and release still need their owners' + tests; rule-bound qualification-evidence verification remains provider-tested. - AUTH-001/018: cover every selected rule branch and read target/path, reject excluded actions and cross-role write/read frames, and isolate attempts. Consumer integration proves that an exact committed-write retry preserves @@ -926,9 +1003,9 @@ claims of executed tests: ## 11. Disposition of the existing nine-blocker review -This section preserves revisions 2–6 and their exact-head review history. Its +This section preserves revisions 2–7 and their exact-head review history. Its older section references and human-handshake language describe those revisions, -not first-release APIs or review of revision 7. The complete previous design is +not first-release APIs or review of revision 8. The complete previous design is retained at `725df163ddcd4f93b4675a3041724b1f59ab8151`. The revision 7 entry below records the new scope; prior findings are not silently erased or promoted to approval of this changed design. @@ -1033,11 +1110,33 @@ executable policy. This revision applies that scope to the existing #359 design: - account for all AUTH-001–019 and EXC-001–007 obligations without treating deferred execution as passed or weakening source-history completeness. -Revision 7 is REVIEW_PENDING. Review the changed scope, selected interface, -write/read handoff and applicability ledger at its exact head; earlier review -dispositions do not transfer. G2 canonical readiness, G3 real interfaces/size -and G4 fresh OFARM2 decision-card approval remain open. This is not an issued -decision card, reviewer sign-off or authorization to implement. +Revision 7 at `feffb585ec569c6aaa8b5d085e94583d1eb9aeca` received +[an initial zero-Blocker review](https://github.com/samovers/OFARM2/pull/359#pullrequestreview-5187397905) +and [a later B1 finding with F1/F2 follow-ups](https://github.com/samovers/OFARM2/pull/359#pullrequestreview-5187464763). +Both retained the two-action scope and open G2/G3/G4 gates. The later finding +requires the bounded correction below; the earlier disposition does not +override it or approve this new head. + +### Revision 8: B1 read-evidence ownership correction + +The user directed the bounded correction after reading both reviews. Sections +4–7 now identify the read rule's exact evidence profile, distinguish provider +evaluation from consumer result qualification, propose its closed input role +and retain the missing machine-binding/producer gates. Section 8 preserves +that split through handoff; AUTH-006 and its focused positive/negative cases +make missing or substituted proof testable without inventing an evidence source. + +F1's existing `AUTHORIZATION_TRACE` read-target coverage remains under G3-READ; +F2's reported facade experiments inform G3-SHAPE. Their unresolved implementation +work is not added to this PR. The revision-4 human-handshake correction and +review closure remain historical facts; the later scope defers that execution, +not its safeguards or past evidence. + +Revision 8 is REVIEW_PENDING, not reviewer sign-off or an implementation card. +Review only B1's ownership, input/evidence evaluation, affected failure/handoff +invariants and the follow-up records absent new evidence of a broader defect. +G2/G3 and later exact G4 approval remain open. No new canonical semantics, +evidence producer, runtime method, budget or workflow gate is created here. ## 12. Expected implementation areas and code excellence @@ -1092,9 +1191,15 @@ The same checker's physical-line counts and budgets are: | `kernel/application_runtime.py` | 221 / 230 | 9 | | application runtime group (runtime_config + application_runtime + deployment_identity) | 179 + 221 + 20 = 420 / 500 | 80 | -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. Moving work to another +F2 in the [later revision-7 review](https://github.com/samovers/OFARM2/pull/359#pullrequestreview-5187464763) +reports two untyped facade probes: 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. These are the reviewer's specific experiments, +not a universal minimum, a typed implementation estimate or an approved budget. +This revision does not reproduce or adopt the probe code. G3-SHAPE must measure +the actual typed partition and review both shape and size; no automatic budget +increase or relocation to hide growth is authorized. Moving work to another module does not alone solve the facade's exact shape or its zero headroom. Before Phase B, G3 must settle the exact typed provider entry, injected @@ -1181,10 +1286,19 @@ The remaining G3 work is bounded, not a request to restart canonical design: | Item | Required closure evidence | Boundary and sequencing | |---|---|---| | G3-INPUT | Exact mappings and real producers for principal/representation/CP3, required principal/session validity, closed write/read attempts and deadlines, and compatible selection; reject forged/mixed frames through production composition | Consume existing accepted producers where sufficient. Human-act capture is deferred, not a substitute for required current validity. Any new authentication/session, selection or transaction authority needs separately scoped work and user direction before edits; do not mint proof here. | -| G3-READ | Exact admitted schema/hash/extractor mapping, coherent SQL, complete source visibility/history/currentness and canonical snapshot proof, truthful global/path/infrastructure failure encoding, bounded representative workload, and continuity from authority observation to protected write or buffered read | Reader/projection implementation belongs here after G2. Missing storage, permission, source-history/snapshot authority or transaction protection belongs to its owner, not a database change hidden in the reader. | -| G3-HANDOFF | Actual write and governed-read interfaces covering every record/set/absence/external/time obligation and attempt-bound evidence, with independently usable provider completion tests | Settle with #178 and the separately owned governed-read design before approving provider code. Durable write coordination and read coverage/qualification/receipts/release stay with their owners. Required real producers must precede their use; later consumer delivery cannot excuse invented fixtures or a type-only prerequisite. | +| G3-READ | Exact admitted schema/hash/extractor mapping, coherent SQL, complete source visibility/history/currentness and canonical snapshot proof, truthful global/path/infrastructure failure encoding, bounded representative workload, and continuity from authority observation to protected write or buffered read; include the exact rule-bound qualification-evidence source/producer and F1's full read-target coverage below | Reader/projection and evidence evaluation belong here after G2. Missing storage, permission, source-history/snapshot authority, qualification-evidence producer or transaction protection belongs to its owner, not a hidden provider capability. | +| G3-HANDOFF | Actual write and governed-read interfaces covering every record/set/absence/external/time obligation and attempt-bound evidence, with independently usable provider completion tests; prove read-qualification inputs reach final evaluation in the required context/order | Settle with #178 and the separately owned governed-read design before approving provider code. Durable write coordination and read coverage/result qualification/receipts/release stay with their owners; rule-bound qualification-evidence evaluation stays with this provider. Required real producers must precede their use; later consumer delivery cannot excuse invented fixtures or a type-only prerequisite. | | G3-SHAPE | Review the exact facade proposal and architecture edges in section 12, then a measured final partition/size and focused production-path test plan against the admitted bindings | One authorization boundary. Existing zero headroom is explicit; no automatic checker relaxation or budget increase. | +F1 is recorded under G3-READ, not a narrowed release scope: full +`RP_READ_TARGET_ONE` coverage includes an existing `AUTHORIZATION_TRACE` target +and a separate `RECEIVE_READ_DATA` decision for that read. An eligible trace-read +case and a missing-authority/evidence refusal belong in the eventual AUTH-001/006 +coverage. This does not expose the provider's own internal output, activate a +trace endpoint or waive redaction/qualification/release controls. F2 remains +under G3-SHAPE with the qualified probe measurements in section 12; no runtime +or checker change is made to close either follow-up in this design correction. + The #353 -> #178 -> #176 sequence describes capability completion, not the separate governed-read protocol's ownership. It cannot postpone an indispensable write/read input producer until after its consumer. If G3 requires an authority @@ -1212,11 +1326,11 @@ disaster/store-loss recovery. The old command successor is a compatibility gate for its consumer, not a reason to amend approved canonical PR #26. No new Delivery issue is created in this revision. -Review disposition: revision 7 is REVIEW_PENDING. G1 is applied; G2/G3 and the +Review disposition: revision 8 is REVIEW_PENDING. G1 is applied; G2/G3 and the later G4 card/approval remain outstanding. Previous reviews stay attached to their exact historical heads and are not transferred to this revision. Review -the changed release scope and affected interface/invariants; do not restart -unaffected findings without new evidence. Exact private names and test-file +the bounded B1 correction, affected interface/invariants and follow-up records; +do not restart unaffected findings without new evidence. Exact private names and test-file partitioning are Preferences only after the substantive interface is settled. @@ -1247,8 +1361,8 @@ transaction coordination, protected effects, selection authority and temporal persistence with their own owners. No cross-boundary implementation is hidden in this plan. -What is next: review revision 7's first-release scope, single evaluation -interface, write/read handoff and AUTH/EXC applicability ledger at its new head; +What is next: review revision 8's read-qualification evidence ownership, closed +input role, failure/handoff cases and F1/F2 records at its new head; close the listed G2/G3 prerequisites with their existing owners before presenting the fresh #359 decision card. No runtime edits, new Delivery issue, baseline or merge are authorized by this design revision. From 7de8a2c4cf6eb1f293560af67e69565122c42f25 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Samo=20A=C4=8Dko?= Date: Sat, 12 Sep 2026 20:51:21 +0200 Subject: [PATCH 8/8] Require resolved read evidence and canonical policy failures 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. --- ...ority_Action_Matrix_Evaluation_RFC_v0_1.md | 88 +++++++++++++------ 1 file changed, 62 insertions(+), 26 deletions(-) diff --git a/docs/rfcs/OFARM_Runtime_Authority_Action_Matrix_Evaluation_RFC_v0_1.md b/docs/rfcs/OFARM_Runtime_Authority_Action_Matrix_Evaluation_RFC_v0_1.md index fc259dd6..d59f68f2 100644 --- a/docs/rfcs/OFARM_Runtime_Authority_Action_Matrix_Evaluation_RFC_v0_1.md +++ b/docs/rfcs/OFARM_Runtime_Authority_Action_Matrix_Evaluation_RFC_v0_1.md @@ -2,9 +2,10 @@ Date: 2026-09-12 -Design revision: 8 — bounded read-qualification evidence correction. This retains -revision 7's complete two-action scope and makes the provider's rule-bound -evidence check distinct from the consumer's result qualification. It consumes +Design revision: 9 — bounded evidence-reference and policy-failure correction. +This retains revision 7's complete two-action scope and revision 8's provider/ +consumer evidence-ownership split. Required evidence is resolved, not accepted +as proof values from an attempt frame. It consumes renewed canonical Phase A approval at PR #11 head `4494924998183fe3fa7bc1b63b76a85893335044` and the aligned #353 scope. It proposes complete evaluation of ASSERT_OPERATION_CLAIM and RECEIVE_READ_DATA through @@ -23,10 +24,12 @@ law changes. Revision 7 at `feffb585ec569c6aaa8b5d085e94583d1eb9aeca` has two exact-head reviews; the later review identified B1's read-evidence ownership ambiguity. -Section 11 records this correction and both non-blocking follow-ups. Prior -reviews do not approve this new head. +Revision 8 at `f97fe8f73d956d2dd6c0f82f133d6800b71055fe` corrected that ownership; +its focused review identified B2's proof-carrier gap and F3's policy-failure +ambiguity. Section 11 records the bounded corrections and prior follow-up +dispositions. Prior reviews do not approve this new head. -Status: revision 8 is REVIEW_PENDING; G1 first-release scope alignment applied; +Status: revision 9 is REVIEW_PENDING; G1 first-release scope alignment applied; G2 canonical readiness, including source-history closure, and G3 implementation prerequisites remain open. The sufficiency of two executable actions is unproved. No OFARM2 semantic approval, runtime implementation, baseline @@ -400,12 +403,15 @@ remain G2/G3 work. The proposed carrier for read-qualification proof is the closed governed-read `attempt` role, supplied by its separately owned read/evidence producer before -final authorization evaluation. It carries immutable proof values or exact +final authorization evaluation. It carries exact immutable revision/digest references and truthful missing/invalid observations, not a -caller-set `qualified` flag or an asserted prior ALLOW. Referenced governed -records are resolved through the provider's typed tenant reader. The provider -verifies every supplied fact under the selected evidence policy, its exact -effect-intent binding and the same governed snapshot/protection context. +caller-set `qualified` flag 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. This is a local input-role proposal, not a new canonical schema, evidence kind or producer implementation. G2 must supply the exact active/current policy, @@ -426,7 +432,7 @@ proof observation does not itself grant read authority or permission to release. | Write or read attempt, deadline, snapshot and protection | Same bound connection supplies tenant/full-transaction identity; each owning protocol supplies its admitted time/guard context | Current UoW has no complete write/read attempt/deadline/guard factories. Tenant challenge time, token lifetime, batch allocation and `bound_at` are not substitutes. Settle #178's write interface and the separately owned governed-read interface before their respective use. | | Command/action and authorization policy | Consume exact verified selections and content-addressed admitted bytes | Current fixed selector selects the incompatible old command in section 9, not a general v0.2 policy. Its owner must supply a compatible reviewed selection; this PR cannot reinterpret it. | | Canonical authority snapshot/currentness and source visibility | Provider verifies canonical proof against coherent tenant reads and exact source/batch provenance | G2 must supply exact bindings; G3 must identify how existing sources prove every required watermark/visibility fact. A SQL snapshot label does not fill this gap. | -| Rule-selected CP2 read-qualification evidence | The read owner's closed attempt supplies immutable proof values/refs or explicit missing/invalid observations; the typed reader resolves referenced governed evidence in the bound snapshot. The provider evaluates `EP_CP2_READ_QUALIFICATION_V0_2` and records individual evidence dispositions before ALLOW. | The separately owned read/evidence producer owes real, same-context inputs before evaluation. Its exact schema/source eligibility and policy bytes remain G2; factory/transport/order are G3. No existing table, CP2 public-result implementation or PR #34 writer is presumed to supply them. | +| Rule-selected CP2 read-qualification evidence | The read owner's closed attempt supplies exact immutable revision/digest references or explicit missing/invalid observations, never authoritative proof values. The typed reader resolves every required evidence reference in the bound snapshot; the provider applies canonical section 12.5 eligibility and `EP_CP2_READ_QUALIFICATION_V0_2`, recording individual evidence dispositions before ALLOW. | The separately owned read/evidence producer owes real, same-context inputs before evaluation. Its exact schema/source eligibility and policy bytes remain G2; factory/transport/order are G3. No existing table, CP2 public-result implementation or PR #34 writer is presumed to supply them. | | Public result/read qualification and source history | Consume exact admitted evidence/history semantics where the selected closure requires them; the provider does not classify public history or release traces | CP2A-DEP01 and #32's completeness/historical-admission proof remain open; #34's proposed writer is not admitted by this plan. Required retention and disclosure bindings also remain real owner dependencies. | For time, follow PR #11 section 18.2 precisely: principal-resolution/session @@ -642,8 +648,13 @@ posture or later result qualification cannot bypass that requirement. Other invalid or unsupported evidence follows its exact canonical disposition, not a newly invented reason or an indiscriminate infrastructure exception. -Missing package/profile bindings still block admission/readiness; malformed -ingress does not become fabricated decision evidence. The read/evidence owner +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 canonical `UNSUPPORTED_EVIDENCE_POLICY` +(default `REQUIRE_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. The read/evidence owner produces the proof inputs described in section 6 and the read consumer owns result qualification/redaction/coverage and release. Neither produces authority merely by qualifying a result. No new producer, release order or canonical @@ -947,7 +958,7 @@ must additionally cover revocation/set changes between evaluation and commit, exclusive deadlines, duplicate consumption, persistence failure, committed refusal with lost response, and separately unknown evidence commits. -### Focused verification for the selected interface, with revision 8's B1 case +### Focused verification for the selected interface, including B1/B2 and F3 These are planned cases under existing invariants, not new canonical rules or claims of executed tests: @@ -962,6 +973,14 @@ claims of executed tests: prepared ALLOW without owned persistence or release. `EP_NONE` on a claim must not bypass required source evidence. These cases require the actual G2/G3 producer/bindings; a mock qualified flag proves nothing. +- AUTH-002/006/009/010/013: put proof values in an owner-issued read frame + without resolvable exact evidence references; they cannot satisfy the policy. + The positive case above must use evidence resolved in the bound snapshot. + Contrast invalid package admission (no decision) with an admitted evaluation + whose read evidence policy is inactive or its exact revision unretrievable: + with all other checks satisfied, require `UNSUPPORTED_EVIDENCE_POLICY` / + `REQUIRE_REVIEW` and individual evidence dispositions, not an ingress refusal. + Combined failures retain canonical aggregation, including global DENY precedence. - AUTH-002/003/011: through the real runtime/UoW, substitute a frame from another tenant/attempt, a handler-constructed selection, a caller deadline, or a JWT cache/challenge expiry for required session proof. None becomes a @@ -1003,9 +1022,9 @@ claims of executed tests: ## 11. Disposition of the existing nine-blocker review -This section preserves revisions 2–7 and their exact-head review history. Its +This section preserves revisions 2–8 and their exact-head review history. Its older section references and human-handshake language describe those revisions, -not first-release APIs or review of revision 8. The complete previous design is +not first-release APIs or review of revision 9. The complete previous design is retained at `725df163ddcd4f93b4675a3041724b1f59ab8151`. The revision 7 entry below records the new scope; prior findings are not silently erased or promoted to approval of this changed design. @@ -1132,11 +1151,28 @@ work is not added to this PR. The revision-4 human-handshake correction and review closure remain historical facts; the later scope defers that execution, not its safeguards or past evidence. -Revision 8 is REVIEW_PENDING, not reviewer sign-off or an implementation card. -Review only B1's ownership, input/evidence evaluation, affected failure/handoff -invariants and the follow-up records absent new evidence of a broader defect. -G2/G3 and later exact G4 approval remain open. No new canonical semantics, -evidence producer, runtime method, budget or workflow gate is created here. +The [focused revision 8 review](https://github.com/samovers/OFARM2/pull/359#pullrequestreview-5187572304) +at `f97fe8f73d956d2dd6c0f82f133d6800b71055fe` accepted the ownership correction +and F1/F2 records, while reporting B2 on the direct-value proof carrier and F3 +on the package-versus-evidence-policy failure wording. Accepting those records +did not close the underlying G3 work or approve implementation. + +### Revision 9: B2 evidence resolution and F3 failure distinction + +The user directed these bounded design corrections after reading that review. +Section 6 removes the direct-value carrier mode: required evidence references +must resolve through the provider's typed tenant reader in the bound snapshot +and satisfy canonical section 12.5. The attempt frame supplies no authoritative +evidence fact. Section 7 distinguishes invalid package admission from an +unavailable/inactive evidence policy during an admitted evaluation, preserving +its canonical reason, default outcome, evidence disposition and aggregation. +The focused verification above covers both distinctions under existing AUTH +invariants; these are planned cases, not executed runtime evidence. + +Revision 9 is REVIEW_PENDING. Review only B2/F3 and affected invariants absent +new evidence of a broader defect. G2/G3 and later exact G4 approval remain open. +No canonical semantics, evidence producer, runtime method, budget or workflow +gate is changed by this revision. ## 12. Expected implementation areas and code excellence @@ -1326,10 +1362,10 @@ disaster/store-loss recovery. The old command successor is a compatibility gate for its consumer, not a reason to amend approved canonical PR #26. No new Delivery issue is created in this revision. -Review disposition: revision 8 is REVIEW_PENDING. G1 is applied; G2/G3 and the +Review disposition: revision 9 is REVIEW_PENDING. G1 is applied; G2/G3 and the later G4 card/approval remain outstanding. Previous reviews stay attached to their exact historical heads and are not transferred to this revision. Review -the bounded B1 correction, affected interface/invariants and follow-up records; +the bounded B2/F3 corrections and affected evidence/failure invariants; do not restart unaffected findings without new evidence. Exact private names and test-file partitioning are Preferences only after the substantive interface is settled. @@ -1361,8 +1397,8 @@ transaction coordination, protected effects, selection authority and temporal persistence with their own owners. No cross-boundary implementation is hidden in this plan. -What is next: review revision 8's read-qualification evidence ownership, closed -input role, failure/handoff cases and F1/F2 records at its new head; +What is next: focused review of revision 9's B2 evidence-reference resolution +and F3 package-versus-policy failure distinction at its new head; close the listed G2/G3 prerequisites with their existing owners before presenting the fresh #359 decision card. No runtime edits, new Delivery issue, baseline or merge are authorized by this design revision.