Define the sharing-access revocation protected-effect contract

[samovers]

Parent: #12

Downstream: samovers/OFARM2#353 and draft PR #359. This is a canonical design prerequisite, not an OFARM2 implementation issue.

Outcome

Define one content-addressed protected-effect contract for SHARE_REVOKE_ACCESS: prove that the exact authorization-bound intent produces one new immutable RevocationDecision terminating one exact SharingGrant, while preserving the grant and its history.

The contract must prove what is saved. It must not decide who may revoke access, broaden the approved revocation rule, or treat a recorded revocation as removal of every possible access path.

Primary trust boundary

Sharing-revocation domain effect semantics and commit classification: the result carrier, exact intent-to-result mappings, permitted derivations, forbidden widening, postconditions, classification, and immutable validation evidence for this one action.

Intended PR boundary

One non-authoritative Phase A RFC candidate under package_meta/history/clean_baseline_migration/phase_reports/. It may inventory governing law and current carriers, define the proposed contract semantics and hostile cases, identify missing separately owned bindings, and present a steward approval card.

No edits to accepted law, Event Grammar, companion policies, current or draft schemas, currentness indexes, transaction coordination, authorization evaluation, database code, or OFARM2 runtime belong in that PR. If a separate authority change is necessary, stop and identify a linked prerequisite.

Governing inputs and status

• Apply the repository authority order: active baseline, accepted RFCs, companion artifacts, then machine contracts. Inspected canonical main: 71ca724a8b6ec23f1655b086a6f549496d10a47f.
• Use the exact semantically approved PR #11 candidate at 03a21f669ee04f96d444e14f00ae7212cab04803, especially sections 7.2, 7.5, 7.6, 7.8, 8, 14, 18, and 24. Its approval is not accepted-law or executable-profile promotion.
• Consume, without redesigning, the semantically approved human-approval transaction protocol in PR #20 at 98f8c4fafbae42c8f7fd931f43f53adcb4733713, tracked by Define governed human-approval transaction and consumption protocol #19. SHARE_REVOKE_ACCESS is not a NOT_REQUIRED finalization action.
• Inventory the current RevocationDecision v0.1 schema at 03_machine_contracts/schemas/core/OFARM_RevocationDecision_schema_v0_1.json, its examples, Constitution authority/revocation clauses, the Authority Source Record Closure RFC section 4.5, the authority companion policy, and the active Event Grammar.
• PR RFC candidate: executable authorization evidence v0.2 #11 section 24 explicitly keeps RevocationDecision v0.1 unchanged. The future exact SharingGrant v0.2 source bytes and policy/intent bindings remain separately governed work. Do not invent executable digests, use an unbound placeholder as proof, or silently reorder that staged delivery.
• Evidence retention and proof-strength decisions remain owned by Define authorization evidence retention and proof-strength postures #14. Later binding review, acceptance, promotion, extraction, and runtime work remain gated by Promote executable authorization constraints and decision evidence RFC v0.2 #21 and the PR RFC candidate: executable authorization evidence v0.2 #11 sequence.

Acceptance criteria

1. Cover exactly SHARE_REVOKE_ACCESS, EI_SHARING_REVOKE_V0_2, and RP_SHARE_REVOKE. Fix the affected family to SHARING_GRANT, mode to TERMINATE, and effect subject to the proposed RevocationDecision ID. No other action, source family, or narrowing mode is admitted.

2. Preserve the separation of one SHARED_ARTIFACT authority target and one existing AFFECTED_SHARING_GRANT state input. The target remains exactly one of the six artifact kinds admitted by PR RFC candidate: executable authorization evidence v0.2 #11. Bind the exact immutable grant ID/digest and artifact revision, with the required scope, tenant, twin, resource-role, and typed-proof relationships. The grant is not a second authority target or independent source of permission to revoke.

3. Provide a complete field-mapping table. Classify each result field as exact copy, contract-defined derivation, required absence, or separately governed input. Close mappings for the proposed ID, family/ref, decidedByPartyRef, decidedAt, effectiveFrom, mode, targetScope, affectedActionClasses, replacementGrantRefs, and notes, including the intent-bound reason. Define the binding to authenticated human act/representation evidence and trusted times without confusing the operator, represented Party, approval actor, subject time, decision time, or commit time. Do not silently drop or reinterpret an authorization-relevant field.

4. Explain where exact grant digest, artifact revision, reason, actor, and other necessary proof are preserved when they are not dedicated fields in the unchanged v0.1 result. A schema-valid result alone is not proof of a faithful effect. Bind the result to the complete immutable intent and validation evidence. If that cannot satisfy governing law without a carrier or authorization change, stop and report the precise prerequisite instead of introducing a local v0.2 record.

5. Require append-only creation of one new result. Prohibit grant editing, deletion, relabelling, changed bytes under an existing ID, implicit replacement creation, lineage-wide revocation, and propagation to another source ID. Do not erase past decisions, infer narrowing from notes or optional fields, or claim that every independent route to the shared artifact has been revoked.

6. Preserve the approved temporal meaning: termination affects the exact source path from effectiveFrom, assessed at trusted evaluation/effect time; caller subjectTime cannot restore revoked authority. Define permitted result-time mappings and postconditions without changing revocation eligibility, index completeness, or lookup semantics owned by authorization.

7. Determine the exact domain event family and commit class from governing law and the active Event Grammar. Keep the domain result distinct from an authorization audit EvidenceEvent. Do not infer classification from the action name or add an automatic companion event/current-state consequence. If classification needs an independently owned amendment, identify and stop at that prerequisite.

8. Define immutable validation evidence with exact intent, result, contract, result-schema, and relevant source bindings/digests; field-mapping and postcondition dispositions; and truthful PASS, FAIL, legitimate NOT_APPLICABLE, and dependency-bound NOT_EVALUATED outcomes. No unevaluated dependency may count as a passing protected-effect check.

9. Require validation before the protected transaction commits. A mismatch commits no revocation effect and does not rewrite the authorization result. Consume the separately owned human-finalization, current-state recheck, atomic evidence/effect persistence, single-use consumption, retry, and recovery protocol; do not implement a transaction manager or create a second evidence store in this task.

10. Include positive and hostile case specifications traceable to each invariant. Cover correct exact-grant termination; wrong family/grant/digest/artifact; target, scope, tenant, or twin substitution; changed reason or effective time; wrong human/representation/time binding; narrowing or hidden replacement semantics; result-ID collision; changed result after validation; grant mutation; missing or unreconstructible proof; incomplete validation; stale finalization state; and partial evidence/effect visibility. Distinguish domain-contract checks from tests owned by the shared authorization/transaction boundaries.

11. State the later immutable contract identity/version/digest and policy-manifest binding requirements without materializing schema bytes in Phase A. Include an authority map, invariant-to-source-to-case traceability, staged delivery, unresolved prerequisites, an explicit semantic approval card, and a one-boundary completion test.

Non-goals and stop conditions

• No authorization eligibility, action matrix, extractor, sovereignty, approval, reason-code, lookup/index, or generic revocation-law change.
• No AuthorityGrant or DelegationGrant revocation contract; no NARROW_SCOPE, NARROW_ACTIONS, or NARROW_TIME implementation.
• No sharing-grant issuance, read/disclosure enforcement, transport release, external notification, key custody, retention decision, or deletion of previously delivered data.
• No other protected-effect family, schema materialization, database writer/migration, OFARM2 runtime change, current/default promotion, merge authority, or production-readiness claim.
• If review requires another trust boundary, stop before editing it and propose a separate linked prerequisite. Do not append cross-boundary fixes merely to clear review.

Completion and handoff

The first deliverable is a reviewable, one-file Phase A candidate with its evidence and explicit open dependencies. Creating this issue does not approve its proposed semantics or authorize implementation. Semantic approval must be recorded against the reviewed candidate; later executable materialization and promotion remain separate decisions.

What is next: inventory the authoritative revocation carrier and classification surfaces, then prepare the one-file Phase A candidate for review.

[samovers]

Phase A candidate is ready for focused review in draft PR #28, exact head ae080693c2ea0c017ae8cc7a7080841ccbb306c0.

The PR adds only one 417-line historical design document. The primary trust boundary stayed sharing-revocation domain effect semantics and commit classification: one exact SharingGrant, one new RevocationDecision v0.1, and TERMINATE only. No runtime, schema, accepted-law, authorization-rule, transaction-protocol or currentness change was made.

The candidate maps all 12 current result properties, defines nine required postconditions, and specifies 30 positive/hostile cases. The cases are design specifications, not executed effect tests. Repository hygiene, currentness, cross-reference and steward checks passed locally; GitHub's automatic repository-validation and generated-currentness checks also passed at this head. The remote file blob matches the verified local document.

Please focus review on the human approver's Party mapping, literal reason/scope/time mappings, governance classification, proof kept outside the unchanged carrier, and exact fresh-approval transaction handoff. The decision card is OFARM-ISSUE27-SHARING-REVOCATION-PROTECTED-EFFECT-001, version 1, in section 15.

Review and semantic approval remain pending. This does not complete #12, materialize executable bindings, promote canonical contracts, authorize a merge, or unblock OFARM2 implementation.

What is next: review this exact candidate head and resolve any in-boundary findings before considering Phase A semantic approval.

[samovers]

Phase A semantic approval recorded

The task user's Phase A semantic approval for draft PR #28 is recorded here. It covers decision OFARM-ISSUE27-SHARING-REVOCATION-PROTECTED-EFFECT-001, version 1, at exact head 4e186aab5c238215906fcf9b24ce74443abb6f72 after the no-blocker re-review.

The primary trust boundary stayed sharing-revocation domain effect semantics and commit classification. The approved candidate defines one exact SharingGrant, one immutable RevocationDecision v0.1 using TERMINATE, 12 result-field mappings, nine required postconditions and 31 design cases. The corrected consumed ceiling is DELEGATION_ALLOWED; authorization and the shared transaction protocol remain separately owned.

This completes the candidate's Phase A semantic approval only. It does not merge PR #28, promote accepted/current law, materialize schemas or executable bindings, complete parent #12, activate a partial rule set, or authorize OFARM2 runtime implementation. The 31 cases remain specifications rather than executed effect tests. The reviewed 420-line document and its Git blob 944e3d3c14bea3996a80e7ff03675f1b52babd59 are unchanged; PR #28 remains draft and unmerged. No other trust boundary changed.

This issue remains open for the separately gated contract/binding work. Source, intent/contract/manifest, shared-evidence, retention (#14), exact binding review and staged-delivery prerequisites remain outstanding.

What is next: reconcile the remaining canonical prerequisites under #12 and #14 before selecting the next bounded task; executable binding review and OFARM2 implementation remain gated.