RFC candidate: executable authorization evidence v0.2 - #11
Conversation
samovers
left a comment
samovers
left a comment
There was a problem hiding this comment.
Review disposition: Request changes
This PR is correctly scoped as a draft, one-file, non-authoritative Phase A candidate: no active law or machine contract is changed, and both repository workflows pass. The proposed semantic approval card is not ready for approval, however. The document closes several real v0.1 gaps but introduces seven executable gaps that could produce false or non-deterministic authorization decisions.
1. Blocker — targetTime permits backdated authorization
Sections 9–14 evaluate role validity, grant validity, delegation source authority, evidence eligibility, sharing grants, and revocations at caller-provided targetTime. Section 17.4 also classifies the full target time as a caller-provided request fact.
A caller whose authority was revoked at 12:00 could therefore request a protected effect at 13:00 while supplying a targetTime of 11:00; the proposed algorithm would evaluate the grant and revocation as if the current effect occurred before revocation.
That collapses materially distinct times. The active Constitution's temporal conformance law requires OFARM to preserve distinctions between occurrence, report, execution, assertion, review, materialization, and other governance-relevant times.
Required patch:
- Separate
subjectTimeorgovernedTargetTimefrom a trustedauthorizationEvaluatedAt. - Define an
effectTimeor transaction time for state-affecting actions. - Check current actor binding, grant validity, delegation, policy applicability, and revocation at the trusted authorization/effect time.
- Where historical authority matters, evaluate it as a second, action-specific condition rather than replacing current authority.
- Add a hostile case: authority is revoked, then a current request supplies a pre-revocation target time. The current effect must not
ALLOW.
No baseline rewrite is needed; the RFC should conform to existing temporal law.
2. Blocker — the decision is not bound to the exact protected effect, and the mandated ordering creates a race
The proposed request records action class, actor, target, purpose, and retrieval hints, but it does not bind the authorization decision to the complete operation-specific input. For example:
SHARE_GRANT_ACCESSdoes not bind the proposed grantee and exact rights;CONTEXT_INSTALL_PACKdoes not bind the exact pack release and installation parameters;ASSERT_COMPLIANCEdoes not bind the exact assertion body and evidence set.
Section 6.3 says human approval should bind “material decision inputs,” but the request/result/trace contract delta contains no general representation or digest for those inputs. An ALLOW could therefore be obtained for one operation and consumed for a materially different operation with the same action and target tuple.
Section 18 then requires the decision bundle to commit before the protected effect. That forces a time-of-check/time-of-use interval in which a grant can be revoked, the target can change, or the operation payload can be substituted. It also provides no decision expiry, single-use consumption, or mandatory revalidation immediately before the effect.
Required patch:
- Add an immutable
effectIntentSchemaRefandeffectIntentDigest, covering all authorization-relevant operation inputs. - Bind human approval to the same digest.
- Define
decisionValidUntiland either single-use consumption or explicit replay semantics. - For an internal governed write, commit the decision bundle and effect atomically in one serializable transaction; the invariant should be “no effect becomes externally visible without its committed decision evidence,” not “the decision must commit in an earlier transaction.”
- For external side effects, atomically commit the decision and an idempotent outbox/effect intent, then record dispatch completion or failure.
- Add hostile cases for payload substitution, replay, and revocation between evaluation and effect.
3. Blocker — “actor posture” is overloaded and conflicts with accepted CP3 semantics
Section 6 defines actor posture as one of:
HUMAN_ACCOUNTABLE_PARTYSPONSOR_BOUND_SOFTWARE_AGENTUNRESOLVED_ACTOR_POSTURE
Section 7 then uses the same term for a different dimension:
SPONSOR_BOUND_ALLOWEDHUMAN_FINAL_ACTION_REQUIREDDIRECT_SOFTWARE_ACTION_PROHIBITED
These are respectively an actor-resolution classification and an action/finalization policy. They must not share one semantic field.
The accepted OFARM_Agent_Actorship_and_Authority_RFC_v0_1.md already requires every software-agent action class to resolve to one of five exact action postures:
AGENT_ALLOWED_WITH_POLICY_CHECKAGENT_ALLOWED_WITH_PREFLIGHT_ONLYAGENT_ALLOWED_WITH_HUMAN_APPROVALHUMAN_ONLYPROHIBITED_FOR_AGENT
The candidate neither preserves these values nor defines an explicit replacement or mapping. In particular, it loses the preflight-only distinction and does not cleanly preserve the difference between HUMAN_ONLY and PROHIBITED_FOR_AGENT.
There is also an unresolved organization-representation seam. The prose correctly says that a natural person may act for a non-natural Party, but the proposed trace requires only one acting Party plus generic actor-resolution references. It does not require both the authenticated natural-person principal and the represented organization. Consequently, an organization-held grant cannot be compared deterministically without either treating the organization as the human or treating the natural person as the grant holder.
Required patch:
Model separate axes:
resolvedPrincipalKind: natural person, software agent, unresolved.authenticatedPrincipalRef.representedPartyRef, when acting for an organization.representationBasisRef.- The accepted five-state
AgentActionPosture, or an explicit governed CP3 v0.2 amendment. - A separate
humanFinalizationRequirement.
For software agents, also require the CP3 actorship/envelope, sponsor, and authority-snapshot references in the decision trace. The active AgentAuthorityEnvelope contract already treats authoritySnapshotRef as mandatory.
This change affects the eventual authorization RFC and action matrix and requires an explicit amendment or compatibility mapping for the accepted CP3 RFC; it cannot be presented as an action-matrix-only change.
4. Blocker — the algorithm requires delegation and evidence constraints that the proposed source contracts cannot encode
The matrix's delegation column contains prose values such as allowed, explicit/cautious, prohibited by default, and explicit only. These are not closed machine tokens. Section 10 then requires proof that “the source authority permitted delegation for this action,” but the proposed common AuthorityGrant v0.2 delta does not add a field that represents that permission. The current AuthorityGrant contract also has no delegability field.
Evidence has a parallel gap. Section 9 requires a direct AuthorityGrant path to pass evidence rules, and section 13 permits evidence requirements on sharing paths. Yet section 17.3 adds the requiredEvidenceRefs plus requiredEvidencePolicyRef pairing only to DelegationGrant v0.2. It does not say where a direct AuthorityGrant or SharingGrant's evidence requirement is stored, nor whether it instead comes from the action-policy rule. Different runtimes would have to invent that answer.
Required patch:
- Replace delegation prose with a closed action-rule ceiling, for example:
DELEGATION_ALLOWEDEXPLICIT_SOURCE_PERMISSION_REQUIREDDELEGATION_PROHIBITED
- Add explicit source-grant delegation permission, such as
delegableActionClassesor a closeddelegationPermission. - Define the intersection and precedence between the action-rule ceiling, source grant, and DelegationGrant.
- State exactly where evidence requirements originate: action rule, each authority-source record, or both.
- If source records may impose evidence, add the all-or-none evidence-policy pairing to every applicable v0.2 source family.
- Define intersection when both policy and source require evidence.
- Add hostile cases where the row permits delegation but the source does not, where the source permits it but the row prohibits it, and where a direct or sharing path has an unrepresentable evidence requirement.
5. Blocker — the target model cannot represent prospective creation and installation actions
Section 8.2 says target proof must establish that the named target already exists. The matrix nevertheless maps all three pack actions, including CONTEXT_INSTALL_PACK, to PACK_ACTIVATION. An activation generally cannot already exist before the install or activation action that creates it.
The same ambiguity appears with other creation actions. For OBSERVE_CREATE_OBSERVATION, either:
targetRefis the new observation, in which case the required existence proof is impossible; ortargetRefis the existing farm/field/crop-cycle resource, in which caseCANONICAL_TRUTHis an architectural layer classification rather than the governed object kind.
This would cause implementations to disagree over whether “target” means the pre-existing resource under authority, the object being created, or the resulting compiled/canonical artifact. The pack policy itself distinguishes an installable pack from a PackActivationSet, so using PACK_ACTIVATION as the sole target kind for installation is not a safe closure.
Required patch:
- Separate the existing
authorizationResourcefrom theeffectSubjector resulting artifact. - Define an explicit existence posture such as
EXISTING_REQUIREDversusPROSPECTIVE_TARGET_ALLOWED. - Distinguish at least
PACK_RELEASEorPACK_ARTIFACTfromPACK_ACTIVATION/PACK_ACTIVATION_SET. - Review the matrix row by row, especially creation actions and
ASSERT_COMPLIANCEtargets involving compiled outputs. - Add hostile cases for a prospective target, a wrong pack release, and an activation identifier substituted for the installed pack.
6. Blocker — mixed-path outcome and reason selection is not deterministic
Section 15.3 describes each outcome independently but does not define a total aggregation rule. Consider three evaluated paths:
- one is complete except for fresh human finalization;
- one contains an unsupported legacy condition;
- one is explicitly revoked.
The definitions simultaneously support REQUIRE_HUMAN_APPROVAL, REQUIRE_REVIEW, and a DENY reason. The RFC does not say which outcome wins.
The reason rule is also incomplete. Problems are sorted by “severity,” reason code, and reference, but no severity ordering is defined. Moreover, when one path allows and another is revoked, blindly selecting the highest-severity problem could give an ALLOW result whose primary reason is ACTIVE_REVOCATION, which is misleading and not a deterministic explanation of the selected path.
Required patch:
- Define a per-path disposition model.
- Define a total aggregation lattice across all evaluated paths.
- State whether unsupported semantics outrank a human-finalization path when no path allows.
- Define outcome-specific primary-reason selection.
- Publish a complete reason-priority table or numeric rank; “severity” cannot remain an undefined implementation choice.
- Add mixed-path conformance fixtures, not only single-failure fixtures.
7. Blocker — durable reconstructability is claimed but not guaranteed
The trace records references and dispositions, and the policy receives a SHA-256 digest. It does not require an immutable revision or content digest for each grant, role assignment, delegation, sharing grant, revocation, actor-resolution record, target/scope proof, evidence record, or evidence-eligibility policy used by the decision. It also does not require the exact policy bundle bytes to remain retrievable; section 16 explicitly avoids defining policy storage.
A logical reference that later resolves to modified or superseding content is not enough to reconstruct the original decision. Likewise, a “completeness-proven index” without a recorded snapshot, canonical-history position, or materialization watermark cannot later prove which revocations and grants were visible to the evaluator. This is especially important because accepted CP3 already requires a software-agent authority snapshot reference.
Required patch:
- Record an
authorityEvaluationSnapshotRef, canonical-history position, or governed materialization snapshot/watermark. - Bind every selected and rejected basis to an immutable revision/assertion reference, or include its content digest.
- Record the exact evidence-policy and actor-resolution revisions.
- Require durable content-addressed retrieval or equivalent retention for the policy bytes covered by
policyDigest. - Define the canonical decision-bundle digest algorithm, including field ordering and excluded fields.
- Add a hostile reconstruction case where the same logical source identifier later has a successor revision.
Required cleanup
The header says the candidate “Depends on” review of OFARM2 #353 and draft OFARM2 PR #359, while sections 23–24 and this PR body correctly state that canonical promotion is a prerequisite for those OFARM2 changes. Replace that header with something such as Triggered by review of and add an explicit Blocks relationship. The current wording reverses the dependency direction.
What should remain unchanged
The following parts are sound and should survive the patch:
- exact authority-family tokens and fail-closed unknown-token handling;
- exact purpose-token matching with explicit legacy migration;
- unsupported free-text conditions producing non-
ALLOW; - separation of target, scope, constraint-evidence, and sovereignty proof fields;
- role-anchor scope caps;
- prohibition on unioning partial grant paths;
- exact-artifact SharingGrant use only for
RECEIVE_READ_DATA; - separate draft, conformance, promotion, extraction, and implementation stages.
Smallest controlled authority impact
No 00_active_baseline/ rewrite is justified. The candidate should be amended to comply with existing temporal, authority, history, and pack law.
The eventual promoted change should be classified as:
- accepted RFC extension: authorization constraint and decision-evidence v0.2;
- accepted RFC amendment or explicit mapping: Agent Actorship/CP3 posture semantics;
- action-matrix update: exact v0.2 matrix;
- companion-policy implication: delegation/evidence-source semantics;
- machine-contract implication: AuthorityGrant, DelegationGrant, SharingGrant, AuthorizationDecisionRequest, Result, and Trace v0.2, plus any necessary agent-envelope compatibility contract;
- implementation/conformance implication: snapshot-bound evaluation, effect-intent binding, atomic effect protocol, mixed-path outcome tests, backdating tests, replay tests, and reconstruction tests.
Keep the PR in draft and do not approve the section 25 semantic card until these blockers are closed.
|
Revision
The dependency header is corrected to Scope remains one non-authoritative candidate document. No active law, accepted RFC, CP3 contract, schema, currentness, or runtime file changed. The full repository validation suite passes locally. Please re-review the expanded section 25 approval card; the PR remains draft. What is next: confirm whether the seven blockers are closed or identify the remaining semantic delta. |
samovers
left a comment
samovers
left a comment
There was a problem hiding this comment.
Re-review disposition: Request changes
Reviewed current head f7f8b6d3838deb61050d071c411261587f4edc4d. The PR remains a one-file, non-authoritative Phase A candidate and is still draft. The revision materially addresses the original seven blockers: backdated authorization, unbound effects, overloaded actor posture, unencodable delegation/evidence rules, prospective targets, mixed-path aggregation, and immutable reconstruction now have substantive proposed closures.
The approval card is still not ready. The expanded design introduces seven remaining executable gaps.
1. Blocker — the “exact” action rule is still incomplete, and the caller still selects the effect-intent schema
effectIntentSchemaRef remains a caller-provided request fact. The selected action rule does not pin an exact permitted schema reference and digest. Section 8 says an operation-specific schema must contain every authorization-relevant input, but there is no closed machine rule determining which schema is authoritative for each action. A caller could therefore supply a weaker schema that omits a grantee, destination, assertion body, pack parameter, or another field that should have been protected by effectIntentDigest. The runtime would either accept that weaker shape or reintroduce hidden action-specific validation outside the declared policy rule.
The action matrix has the same problem elsewhere:
decisionValidUntilis said to come from the selected rule, but no row contains an exact validity duration or function;- historical-authority checking is optional by action rule, but no row declares it;
- dispatch-current authority is optional by action rule, but no row declares it;
- action-rule evidence policies are allowed, but the table does not identify them;
- the pack rows list both
GOVERNED_SCOPEandPACK_REGISTRYin a singularauthorizationResourcecolumn without saying whether the values are alternatives or conjunctive requirements.
The last ambiguity is security-relevant. If the two pack resources are alternatives, authority over only the registry or only the farm scope may be enough. If they are conjunctive, the singular request and proof model cannot represent them.
Required patch:
- Each row must bind an immutable
effectIntentSchemaRefand schema digest, or a closed set of permitted schema revisions. - The caller may submit an intent instance, but may not choose a weaker governing schema.
- Replace singular ambiguous resources with named resource requirements, cardinality, and explicit
ALL_OF/ONE_OFsemantics. - Put every policy-derived field in the rule: validity, historical-authority posture, dispatch reauthorization posture, evidence policies, consumption mode, resource roles, and effect-intent schema.
- Add hostile cases for a caller-selected weaker schema and for satisfying only one of the pack action’s required resources.
2. Blocker — there is still no authorization protocol for governed reads, and PREFLIGHT_ONLY is being reinterpreted
The matrix includes RECEIVE_READ_DATA, marks it AGENT_ALLOWED_WITH_PREFLIGHT_ONLY, and gives it a prospective DATA_ACCESS effect. Section 18, however, defines protocols only for:
- internal governed writes;
- external side effects; and
- non-
ALLOWresponses.
It never defines how an allowed read is executed. There is no requirement that authorization and data retrieval use the same governed snapshot, that the returned bytes are bound to the authorized resource/query, that decision evidence commits before disclosure, or that streaming stops safely if persistence or qualification fails.
This is not a minor omission. CP2 requires public read payloads to carry qualification, problems, trace references, and next actions, and it explicitly treats preflight or dry-run as non-authoritative. The candidate instead defines AGENT_ALLOWED_WITH_PREFLIGHT_ONLY to mean that the actual action becomes permitted after preflight and qualification. Active CP3 fixes that posture token but does not give the candidate authority to silently change “preflight only” into “allowed after preflight.”
Required patch:
- Add an explicit governed-read protocol:
- evaluate authorization and retrieve the exact resource/query result from one governed snapshot;
- bind the resource revision, QuerySpecification/plan where applicable, redaction policy, qualification envelope, and returned payload digest;
- persist decision and consumption evidence before any protected bytes leave the trust boundary;
- define streaming and partial-response failure behavior;
- ensure persistence failure leaks no protected payload.
- Either map actual
RECEIVE_READ_DATAexecution toAGENT_ALLOWED_WITH_POLICY_CHECKplus mandatory CP2 qualification, or explicitly promote a CP3 amendment defining whyPREFLIGHT_ONLYpermits actual data disclosure. It cannot be labelled a no-change compatibility mapping as currently written.
3. Blocker — external dispatch can outlive the decision and authority without changing a watermark
Before external dispatch, the candidate reauthorizes when:
- the action rule requires dispatch-current authority; or
- a relevant revocation or policy watermark changed.
It does not require dispatch to occur before decisionValidUntil. It also does not unconditionally recheck time-based source validity, representation validity, approval expiry, or evidence freshness. A grant can naturally reach validUntil, an approval can expire, or evidence can become stale while every stored watermark remains unchanged. The dispatcher could then send the filing or external effect under an expired decision. The exact matrix does not contain the dispatch-current flag that supposedly controls this behavior.
Active authority law already requires final re-evaluation when a prepared action crosses a revocation boundary before final promotion. The same principle applies when an outbox entry has been prepared but the real filing or delivery has not yet occurred.
Required patch:
- Dispatch must never occur after
decisionValidUntil. - Dispatch must re-evaluate all clock-dependent constraints, even when no index watermark changed.
- Every externally dispatched action row must declare whether:
- outbox commitment is the governed final effect; or
- actual dispatch is the governed final effect and requires current authority.
- Formal filing should default to dispatch-current authorization unless stewards explicitly decide otherwise.
- Add a hostile case where the source grant expires naturally after outbox commitment with no watermark change.
4. Blocker — the human-approval lifecycle and machine contract remain undefined
A fresh human approval must bind the effect digest, policy digest, authority snapshot, Party, and decisionValidUntil. But the candidate does not define how such an approval is produced and later consumed:
- the first evaluation without approval commits
REQUIRE_HUMAN_APPROVAL; - a later final evaluation will normally use a newer authority snapshot and a newly computed validity window;
- an approval bound to the first snapshot therefore does not automatically match the second evaluation;
- the document does not say whether the approval is minted inside the final effect transaction, whether an earlier approval challenge remains valid across snapshots, or whether the entire operation must be repeated.
It also does not say whether an authenticated natural person directly performing an FA row satisfies the approval requirement through that same human act or requires a separate approval act or separate person.
The proposed contract family includes decisions, consumption, snapshots, and effect receipts, but names neither a new authorization-approval/challenge contract nor an existing governed contract adopted for this purpose. Merely carrying approval references is not enough to prove the fields, signer, scope, freshness, and lifecycle the RFC now requires.
Required patch:
- Define an
AuthorizationApprovalChallengeandAuthorizationHumanApproval, or explicitly adopt an existing contract that carries all required semantics. - Define the sequence:
- prepare and display the exact effect intent;
- record the authenticated human act;
- re-evaluate all current authority;
- bind the approval to the final snapshot and effect digest;
- consume approval and decision atomically with the effect.
- Define whether direct human invocation can satisfy
FRESH_HUMAN_APPROVAL_REQUIRED. - Define whether self-approval is permitted or a distinct approver is required by policy.
- Add hostile tests for snapshot change between challenge and approval, approval expiry, direct-human finalization, and approval replay.
5. Blocker — software-agent authoritySubjectPartyRef is not deterministically derivable from current CP3
The candidate injects one global authoritySubjectPartyRef before path evaluation and says it must be resolved from the active CP3 authority envelope. Current CP3 contracts do not carry that field. They carry a sponsor, action, target scope, authority snapshot, actorship basis, and optional authority/delegation references. The actorship binding likewise states that it is not an AuthorityGrant and does not identify one universal Party whose authority the agent inherits.
This matters because an agent may:
- hold authority through its own recognized Party/agent identity;
- act under an explicit delegation for another Party;
- have several candidate grants or delegations pointing to different Parties.
The valid authority subject can therefore be path-specific. Resolving one Party before evaluating the candidate paths either excludes legitimate paths or encourages an implementation to treat the sponsor as the authority subject. Active CP3 explicitly says sponsor identity does not itself grant authority and delegation must not be silent.
Required patch:
- Define a closed authority-subject basis, for example:
AGENT_PARTY_DIRECT_GRANT;REPRESENTED_PARTY_EXPLICIT_DELEGATION;- another explicitly governed representation basis.
- Bind the authority subject to an immutable actorship/grant/delegation revision.
- Evaluate it per candidate path when multiple authority subjects are possible.
- Do not derive it from sponsor identity.
- If the CP3 envelope must carry a new authority-subject field, acknowledge that as a CP3 contract version or stacked RFC change rather than claiming that current CP3 contracts remain sufficient.
6. Blocker — an invalid request cannot produce the validated refusal bundle the RFC requires
The reason table classifies REQUEST_SCHEMA_INVALID and EFFECT_INTENT_SCHEMA_INVALID as DENY. Global-precondition processing occurs before path evaluation. Section 18.4 then requires every DENY to commit a request/result/trace bundle, while section 18.5 defines the bundle digest over the complete validated request, result, and trace records.
Those rules cannot all be true. A schema-invalid request cannot simultaneously be a validated AuthorizationDecisionRequest v0.2 inside the durable bundle. Persisting it as though valid would make the decision evidence false; refusing to persist it would violate the stated refusal rule.
Required patch:
Choose one explicit model:
- Treat parse/schema failures as ingress/runtime refusals outside
AuthorizationDecisionOutcome; or - add an
AuthorizationRequestRejection/AuthorizationAttemptenvelope carrying:- raw-input digest;
- claimed schema;
- validation failures;
- trusted receipt time;
- principal/session context where available;
- no claim that the invalid payload is an AuthorizationDecisionRequest.
Only a schema-valid request should enter the authorization decision bundle and outcome lattice.
7. Blocker — the decision-bundle digest exclusion is not exact and permits name-based exclusion injection
Section 18.5 excludes the member named decisionBundleDigest “wherever it occurs.” That is not an exact canonical projection. It can be implemented as recursive deletion by property name, which would exclude any nested field carrying the same name—including a caller-controlled or embedded field—from the integrity digest. Two implementations could also disagree over whether “wherever” means only the top-level result/trace fields or every nested occurrence.
Required patch:
- Specify the exact JSON Pointer paths excluded from the digest, for example:
/result/decisionBundleDigest;/trace/decisionBundleDigest;- any other individually enumerated schema location.
- Prohibit
decisionBundleDigestat all other schema locations, or ensure those occurrences remain hashed. - Add a hostile fixture with a nested field of the same name and prove it cannot be altered without changing the bundle digest.
- Define behavior when an expected exclusion pointer is absent or duplicated.
What the revision now gets right
The following parts are now substantially sound and should remain:
- caller
subjectTimecannot restore revoked current authority; - current and historical authority checks are separated;
- effect intent uses JCS/SHA-256 and is bound to approvals and decisions;
- internal governed writes use one serializable decision/effect transaction;
- direct, role, delegated, and sharing paths remain separate;
- delegation uses closed action-rule ceilings and explicit source permissions;
- action-rule and source evidence requirements are cumulative;
- prospective effect subjects are separated from existing authorization resources;
- path dispositions and global aggregation are deterministic;
- immutable source revisions, policy bytes, and authority snapshots support reconstruction;
- purpose matching, unsupported legacy conditions, typed proof separation, and no partial-path unioning remain fail-closed.
Smallest controlled patch
No active-baseline rewrite is justified. Keep the change in this candidate document and revise the future authority surface as:
- accepted RFC extension: complete action-rule fields, read protocol, approval lifecycle, ingress rejection, dispatch boundary, and digest projection;
- CP3 implication: either a true compatibility mapping or an explicitly stacked semantic/contract amendment for
PREFLIGHT_ONLYand software-agent authority-subject resolution; - machine-contract implication: effect-intent schemas, composite resource requirements, human approval/challenge, rejected-request evidence, governed read/effect receipt, and exact digest fields;
- implementation/conformance implication: weaker-schema substitution, composite-resource escape, unauthorized read disclosure, expired dispatch, approval snapshot rollover, ambiguous agent authority subject, malformed request, and nested digest-field hostile tests.
Keep PR #11 in draft and do not approve the expanded section 25 steward card yet.
|
Re-review requested on The candidate now closes all seven blockers from Local repository hygiene, generated-currentness, steward guardrails, What is next: review the current head while PR #11 remains draft. |
samovers
left a comment
samovers
left a comment
There was a problem hiding this comment.
Re-review disposition: Request changes
Reviewed current head c6b445679e2a30d31c36da1af3c0b8f9c930a614. PR #11 remains a draft, one-file, non-authoritative Phase A candidate. The revision materially closes the seven specific findings from the previous review: schema selection is now rule-owned, resources are composed explicitly, reads have a protocol, dispatch has expiry checks, approvals have challenge records, agent authority subjects are path-specific, malformed input is separated from authorization outcomes, and the digest projection uses exact JSON Pointers.
The semantic approval card is still not ready. Seven remaining issues affect executable authority, canonical-history integrity, or protected disclosure.
1. Blocker — formal filing has no executable actor at dispatch
OUTPUT_FILE_SUBMISSION_ASSEMBLY is classified as HUMAN_ONLY with DIRECT_HUMAN_ACTION_REQUIRED, while its external posture is DISPATCH_CURRENT_AUTHORITY_REQUIRED. Section 18.6 then requires the dispatcher to create a fresh authorization decision immediately before sending the filing. A software dispatcher cannot pass the same action’s HUMAN_ONLY rule. Treating the absent human as the direct principal would make the trace false; requiring the human to be interactively present for every send or retry is not defined. No separate governed transmission action exists in the twenty-row matrix.
This also exposes an unresolved distributed-systems boundary. A database transaction can authorize and reserve a dispatch attempt, but it cannot atomically prevent a revocation between that commit and the external network operation. The RFC must name the legal linearization point instead of implying exact current authority at an external receiver without receiver-supported fencing.
Required patch:
- Choose one explicit model:
- outbox commitment is the governed filing effect and later transport exercises no new authority; or
- external transmission is a separate governed action with its own action class and software-agent posture.
- If transmission remains a protected second action, create a stacked action-class/CP3 RFC rather than reusing the human-only filing action.
- Distinguish the human filing decision from mechanical delivery in the trace and receipts.
- Define whether revocation after the dispatch-reservation commit cancels the attempt, and how that is technically enforced.
- Add hostile cases for automated dispatch, retries after the human session ends, and revocation after reservation but before network send.
2. Blocker — SHARE_REVOKE_ACCESS models the wrong canonical effect
The matrix gives SHARE_REVOKE_ACCESS an existing SHARING_GRANT effect subject, while the resource policy requires only the shared artifact. The intent profile names an existing SharingGrant and revocation parameters, but the prospective record created by the action is not represented.
Active authority law says that a RevocationDecision ends or narrows an AuthorityGrant, DelegationGrant, or SharingGrant prospectively. The active machine contract likewise models revocation as a separate record referencing the affected grant. It does not rewrite the grant or create a successor SharingGrant revision.
The current effect-subject model could therefore lead an implementation to mutate or supersede the SharingGrant itself, losing the distinction between source authority and the governance decision that acts on it.
Required patch:
- Require the existing
SharingGrantand shared artifact as named authorization resources. - Make the prospective effect subject a
REVOCATION_DECISIONor an explicitly versioned v0.2 equivalent. - Preserve the affected SharingGrant unchanged and link the new decision through artifact family, immutable revision, mode, scope, and
effectiveFrom. - Review
CONTEXT_DEACTIVATE_PACKunder the same rule: deactivation must create an explicit governance/event consequence rather than silently rewriting an existing activation record.
3. Blocker — the candidate bypasses the existing EnforcementChain and leaves its new durable records outside event/commit law
The candidate introduces action rules, rejection records, snapshots, decisions, challenges, approvals, consumption records, effect receipts, read receipts, and dispatch evidence. It never assigns these records a primary event family, commit class, truth/evidence/runtime-log posture, correction rule, or current-state eligibility. Section 18.4 then describes applying a protected effect once authorization and persistence checks succeed.
Active OFARM law requires every governed event to have one primary event family and distinguishes event family from commit class. An evidence record does not create hard truth by itself, while governance decisions require valid authority, scope, and traceability.
The Platform baseline also makes authority only the second gate in an eight-gate EnforcementChain. Structural/semantic validation, pack applicability, evidence sufficiency, review/promotion, materialization, and publication/export gates remain independently mandatory where applicable. An authorization ALLOW cannot by itself authorize a pack activation, compliance promotion, attestation, filing, or authoritative materialization.
Required patch:
- State explicitly that
ALLOWis an authority-gate result, necessary but not sufficient for the governed effect. - Require
AuthorizationEffectReceiptandAuthorizationGovernedReadReceiptto bind the applicable validation, pack, evidence, review/promotion, materialization, publication, and qualification gate traces. - Add a classification matrix for every new durable contract:
- primary event family where it represents an event;
- commit class;
- canonical evidence versus runtime/security telemetry;
- append-only and correction/supersession behavior;
- whether it may contribute to current state.
- Separate the eventual authority-model RFC extension from the Platform runtime/effect-protocol extension, or explicitly classify both authorities. The serializable transaction, read gateway, outbox, dispatcher, and streaming rules are runtime law, not merely source-record semantics.
4. Blocker — the human-approval profile still does not define who may approve an agent action
The current FRESH_APPROVAL_SELF_5M_V0_2 profile fixes separation, challenge age, approval age, and single-use behavior. It does not define the exact approver-eligibility rule. Several rows permit a software agent with human approval—structural assertions, compliance assertions, and sharing grant/revocation—but a software agent has no natural-person “self.” The challenge carries “closed approver-eligibility requirements,” yet no current row or profile says whether the eligible human is the sponsor, grantor, represented Party’s controller, holder of the same authority, or holder of a separate approval authority.
Sponsor identity cannot fill this gap: active CP3 treats sponsorship as accountability evidence, not as an AuthorityGrant or silent delegation.
The snapshot rule also remains too strong to be executable reliably. The challenge and final authorityEvaluationSnapshotRef must be identical, while the snapshot includes a canonical-history position and multiple index watermarks. Persisting the challenge/approval or processing an unrelated event may advance that position even when every authority-relevant fact remains unchanged. The RFC does not define whether such records are excluded or whether snapshot equivalence is narrower than identifier equality.
Required patch:
- Define exact approver eligibility for each current approval profile.
- For agent actions, require an immutable relationship and authority basis tying the approving natural person to the path-specific authority subject and action. Sponsor status alone must remain insufficient.
- State whether approval requires the same action authority, a separate approval authority, or another named governed basis.
- Replace global snapshot-reference equality with an exact relevant-state equivalence rule, or define an authority-state digest covering only the principal, grants, delegation, revocation, resources, evidence, policy, and separation facts relevant to that challenge.
- Record both challenge and final snapshots plus the equivalence proof.
- Add hostile cases for an unrelated history change, a relevant grant change, an arbitrary sponsor approval, and an approval by a human with no applicable authority.
5. Blocker — the resource model remains semantically open and cannot express heterogeneous composite authority safely
The matrix now uses broad bucket kinds such as GOVERNED_SCOPE, GOVERNED_RECORD, SHARED_ARTIFACT, and DATA_RESOURCE. Their concrete membership is not enumerated in the semantic profile. A future schema could consequently decide whether a review action covers an assertion, an output, a grant, a pack record, or another object. That is model meaning, not a schema-detail decision. The target-kind ambiguity that v0.2 was supposed to close has therefore moved into undefined bucket expansion.
Composite pack policies also treat TARGET_SCOPE, PACK_REGISTRY, and one or more pack releases as authorization resources that one complete path must cover. Current AuthorityGrant law and contract shape are centered on one target scope, while RoleAssignment contains independently listed anchor scopes. The proposed v0.2 source delta adds role/kind/ref narrowing but does not define role-specific scopes or a multi-resource authority envelope. With NO_INHERIT, one ordinary grant/anchor path may be unable to cover a farm scope, deployment registry, and content-addressed pack release simultaneously. Conversely, an implementation that treats any one of them as sufficient would create a false allow.
A pack release also appears to be an integrity/input object, not necessarily an object over which the installer must hold authority. The current model does not distinguish these roles.
Required patch:
- Enumerate the closed concrete kinds represented by every bucket before semantic-profile approval.
- Give each resource role a closed semantic posture, such as:
AUTHORITY_TARGET;CONTROL_PLANE_AUTHORITY_TARGET;INTEGRITY_INPUT;EVIDENCE_INPUT.
- State exactly which roles must be covered by grant scope and RoleAssignment anchors.
- Define role-specific scope constraints in AuthorityGrant v0.2, or define an explicit governed
ALL_OFauthority-basis composition rather than relying on one single-scope grant. - Specify whether multiple anchor scopes may jointly cover a composite rule, and prevent accidental cross-path union.
- Do not let the later binding-schema PR invent the concrete kind sets or authority role semantics.
6. Blocker — duplicated request and effect-intent facts have no exact cross-binding rule
The request carries named authorization resources, effect subject, subjectTime, twin, and requestedUsePurpose. The operation-specific effect intents separately carry scope/resource revisions, proposed identifiers, subject or execution time, purpose, grantee, artifact, destination, and similar values. The RFC cryptographically binds both structures but does not define an exact equality or derivation map between duplicate facts.
This permits a confused-deputy implementation. For example:
- the request may prove authority over resource revision A while the effect intent acts on revision B;
requestedUsePurposemay contain an authorized token while the actual sharing/read intent names another purpose;- the request’s effect-subject identifier may differ from the identifier created by the committed intent;
- the scope or twin evaluated in the authority path may differ from the scope or twin written into the resulting assertion.
Both objects can be individually valid and digest-bound while disagreeing about what was authorized.
Required patch:
- Choose one authoritative location for every authorization-relevant fact and derive all mirrored fields from it; or
- publish a closed cross-binding matrix of request JSON Pointers to effect-intent JSON Pointers with exact equality/type rules.
- Cover at least resource roles/revisions, effect-subject kind/ref, scope, twin, subject time, purpose, grantee, rights, destination, pack release, assembly revision, and proposed result identifier.
- Treat any mismatch as an ingress rejection or closed denial before path selection.
- Record the cross-binding dispositions in the trace.
- Add hostile fixtures where each duplicate field is independently substituted.
7. Blocker — the protected-disclosure boundary remains incomplete
The governed-read protocol binds the query/plan, redaction policy, qualification envelope, and returned payload. It does not explicitly require every returned row, field, aggregate, lineage item, or metadata value to be covered by the selected AuthorityGrant/DelegationGrant/SharingGrant path. RP_DATA_RESOURCE_ONE authorizes one broad DATA_RESOURCE; a query can still produce records from multiple scopes or authority subjects. Recording what was returned is not the same as proving each returned item was authorized. CP2 qualification describes reliance and disclosure posture; it is not an independent source of receive/use authority.
The streaming rule also allows every precommitted chunk to be sent after the evidence commit. It does not state what happens when the decision expires or access is revoked midway through a long stream. Active authority law permits revocation to terminate future visibility and use. Future chunks are future disclosure, even when their digests were committed earlier.
Finally, non-ALLOW traces and ordered path diagnostics can themselves reveal resource existence, grant identifiers, role assignments, revocations, tenant relationships, or evidence posture to a caller who was denied access. The candidate persists the complete trace and then permits a typed response, but does not define caller-facing redaction or a separate authorization check for trace retrieval. CP2 explicitly requires trace retrieval to remain subject to authority and redaction.
Required patch:
- Require a result-set authorization proof showing that every unredacted returned item and field is covered by the selected path, purpose, scope, tenant, and sovereignty rules.
- Define aggregate/count/inference handling rather than treating metadata as automatically safe.
- Define the disclosure linearization point and revocation posture for buffered and streamed reads.
- Either recheck a principal-bound disclosure lease before each chunk or explicitly approve that manifest commitment completes the whole disclosure despite later revocation; the latter would need a clear authority-policy amendment.
- Separate the complete internal decision trace from the caller-facing result.
- Apply CP2 qualification and redaction to denial reasons and diagnostics.
- Require separate
RECEIVE_READ_DATAauthorization for full trace retrieval, with an explicit indication when details were redacted or withheld.
What should remain unchanged
The current revision’s following closures are substantively useful:
- rule-selected effect-intent schemas and immutable binding manifests;
- separate current and historical authority checks;
- path-specific software-agent authority subjects;
- exact purpose tokens and fail-closed legacy conditions;
- closed delegation ceilings and source permissions;
- cumulative action/source evidence requirements;
- prospective effect-subject handling;
- ingress rejection outside
AuthorizationDecisionOutcome; - deterministic path aggregation and ranked reasons;
- exact JSON Pointer digest projection;
- immutable snapshots and source revisions;
- serializable internal-write evidence ordering.
Smallest controlled authority impact
No broad rewrite of 00_active_baseline/ is justified. The follow-up should identify these affected authorities explicitly:
- Accepted RFC extension:
OFARM_Authority_Policy_Model_RFC_v0_1.mdand the Authority Action Matrix, covering exact resources, effect subjects, approval authority, purpose cross-binding, and external-action separation. - Companion-artifact implication:
OFARM_Event_Grammar_and_Commit_Matrix_v0_1.md, adding explicit classification for the new authorization/effect evidence families. - Platform runtime-law implication: the EnforcementChain and atomic write/read/outbox protocols. These cannot be presented as authorization-model semantics alone.
- CP3 or action-vocabulary implication: formal filing transport if actual dispatch remains a separate protected software action.
- Machine-contract implication: role-specific resource constraints, RevocationDecision effect binding, approval eligibility, result-set authorization proof, caller-facing redaction, and gate-trace receipts.
- Conformance implication: dispatch actor contradiction, prospective revocation record, other-gate bypass, arbitrary approver, snapshot-equivalence, bucket-kind expansion, heterogeneous pack scope, cross-field substitution, unauthorized query rows, midstream revocation, and denial-trace leakage.
Final disposition: keep PR #11 in draft and do not approve the section 25 steward card.
|
Re-review requested on The candidate now closes the seven blockers with a smaller boundary:
Overdesign removed: dispatch-current reauthorization, protected streaming, replay, universal fixed timers, and fourteen independent top-level contract families. Event Grammar, Platform/runtime integration, buffered disclosure, and filing transport remain explicit stacked trust boundaries. Only the existing candidate file changed. What is next: confirm whether the seven blockers are closed or identify the remaining semantic delta. |
samovers
left a comment
samovers
left a comment
There was a problem hiding this comment.
Re-review disposition: Request changes
Reviewed current head 044f189630bb648f8156861e7fe11e4064e1604d. The PR remains draft, mergeable, one-file, and non-authoritative. The latest commit substantially closes the seven findings from the previous review: filing now has a declared linearization point, sharing revocation creates a separate decision, authority ALLOW is separated from whole-chain success, approval eligibility is explicit, resource roles are closed, request facts derive from one effect intent, and protected reads are buffered with per-result coverage.
The steward card is still not ready for approval. Seven executable gaps remain.
1. Blocker — existing grants silently inherit future rule changes
The candidate makes every decision depend on an immutable action rule, schema, extractor, evidence profile, and policy digest. The proposed v0.2 source records, however, are not bound to the rule or policy bundle under which the grantor consented. They may optionally narrow by action, target, subject, profile ID, or twin, but there is no required issuedUnderPolicyDigest, authorizedRuleDigest, or governed compatibility posture.
That means an unchanged grant can silently acquire new powers when a later matrix revision:
- adds a target kind;
- changes an extractor;
- broadens an effect-intent schema;
- weakens evidence requirements;
- relaxes human finalization;
- expands delegation;
- changes historical-authority posture.
Binding the decision to the new rule proves which policy the evaluator used. It does not prove that the grantor authorized the broadened meaning of that action class.
Required patch:
- Every
AuthorityGrant v0.2,DelegationGrant v0.2, and applicableSharingGrant v0.2must bind the authorization policy/rule revision under which it was issued. - Define an exact compatibility law:
- automatic reuse is permitted only when the new rule is mechanically proven to be an equal or stricter subset;
- any widening requires a new grant, explicit migration, or governed reapproval.
- Profile identifiers alone are insufficient unless every authorization-relevant change necessarily creates a new profile identifier.
- Add hostile cases for target expansion, reduced evidence, relaxed human posture, and a changed extractor under an unchanged action class.
This affects the accepted Authority Policy RFC, Authority Source Record Closure RFC, action matrix, and v0.2 source contracts. It does not require a Constitution rewrite.
2. Blocker — RevocationDecision v0.1 cannot identify the immutable source revision being revoked
The candidate now treats grants as logical references with immutable revisions and requires traces to bind exact source revisions. It nevertheless leaves RevocationDecision v0.1 unchanged. That contract contains only revokesArtifactFamily and revokesArtifactRef; it has no target revision, content digest, grant-lineage posture, or rule saying whether termination applies to one revision, every revision of the logical identity, or future successors.
The authorization receipt cannot repair this omission. The canonical revocation decision itself must carry sufficient meaning for every future evaluator. Otherwise a successor grant revision could accidentally escape a revocation, or a revocation intended for one revision could terminate a later replacement.
Required patch:
Either:
- add
RevocationDecision v0.2with:- logical target reference;
- immutable target revision or digest;
- explicit lineage reach such as
EXACT_REVISION,LOGICAL_GRANT_ALL_REVISIONS, or another closed mode; - successor/replacement behavior; and
- deterministic lookup semantics;
or:
- explicitly establish that every grant identifier is a one-record immutable identity, can never have another revision, and every modification creates a different grant identifier.
The latter would need to be reconciled with the candidate’s repeated logical-reference/revision model. SHARE_REVOKE_ACCESS should not be approved until this is closed.
3. Blocker — the intent is cryptographically bound, but the resulting protected effect is not
The action rule binds an exact effect-intent schema and an authorization-view extractor. For internal writes, the runtime is then told to “apply the exact protected effect” and record the resulting immutable revision. There is no content-addressed protected-effect contract, output/result schema, intent-to-result projection, or postcondition proof establishing that the committed artifact actually equals the authorized intent.
Atomicity only proves that the decision and effect committed together. It does not prove semantic equality. A defective or hostile implementation could authorize:
- a read-only SharingGrant but commit broader rights;
- one pack successor set but persist another;
- a compliance assertion with body A but write body B;
- one review decision kind but create another.
The trace could still contain the original effectIntentDigest.
Required patch:
- Every state-affecting action rule must bind an immutable
protectedEffectContractRefand digest. - That contract must define:
- the resulting record/event schema;
- exact mappings from intent fields to resulting fields;
- permitted derived fields;
- forbidden widening;
- event/commit classification;
- postconditions and resulting-revision digest.
- Before commit, the runtime must validate the resulting artifact against that contract.
- The governed-effect receipt must record intent digest, result digest, contract digest, and each intent-to-result disposition.
- Any mismatch must abort the transaction.
- Add hostile cases for rights, destination, successor state, assertion body, and review-decision substitution.
This is an implementation/conformance implication and a protected-effect contract prerequisite, not a reason to put domain semantics inside the authorization evaluator.
4. Blocker — historical authority checks conflate the reporter with the performer
ASSERT_OPERATION_CLAIM and OPERATE_REPORT_EXECUTION use CURRENT_AND_SUBJECT_TIME. The same selected authority path is therefore checked both now and at the reported execution time. Their effect-intent profiles identify scope, operation/plan, report body, execution time, and evidence, but do not require the actual performing Party or agent and its historical authority basis.
This produces two incorrect outcomes:
- A farmer reporting work performed by a properly delegated contractor may fail because the farmer’s own reporting path did not exist at execution time.
- A reporter who held authority at that time may pass even though somebody else performed the work without authority.
OFARM already distinguishes an operation claim from an accepted executed intervention consequence. The report’s submitter, the alleged performer, and the authority to execute are separate facts.
Required patch:
- Separate:
- current authority to submit the claim/report;
- identity of the alleged performer;
- historical authority to execute, when policy requires it.
- Add
performedByPartyRefor software-agent actorship fields and immutable historical authority evidence to execution-report intents. - Replace the binary historical posture with a closed posture such as:
CURRENT_REPORT_AUTHORITY_ONLY;CURRENT_REPORT_PLUS_NAMED_PERFORMER_EXECUTION_AUTHORITY;CURRENT_REPORT_PLUS_HISTORICAL_REPORTER_AUTHORITY, if a real use case requires it.
- If an operation claim is allowed without verified execution authority, retain that uncertainty and let evidence/review/promotion gates decide whether it becomes an accepted execution consequence.
- Add cases for contractor execution reported by the farmer, retrospective correction by a successor operator, and an authorized reporter describing an unauthorized performer.
5. Blocker — post-commit transport can violate prospective sharing and data-sovereignty revocation
The candidate defines the authenticated human’s outbox commit as the filing action and allows byte-identical transport or retry after the human’s authority, approval, session, or decision expires. It also expressly says that a later sharing or authority revocation does not stop transport.
That may be defensible for the already-completed human filing decision. It is not automatically defensible for the later release of protected bytes across an external boundary. Active authority law says revocation may terminate future access or future use rights. The actual recipient obtains visibility when delivery occurs, not when an internal outbox row is committed.
The candidate currently collapses two questions:
- Was the human filing decision validly completed?
- May the transport subsystem still disclose these bytes to this destination now?
Required patch:
- Preserve outbox commit as the final
OUTPUT_FILE_SUBMISSION_ASSEMBLYact if stewards approve that meaning. - Add a distinct transport-release eligibility check covering:
- current data-sovereignty and disclosure policy;
- destination and recipient eligibility;
- current sharing or statutory disclosure basis;
- transport custody and endpoint binding;
- cancellation/hold status.
- This check must not impersonate the human or re-exercise filing authority.
- A policy may declare delivery irrevocable at outbox commitment, but only through an explicit, content-addressed regime-specific rule. It must not be the universal default.
- Remove the hostile-case assertion that every later sharing revocation permits transport.
- Add cases where filing authority remains historically valid but the recipient’s future access is revoked before delivery.
6. Blocker — hash-only display and payload evidence is not reconstructible
The approval challenge binds a digest of the human-visible representation, but it does not require immutable retention of the representation bytes, media type, locale, renderer, or rendering-policy revision. The governed-read receipt similarly binds a buffered-payload digest and coverage manifest, but does not require a retrievable payload reference or an exact serialization contract.
A SHA-256 digest proves equality only when somebody still has the candidate bytes. It does not reconstruct:
- what the human actually saw;
- the exact text, ordering, units, locale, omissions, or warnings;
- the exact payload sent to the reader.
Origin records and query plans are insufficient for byte-exact reconstruction when serializer, renderer, vocabulary labels, locale, or display policy can change.
Required patch:
- Approval evidence must bind a content-addressed human-visible representation reference, media type, renderer/version, locale/timezone, and digest.
- Read evidence must bind either:
- an encrypted/content-addressed retained payload reference for the governed retention period; or
- an immutable serialization contract plus every input needed for deterministic byte reconstruction.
- Where privacy policy forbids payload retention, state explicitly that evidence is digest-verifiable rather than reconstructible and do not claim stronger proof.
- Define retention, encryption, deletion, and redaction behavior without deleting the historical fact that disclosure occurred.
- Add hostile cases where renderer or serializer versions change after the decision.
7. Blocker — MINIMUM_DISCLOSURE_V0_2 conflicts with accepted CP2 result-qualification law
For DENY and REQUIRE_REVIEW, the candidate permits only the public code REQUEST_NOT_COMPLETED. It withholds the authorization outcome, reliance posture, reason category, and indication that details were redacted.
Accepted CP2 requires public/state-affecting/high-consequence results to expose material qualification, including permission/redaction posture, data-absence reason, blocked-use classes, trace posture, and safe display hints. It also requires registered reason codes that distinguish permission-limited, stale, disputed, unresolved, evidence-insufficient, redacted, and blocked cases. A redacted or denied trace must still be identified as redacted or denied.
Security minimization does not require returning grant IDs, target existence, or policy internals. It does require a truthful safe category.
Required patch:
- Preserve a safe top-level distinction between at least:
AUTHORIZATION_DENIED;AUTHORIZATION_REVIEW_REQUIRED;HUMAN_ACTION_REQUIRED;REQUEST_INVALID;DETAILS_REDACTEDor equivalent trace posture.
- Return or link a CP2-compatible qualification envelope with only non-sensitive fields.
- Keep basis identifiers, resource existence, internal reason ranking, and revocation details redacted.
- Register the public codes in the active RuntimeProblem reason-code process rather than defining an isolated authorization-only public vocabulary.
- Add cases proving both that sensitive details do not leak and that redaction/permission/review posture is not hidden.
What is now sound
The current revision’s following parts should remain:
- one rule-selected effect-intent schema and declarative extractor;
- one explicit authority target plus typed non-authority inputs;
- path-specific software-agent authority subjects;
- exact purpose tokens and fail-closed legacy conditions;
- closed delegation ceilings and source permissions;
- current versus historical time separation;
- prospective
RevocationDecisionand packStructureEventeffects; - authority
ALLOWas only one EnforcementChain gate result; - buffered, per-item-covered reads with no v0.2 streaming;
- internal full traces with separately authorized retrieval;
- relevant-state approval comparison rather than full-history equality;
- exact JSON Pointer digest projection;
- append-only authorization evidence with no domain-current-state eligibility;
- explicit draft, binding, conformance, promotion, extraction, and implementation stages.
Both repository workflows pass at the current head; this review is about semantic and executable closure, not repository hygiene.
Smallest controlled authority impact
No broad 00_active_baseline/ rewrite is justified. The required changes should be classified as:
- Accepted RFC extension: grant-to-rule compatibility, reporter/performer separation, transport-release eligibility, and protected-effect postconditions.
- Accepted/source-contract extension: source policy bindings and revision-specific revocation semantics.
- CP2 compatibility implication: safe public qualification and redaction-aware reason codes.
- Platform runtime implication: result-contract validation, external release checks, immutable display/payload evidence, and receipt construction.
- Machine-contract implication: likely
RevocationDecision v0.2, source-policy compatibility fields, protected-effect contract bindings, result/postcondition evidence, and content-addressed display/payload references. - Conformance implication: rule-upgrade widening, wrong-revision revocation, authorized-intent/actual-effect divergence, reporter/performer mismatch, post-commit disclosure revocation, hash-only reconstruction, and over-redacted public results.
Final disposition: keep PR #11 in draft and do not approve the section 25 steward card.
samovers
left a comment
samovers
left a comment
There was a problem hiding this comment.
Re-review disposition: Request one bounded change
Reviewed current head e1442fca4ee743ea72c90cfdb860180c9dc2d85b. I limited this review to the delta since 044f189, issue #10's authorization-law boundary, contradictions with active OFARM authority law, and whether the previous seven findings are actually closed.
I did not treat the separately tracked domain-effect, transport-release, or retention implementations as missing work in this PR. PR #11 remains a draft, one-file, non-authoritative candidate.
Blocker — source grants bind the row, but not all shared semantics that determine what the row means
The revision requires each v0.2 source to record:
issuedUnderPolicyDigest; and- an exact
{actionClass, ruleId, ruleDigest}binding.
At evaluation time, only the action-rule binding is compared. issuedUnderPolicyDigest is deliberately audit-only so an unrelated action-row change does not invalidate the grant. That is a sensible goal.
The unresolved problem is that ActionAuthorizationRule does not explicitly bind all shared authorization semantics used to interpret the row. Examples include:
- exact purpose comparison;
- role/grant/scope intersection;
- revocation application;
- prohibition on combining partial paths;
- path aggregation;
- tenant and proof interpretation.
A later policy could, for example, change purpose comparison from exact match to case-insensitive matching while leaving the row's fields and ruleDigest unchanged. The old grant would then authorize more than the grantor originally approved, even though the candidate claims that exact rule binding prevents silent semantic widening.
This is not a reason to compare the entire policy-bundle digest or build a semantic-subset theorem engine.
Required patch:
- Define
ruleDigestas the digest of the complete resolved per-action semantic closure, including every shared policy component that can change eligibility or increase authority. - Alternatively, add an immutable
authorizationSemanticsRefandauthorizationSemanticsDigestto every resolved rule and include them inruleDigest. - Shared changes that affect only diagnostics or unrelated action classes should remain outside that closure.
- Add one hostile case: a shared purpose, scope, revocation, or path-composition rule changes while the visible action row remains unchanged; the old source must fail with
SOURCE_RULE_BINDING_MISMATCH. - Do not add a new top-level contract family or cross-version compatibility engine.
Previous seven findings
They are now adequately closed or correctly separated:
- Authority sources use one-record immutable IDs, making exact
RevocationDecision v0.1termination coherent. - Protected-effect equality is bound to separately owned contracts under issue #12 rather than being reimplemented inside authorization.
- Current report authority is separated from alleged performer identity and historical execution authority.
- Filing authority ends at the human outbox commitment, while current external release eligibility is separately governed by issue #13.
- Display and read evidence no longer overclaim byte reconstruction; retention and custody are correctly isolated in issue #14.
- Caller-facing non-
ALLOWresults preserve CP2-compatible denial, review, human-action, invalid-input, and redaction posture without exposing internal authority evidence. - The staged sequence prevents #12–#14, CP2 contract work, or OFARM2 implementation from being silently absorbed into this PR.
No other blocking finding remains. After the per-action semantic-closure digest is made explicit, the Phase A candidate is ready for steward semantic approval. That approval would still not promote active law, schemas, currentness, or unblock OFARM2 implementation by itself.
|
Assessment of the latest re-review: accepted as one bounded blocker. This finding is inside issue #10 and is not scope drift. Issue #10 owns the executable meaning of purpose, scope, revocation, proof, and authority-path evaluation, including protection against policy-digest drift. If those shared semantics can change without changing the per-action rule digest, an existing source can silently gain authority despite its exact rule binding. The bounded correction should define ruleDigest over the complete resolved per-action semantic closure. That closure should bind every shared component that can change eligibility or increase authority, while excluding diagnostic-only behavior and unrelated action classes. One hostile case should show that a shared purpose, scope, revocation, or path-composition change with an otherwise unchanged visible row causes SOURCE_RULE_BINDING_MISMATCH. To avoid over-design, this should not add a new top-level contract family, compare the whole policy-bundle digest, introduce a semantic-subset engine, or pull the separately tracked protected-effect, transport-release, or retention work from issues #12–#14 into this PR. A separate authorization-semantics abstraction is unnecessary unless the existing resolved-rule packaging cannot express immutable component refs and digests. Primary trust boundary: canonical authorization law and decision evidence. The intended PR boundary remains the one-file, non-authoritative Phase A candidate. Scope remains inside that boundary. |
|
Final semantic re-review requested on The bounded blocker is closed in the existing candidate document:
No full policy-bundle comparison, new top-level family, mutable semantics registry, cross-digest compatibility engine, or semantic-subset proof was added. Issues #12–#14 remain separate.
Primary trust boundary: canonical authorization law and decision evidence. Scope stayed inside PR #11's stated boundary. What is next: confirm final semantic approval or identify any remaining authorization-law defect while PR #11 remains draft. |
samovers
left a comment
samovers
left a comment
There was a problem hiding this comment.
Re-review disposition: No blocking findings
Reviewed current head b0e0409a939539b85ce6d89105230aeb51e589ca against the previously reviewed head e1442fca4ee743ea72c90cfdb860180c9dc2d85b. The new commit changes only the existing candidate document, with a narrowly targeted 24-line delta. PR #11 remains draft, one-file, and non-authoritative.
The previous blocker is closed
The earlier version bound authority sources to the visible resolved action rule but did not explicitly guarantee that shared authorization semantics were part of that rule's digest.
The patch now defines ruleDigest over the complete resolved per-action semantic closure. That closure includes:
- all rule-local fields;
- purpose comparison;
- role, grant, scope, inheritance, delegation, and sharing intersections;
- trusted-time and revocation behavior;
- evidence, sovereignty, proof, and tenant interpretation;
- prohibition on partial-path union;
- path sufficiency and deterministic selection;
- outcome aggregation.
A change to any included semantic component changes ruleDigest, even when the visible matrix row is unchanged. Existing sources bound to the previous digest then fail closed with SOURCE_RULE_BINDING_MISMATCH.
That addresses the actual risk: an unchanged grant can no longer silently inherit changed purpose, scope, revocation, evidence, delegation, or path-composition meaning.
Drift check
No drift in the new delta.
The change remains directly inside issue #10's trust boundary: executable authorization semantics and machine-contract evidence. It does not introduce:
- another action class;
- another top-level contract family;
- a general policy language;
- a mutable semantics registry;
- runtime implementation;
- a semantic-subset theorem engine;
- changes to protected-effect, transport-release, or retention ownership.
The separately tracked boundaries under issues #12, #13, and #14 remain separate rather than being pulled back into PR #11.
Over-design check
The per-action semantic closure is justified and is the smallest safe solution among the realistic options:
- A visible-row digest is too weak because shared authorization semantics could change without changing the row.
- A whole-policy-bundle digest comparison is too broad because an unrelated action or diagnostic change would invalidate every grant.
- Automatic "new rule is narrower" analysis would require the generic semantic-subset engine that should not be introduced here.
- An exact per-action closure digest invalidates only sources affected by changed authority meaning and remains mechanically simple.
The main cost is operational: even a stricter semantic change requires a new source record, explicit migration, or reapproval. That is conservative, but explicit and appropriate for v0.2. It is preferable to a complex compatibility engine whose correctness would itself become an authorization risk.
The candidate as a whole is large, but the current patch does not add architectural machinery. Most of the size records explicit decisions, invariants, hostile cases, and boundaries accumulated through review. Further semantic expansion would be counterproductive; the correct next move is to freeze this Phase A design and proceed through its declared staged process.
Final assessment
- Prior blocker: closed
- New semantic blocker: none
- Scope drift: none in the current delta
- New over-design: none
- Repository validation: both current-head workflows completed successfully
- Phase A status: ready for steward semantic approval
Semantic approval would authorize preparation of the governed follow-on artifacts only. It would not by itself accept the RFC, promote schemas, change current/default law, authorize merge, or resume OFARM2 runtime implementation.
Steward semantic approval — grantedI explicitly grant Phase A semantic approval for the authorization-law candidate at commit This approval accepts the proposed answers in section 25, including the complete resolved per-action semantic-closure digest, exact-digest source compatibility, fail-closed authority evaluation, decision-evidence requirements, hostile cases, staged delivery, and the stated separation of adjacent trust boundaries. The approved primary trust boundary is canonical authorization law and decision evidence. PR #11 stayed within that boundary as a one-file, non-authoritative candidate. Protected-effect contracts (#12), transport-release eligibility (#13), evidence retention/proof strength (#14), CP2 contract work, active/current promotion, and OFARM2 runtime implementation remain separately governed. This decision authorizes preparation of the declared governed follow-on artifacts. It does not by itself:
Any semantic change to the approved Phase A design requires renewed steward review and approval. PR #11 remains draft as the durable candidate and approval record. What is next: freeze the Phase A semantics and begin the next declared prerequisite as its own bounded issue and PR. |
|
Renewed semantic re-review requested on The previous approval at Please review only the final-review authorization closure and confirm whether it stays inside PR #11's existing trust boundary:
The requested hostile cases, invariant, traceability entry, approval-card decisions, and completion criterion are included. The delta remains one non-authoritative candidate file. Repository validation, generated-currentness, Markdown table checks, and exact 20/20 matrix alignment pass. Primary trust boundary: canonical authorization law and decision evidence. Intended PR boundary: the existing one-file Phase A candidate only. What is next: identify any remaining authorization-law defect or confirm no blocking findings; explicit renewed steward approval remains a separate decision. |
samovers
left a comment
samovers
left a comment
There was a problem hiding this comment.
Re-review disposition: No blocking findings
Reviewed current head baf9eed06c8db4b80d27355d7c05678e966f0eef against the previously approved semantic head b0e0409a939539b85ce6d89105230aeb51e589ca. The delta is one commit, one candidate file, and 29 changed lines. PR #11 remains draft, mergeable, and non-authoritative.
Semantic assessment
The amendment corrects a genuine contradiction rather than expanding the architecture.
The accepted Authority Action Matrix gives all three final review actions scope over consequences. The current ReviewDecision v0.1 contract explicitly permits ACCEPTED_EVENT_CONSEQUENCE as a reviewed artifact family and supports the outcome states ACCEPTED, REJECTED, CONTESTED, and SUPERSEDED.
The patch now:
- gives only
REVIEW_ACCEPT,REVIEW_REJECT_OR_CONTEST, andREVIEW_SUPERSEDEthe newRP_FINAL_REVIEW_TARGET_ONEpolicy; - leaves
REVIEW_REQUESTon its existing policy; - adds
ACCEPTED_EVENT_CONSEQUENCEas one exact, immutable authority-target branch; - binds
REVIEW_ACCEPTtoACCEPTED; - binds
REVIEW_SUPERSEDEtoSUPERSEDED; - requires
REVIEW_REJECT_OR_CONTESTto bind exactly one ofREJECTEDorCONTESTEDinside the validated effect intent.
Keeping REJECTED versus CONTESTED in the single effect intent is the correct minimal solution. Splitting the accepted combined action into two new action classes would be a broader authority-model change and would be unnecessary here.
The amendment also preserves the correct boundary with issue #15. PR #11 determines what target and requested outcome are authorized; #15 remains responsible for the ReviewDecision result schema, intent-to-result mapping, governance-event classification, postconditions, and validation evidence.
Drift check
No scope drift.
The amendment does not change:
- who may perform final review;
- the authority family;
- inheritance or delegation posture;
- CP3 or human-finalization rules;
- unrelated review, read, evidence, pack, output, or sharing actions;
- active law, schemas, runtime code, currentness, or OFARM2 implementation.
It also correctly supersedes the earlier head-specific semantic approval instead of pretending that approval automatically carries over to changed rule meaning.
Over-design check
No new over-design in this delta.
Creating one separate final-review target policy is justified. Adding ACCEPTED_EVENT_CONSEQUENCE directly to the existing RP_REVIEW_TARGET_ONE policy would also widen REVIEW_REQUEST, which issue #16 explicitly excludes. The separate policy is therefore the smaller controlled patch.
The amendment adds no:
- new action class;
- generic review-expression language;
- top-level contract family;
- runtime mechanism;
- local domain mapping;
- new target behavior outside the three final review actions.
Both current-head validation workflows pass. The update also reports 20/20 action-resource alignment and unchanged currentness.
Final assessment
- Triggering contradiction: closed
- Target closure: sound
- Outcome closure: sound
- Boundary with #15: preserved
- Scope drift: none
- New over-design: none
- Renewed Phase A semantic approval: appropriate
Approval of this head would allow issue #15 to resume its separate candidate work. It would not accept or merge the RFC, promote schemas, change active/current law, or authorize OFARM2 runtime work.
Renewed steward semantic approval — grantedI explicitly grant renewed Phase A semantic approval for the authorization-law candidate at commit This approval accepts the previously approved Phase A design as amended by issue #16, including:
The approved primary trust boundary remains canonical authorization law and decision evidence. PR #11 stayed within that boundary as a one-file, draft, non-authoritative candidate. The separately owned This approval supersedes the head-specific approval at
Any later semantic change to PR #11 requires renewed review and approval. PR #11 remains draft as the durable candidate and approval record. What is next: close issue #16 and resume issue #15 on its separate protected-effect branch. |
|
Renewed steward semantic review requested for amended head The previous approval at Primary trust boundary: canonical authorization target eligibility for final review. This 24-line, one-file delta closes the active The amendment:
This action split follows the accepted Authority Action Matrix: accept and reject-or-contest explicitly carry case scope, while supersede is not widened by inference. Scope exclusions remain unchanged: no domain result mapping, consequence composition, event/commit classification, schema, runtime, currentness, or OFARM2 edit. Issue #16 tracks this bounded prerequisite; PR #17 remains the separate ReviewDecision domain-contract boundary. Local validation passes: full repository suite, generated-currentness, repository hygiene, 20/20 core-to-extension action/resource alignment, single policy definition with exactly two selections, Markdown tables, and Please review this head for renewed semantic approval before PR #17 treats the authorization target closure as settled. |
samovers
left a comment
samovers
left a comment
There was a problem hiding this comment.
Review disposition: No semantic blockers; one required metadata correction
Reviewed current head 5974bb916ac8a2c5a6230facbb9836f639c754c3 against the last reviewed head baf9eed06c8db4b80d27355d7c05678e966f0eef.
The current delta is one commit, one candidate file, and 24 changed lines. PR #11 remains draft, mergeable, and non-authoritative. Both current-head validation workflows pass.
Semantic assessment
The amendment correctly restores EVIDENCE_SUFFICIENCY_CASE as a final-review authority target for exactly the two applicable action classes:
REVIEW_ACCEPTREVIEW_REJECT_OR_CONTEST
It deliberately does not add that target to:
REVIEW_SUPERSEDEREVIEW_REQUEST- unrelated actions
That matches the accepted Authority Action Matrix: accept and reject-or-contest explicitly include “case scope,” while supersede is limited to assertion, consequence, and state scope. The current ReviewDecision v0.1 carrier also explicitly recognizes EVIDENCE_SUFFICIENCY_CASE as a reviewed artifact family.
The new policy remains exact and fail-closed:
- one
PRIMARY_RECORD; - one concrete target kind;
- one logical reference;
- one immutable revision reference or content digest;
- no target-family aliasing;
- no widening of another action’s policy.
The extension matrix consistently applies RP_FINAL_REVIEW_CASE_ELIGIBLE_TARGET_ONE only to accept and reject-or-contest, while supersede retains RP_FINAL_REVIEW_TARGET_ONE.
The candidate also adds the necessary hostile cases:
- omission or substitution of the evidence-sufficiency-case target;
- use of the case-eligible policy by supersede, review request, or an unrelated action;
- immutable kind/ref/revision substitution.
The invariant, review traceability entry, steward approval card, and Phase A completion criteria have also been updated.
Drift and over-design check
No scope drift in the amendment.
This is a direct correction of the contradiction exposed during PR #17 review. It stays inside PR #11’s authorization-law boundary: which action may be authorized against which exact target. It does not attempt to define the resulting ReviewDecision, case-review effect, event classification, postconditions, or runtime transaction.
No new over-design.
A separate case-eligible resource policy is justified:
- Adding
EVIDENCE_SUFFICIENCY_CASEtoRP_FINAL_REVIEW_TARGET_ONEwould also widenREVIEW_SUPERSEDE. - Adding it to
RP_REVIEW_TARGET_ONEwould widenREVIEW_REQUEST. - Introducing policy inheritance or a generic target-set composition mechanism would add more machinery than this single explicit policy.
The amendment adds no new action class, top-level contract family, runtime mechanism, generic review language, or semantic-subset engine.
Required metadata correction
The PR description is stale. The actual head is 5974bb9, but the description still says:
Current head
baf9eedcloses the bounded final-review contradiction...
It consequently describes only the previous accepted-consequence and outcome amendment and does not state that the evidence-sufficiency-case target has now been restored.
Before treating the PR description as the project handoff, update it to:
- name current head
5974bb916ac8a2c5a6230facbb9836f639c754c3; - explain the accept/reject-only evidence-case target restoration;
- state that the semantic review recorded for
baf9eedis superseded by this new rule change; - require renewed semantic approval at
5974bb9.
PR #17 also still declares a dependency on PR #11 at baf9eed; that downstream pin must be updated after the new head is approved. This is not a PR #11 semantic blocker, but PR #17 must not continue against its older authorization closure.
Final assessment
- Evidence-sufficiency-case target restoration: correct
- Accept/reject action scoping: correct
- Supersede and review-request containment: correct
- Immutable target binding: preserved
- Hostile coverage: adequate
- Scope drift: none
- New over-design: none
- Semantic blockers: none
- PR-description metadata: must be refreshed
Current head 5974bb9 is ready for renewed Phase A semantic approval. That approval would not merge the PR, promote active law or contracts, change currentness, or authorize OFARM2 runtime work.
Renewed steward semantic approval — grantedI explicitly grant renewed Phase A semantic approval for the authorization-law candidate at commit This approval accepts the previously approved Phase A design as amended by issue #16, including:
The approved primary trust boundary remains canonical authorization law and decision evidence. PR #11 stayed within that boundary as a one-file, draft, non-authoritative candidate. The separately owned This approval supersedes the head-specific approval at
Any later semantic change to PR #11 requires renewed review and approval. PR #11 remains draft as the durable candidate and approval record. What is next: close issue #16 and continue review of PR #17 against this exact approved authorization head. |
samovers
left a comment
samovers
left a comment
There was a problem hiding this comment.
Re-review disposition: No blocking findings
Reviewed PR #11 at current head 03a21f669ee04f96d444e14f00ae7212cab04803 against the previously reviewed head 67c7195baa641a6ddbb791058962938cb1637e43.
The delta is one commit changing only the existing non-authoritative candidate document: 21 additions and 13 deletions. PR #11 remains draft, open, and mergeable.
Previous blocker: closed
The path-selection sequence is now complete and deterministic:
- Section 15.5 determines the winning path disposition using the existing outcome lattice.
- Section 15.2 selects the lowest canonical tuple among paths having that disposition.
- Section 15.6 selects the primary reason from the already-selected path.
The same canonical tuple now applies to:
PATH_ALLOW;PATH_REQUIRE_HUMAN_APPROVAL;PATH_REQUIRE_REVIEW; andPATH_DENY.
PATH_INAPPLICABLE never wins and is never selected. When no candidate path exists or all paths are inapplicable, no path is fabricated: the result is DENY, the primary reason is NO_AUTHORITY_BASIS, and the trace has no winning disposition or selected path.
The relationship between path selection and reason ranking is also explicit. Numeric rank chooses the primary reason within the selected path; it does not influence which path is selected. Consequently, implementations cannot disagree by having one select the lowest path tuple while another selects the path containing the lowest-ranked failure.
Conformance coverage
The candidate now includes the required hostile cases:
- two review-required paths with reversed enumeration must select the same canonical path and primary reason;
- two denial paths with reversed enumeration must do the same;
- zero candidates or all-inapplicable candidates must produce
NO_AUTHORITY_BASISwithout a selected path.
These cases test the observable outputs that matter: outcome, selected authority basis, primary reason, and ordering independence.
Invariant 32 was strengthened consistently: the same immutable intent, snapshot facts, policy bytes, and basis revisions must now produce the same selected path, result, primary reason, and ordered evidence. The traceability entry and steward approval card were also updated to include selected-path determinism and the no-authority-basis exception.
Drift and over-design check
No scope drift. The commit changes only authorization path aggregation and evidence determinism. It does not alter:
- who holds authority;
- action or target eligibility;
- the v0.1-to-v0.2 target ledger;
- delegation, purpose, evidence, revocation, CP2, or CP3 semantics;
- human-approval eligibility;
- protected-effect contracts;
- transaction coordination;
- transport-release rules;
- schemas, runtime code, or currentness.
No new over-design. The correction reuses the existing path tuple, dispositions, outcome lattice, and reason table. It introduces no new reason code, path type, policy abstraction, schema family, tie-break service, or general-purpose rule mechanism.
Adding reason rank to the path-selection tuple would have been unnecessary and semantically wrong: it would make diagnostic severity choose the authority basis. The current separation—canonical basis first, path-local reason second—is cleaner.
The current-head repository-validation and generated-currentness workflows both completed successfully.
Final assessment
- Previous selected-path blocker: closed
- New semantic blockers: none
- Deterministic non-
ALLOWselection: closed - No-applicable-path handling: closed
- Scope drift: none
- New over-design: none
- Phase A disposition: ready for exact-head steward semantic approval
Approval applies only to head 03a21f669ee04f96d444e14f00ae7212cab04803. It would not merge the PR, accept RFC law, create or promote schemas, change current/default status, or authorize OFARM2 runtime implementation.
Any dependent artifact still pinned to the superseded 5974bb9 authorization semantics must refresh its exact-head dependency after this head receives approval.
Renewed steward semantic approval — grantedI explicitly grant renewed Phase A semantic approval for the authorization-law candidate at commit This approval accepts the complete candidate and the section 25 decisions at that exact head, including:
The approved primary trust boundary is canonical authorization law and deterministic decision/effect evidence. PR #11 stayed within that boundary as a one-file, draft, non-authoritative candidate. Protected-effect contracts, the final This approval supersedes the head-specific approval at This decision does not:
Any later semantic change to PR #11 requires renewed exact-head review and approval. PR #11 remains draft as the durable candidate and approval record. What is next: refresh PR #17's dependency to this exact approved authorization head and resolve its separate protected-effect review findings. |
Separate the twenty-action catalogue from exact package admission without changing rule semantics. Retain full selected dependency closure, scoped promotion gates, and the unresolved source-history proof. Prior semantic approval does not transfer to this revision. Part of #10; updates existing draft PR #11 only.
samovers
left a comment
samovers
left a comment
There was a problem hiding this comment.
Exact-head review — release-scope amendment
No blocking findings in the current release-scope amendment. I recommend renewed Phase A semantic approval—not merge, promotion, or runtime implementation.
Reviewed head: 4494924998183fe3fa7bc1b63b76a85893335044.
Comparison: previously approved 03a21f669ee04f96d444e14f00ae7212cab04803 → reviewed head. Review focused on the scope amendment, its interactions with the existing authorization semantics, and the adjacent history-governance dependencies. The live head was reconfirmed before posting.
Reviewed candidate: authorization_constraints_and_decision_evidence_rfc_candidate_v0_2.md.
What holds up
The two-action scope is an enforceable package boundary, not a runtime shortcut. Sections 7.2.1 and 18.1 require an immutable admitted set containing exactly ASSERT_OPERATION_CLAIM and RECEIVE_READ_DATA, with exactly one complete resolved rule per member. Invalid membership makes the package inadmissible; the runtime cannot salvage it by selecting a working subset. Excluded actions stop at ingress, without a fabricated authorization decision or fallback to another policy. That is the right distinction between an unavailable capability and a valid request denied by authorization.
Smaller scope does not weaken either selected rule. Sections 7.2.1, 7.4 and 17.3 preserve the full read-resource alternatives and authority paths; a claim-only read implementation cannot claim complete RECEIVE_READ_DATA coverage. Source reuse still requires exact actionClass, ruleId, and complete per-action ruleDigest equality, plus all current authority checks. A changed package digest is neither automatic grant invalidation nor permission for cross-rule-digest compatibility.
Deferring human-approval workflows does not remove shared prerequisites. Sections 17.2 and 24 retain the four package families and all eleven delivery stages. Selected claim/read paths still need their complete transaction, single-use, evidence, retention, refusal-qualification, and disclosure contracts. In particular, NOT_REQUIRED does not allow an uncovered read to borrow a write-only transaction protocol. Deferral requires an explicit dependency-review justification, rather than merely declaring a feature out of scope.
The new conformance cases address the main ways this scope could be misrepresented. Section 22 covers admitted-set tampering, missing dependencies, fallback requests, accidental activation through family-level currentness, claim-only read coverage, and an implementation that refuses everything while claiming completion. Expansion requires separate review, binding, conformance, promotion, and trusted selection.
Remaining delivery blocker—not a defect introduced by this amendment
The two-action package has not yet been shown to be deliverable.
Section 24.1 correctly leaves open whether complete history classification and historical-admission verification can be established while qualifying-record authoring is non-executable. An inactive writer, an empty lookup, or one valid qualifying record does not prove complete history. The document explicitly blocks complete binding and promotion until the owning contracts demonstrate the required guarantees.
That matches the adjacent records: PR #31 at 092be94f3a67497ba619295932cd0b2b1e9443f3 retains CP2A-DEP01, issue #32 owns classifier/completeness semantics, and PR #34 at 69682c2f918ef18756261a1186294cc3a5ebe44d retains QG-DEP01 for its proposed authoring authority. This amendment neither closes those dependencies nor silently admits GOVERN_AUTHORIZATION_EVIDENCE_QUALIFICATION.
The important distinction is: the scope model is reviewable now; the claim that exactly two executable actions are sufficient remains unproven. If the dependency proof requires another action, that must return as a separately reviewed scope amendment.
Validation and disposition
All four GitHub checks at the reviewed head reported success when inspected during review. I did not rerun repository checks locally or execute runtime tests. The added hostile cases remain specifications, not runtime evidence; the PR itself acknowledges that repository checks largely exclude the historical candidate lane.
No changes requested within this PR's scope. Renewed steward approval should name the exact head and remain limited to Phase A semantics. Keep the PR draft, the history dependencies open, and implementation/promotion gated as specified in sections 24–26.
This review is a recommendation for renewed Phase A approval, not the steward approval itself. Posting it does not authorize merge, materialization, accepted-law/currentness promotion, downstream repinning, extraction, deployment, or OFARM2 runtime implementation.
samovers
left a comment
samovers
left a comment
There was a problem hiding this comment.
Exact-head re-review — release-scope amendment
No blocking findings. My previous recommendation stands: renewed Phase A semantic approval only—not merge, promotion, or runtime implementation.
Reviewed head: 4494924998183fe3fa7bc1b63b76a85893335044.
There has been no new commit since the previous posted review, so this was a second examination of the same amendment, not verification of a subsequent fix. The PR remains draft and unmerged.
What I rechecked
Admission cannot be bypassed through authorization or fallback. Sections 7.2.1 and 18.1 require the package to bind the exact admitted-action set and complete rules. An excluded action cannot enter the authorization outcome lattice, and an invalid package cannot be repaired by evaluating only its valid subset. Nothing in the retained evaluation rules gives a grant or an otherwise sufficient authority path permission to override that admission boundary.
Reduced packaging does not create weaker source-consent semantics. Sections 7.4, 16 and 17.3 preserve the distinction between the complete package digest and the selected action's complete semantic-closure digest. A source can remain eligible after an unrelated package change only when its exact action/rule binding still matches and every current authority check passes. This does not permit compatibility by presumed equivalence or by claiming the new rule is a narrower subset.
The claim transaction contract does not accidentally become the read transaction contract. PR #26 at e042efa2911b2ef0a61603b8e0adaa6911c03ac0 covers state-affecting NOT_REQUIRED actions, with an operation-claim handoff. It is not sufficient evidence of a governed-read protocol. Section 24 explicitly preserves that distinction, while section 18.5 still requires complete buffered-result coverage and atomic persistence of decision, consumption, and read evidence before disclosure. I found no waiver hidden in the smaller release scope.
Gates that must remain open
History completeness remains unresolved. The candidate does not demonstrate that qualifying-record authoring can safely remain non-executable while the required classifier establishes complete history and verifies historical admission. Section 24.1 correctly preserves this as a prerequisite to complete binding and promotion—not something satisfied by an empty lookup, an inactive writer, or permanent UNAVAILABLE responses. This is an acknowledged delivery blocker, not a newly discovered defect in the scope amendment. Keep CP2A-DEP01 and the separately owned QG-DEP01 obligations open; the classifier, qualifying-record governance and public consumer retain their respective boundaries.
Downstream approval pins have not yet moved. At re-review, issue #21 still names the historical approved authorization head, 03a21f669ee04f96d444e14f00ae7212cab04803. That is consistent with the amendment's explicit requirement to obtain renewed approval before aligning downstream scope records; the candidate cannot silently override the existing promotion issue.
Disposition and validation limits
No additional patch requested within this PR. The scope model is suitable for renewed exact-head Phase A approval. That approval must not be recorded as proof that the two-action package is deliverable or that its dependencies are closed.
The repository-validation and generated-currentness workflows reported success at the reviewed head. I did not rerun local checks or execute runtime conformance; the hostile cases remain specifications rather than execution evidence.
This is a review comment and recommendation, not a steward semantic-approval record. Keep the PR draft and preserve the separately governed binding, acceptance, conformance, promotion, extraction and runtime gates.
Renewed steward Phase A semantic approval — recordedRecorded from the user's instruction in this task: “no blockers, i approve”. Approved exact head: The exact-head review and re-review both report no blocking findings. The live head was verified unchanged before recording this approval. Approved scopePrimary trust boundary: canonical authorization policy scope and admission, within canonical authorization law and machine-contract governance. The approval covers the Phase A release-scope model: preserve the twenty-action catalogue and complete rule meanings; propose exact initial admission of Limits retainedSection 24.1 remains open. This approval does not establish that complete history classification and historical-admission verification are possible while qualifying-record authoring is non-executable. CP2A-DEP01, #32 and the separately owned QG-DEP01 obligations remain unresolved. No extra action, writer, classifier or PR #34 approval is implied. This is the user's semantic approval recorded by the AI, not AI-granted approval or a formal GitHub APPROVE review. It does not authorize merge, machine materialization, accepted-law/currentness promotion, extraction, source issuance, deployment or OFARM2 runtime implementation. No downstream issue scope or dependent approval pin changes automatically. The earlier approval at What is next: align the prepared downstream scope records against this approved head and approval record as a separate scoped step, preserving the history-proof and real transaction/read-producer gates before any implementation. |
samovers
left a comment
samovers
left a comment
There was a problem hiding this comment.
Re-review — Phase A approval and downstream scope alignment
No blocking findings. The non-blocking P3 metadata finding from this re-review was corrected before publication and is now resolved. The disposition remains Phase A approval recorded; delivery still blocked.
Reviewed exact head: 4494924998183fe3fa7bc1b63b76a85893335044. The live head was verified unchanged immediately before posting. The PR remains draft and unmerged. This pass checked the approval record and downstream scope alignment against the previously reviewed candidate; it is not a review of a new semantic revision.
P3 — Stale downstream-alignment wording: resolved before posting
At the time of the preceding re-review, the PR description said:
Downstream #10/#21 and OFARM2 #353/#178/#175/#167/#176 scope edits remain unapplied
Its closing next-step paragraph also still directed that alignment. This was stale for at least canonical issues #10 and #21, which had already been explicitly aligned to this approved head and its approval record.
Posting-time verification: the current PR description no longer makes that claim. It records completed scope-record alignment and replaces the stale next step while retaining the distinction between alignment and implementation approval. The requested metadata correction is therefore resolved; no additional patch is requested for this finding.
This was handoff/control metadata, not a semantic amendment. No active-baseline file, approved candidate byte, schema or runtime change was needed. I did not independently audit every OFARM2 downstream issue or review the newly referenced OFARM2 PR #359 revision in this pass; resolving this wording finding does not approve that implementation-side design.
Approval is recorded with the correct limits
The renewed approval record explicitly names the reviewed head and confines approval to the Phase A release-scope model. It preserves complete selected-rule semantics and dependencies, records the other eighteen actions as deferred, and distinguishes recorded user approval from AI-granted authority or a formal GitHub APPROVE review.
It leaves section 24.1, CP2A-DEP01 and the separately owned QG-DEP01 obligations unresolved. It does not approve the qualifying-record writer, PR #34, source issuance, machine materialization, accepted-law/currentness promotion, extraction or implementation. I found no expansion of authority in that approval record.
Downstream alignment preserves the delivery blockers
The reviewed alignment of #10 preserves the full twenty-action programme while identifying the initial two-action scope. The updated #21 names the new approved source and applies its prerequisites to the complete selected scope.
In particular, #21 still requires complete source-history and historical-admission proof and rejects permanent history unavailability or a second policy as workarounds. It also requires a separately governed read transaction, coverage, receipt and disclosure protocol rather than treating PR #26's write-only profile as sufficient. Exact schema/manifest binding review remains a prerequisite to accepted-law promotion.
Scope alignment has progressed; dependency closure has not been established by that progress.
Disposition and verification limits
No semantic revision is requested. The metadata finding is resolved, and the existing Phase A approval remains applicable to this unchanged head. Merge, promotion, extraction and runtime work remain gated; no dependent candidate receives approval from this review.
I did not rerun repository or runtime tests, audit every OFARM2 downstream issue, or execute the hostile cases in this pass. This is a review comment, not a formal GitHub approval or authorization to proceed to later stages.
1 participant
Part of #10. Existing authorization-law candidate; no new PR or implementation scope.
Current revision — renewed Phase A semantic approval recorded
Release-scope amendment revision 1, 2026-09-11, at exact head
4494924998183fe3fa7bc1b63b76a85893335044.Renewed steward Phase A semantic approval is recorded for exact head
4494924998183fe3fa7bc1b63b76a85893335044from the user's instruction, “no blockers, i approve”, after the exact-head review and re-review both found no blockers. This is the user's approval recorded by the AI, not an AI-granted approval or formal GitHub APPROVE review.The prior semantic approval remains history at
03a21f669ee04f96d444e14f00ae7212cab04803; the new record specifically approves this release-scope revision. No dependent candidate is automatically repinned or reapproved. The reviewed candidate bytes remain unchanged; their pre-approval labels are historical at this approved head.Exact amendment diff
Outcome
ASSERT_OPERATION_CLAIMandRECEIVE_READ_DATA, each with its complete unchanged semantics.Open dependency — not solved by smaller scope
Can required history classification and historical-admission verification be complete while qualifying-record authoring is non-executable?
Section 24.1 retains PR #31's
CP2A-DEP01, #32's separate classifier/completeness ownership and the unapproved #33 / PR #34 proposal withQG-DEP01. This revision neither addsGOVERN_AUTHORIZATION_EVIDENCE_QUALIFICATIONnor approves or implements its writer. An inactive writer, empty lookup or individually valid qualifier is not proof of complete history.The answer has not been demonstrated in either direction. That blocks complete binding, promotion and runtime-readiness claims, not review of this Phase A scope model. A required scope expansion must receive its own explicit review; it cannot silently grow the two-action set.
Primary trust boundary and PR boundary
Primary boundary: canonical authorization policy scope and admission, within canonical authorization law and machine-contract governance.
Only the existing non-authoritative candidate under historical phase reports changes. Scope stayed inside this boundary. No active law, accepted RFC, schema, current/default pointer, principal resolution, authority mutation, protected-effect contract, transaction protocol, disclosure implementation, history classifier/writer, database authority, key custody or OFARM2 runtime code changes.
The smaller first-delivery release-scope model now has Phase A semantic approval only. It is not approval for machine materialization, accepted-law/currentness promotion, extraction, implementation, merge or deployment. Downstream #10/#21 and OFARM2 #353/#178/#175/#167/#176 scope records were explicitly aligned on 2026-09-11 with this approved head and approval record; their previous bodies remain preserved. OFARM2 PR #359 now has implementation-side Phase A revision 7 at
feffb585ec569c6aaa8b5d085e94583d1eb9aeca, REVIEW_PENDING, with no runtime code changes or implementation approval. Canonical PR #34 remains unchanged; no dependency approval is transferred. This PR's reviewed candidate bytes and approved head are unchanged.Validation of this revision
git diff --check— PASS.validate_repo_hygiene.py— PASS.check_generated_currentness.py— PASS.check_repository_cross_references.py— PASS.check_repository_steward_guardrails.py— PASS.4494924998183fe3fa7bc1b63b76a85893335044— PASS (generated-currentnessandrepository-validationon both triggered runs).The repository checks largely exclude historical phase reports. They establish package hygiene, not semantic approval, complete dependency closure or runtime conformance. The added hostile cases are specifications, not executed runtime tests. No expensive OFARM2 baseline test was run.
Previous PR description — historical, before this release-scope amendment
The following description and its “current head,” approval, validation and next-step statements refer only to the earlier revision. They do not govern the new head above.
Part of #10.
Amends #16 and #18 and remains the authorization-law prerequisite for #15.
Outcome
Adds the one-file, non-authoritative Phase A candidate for executable authorization constraints and durable decision/effect evidence v0.2.
Current head
03a21f669ee04f96d444e14f00ae7212cab04803closes the latest exact-head formal re-review finding:PATH_ALLOW,PATH_REQUIRE_HUMAN_APPROVAL,PATH_REQUIRE_REVIEW, andPATH_DENY;PATH_DENYfrom the no-applicable-path case;PATH_INAPPLICABLEpaths deterministically yieldsDENYwithNO_AUTHORITY_BASISand no selected path;The preceding
67c7195baa641a6ddbb791058962938cb1637e43amendment closed the global-precondition review:NOT_EVALUATEDis trace-only, unranked, and excluded from aggregation;OBSERVE_ATTACH_EVIDENCEis classifiedRETYPED;EP_FORMAL_FILING_V0_2; andThe earlier
0fc0d02a5cd555ab7d449758676eb75906e77b74amendment closed the remaining deterministic-evaluation and target-delta findings:HUMAN_FINAL_ACTION_REQUIREDis the sole primary reason forREQUIRE_HUMAN_APPROVAL;Renewed steward semantic approval is recorded for exact head
03a21f669ee04f96d444e14f00ae7212cab04803after an exact-head review found no blocking findings. It supersedes the approval at5974bb916ac8a2c5a6230facbb9836f639c754c3. Dependent candidate work may refresh its authorization dependency to this exact approved head, but this approval does not approve any dependent protected-effect contract in advance.Primary trust boundary
Canonical authorization law and decision/effect evidence governance: what facts may contribute authority, how paths aggregate and are selected, what each constraint means, what must be proved before authority-gate
ALLOW, and what authorization evidence must record.PR boundary
This PR changes only one candidate document under the historical phase-report lane. It does not change active law, accepted RFCs, companion policy, schemas, runtime code, grant/revocation state, domain result contracts, Event Grammar, CP2 contracts, transaction coordination, transport runtime, retention/encryption/key custody, database authority, deployment, or currentness.
The PR remains draft and non-authoritative. No merge, promotion, schema creation, currentness change, or OFARM2 runtime work is authorized.
Dependencies
ReviewDecisionprotected-effect contract, gated on exact-head approval here;Validation
git diff --check— PASSpython3 package_meta/tools/run_repository_validation_suite.py— PASSpython3 package_meta/tools/check_generated_currentness.py— PASSWhat is next: keep PR #11 draft and refresh PR #17's dependency to exact approved authorization head
03a21f669ee04f96d444e14f00ae7212cab04803before resolving its separate protected-effect findings.What is next: review the aligned implementation-side design in OFARM2 PR #359 at
feffb585ec569c6aaa8b5d085e94583d1eb9aeca. Keep source-history closure and real transaction/read-producer gates open before its fresh implementation card; this canonical Phase A approval does not authorize implementation, merge or promotion.