Canon / Service composition

Action Boundary

Put the control where the action happens. Five composed services connect the evidence required before an action to the records, decisions, and replay that follow it.

Tested bounded referenceNo production acceptanceScoped test evidence
Service map JSON

Choose a service to inspect its contract and proof boundary.

One revision-bound record. Requirements, authority, observations, decisions, and replay stay connected.

Lifecycle position describes the service’s role, not its implementation status. These are compositions of existing canon components, not new receipt types.

Shared reference / Synthetic fixtures only

Inspect the evidence. Keep the distinctions.

Local checks · No external effect

A local in-memory effect store demonstrates one-use admission, refusal, and replay prevention. It controls no external system and is not durable across a restart.

This workbench consumes hive.reference.* application formats. It does not execute the selected canonical receipt verifiers; composition links are not conformance evidence.

Reference checks have not run. JavaScript loads the selected fixture and checker.
Case / revisionNot loaded
Pinned ruleNot loaded
Demo trust as ofNot selected

Six independent checks. A valid signature is not source truth, party acceptance, or a confirmed effect. Select any result to inspect its evidence.

Evidence in this revision

Counts await a checked fixture. No population is assumed.

Required evidence and its identifiers will appear here after a fixture loads.

Selected package · raw JSON
No package loaded.

Integrity evidence

Not checked

Select a result dimension or an evidence record. The exact data supporting that result stays inspectable.

Case digest
Unavailable
Rule digest
Unavailable
Checker profile
Unavailable
Evidence and check details
No check result loaded.
Exercise the local action boundaryOne-use admission, refusal, and replay

The gate controls only a local in-memory record. It uses the fixture’s declared clock for a reproducible exercise, not current production time. State is lost on reload; no external system is called.

Choose a supported fixture and explicitly select the demo trust policy before exercising admission.

Local events and receipts · raw JSON
No local effect attempted.
Retain this exact snapshot

Exports become available only for the current loaded snapshot.

Offline ZIP requires available release-matched checker files and an explicitly selected trust policy.

All verification results · raw JSON
No verification results.

Service contract / action-boundary

Action Boundary

Map revision 2026-09-12.1

Specified mechanism

Bind the prerequisite evidence, approved payload, destination, tenant, validity interval, and one-use authorization to an effect adapter with atomic consumption.

Why it matters

Prevent a specific unapproved effect while leaving permitted work moving, and retain a reviewable reason for each refusal.

Target capabilities: not all implemented by this reference

The admission decision is tied to the actual effect boundary and its replay state. Pre-effect authorization and post-effect observation are separate, linked artifacts.

  • Payload and destination-bound admission
  • Atomic one-use authorization consumption
  • Revocation-aware failure handling
  • Time-of-check to time-of-effect controls
  • Separate sidecar, shadow, and enforced operating modes

IN Contract inputs

  • bounded action and effect adapter
  • prerequisite evidence and rule version
  • authorized issuer and delegation scope
  • freshness and revocation context
  • idempotency and replay ledger

OUT Specified outputs

  • bound admission or refusal decision
  • consumed one-use authorization
  • post-effect observation where available
  • recovery and partial-effect state
  • bypass and refusal evidence
Canonical composition18 canon components
Service lifecycle statesSpecification, not current case state
  1. requested
  2. evidence_pending
  3. authorized
  4. refused
  5. authorization_consumed
  6. effect_observed
  7. effect_unknown
  8. reconciled

These are declared states of the composed service. They do not change the recorded status: tested_bounded_reference; production not_accepted.

Metric definitions3 definitions · no claimed performance

These are measurement contracts, not measured results. Any published value also needs a unit, interval, rule revision, cohort, and evidence references.

Admission outcomes

gate_decisions
Numerator
allowed, refused, error, and unresolved decisions separately
Denominator
all eligible attempts at the named boundary
Unknown when
capture of attempts is incomplete
Does not mean
all actions in the customer's environment

Confirmed effects in scope

effect_confirmation
Numerator
consumed authorizations with valid matching effect evidence
Denominator
consumed authorizations requiring effect evidence
Unknown when
effect observation is unavailable
Does not mean
global exactly-once assurance

Admission latency

enforcement_latency
Numerator
measured decision latency distribution
Denominator
eligible measured decisions per profile and load regime
Unknown when
no controlled measurement exists
Does not mean
simulation replay throughput
Production gatesNot accepted

No live service, source adapter, or production acceptance is asserted. The following gates must be evidenced for an authorized integration.

  1. 01effect adapter with no uncontrolled bypassEvidence required
  2. 02durable atomic replay stateEvidence required
  3. 03authority and revocation SLAEvidence required
  4. 04failure and partial-effect recovery protocolEvidence required
  5. 05controlled bypass and load testsEvidence required

Acceptance / Full criteria

What must hold before acceptance.

Criteria are not test results

4 service-specific criteria and 14 shared requirements. An exercise of a synthetic case is not completion of this acceptance contract.

Action Boundary criteria4 criteria
  1. AB-01P0
    Given
    an authorization bound to payload A
    When
    payload B is submitted
    Then
    the controlled effect is refused and the mismatch is recorded
  2. AB-02P0
    Given
    a consumed authorization
    When
    the same or concurrent request is retried
    Then
    no additional controlled effect occurs
  3. AB-03P0
    Given
    revoked, expired, or unresolvable authority
    When
    enforced admission runs
    Then
    the action is refused or blocked according to the explicit fail-closed policy
  4. AB-04P0
    Given
    an observational sidecar
    When
    evidence collection fails
    Then
    the result is an evidence gap, not a claim that the customer's action was blocked
Shared service requirements14 requirements
  1. SH-01P0

    Stable signed identities

    Existing signed type strings, bytes, schemas, fixture fingerprints, and canonical anchors are unchanged.

  2. SH-02P0

    Immutable case revisions

    Every calculation, export, and party decision identifies the same case revision, input digest, rule digest, and checker profile.

  3. SH-03P0

    Explicit unknown evidence

    Unknown denominator, absent source, unsupported algorithm, stale trust, and unavailable dependency never become a passing result.

  4. SH-04P0

    Independent dimensions

    Integrity, trust, coverage, calculation, acceptance, and effect are displayed separately without a misleading aggregate success badge.

  5. SH-05P0

    Separate trust configuration

    A key supplied inside a package cannot authorize itself. Trust purpose, key epoch, validity interval, revocation state, and offline as-of limits are explicit.

  6. SH-06P0

    Preserved corrections

    Corrections reference the original record and reason. Earlier bytes remain inspectable and prior acceptance does not silently transfer to the new revision.

  7. SH-07P0

    Strict inputs and safe resources

    Schemas bound sizes, safe integer ranges, identifiers, timestamps, nesting, duplicate keys, unknown fields, graph cycles, and invalid references. Ambiguous input is rejected.

  8. SH-08P0

    Tenant and privacy boundary

    An integrated service enforces tenant scope and roles server-side; its public reference accepts synthetic fixtures only and makes no customer-source calls.

  9. SH-09P0

    Recipient portability

    A retained package, separate trust configuration, pinned checker, file manifest, and instructions reproduce the declared checks with Hive unavailable.

  10. SH-10P0

    Reproducible observability

    Every metric identifies its unit, numerator, denominator, interval, rule revision, and evidence references. Replay performance is never advertised as production capacity.

  11. SH-11P0

    No hidden scope expansion

    Discovery cannot alter a pilot, create an engagement, enable an adapter, or cause an external effect. Existing buyer files and shared assets remain byte-identical.

  12. SH-12P0

    Failure and recovery

    Production admission defines backpressure, retries, idempotency, out-of-order input, revocation, partial writes, disaster recovery, and retention behavior before operational acceptance.

  13. SH-13P1

    Interoperable export profiles

    A new adapter preserves original signed bytes and passes version-specific conformance vectors. Unsupported versions fail closed without silent downgrade.

  14. SH-14P1

    Recipient-controlled exercise

    An independent recipient can supply a challenge, run an accepted profile, and retain negative results without relying on the issuer's dashboard.

Maturity and admission model5 distinct stages
specified

Service contract specified

  • versioned contract
  • canonical dependency map
  • failure semantics
  • acceptance criteria
reference

Reference implementation

  • bounded working implementation
  • adversarial tests
  • reproducible package
  • explicit reference boundary
integrated

Authorized integration

  • authenticated sources
  • tenant isolation
  • authorized owners
  • trust and retention configuration
  • effect-boundary tests where applicable
operational

Operationally accepted

  • deployed revision acceptance
  • controlled load and recovery evidence
  • support and incident process
  • customer acceptance
independently_exercised

Independently exercised

  • qualified separate operator
  • declared challenge and scope
  • retained reproducible evidence
  • documented unresolved findings

Shared architecture

One canon. Explicit boundaries.

Open the receipt canon ↗

The five services compose these layers. None replaces a canonical component or extends what it proves.

01Demand and scope4 canon components

Demand defines the evidence required. Gateway arrival and downstream execution remain separate facts.

3 typed receipt contracts · 1 external services · 0 composites

02Source and capture5 canon components

Commitments bind supplied bytes and declared source context, not source truth.

5 typed receipt contracts · 0 external services · 0 composites

03Identity and authority6 canon components
04Serving and effect8 canon components
05Support and evaluation8 canon components
06Handoff and reconciliation6 canon components
07Disclosure and continuity6 canon components

Verification tools can be public while source evidence stays private. Offline decisions remain bounded by supplied trust information and its as-of time.

6 typed receipt contracts · 0 external services · 0 composites