Canon / Service composition

Counterparty Reconciliation

Resolve the discrepancy, preserve the record. 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

Reproduce counts and explain retries, conflicts, corrections, and stale decisions from separately labeled synthetic observations. No real counterparty supplies or approves them.

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 / counterparty-reconciliation

Counterparty Reconciliation

Map revision 2026-09-12.1

Specified mechanism

Normalize only the comparison view while retaining original signed observations, then apply a pinned reconciliation rule and collect separately authorized decisions.

Why it matters

Make investigations less dependent on screenshots, repeated handoffs, and an undocumented choice of whose log to trust.

Target capabilities: not all implemented by this reference

The calculation and each participant's acceptance are different version-bound objects. Disputes and superseding evidence can coexist with valid cryptographic checks.

  • Cross-party differential replay
  • Explicit source precedence without overwriting source bytes
  • Idempotent logical-event reconciliation
  • Acceptance invalidation on material change
  • Selective evidence exchange within party permissions

IN Contract inputs

  • authenticated party observations
  • logical-event identity and attempts
  • rule version and precedence
  • correction and late-arrival policy
  • participant identity and decision authority

OUT Specified outputs

  • immutable reconciliation case
  • per-party count reproduction
  • difference explanation with evidence references
  • exception and correction history
  • version-bound accept, reject, or escalate decisions
Canonical composition8 canon components
Service lifecycle statesSpecification, not current case state
  1. collecting
  2. ready_to_calculate
  3. calculated
  4. pending_acceptance
  5. accepted
  6. disputed
  7. superseded

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.

Count difference

count_delta
Numerator
producer logical count minus recipient reproduced logical count
Denominator
not a ratio
Unknown when
one side lacks reproducible permitted inputs
Does not mean
automatic billing adjustment

Jointly accepted revisions

accepted_case_rate
Numerator
eligible current case revisions accepted by every required authorized party
Denominator
eligible current calculated case revisions
Unknown when
required party set is not fixed
Does not mean
matching signatures

Investigation effort

investigation_effort
Numerator
measured handling minutes for closed comparable cases
Denominator
closed comparable cases in the same cohort
Unknown when
baseline or case timestamps are unavailable
Does not mean
a synthetic time-saving claim
Production gatesNot accepted

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

  1. 01party-specific authenticated adaptersEvidence required
  2. 02authorized decision rolesEvidence required
  3. 03record-custody and source-precedence agreementEvidence required
  4. 04replayable versioned reconciliation ruleEvidence required
  5. 05dispute ownership and escalation processEvidence 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.

Counterparty Reconciliation criteria4 criteria
  1. CR-01P0
    Given
    two consistent attempts for one logical event
    When
    the agreed deduplication rule runs
    Then
    attempt count rises while logical count stays one
  2. CR-02P0
    Given
    conflicting records with valid signatures
    When
    the case is checked
    Then
    integrity can pass while reconciliation remains disputed
  3. CR-03P0
    Given
    acceptance of revision one
    When
    a material correction creates revision two
    Then
    the earlier decision is retained and revision two awaits its own decision
  4. CR-04P1
    Given
    a delayed authorized observation
    When
    the late-data rule admits it
    Then
    a new case revision is created without changing previous exports
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