Canon / Service composition

Portable Trust

Keep the ability to check. 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

Real Ed25519 signatures on neutral synthetic packages, an explicitly selected demo public key, and a Node offline checker. No accredited implementation validation, outside witness, or live trust authority is implied.

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 / portable-trust

Portable Trust

Map revision 2026-09-12.1

Specified mechanism

Package original signed objects, permitted replay inputs, profile and checker versions, trust context, disclosure boundaries, and a content manifest with a fail-closed verifier.

Why it matters

Reduce dependence on a vendor's availability and preserve a practical review path through disputes, system changes, and retention periods.

Target capabilities: not all implemented by this reference

Algorithm-agile profile verification and as-of trust evaluation keep signature validity, trust status, source availability, replay, and checkpoint evidence separate.

  • Profile-specific algorithm agility without downgrade
  • Offline as-of trust and revocation semantics
  • Independent trust bootstrap and key rotation
  • Deterministic replay with selective disclosure boundaries
  • Package and verifier supply-chain verification

IN Contract inputs

  • original signed artifacts
  • permitted replay material
  • expected keys from a separate trust channel
  • algorithm and checker profile
  • manifest, retention, and disclosure terms

OUT Specified outputs

  • recipient-held evidence package
  • per-check verification results
  • offline replay report
  • trust as-of and unsupported-state report
  • portable correction and revision history
Canonical composition10 canon components
Service lifecycle statesSpecification, not current case state
  1. assembled
  2. manifest_checked
  3. trust_checked
  4. integrity_checked
  5. replayed
  6. partially_verifiable
  7. rejected

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.

Reproducible packages

portable_replay
Numerator
eligible packages reproducing all required supported checks in a clean recipient environment
Denominator
eligible packages tested under the stated profile
Unknown when
recipient-side test has not occurred
Does not mean
downloads or website visits

Trust information age

trust_freshness
Numerator
verification time minus trust snapshot time
Denominator
not a ratio
Unknown when
no authenticated trust timestamp exists
Does not mean
proof no later revocation occurred

Required files retained

retained_completeness
Numerator
required manifest files present with matching digests
Denominator
required files named by the pinned package profile
Unknown when
manifest or profile is untrusted
Does not mean
source completeness
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 trust distribution and rotationEvidence required
  2. 02profile-conformance acceptanceEvidence required
  3. 03independent recipient replayEvidence required
  4. 04retention and recovery testsEvidence required
  5. 05verifier release and dependency integrityEvidence 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.

Portable Trust criteria4 criteria
  1. PT-01P0
    Given
    a complete retained supported package and separate trusted key
    When
    Hive is unavailable
    Then
    the pinned checker reproduces supported checks without network access
  2. PT-02P0
    Given
    a package that substitutes its own key
    When
    verification runs
    Then
    the substituted key does not become trusted
  3. PT-03P0
    Given
    an unsupported mandatory signature profile
    When
    the package is checked
    Then
    unsupported is returned with no fallback to a weaker successful check
  4. PT-04P0
    Given
    valid as-of trust but unavailable current revocation data
    When
    offline verification runs
    Then
    the result states its as-of limit and does not assert current non-revocation
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