Canon / Service composition

Evidence Contract Studio

Define the evidence before the event. 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

An evidence lifecycle

05 composed services

Choose a service to inspect its contract and proof boundary.

Before

Define the obligation

  1. 01SpecifyEvidence Contract StudioSelected service

During

Bind evidence to action

  1. 02AuthorizeAction BoundaryInspect service
  2. 03TraceDecision Evidence GraphInspect service

After

Reconcile. Retain. Replay.

  1. 04ReconcileCounterparty ReconciliationInspect service
  2. 05Verify againPortable TrustInspect service

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

Inspect declared requirements and missing evidence in a fixed neutral synthetic case. A general rules compiler and legal-framework review are separate production deliverables.

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 / evidence-contract

Evidence Contract Studio

Map revision 2026-09-12.1

Specified mechanism

Compile a bounded declarative evidence profile into required fields, source constraints, applicability rules, coverage obligations, and deterministic acceptance checks.

Why it matters

Reduce repeated interpretation of evidence requests and make missing obligations visible before review starts.

Target capabilities: not all implemented by this reference

A versioned obligation graph links each declared requirement to its capture point and verifier, with change-impact analysis across affected evidence and decisions.

  • Dependency-aware requirement compilation
  • Evidence coverage distinct from legal compliance
  • Explicit schema and rule migration impact
  • Source authenticity requirements before capture
  • Contract conformance packs for new adapters

IN Contract inputs

  • workflow scope and purpose
  • source and custodian inventory
  • versioned requirements and applicability
  • capture boundary and expected population
  • retention and disclosure policy

OUT Specified outputs

  • versioned evidence profile
  • requirement-to-evidence map
  • unmapped and untestable obligations
  • profile diff and affected-case report
  • conformance vectors
Canonical composition8 canon components

Each link opens the actual receipt canon, including that component’s own recorded implementation state and proof ceiling. A component’s status does not grant production acceptance to this service.

8 typed receipt contracts · 0 external services · 0 composites

Stipryn (pre-submission proof-level binding)stiprynImprimatur (pre-attestation clearance primitive)imprimaturScreening Attestation Receiptscreening-attestationJurisdictional Clearance Receiptjurisdictional-clearanceEvARevarEvaluation Administration Receipteval-administrationSubmission Attestation Receiptsubmission-attestationRetention Policy Commitment Receiptretention-policy
Service lifecycle statesSpecification, not current case state
  1. draft
  2. review_required
  3. approved_for_scope
  4. active_version
  5. superseded
  6. withdrawn

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

Metric definitions2 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.

Mapped requirements

requirement_coverage
Numerator
applicable requirements with an evidence binding and check
Denominator
all requirements declared applicable in the approved version
Unknown when
applicability is unresolved
Does not mean
percentage legal compliance

Evidence capture coverage

capture_coverage
Numerator
eligible logical events with required evidence complete
Denominator
eligible logical events in the scoped expected population
Unknown when
expected population is not established
Does not mean
received receipts divided by received receipts
Production gatesNot accepted

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

  1. 01reviewed profile and source ownershipEvidence required
  2. 02bounded compiler with no arbitrary code executionEvidence required
  3. 03schema version governanceEvidence required
  4. 04signed profile authorizationEvidence required
  5. 05capture denominator validationEvidence 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.

Evidence Contract Studio criteria4 criteria
  1. EC-01P0
    Given
    an unknown applicability decision
    When
    the profile is evaluated
    Then
    the requirement remains unresolved and cannot increase the covered count
  2. EC-02P0
    Given
    a referenced evidence source is missing
    When
    the case is evaluated
    Then
    the obligation names the missing source and produces an incomplete result
  3. EC-03P0
    Given
    a changed rule version
    When
    a previous case is inspected
    Then
    the original rule remains pinned and a new result requires a new revision
  4. EC-04P1
    Given
    a new source adapter
    When
    the profile conformance vectors run
    Then
    all required positive and negative vectors pass before adapter admission
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 ↗
Architecture specification ↗Operation readiness JSON ↗

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

Stipryn (pre-submission proof-level binding)stiprynCarnac control plane and Arrival CountersignaturecarnacImprimatur (pre-attestation clearance primitive)imprimaturIntent Affirmation Receiptintent-affirmation
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

HiveBound Envelope (typed facade)hivebound-envelopeCapture Commitment Receiptcapture-commitmentAFiR-OCR DocProofafir-ocr-docproofCorpus Commitment Receiptcorpus-commitmentOriginProoforiginproof
03Identity and authority6 canon components

Authority must be linked to the issuer, resource, operation, validity interval, and applicable trust policy.

6 typed receipt contracts · 0 external services · 0 composites

Granter Qualification Receiptauthority-qualificationDelegated authority chainauthority-delegationAuthority Carriage Receiptauthority-carriageAuthority Revocation Receiptauthority-revocationDelegation Attenuation Receiptdelegation-attenuationAuthorization Decision Receiptauthorization-decision
04Serving and effect8 canon components

A declared state is not a trusted measurement. Effect claims require observations at the actual controlled boundary.

8 typed receipt contracts · 0 external services · 0 composites

SiGR MiR (model identity and relineage)sigr-mirSiGR Manifest (streaming model manifest attestation, TEE-less)sigr-manifestNumeric Lineage Receiptnumeric-lineageCache Epoch Receiptcache-epochEntropy Custody Receiptentropy-custodyS2S (Silicon-to-Signature)s2sEffect closure receipteffect-closureEffect Quiescence Receipteffect-quiescence
05Support and evaluation8 canon components

Structural support links, semantic evaluation, technical calculation, and real-world correctness are distinct.

8 typed receipt contracts · 0 external services · 0 composites

SiGR GCA (grounding claims attestation)sigr-gcaDecision Provenance Bindingdecision-provenanceEvARevarEvaluation Administration Receipteval-administrationBonded Performance Attestation (budget leg)bpa-budgetBonded Performance Attestation (attestation leg)bpa-attestationControl Replay Receiptcontrol-replayAnalysis Replay Receiptanalysis-replay
06Handoff and reconciliation6 canon components

A calculated agreement is not party acceptance. Corrections preserve previous evidence and decisions.

6 typed receipt contracts · 0 external services · 0 composites

Custody Handoff Receiptcustody-handoffLedger Parity Receiptledger-parityMulti Source Divergence Detection (MSDD)multi-source-divergenceCorrection and supersession receiptsupersession-receiptProof state transition containerproof-transitionSequence Attestation (SA), event order bracketed by external timesequence-attestation
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

Disclosure Presentation Receiptdisclosure-presentationPortable transition proofproof-transition-portableTransparency Checkpoint Receipttransparency-checkpointRetention Policy Commitment Receiptretention-policyRetention Purge Receiptretention-purgeVerdict Custody Declarationverdict-custody