Skip to content

Define executable authorization constraints and decision evidence v0.2 #10

Description

@samovers

Downstream consumers: samovers/OFARM2#353 and existing draft samovers/OFARM2#359.

Scope alignment (2026-09-11): Renewed canonical Phase A approval at exact PR #11 head 4494924998183fe3fa7bc1b63b76a85893335044 governs the closed first-release scope. The full twenty-action programme remains open; candidate approval and this issue edit do not create executable authority.

Outcome

Define the canonical authorization semantics and machine-contract evidence needed for a runtime evaluator to make a truthful, fail-closed decision from an action class, accountable actor, governed target, live authority path, scope proof, constraint evidence, and revocation posture.

Primary trust boundary

Canonical authorization law and machine-contract governance: the boundary that defines what an authority constraint means, what must be proved before ALLOW, and what a durable authorization decision bundle must record.

Why this is required

The current v0.1 contracts cannot represent the policy version/digest, accountable actor posture, full target identity, generic scope-proof references, or constraint-evidence references used by a decision. The current AuthorityGrant, DelegationGrant, and SharingGrant contracts also expose free-text purpose and conditions, while AuthorizationDecisionRequest exposes an unrelated caller usePurpose; active law does not define a safe executable comparison. Implementations must not invent those semantics locally or misuse dataSovereigntyBoundaryRefs as a generic proof bucket.

Authority map

  • The Constitution and Platform runtime baseline remain higher authority.
  • The accepted Authority Policy Model, Authority Action Matrix, and Authority/Delegation/Data Sovereignty policy own existing authorization semantics.
  • This issue owns only the missing executable constraint semantics and versioned authorization request/result/trace evidence contract.
  • Explicit current/default promotion remains a later human-governed decision under CP15; adding a draft schema must not promote it.
  • OFARM2#353 owns runtime evaluation after the canonical prerequisite is accepted, promoted, and extracted verbatim.

Acceptance criteria

  • An accepted RFC defines actor-posture semantics without treating omission or retry of optional AI metadata as proof that no AI participated. AI assistance never creates authority; authenticated accountable-human final action and sponsor-bound software-agent actorship remain distinct.
  • The RFC defines exact action-class-to-authority-family comparison, including the canonical token mapping and fail-closed handling of unknown family values.
  • The RFC defines exact purpose behavior, including where a requested purpose comes from, how it binds to the governed target, how matching is performed, and how legacy free-text purpose is migrated without silently widening authority.
  • Free-text or otherwise unsupported conditions cannot be guessed true. Unknown or unevaluable conditions produce a non-ALLOW disposition and durable reason.
  • Required evidence references must resolve under an active evidence-eligibility policy for the target time and use. Missing, wrong-kind, stale, disputed, superseded, cross-tenant, or otherwise unusable evidence cannot support ALLOW.
  • Role-targeted grants and delegated source grants are bounded by the referenced RoleAssignment anchor scopes as well as the grant/delegation scope.
  • A versioned authorization decision bundle records at least: policy identifier/version/digest and selected rule; actor posture; full target kind/ref/scope/time/twin; role, grant, delegation, sharing, and revocation bases; target and scope proof references; constraint evidence and dispositions; inheritance mode; deterministic outcome and reason.
  • dataSovereigntyBoundaryRefs remains limited to actual DataSovereigntyBoundary records.
  • v0.1 compatibility and migration behavior is explicit. No compatibility path may claim v0.2 proof strength while omitting required evidence.
  • Hostile conformance covers AI-metadata omission/retry, mismatched purpose, caller-only purpose, unknown conditions, missing/stale/wrong-tenant evidence, role-scope escape, wrong target kind/ref, missing scope proof, policy-digest drift, and proof-field substitution.
  • Current/default promotion occurs only in a separate explicit promotion step after accepted semantics, draft schemas, examples, conformance, hostile review, and steward approval.
  • OFARM2 extraction remains byte-identical to the promoted canonical contracts.

Staged delivery

Follow PR #11 section 24 for each explicitly approved closed release scope. The initial executable authorization package contains exactly ASSERT_OPERATION_CLAIM and RECEIVE_READ_DATA, each with complete unchanged rule semantics and every required transitive contract. Catalogue membership is not executable admission. The remaining eighteen actions and their independent profiles remain open under this issue, not passed or implemented.

All eleven stages remain required: Phase A candidate; exact semantic-profile/release-scope approval; adjacent contract prerequisites; policy-bundle draft; source-bundle draft; decision/finalization-evidence drafts; exact binding review and scoped accepted law; production-reachable hostile conformance; explicit scoped current/default promotion; byte-identical OFARM2 extraction; then separately approved OFARM2 runtime work. In particular, exact schema/manifest bytes and binding review precede accepted-law promotion. The older abbreviated six-step ordering below is historical and supplies no exception.

Deferring an unselected action's independent effect or human-finalization profile requires an explicit dependency-closure disposition. Shared source, representation, CP3, sharing, revocation, snapshot, time, evidence, retention, public refusal/history and disclosure requirements cannot be omitted. The source-history question in section 24.1, including CP2A-DEP01 and the separately owned #32/#33/PR #34 obligations, remains unresolved. This amendment does not establish that the two-action package is deliverable, approve a qualifying writer or admit an additional action.

Each later PR retains one primary trust boundary and its own applicable authority. No stage, issue closure, candidate approval or draft schema implicitly performs the next stage.

Non-goals

  • No OFARM2 runtime implementation in this issue.
  • No authentication, credential verification, principal resolution, CP3 actorship implementation, grant/delegation/sharing mutation, database role or migration, bootstrap/recovery/break-glass, key custody, signing, deployment, or production-readiness claim.
  • No new authority action class and no broad rewrite of the active baseline.
  • No generic condition language beyond the minimum semantics explicitly accepted here.

Primary risk and containment

The risk is a false ALLOW backed by caller-selected or unrecorded purpose, actor posture, target, scope, or constraint facts. Containment is versioned canonical semantics, closed comparisons, fail-closed unsupported conditions, durable proof references, explicit migration, staged currentness promotion, and hostile conformance.

Previous issue body — superseded scope history, captured 2026-09-11

This is the complete previous body. Its scope, source pins and next-step wording are historical; the amended current text above controls. Prior decisions and approvals remain attached to their original revisions.

Dependency: samovers/OFARM2#353 and draft samovers/OFARM2#359.

Outcome

Define the canonical authorization semantics and machine-contract evidence needed for a runtime evaluator to make a truthful, fail-closed decision from an action class, accountable actor, governed target, live authority path, scope proof, constraint evidence, and revocation posture.

Primary trust boundary

Canonical authorization law and machine-contract governance: the boundary that defines what an authority constraint means, what must be proved before ALLOW, and what a durable authorization decision bundle must record.

Why this is required

The current v0.1 contracts cannot represent the policy version/digest, accountable actor posture, full target identity, generic scope-proof references, or constraint-evidence references used by a decision. The current AuthorityGrant, DelegationGrant, and SharingGrant contracts also expose free-text purpose and conditions, while AuthorizationDecisionRequest exposes an unrelated caller usePurpose; active law does not define a safe executable comparison. Implementations must not invent those semantics locally or misuse dataSovereigntyBoundaryRefs as a generic proof bucket.

Authority map

  • The Constitution and Platform runtime baseline remain higher authority.
  • The accepted Authority Policy Model, Authority Action Matrix, and Authority/Delegation/Data Sovereignty policy own existing authorization semantics.
  • This issue owns only the missing executable constraint semantics and versioned authorization request/result/trace evidence contract.
  • Explicit current/default promotion remains a later human-governed decision under CP15; adding a draft schema must not promote it.
  • OFARM2#353 owns runtime evaluation after the canonical prerequisite is accepted, promoted, and extracted verbatim.

Acceptance criteria

  • An accepted RFC defines actor-posture semantics without treating omission or retry of optional AI metadata as proof that no AI participated. AI assistance never creates authority; authenticated accountable-human final action and sponsor-bound software-agent actorship remain distinct.
  • The RFC defines exact action-class-to-authority-family comparison, including the canonical token mapping and fail-closed handling of unknown family values.
  • The RFC defines exact purpose behavior, including where a requested purpose comes from, how it binds to the governed target, how matching is performed, and how legacy free-text purpose is migrated without silently widening authority.
  • Free-text or otherwise unsupported conditions cannot be guessed true. Unknown or unevaluable conditions produce a non-ALLOW disposition and durable reason.
  • Required evidence references must resolve under an active evidence-eligibility policy for the target time and use. Missing, wrong-kind, stale, disputed, superseded, cross-tenant, or otherwise unusable evidence cannot support ALLOW.
  • Role-targeted grants and delegated source grants are bounded by the referenced RoleAssignment anchor scopes as well as the grant/delegation scope.
  • A versioned authorization decision bundle records at least: policy identifier/version/digest and selected rule; actor posture; full target kind/ref/scope/time/twin; role, grant, delegation, sharing, and revocation bases; target and scope proof references; constraint evidence and dispositions; inheritance mode; deterministic outcome and reason.
  • dataSovereigntyBoundaryRefs remains limited to actual DataSovereigntyBoundary records.
  • v0.1 compatibility and migration behavior is explicit. No compatibility path may claim v0.2 proof strength while omitting required evidence.
  • Hostile conformance covers AI-metadata omission/retry, mismatched purpose, caller-only purpose, unknown conditions, missing/stale/wrong-tenant evidence, role-scope escape, wrong target kind/ref, missing scope proof, policy-digest drift, and proof-field substitution.
  • Current/default promotion occurs only in a separate explicit promotion step after accepted semantics, draft schemas, examples, conformance, hostile review, and steward approval.
  • OFARM2 extraction remains byte-identical to the promoted canonical contracts.

Staged delivery

  1. Phase A candidate: complete trust model, semantic decisions, contract delta, migration, invariants, hostile cases, traceability, and approval card. No active law or schema change.
  2. Accepted-RFC promotion after semantic approval.
  3. Draft/non-default v0.2 request/result/trace schemas and examples.
  4. Executable hostile conformance.
  5. Explicit current/default promotion and currentness-index update after steward approval.
  6. Verbatim OFARM2 extraction, then resume OFARM2#359.

Non-goals

  • No OFARM2 runtime implementation in this issue.
  • No authentication, credential verification, principal resolution, CP3 actorship implementation, grant/delegation/sharing mutation, database role or migration, bootstrap/recovery/break-glass, key custody, signing, deployment, or production-readiness claim.
  • No new authority action class and no broad rewrite of the active baseline.
  • No generic condition language beyond the minimum semantics explicitly accepted here.

Primary risk and containment

The risk is a false ALLOW backed by caller-selected or unrecorded purpose, actor posture, target, scope, or constraint facts. Containment is versioned canonical semantics, closed comparisons, fail-closed unsupported conditions, durable proof references, explicit migration, staged currentness promotion, and hostile conformance.

What is next: prepare and review the non-authoritative Phase A candidate before any accepted-law or machine-contract edit.

What is next: complete the selected dependency closure and separately authorized contract/binding stages before #21 promotion. Keep the full catalogue programme and source-history proof open; no runtime work or merge is authorized by this scope alignment.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions