Define AssertionRecord protected-effect contract

[samovers]

Parent: #12

Depends on the exact approved authorization candidate in PR #11 at 03a21f669ee04f96d444e14f00ae7212cab04803. The shared transaction dependency in #19 is complete at approved PR #20 head 98f8c4fafbae42c8f7fd931f43f53adcb4733713.

Outcome

Define one content-addressed protected-effect contract for the assertion family so ASSERT_STRUCTURE, ASSERT_OPERATION_CLAIM, and ASSERT_COMPLIANCE can produce immutable AssertionRecord results that faithfully implement the exact authorization-bound effect intent without widening a claim, fabricating acceptance, or changing the authorization result.

Primary trust boundary

Assertion-domain effect semantics and commit classification: the boundary that owns the assertion result carrier, exact intent-to-result mappings, permitted derivations, forbidden widening, event/commit classification, postconditions, and immutable validation evidence.

Intended PR boundary

One non-authoritative Phase A RFC candidate under the historical phase-report lane. It may inventory current assertion carriers and governing law, propose the minimum future contract delta, define exact mappings and hostile cases, and name separately governed prerequisites.

It must not edit authorization law or PR #11, current or draft schemas, Event Grammar, accepted RFCs, companion policies, transaction coordination, evidence retention/custody, database authority, currentness, OFARM2 runtime code, or production claims.

Acceptance criteria

• Bind exactly three authorization actions: ASSERT_STRUCTURE, ASSERT_OPERATION_CLAIM, and ASSERT_COMPLIANCE; no other action or result family enters this contract.
• Map those actions to the contract-supported assertion subtypes using the exact approved PR RFC candidate: executable authorization evidence v0.2 #11 effect-intent schemas and authorization envelope, without caller-selected subtype substitution.
• Identify the exact immutable governed target, effect subject, scope, tenant, twin, subject time, assertion body, evidence, policy/rule, performer-provenance, and proposed-result bindings required for each action.
• Keep current reporter authority separate from alleged historical performer identity or authority for operation claims.
• Define every result field as exact-copy, contract-defined derivation, required absence, or separately governed input; ambiguous or lossy mappings fail.
• Prevent an assertion submission from claiming review acceptance, promotion, current-state truth, compliance truth, successful execution, or any wider consequence not present in the authorized intent and owning contracts.
• Determine the exact Event Grammar family and commit class for each result, or stop on a separately owned Event Grammar prerequisite rather than inventing a local classification.
• Define an immutable validation trace containing the intent, proposed result, contract, result-schema, mapping, postcondition, and relevant source digests with truthful PASS, FAIL, legitimate NOT_APPLICABLE, and dependency-bound NOT_EVALUATED dispositions where needed.
• Require protected-effect validation before the shared Define governed human-approval transaction and consumption protocol #19 atomic transaction gate; a domain validation failure commits no assertion effect and does not rewrite the authorization outcome.
• State the minimum future AssertionRecord carrier or protected-effect schema delta without creating or promoting schema bytes in Phase A.
• Add production-reachable hostile cases for subtype substitution, changed assertion bodies, target/scope or tenant mismatch, subject-time substitution, evidence or policy substitution, reporter/performer conflation, false execution/compliance claims, result-ID collision, mutation of an existing assertion, omitted required fields, and partial transaction visibility.
• Include invariants, traceability to Define protected-effect contracts for authorization-bound state changes #12 and the approved PR RFC candidate: executable authorization evidence v0.2 #11 inputs, staged delivery, an explicit steward approval card, and a one-boundary completion test.

Non-goals

• No authorization eligibility, action, target, posture, path, reason, approval, or consumption change.
• No observation, evidence-link, intervention, execution-report, review, pack, output, sharing, or read contract.
• No generic assertion language or claim-reasoning engine.
• No review/promotion decision, current-state materialization, truth acceptance, or external release.
• No schema materialization, current/default promotion, database/runtime implementation, or deployment claim.

Scope-expansion rule

If the mapping requires a new authorization target or effect-intent field, an Event Grammar amendment, a shared evidence-retention decision, transaction-protocol change, or another domain result family, stop before editing that boundary and open a linked prerequisite or follow-up.

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