# Hive Five Canon Services

## Versioned product architecture

| Field | Value |
| :--- | :--- |
| Document version | 1.0.2 |
| Specification date | 2026-09-12 |
| Status | Builder-ready target architecture, with release and integration acceptance gates |
| Product identity | Make automated work checkable |
| Service IDs | `evidence-contract`, `counterparty-reconciliation`, `decision-evidence`, `action-boundary`, `portable-trust` |
| Canon relationship | Five service compositions over the existing canon, not five new signed primitive types |
| Delivery boundary | Canon discovery, contracts, reference evidence, and independently qualified integrations |
| Runtime claim | This specification does not assert that the five hosted services, proposed APIs, or customer integrations are installed |
| Change authority | Product owner owns service scope. Canon steward owns primitive identity. Security owner owns trust policy. Integration owner owns effect-boundary acceptance. |

Normative language: **MUST** is a release requirement for the stated acceptance tier. **SHOULD** is a P1 requirement that needs a documented exception if omitted. **MAY** is optional and must not be advertised as installed merely because it appears here. Proposed application objects and API names in this document are not additions to the primitive registry.

### Reading order

1. Problem, canon composition, shared architecture, and discovery define the product and evidence model.
2. The five named service sections define their contracts.
3. Shared trust through metrics define interoperability, operations, threats, and acceptance.
4. Packaging, reference implementation, and open decisions define readiness and release audit.
5. Appendix A accounts for the whole public canon.

## Problem, goals, and product boundaries

### Problem statement

The product is for people who must explain an automated workflow to someone who did not operate it: a recipient, reviewer, operations lead, control owner, or authorized counterparty. The architectural problem is not simply a lack of signed records. It is the absence of a shared, versioned account of what evidence was required, what arrived, how a result was calculated, what action was controlled, and what each party accepted.

The supplied review identifies four outcomes that cannot be compressed into one passing badge: integrity, coverage, rule calculation, and party acceptance. It also identifies missing expected-population definitions, unsupported enforcement implications, and the need to retain evidence outside the website. Unified review: `hive-the-five-unified-review.pplx.md`

Frequency, investigation cost, willingness to pay, and production improvement baselines are **not measured by this architecture**. The problem statements below are product hypotheses to validate through use. Public discovery must not wait for a buyer pilot, but a production outcome claim must wait for its own evidence.

### Five service identities

| Service | Plain English promise | Buyer problem | Concrete product outcome |
| :--- | :--- | :--- | :--- |
| Evidence Contract Studio | Decide what evidence a workflow must produce before relying on it. | Teams interpret requirements differently and discover missing records too late. | A versioned evidence profile, requirement map, capture plan, and explicit gaps. |
| Counterparty Reconciliation | Compare the same case without pretending both parties agree. | Parties count different events, retain different records, and confuse a calculated result with agreement. | A reproducible case with each observation, difference, amendment, and authorized decision preserved. |
| Decision Evidence Graph | Open a result and follow its supplied support. | Reviewers cannot identify which source, transformation, or evaluator supports a decision. | An inspectable dependency graph with link verification, calculation replay, and semantic assessment kept distinct. |
| Action Boundary | Require the right evidence before one controlled effect can happen. | A policy check or receipt can exist while an unprotected execution path still performs the action. | A qualified pre-effect integration with bound authority, refusal, single-use execution controls, and later outcome evidence. |
| Portable Trust | Keep the record and check it without the originating website. | Evidence depends on a vendor session, opaque verifier, or trust configuration that cannot be retained. | A recipient-held package, supported local checker, explicit trust basis, and dated verification result. |

The services form one before, during, and after workflow. A customer may use one service on its own. Composition does not require buying, enabling, or demonstrating all five.

### Goals

1. **Recipient understanding:** a reviewer can identify the case version, rule, supplied evidence, missing inputs, and party decisions without treating cryptographic validity as truth.
2. **Reproduction:** a supported recipient can reproduce each declared deterministic calculation from an exported package, or receive a precise explanation of what prevents reproduction.
3. **Bounded control:** an integration accepted for enforcement prevents its named effect when required authority or evidence fails, including documented bypass and recovery tests.
4. **Evidence continuity:** corrections, key changes, source gaps, and service outages preserve an inspectable history instead of replacing it with an unexplained current status.
5. **Organic discovery:** each service is reachable through the canon now, with accurate maturity, source contracts, synthetic evidence where available, and clear next steps for integration.

Correctness targets are the P0 tests in “Acceptance criteria and independent challenge.” Product improvement targets require baseline collection and owner approval as specified in “Metrics and measurement contracts.” No latency, throughput, savings, adoption, or accuracy promise is created here.

### Non-goals

1. Creating five replacement receipt types, renaming canonical primitives, or normalizing old signed envelopes into a new signed format.
2. Declaring legal compliance, regulator acceptance, source truth, insurer approval, or independent organizational agreement from a signature.
3. Requiring a gateway, blockchain, payment rail, external witness, or hosted lookup for every evidence workflow.
4. Turning an observational service into an execution gate, or presenting a local bounded reference effect as a deployed external control.
5. Modifying existing buyer pitches, making adopters out of prospects, publishing private or unfiled material, or declaring commercial terms.

### Prioritized user stories

| Priority | Story | Service |
| :--- | :--- | :--- |
| P0 | As a control owner, I want to freeze requirements and applicability before a run so later review uses the same evidence contract. | Evidence Contract Studio |
| P0 | As a requester, I want to state my evidence demand without depending on the recipient to cooperate so my own reliance boundary is recorded. | Evidence Contract Studio |
| P0 | As a recipient, I want expected events and received records counted separately so missing capture cannot appear as complete coverage. | All five |
| P0 | As a counterparty, I want to accept or dispute an exact case version without endorsing every source statement so my decision has a clear scope. | Counterparty Reconciliation |
| P0 | As a reviewer, I want to distinguish a linked passage from an evaluated supporting passage so I know what was actually checked. | Decision Evidence Graph |
| P0 | As an operator, I want a refused action to remain impossible through every documented route into the named effect so a policy result is not merely advisory. | Action Boundary |
| P0 | As a recipient with no network, I want a retained package to show what verifies, what replays, and what trust facts are only known as of a date. | Portable Trust |
| P0 | As a data owner, I want to disclose only permitted evidence and see which conclusions the omissions prevent. | All five |
| P1 | As a profile maintainer, I want a proposed ruleset change to identify affected obligations and prior cases without rewriting historical decisions. | Evidence Contract Studio |
| P1 | As a case owner, I want to invite an additional authorized party and preserve earlier quorum decisions under their original rules. | Counterparty Reconciliation |
| P1 | As an investigator, I want to replace one input in an isolated replay and see affected results without changing the original case. | Decision Evidence Graph |
| P1 | As an integration owner, I want a shadow evaluation of a candidate policy without changing the production enforcement mode. | Action Boundary |
| P1 | As a trust administrator, I want to rotate or retire a key while retaining the ability to evaluate historical packages under dated policies. | Portable Trust |

## Canon composition and evidence of current status

### Exact identity rules

The inspected registry is schema version `1.1.0` and records 134 entries: 105 typed receipt contracts, 16 external services, and 13 product composites; all 134 entries carry `current_acceptance.status: not_tested`. Current registry: `canon/registry/hive-canon-registry.json`

Registry entries use `canonical_type`, `anchor`, and `category`, not a generic `id` field; some external and composite entries have a null `canonical_type`. Current registry: `canon/registry/hive-canon-registry.json`

Builders MUST therefore resolve a primitive reference using the exact `canonical_type` plus its registry anchor and category. For an entry without a type, use the exact anchor plus category. Service IDs live in a separate namespace. Do not fabricate a dotted receipt type from a service ID or a composite name.

Each release MUST pin a digest of the registry bytes it used. A new registry snapshot can add discovery mappings without reclassifying an old receipt, altering an old signature, or upgrading an integration's operational acceptance.

### Service-to-canon spine

The following selected component sets are resolved directly from the authoritative `composition_anchors` arrays. They are discovery composition selections, not claims that a runtime adapter is installed. Exact type and category provenance: `canon/registry/hive-canon-registry.json`; selection provenance: `canon/surfaces/surface-map.json`.

| Service | Exact selected canonical types | Selected category count |
| :--- | :--- | :--- |
| Evidence Contract Studio | `proof.demand`, `imprimatur.clearance`, `screening.attestation`, `jurisdictional.clearance`, `eval.attestation`, `eval.administration`, `submission.attestation`, `retention.policy` | 8 typed contracts |
| Counterparty Reconciliation | `custody.handoff`, `ledger.parity`, `divergence.record`, `mandate.crossacceptor`, `authority.carriage`, `supersession.receipt`, `proof.transition`, `disclosure.presentation` | 8 typed contracts |
| Decision Evidence Graph | `sigr.gca`, `afir.ocr.docproof`, `decision.provenance`, `hivebound.envelope`, `capture.commitment`, `sigr.mir`, `sigr.manifest`, `numeric.lineage`, `cache.epoch`, `entropy.custody`, `s2s.signature`, `analysis.replay`, `stage.replay` | 13 typed contracts |
| Action Boundary | `imprimatur.clearance`, `proof.demand`, `authorization.decision`, `authority.qualification`, `authority.delegation`, `authority.revocation`, `authority.carriage`, `delegation.attenuation`, `proof.transition`, `effect.closure`, `effect.quiescence`, `usap.pbs`, `usap.refusal`, `usap.howler`, `usap.perimeter`, `usap.diurnal`, `usap.egress`, `usap.forensic` | 18 typed contracts |
| Portable Trust | `proof.transition.portable`, `transparency.checkpoint`, `receipt.registry.sovereign`, `disclosure.presentation`, `replay.disclosurefree`, `viewkey.disclosure`, `retention.policy`, `retention.purge`, `verdict.custody`, `control.replay` | 9 typed contracts + 1 external service |

`canon/surfaces/canon-bindings.json` is the service dependency annotation contract. It resolves every selected service anchor and shared-layer anchor to its exact canonical type and category, use, applicability, required check level, required constituents, and narrowing limitation. Its inherited boundary text and verdict ceilings are preserved from the registry; annotations may narrow but never strengthen them.

Selected components include typed receipt contracts and external services. Use “canon components” for a mixed category count, not “primitives.” The bindings manifest does not create receipt types, change original registry entries, or claim that the reference executes the selected canonical verifiers.

`proof.transition` is selected for Counterparty Reconciliation, Action Boundary, and the shared reconciliation layer. It is **not** in the selected service arrays for Decision Evidence Graph or Portable Trust. Its use in those two service designs below is conditional: a full transition replay would require admitting the full source container and actual input envelopes under a separately qualified adapter. The portable final-state assertion alone cannot supply those constituents.

Other conditional instruments mentioned in service prose remain optional profile design choices unless they appear in that service's selected array. Their discussion does not silently alter the catalog.

Bindings remain profile-specific. In particular:

* `capture.commitment` commits recording-related bytes and an ordered recording chain; do not turn it into a universal capture-of-anything primitive. Capture commitment schema: `hive-verifier-api/src/typed/schemas/capture-commitment-v1.json`
* `authorization.decision` has a specific observer and payment-related evidence boundary; it is not a generic bearer capability for arbitrary actions. Authorization decision schema: `hive-verifier-api/src/typed/schemas/authorization-decision-v1.json`
* `control.replay` covers supplied control-cycle evidence and a specified replay procedure, not arbitrary business calculations or physical causation. Current registry: `canon/registry/hive-canon-registry.json`
* `stage.replay` is selected for Decision Evidence Graph, but records staged preprocessing, digest comparisons, and reported stage custody; it does not execute the stages, and `stages_reexecuted_by_service` is fixed to false. Stage replay schema: `hive-verifier-api/src/typed/schemas/stage-replay-v1.json`
* The typed `hivebound.envelope` facade and the original HiveBound envelope are distinct verification profiles, with separate schema routing. HiveBound facade schema: `hive-verifier-api/src/typed/schemas/hivebound-envelope-v1.json` Schema routing: `hive-verifier-api/server.js`

### Demand is not a gateway

`proof.demand`, anchor `stipryn`, binds a request digest and anchored proof requirements declared by the requesting party; it neither transmits nor rewrites the request and does not establish that a response satisfies those requirements. Its current schema permits proof levels `none`, `cited`, `sourced`, `verified`, and `attested`. Proof demand schema: `hive-verifier-api/src/typed/schemas/proof-demand-v1.json`

The Studio MUST define how a selected profile interprets these labels. It MUST NOT treat the word `verified` inside a demand as an already completed verification.

`gateway.countersignature`, anchor `carnac`, is an external-service entry, while `carnac-gateway`, `carnac-director`, and `carnac-governance` are composites rather than signed primitive types. Current registry: `canon/registry/hive-canon-registry.json`

A requester's demand MAY be used without a gateway. A qualified gateway MAY compare origin and arrival evidence, but that comparison does not become party acceptance, semantic correctness, or effect prevention by association. `receipt.reduction`, anchor `r3pv`, and `flow.protection`, anchor `protected-flow`, remain separate external composition options whose current acceptance is not established by this release. Current registry: `canon/registry/hive-canon-registry.json`

### Installed code is not installed service

The source exposes a service-local `POST /verify` and `GET /schema`; `POST /verify` invokes envelope verification and is not a universal five-service API. Verifier server: `hive-verifier-api/server.js`

The supplied repository review found no implementations of `/api/frameworks`, `/api/receipts/compliance/latest`, `/api/receipts/bilateral/latest`, `/api/attestations/grounding/summary`, `/api/gate/decisions`, `/api/demo/run`, or `/api/verify` in its audited snapshot. Unified review: `hive-the-five-unified-review.pplx.md`

This architecture does not revive those routes as installed endpoints. “Discovery, proposed manifest, and API contract” defines new proposed resource interfaces with their own status fields. Adapter acceptance MUST verify the exact host, path, method, schema, authorization, deployment revision, and response behavior. A health response or a historical production label is insufficient.

## Shared architecture and evidence model

### System components

```text
Canon discovery and service manifest
            |
Evidence Contract Studio
  profile + demand + source and population plan
            |
Authenticated source adapters and retained original bytes
            |
Immutable case event log + artifact store + tenant authorization
            |
       Three coordinated service views:
       Counterparty Reconciliation
       Decision Evidence Graph
       Action Boundary
            |
Versioned case projection + separate party decisions
            |
Portable Trust packager and local verification
            |
Recipient-held evidence + later challenge + correction
```

Shared services MUST include:

* A profile store with immutable released versions and separately editable drafts.
* An append-only case event log with tenant-scoped sequence numbers and explicit corrections.
* An artifact store retaining original bytes and authorized, versioned derived views.
* A typed adapter registry selecting a verifier by exact envelope profile, schema, and algorithm.
* An evaluator runner distinct from signature checking and from deterministic business-rule calculation.
* A trust-policy resolver with dated key, organization, authority, and revocation information.
* A read-model projector serving the same snapshot to all five views.
* An export planner that computes the transitive evidence closure permitted for a recipient.

Only Action Boundary's qualified enforcement path belongs on the critical path to an external effect. Observational capture failures MUST become evidence gaps, not a claim that an action was blocked.

### Shared application objects

These are proposed service objects, not canonical signed receipt types. A profile MAY bind their bytes using a compatible existing canonical contract when that contract's schema and ceiling genuinely fit. It MUST otherwise preserve their own application authentication evidence without claiming a canon primitive exists.

| Object | Required content | Identity and immutability |
| :--- | :--- | :--- |
| `EvidenceProfile` | Profile ID/version, owner, applicability, rule references, requirements, population method, source classes, adapters, authority policy, timing, exclusions, disclosure, retention, limits | Released version is immutable. Its digest covers normative fields. A change creates a new version. |
| `CaseSnapshot` | Case ID, tenant scope, revision, profile digest, event-log checkpoint, evidence-set digest, source mode, six result dimensions, trust/freshness, decisions, unresolved reasons | Revision is monotonic within the case. Snapshot digest identifies the exact projected state. |
| `EvidenceRef` | Original artifact digest and byte length, media type, canonical type and schema if applicable, envelope profile, origin/source class, capture times, access classification, retention, verification reference | Digest identifies bytes, not identity, truth, or permission to fetch them. |
| `CoverageStatement` | Expected population descriptor, bounded window, population authority, source snapshot/cursors, expected and observed IDs or retained commitments, exclusions, late policy, counts, status | Each statement is bound to a case revision and population snapshot. Later evidence creates another statement. |
| `CalculationRun` | Rule ID/version and executable digest, input closure, units, numeric rules, runtime build, start/end, result, errors, replay class | Never inherits the previous run's result after an input or rule change. |
| `PartyDecision` | Signed tenant scope, intended audience, decision profile, party and actor, role, authority reference, exact case/result digest, decision, stated scope, reason, time, authentication evidence, supersession reference | Append-only decision history. No automatic acceptance inheritance or cross-tenant replay. |
| `SemanticAssessment` | Claims and support spans, evaluator identity/method/version, input digest, rubric, result, uncertainty, abstentions, run details | Distinct from a GCA reference link and from signature integrity. |
| `BoundaryAttempt` | Action ID/digest, mode, policy/version, authority snapshot, nonce, idempotency scope, prerequisite evidence, decision, reservation, effect record and status | Logical action and physical attempts are distinct. One accepted authorization cannot silently authorize a modified action. |
| `VerificationReport` | Checker/profile versions, package digest, check mode, trust snapshot, verification time, per-check results, omissions, warnings | A derived report. It never overwrites the original receipt or becomes an independent witness by being signed by the same operator. |

Every object MUST declare `object_version`. Unknown required fields or unsupported versions MUST produce `unsupported_profile`, not partial success. An extension namespace MAY carry optional annotations only when the profile defines whether those bytes affect identity and computation.

### Common field rules

* IDs are opaque, stable, tenant-scoped application identifiers, not email addresses or account numbers.
* Application timestamps use UTC with an explicit offset and retained precision. Preserve original typed timestamp formats unchanged inside original envelopes.
* Record `event_time`, `observed_at`, `ingested_at`, `evaluated_at`, and `verified_at` separately where applicable. An issuer's timestamp is a declaration unless a separately accepted time source supports it.
* Digest references specify algorithm, encoding, exact byte target, and target length. Body digest, full-envelope digest, and package digest are different fields.
* Financial amounts, quantities, and rates in new application objects use integer units or canonical decimal strings with units, scale, rounding, and overflow policy. Binary floating-point approximations MUST NOT silently control a threshold.
* Missing, null, zero, empty, redacted, not applicable, and unsupported are distinct states. A parser MUST NOT coerce one into another.
* Source class is one of `synthetic`, `caller_asserted`, `authenticated_source`, `independently_observed`, or `derived`. `independently_observed` requires a separate relationship assessment; the label is not awarded by key count.
* Every reference identifies whether its bytes are included, authorized for later retrieval, withheld, deleted under policy, unavailable, or not collected.
* An object containing synthetic evidence MUST remain visibly synthetic unless a profile explicitly permits a mixed-source case and identifies each source separately. Production totals MUST exclude synthetic records.

### Six independent result dimensions

The UI and API MUST expose all six dimensions even when another one fails. Integrity, coverage, calculation, and party acceptance remain the four core evidence outcomes; trust and effect are separate first-class dimensions, not hidden qualifiers.

| Dimension | Allowed application states | Meaning |
| :--- | :--- | :--- |
| Integrity | `pass`, `fail`, `unsupported`, `unavailable`, `not_checked` | Whether the supplied bytes passed the selected schema, digest, signature, and typed checks. A typed adverse verdict can still be an intact valid receipt. |
| Coverage | `complete`, `incomplete`, `unknown`, `not_applicable` | Relationship between known expected evidence and observed evidence within a frozen scope. |
| Calculation | `reproduced`, `different`, `blocked`, `not_applicable` | Whether the declared procedure was rerun and what resulted. A reproduced result can be a refusal or adverse outcome. |
| Trust, field `trust` | `trusted_for_scope`, `untrusted`, `revoked`, `unknown`, `not_checked` | Whether independently configured policy accepts the signer for this purpose and time. |
| Effect, field `effect` | `not_attempted`, `refused`, `authorized`, `observed`, `confirmed_in_scope`, `unknown`, `not_applicable` | What is known about the named effect, separately from policy evaluation. |
| Party acceptance, field `acceptance` | Per required party: `accepted`, `rejected`, `escalated`, `pending`, `stale`, `not_applicable` | The party's authenticated decision about its stated scope and exact case version. |

These are the exact discovery-map dimension IDs and states. Service map: `canon/surfaces/surface-map.json`

Detailed reasons such as `missing_input`, `expired_key`, `example_only`, `recorded_only`, `not_evaluated`, `withdrawn`, and `empty_population` belong in `reason_codes` or versioned operation-specific detail fields, not invented top-level map states. An evaluator not run leaves calculation `blocked` if that evaluation is required for the selected calculation, or `not_applicable` if it is outside that calculation's scope. The separate semantic-assessment detail says `not_evaluated`.

Authority, freshness, semantic assessment, and effect evidence are not implicit meanings of an integrity pass. A withdrawn decision is retained historically, marked stale for current reliance, and leaves the required current decision pending. A disputed case may contain rejected, escalated, or pending party decisions.

A profile MAY compute a workflow disposition such as `ready_for_review`, `ready_for_effect`, `blocked`, or `closed_disputed`. It MUST return the explicit predicates used and retain all underlying dimensions. There is no universal `verified: true` field for the whole product.

### Coverage and event identity

The expected-population method MUST be selected before claiming completeness. It can be a committed request roster, an authorized source range with stable cursors, an agreed bounded schedule, or another documented source snapshot. Received receipts alone cannot define what should have arrived.

For a fixed population \(E\), let \(O\) be observed eligible logical event IDs, \(X\) be explicitly approved excluded IDs, and \(D = E \setminus X\). The observed-event numerator is the number of IDs in \(D \cap O\); the denominator is the number of IDs in \(D\). This diagnostic is `observed_event_coverage`, not the catalog's stronger `capture_coverage`, evidence validity, or legal coverage. Required artifacts per event form a separate obligation set.

The outward `coverage: complete` state requires a known expected population and all required evidence obligations satisfied under the profile. Merely observing every event is insufficient if required artifacts are still missing. The catalog's `capture_coverage` numerator counts eligible events with all required evidence complete.

Rules:

1. Preserve the expected-set snapshot or enough authorized material to reproduce it. A digest alone does not let a recipient enumerate or reproduce that set.
2. Count a logical event once. Retain every attempt with its own attempt ID, source cursor, status, and retry relation.
3. Conflicting logical-ID mappings are unresolved conflicts, not whichever record arrived last.
4. Count unexpected events separately. Do not inflate the denominator after seeing an inconvenient result without an explicit population amendment.
5. An unknown population produces `coverage: unknown` and null numerator/denominator where they cannot be established.
6. An established empty denominator produces `reason_codes: ["empty_population"]` with a null ratio, never 100 percent coverage. Use `not_applicable` if the profile permits an empty scope; otherwise use `incomplete` with the missing-scope obligation.
7. Use event-time windows with a declared inclusion rule, such as `[opens_at, closes_at)`, and a separately declared late-arrival cutoff. Closing a window freezes a statement, not history.
8. A late or corrected record creates a new case revision, marks affected prior decisions as applying to an older revision, and triggers recalculation only under the amendment policy.
9. A recorded artifact can count as observed while failing integrity. Publish observed, valid, invalid, withheld, late, and missing counts separately.

### Case and correction lifecycle

```text
draft -> scoped -> collecting -> reviewable -> under_review
under_review -> closed_accepted | closed_disputed | closed_unresolved
any retained revision -> superseded_by(new revision)
```

`reviewable` means enough structure exists to review, not that coverage is complete or all checks pass. Closure is a workflow decision with an explicit rule and actor. It is not proof that no later correction exists.

A correction MUST:

1. Name original evidence and affected case/result digests.
2. State reason, author, authority, effective time, observation time, and scope.
3. Preserve old bytes and original verification outcomes.
4. Rebuild affected derived results and leave unaffected results traceable to the prior run.
5. Request fresh party decisions where their accepted scope changed.
6. Export both the old and new states when permitted.

`supersession.receipt` can bind the replacement relationship but does not establish that replacement content is correct or mutate the original receipt. Supersession schema: `hive-verifier-api/src/typed/schemas/supersession-receipt-v1.json`

## Discovery, proposed manifest, and API contract

### Discover now, qualify operation separately

The canon MUST offer five named entry points immediately in this release's discovery design. Each entry MUST explain the buyer job, show the existing primitive composition, link its architecture and available artifacts, and state what is specified, locally demonstrated, integrated, or operationally accepted.

The current service map names publication mode `review_preview`, sets `indexable: false`, and requires production acceptance; it explicitly permits canon discovery without changing an engagement or authorizing an integration. “Discover now” means reachable through the canon review surface, not a claim that the preview is publicly search-indexed or operationally accepted. Service map: `canon/surfaces/surface-map.json`

No pilot outcome is a prerequisite for publishing an accurate service description or a labeled synthetic reference. No unimplemented service may be labeled live simply to make discovery more compelling.

Navigation SHOULD work from both directions:

* A service page links to the canonical instruments it composes.
* A primitive page or canon map points to the service jobs that can use it.
* Before, during, and after workflow filters reveal families without turning every primitive into a top-level product.
* Every displayed result opens its exact case revision, evidence, rule, and unresolved reasons.
* Back navigation preserves case, scenario, selected evidence, and keyboard focus.

Discovery MUST remain confined to canon and approved public service material. Existing buyer demos do not gain cross-sell cards or links as a side effect.

### Installed discovery-map contract and proposed runtime manifest

The release's machine-readable catalog is `surface-map.json`, with `schema_version: "1.0.0"`, `map_id: "hive.canon.service-surfaces"`, `kind: "service_composition_map"`, and `counts_as_receipt_contract: false`. Its `surfaces` array uses `id` and `name` for the five service identities. Service map: `canon/surfaces/surface-map.json`

The map's exact service fields are `id`, `name`, `eyebrow`, `headline`, `promise`, `buyer_question`, `value`, `mechanism`, `differentiator`, `composition_anchors`, `inputs`, `outputs`, `state_machine`, `advanced_capabilities`, `proof_ceiling`, `reference_scope`, `production_status`, `reference_status`, `discovery_path`, `reference_scenarios`, `metrics`, `production_gates`, and `acceptance_tests`. A tested reference additionally requires `reference_evidence` with an accountable owner and hash-bound scoped acceptance. Service map: `canon/surfaces/surface-map.json`

Builders MUST preserve those field names. Retired campaign labels are excluded from the public map; the five service identities are authoritative here. `composition_anchors` is the authoritative discovery selection. Additional conditional instruments discussed in this architecture are design options, not silently added installed dependencies.

The map uses the maturity IDs `specified`, `reference`, `integrated`, `operational`, and `independently_exercised`. `reference_status` is independent of `production_status`; the map may say `implementation_under_test` until tests justify an update. Service map: `canon/surfaces/surface-map.json`

The following **separate proposed runtime manifest extension** adds operation-level detail without renaming the installed map or claiming that this extension is already served:

```json
{
  "manifest_version": "1.0.0",
  "id": "evidence-contract",
  "name": "Evidence Contract Studio",
  "kind": "canon_service_composition",
  "new_primitive_types": [],
  "specification": {
    "version": "1.0.0",
    "status": "specified",
    "path": "/canon/surfaces/ARCHITECTURE.md"
  },
  "canon_snapshot": {
    "registry_version": "1.1.0",
    "registry_digest": null,
    "registry_digest_status": "populate_at_release"
  },
  "canon_refs": [
    {
      "canonical_type": "proof.demand",
      "anchor": "stipryn",
      "category": "typed_receipt_contract",
      "use": "pre-submission evidence demand"
    }
  ],
  "discovery": {
    "publication": "review_preview",
    "indexable": false,
    "runtime_claim": "none"
  },
  "reference_implementation": {
    "status": "not_assessed_by_this_specification",
    "source_revision": null,
    "artifact_digest": null,
    "supported_operations": [],
    "test_report": null,
    "scenario_mode": null,
    "key_trust": null
  },
  "integration": {
    "status": "not_accepted",
    "boundary_id": null,
    "owner": null,
    "test_report": null
  },
  "production_acceptance": {
    "status": "not_tested",
    "observed_at": null,
    "source_revision": null,
    "deployed_revision": null,
    "evidence": null
  },
  "api_contracts": [
    {
      "operation": "compile_profile",
      "contract_version": "1.0.0",
      "method": "POST",
      "proposed_path": "/canon-services/v1/profiles/{profile_id}/compile",
      "installation_status": "proposed",
      "accepted_base_url": null
    }
  ]
}
```

A release publisher MUST replace placeholders only with measured evidence. A qualified local implementation can support the map's `reference` tier, with `reference_status` updated by its owner and operation-specific evidence in this proposed extension; that change MUST NOT upgrade `production_status`, `integration`, or `production_acceptance`.

The manifest MUST support per-operation readiness. An exported checker, a static sample, a working in-memory calculation, and a hosted write API are not interchangeable maturity claims. The running build MUST expose its contract and build versions without leaking configuration secrets.

The current-release operation inventory is assigned the path `canon/surfaces/operations.json`; its release owner maintains it separately from this architecture and the proposed hosted manifest. Before publishing an implemented operation claim, that inventory MUST identify the operation, service IDs, supported application profile/version, executable entry point or explicit absence of one, current maturity, owner, test evidence, and remaining limitations. An operation with no executable stays `specified`; a file path alone is not a passing test.

The discovery pages MUST expose this public architecture and operation inventory directly. Advanced mechanism and output lists MUST be labeled **Target capabilities, not all implemented by this reference** unless operation-scoped evidence supports a more specific claim. The inventory and bindings manifest must not be confused: one records implementation scope, the other records permitted canonical composition.

### Proposed resource API

All routes in this table are **proposed application interfaces**, not claims about installed routes. A local library may implement equivalent operations before a server exists.

| Service | Proposed operation and route | Input | Output and concurrency |
| :--- | :--- | :--- | :--- |
| Shared | `GET /canon-services/v1/manifest` | Optional supported manifest version | Public safe capability and maturity data, no tenant records |
| Shared | `GET /canon-services/v1/cases/{case_id}?revision={revision}` | Authorized case and revision | Immutable snapshot, `ETag`, profile and evidence digests |
| Shared | `GET /canon-services/v1/cases/{case_id}/events?after={cursor}` | Tenant-scoped cursor | Ordered event page and next cursor, or explicit expired cursor |
| Evidence Contract Studio | `POST /canon-services/v1/profiles` | Draft profile | Draft ID and revision |
| Evidence Contract Studio | `POST /canon-services/v1/profiles/{profile_id}/compile` | Exact draft revision and adapter capability snapshot | Compiled obligations, unsupported requirements, validation report |
| Evidence Contract Studio | `POST /canon-services/v1/profiles/{profile_id}/releases` | Frozen revision, approvals, effective interval | Immutable profile version and digest |
| Counterparty Reconciliation | `POST /canon-services/v1/cases/{case_id}/observations` | Source batch, cursor, schema and original-byte references | Admission report and new revision |
| Counterparty Reconciliation | `POST /canon-services/v1/cases/{case_id}/reconciliations` | Revision, rule and population snapshot | Calculation run and difference set |
| Counterparty Reconciliation | `POST /canon-services/v1/cases/{case_id}/decisions` | PartyDecision bound to exact revision | Recorded decision or stale-version conflict |
| Decision Evidence Graph | `POST /canon-services/v1/cases/{case_id}/graphs` | Nodes, edges, profile, evidence closure | Graph revision and structural validation |
| Decision Evidence Graph | `POST /canon-services/v1/graphs/{graph_id}/evaluations` | Graph revision, evaluator and method pin | Semantic assessment job/result, never a signature-only proxy |
| Decision Evidence Graph | `POST /canon-services/v1/graphs/{graph_id}/replays` | Graph revision, supported replay scope | Replay result, unsupported steps, affected-node set |
| Action Boundary | `POST /canon-services/v1/boundaries/{boundary_id}/attempts` | Action, authority, evidence, idempotency key | Refusal, pending checks, or bounded reservation |
| Action Boundary | `POST /canon-services/v1/boundaries/{boundary_id}/attempts/{attempt_id}/execute` | Reserved exact action and commit preconditions | Effect status; callable only by the qualified executor |
| Action Boundary | `GET /canon-services/v1/boundaries/{boundary_id}/attempts/{attempt_id}` | Authorized attempt ID | Current known state with uncertainty and closure evidence |
| Portable Trust | `POST /canon-services/v1/cases/{case_id}/exports` | Revision, recipient, disclosure profile, desired replay scope | Export plan/job, omitted dependencies, package digest when ready |
| Portable Trust | `POST /canon-services/v1/verification-jobs` | Explicitly authorized uploaded package and trust-policy reference | Hosted verification job; local verification remains preferred for confidential evidence |
| Portable Trust | Local `verifyPackage(bytes, trustPolicy, options)` | Retained package, independently chosen trust, check time | Structured VerificationReport with no network required for supported offline mode |

Write requests MUST include an idempotency key scoped to tenant, operation, resource, and normalized request digest. The same key with the same request returns the original operation identity. The same key with different bytes returns `409 idempotency_conflict`. Concurrent updates use an expected revision or `If-Match`; a stale update does not silently merge accepted scopes.

### Responses and failure protocol

Responses MUST include `contract_version`, `request_id`, `operation_id` where durable work began, `case_revision` where relevant, `observed_at`, and structured state or error information.

Proposed transport semantics:

* `200` or `201`: an operation completed or was created. This is not a proof verdict.
* `202`: durable asynchronous job accepted, with authorized status location and cancellation behavior.
* `400`: malformed syntax; no partial evidence admission.
* `401` or `403`: unauthenticated or unauthorized. Do not reveal private object existence.
* `404`: missing resource within the authorized namespace, not an invalid signature.
* `409`: revision, identity, idempotency, or unresolved mutation conflict.
* `413`: declared input/resource limit exceeded.
* `422`: well-formed but unsupported or semantically invalid contract request.
* `429`: admitted load limit reached, with bounded retry guidance.
* `503`: required dependency unavailable or signer not configured, with retryability and admitted-work status.

A completed check of invalid evidence returns a verification result, not a transport exception. `invalid_signature`, `digest_mismatch`, `missing_input`, `untrusted_key`, `revoked_key`, `stale_trust`, `unsupported_algorithm`, `not_found`, `access_withheld`, and `dependency_unavailable` remain distinct reason codes. Do not translate an opaque legacy failure into a more precise state unless the adapter can establish it.

## Evidence Contract Studio

**Service ID:** `evidence-contract`

### Buyer value and jobs

The Studio turns “we need evidence” into a specific agreement about records, checks, responsibility, and exceptions. It is a design tool and a runtime contract source, not a compliance badge generator.

Core jobs:

1. Define the question the workflow must answer.
2. Select applicable requirements and record why others are excluded or unresolved.
3. Map requirements to evidence-producing adapters and canonical checks.
4. Bind requester-controlled evidence demand before submission where applicable.
5. Specify the expected population, calculation, authority, acceptance, and retention policies.
6. Compile a profile that the capture, reconciliation, graph, gate, and export services can consume.
7. Review changes as new versions, including their impact on historical comparisons.

### Technical differentiator

The proposed differentiator is a **versioned evidence obligation compiler**. It produces a dependency graph from requirements to source artifacts, checks, evaluations, and required decisions. It explicitly represents requirements that a selected adapter cannot satisfy.

The compiler MUST produce an explainable plan, not an opaque score. Each obligation resolves to a source contract, verification method, timing rule, owner, and expected output. It SHOULD support impact analysis: changing one ruleset clause identifies affected evidence obligations and service operations before that version is released.

This is an engineering design claim, not a novelty, patent, or market-leadership assertion.

### Canon composition and proof ceiling

* Use `proof.demand` for requester-controlled pre-submission bindings, not fulfillment. Proof demand schema: `hive-verifier-api/src/typed/schemas/proof-demand-v1.json`
* Use `screening.attestation`, `jurisdictional.clearance`, `eval.attestation`, `eval.administration`, and `submission.attestation` only for requirements matching their specific contracts. Current registry: `canon/registry/hive-canon-registry.json`
* `jurisdictional.clearance` records a declared configuration against a named registry/ruleset boundary; it does not establish legal compliance, complete/current rules, or regulator acceptance. Jurisdictional clearance schema: `hive-verifier-api/src/typed/schemas/jurisdictional-clearance-v1.json`
* `eval.administration` records a declared administration arrangement and computes an independence class from supplied relationship data; it does not independently establish those relationships or an evaluation score. Evaluation administration schema: `hive-verifier-api/src/typed/schemas/eval-administration-v1.json`

A mapping table MUST say “evidence supporting this selected requirement,” not “requirement legally satisfied.” A commercial or legal interpretation remains attributed to its responsible reviewer.

### Inputs and outputs

Additional `EvidenceProfile` fields:

```text
profile_id, profile_version, draft_revision, title, owner
question: purpose, intended_reliance, prohibited_reliance
rulesets[]: ruleset_id, version, content_digest, issuer, effective_interval
requirements[]:
  requirement_id, requirement_text_ref, applicability_state, rationale
  evidence_obligations[], canonical_refs[], source_contract_refs[]
  check_method, timing, required_party_roles[], unresolved_reasons[]
population: method, authority, scope, snapshot_rule, exclusions, late_rule
calculation: executable_ref, version, input_schema, units, rounding
authority_policy_ref, acceptance_policy_ref, trust_policy_ref
disclosure_policy_ref, retention_policy_ref, resource_limits
approvals[]: actor, role, reviewed_revision, decision, authentication_ref
supersedes_profile_ref, compatibility_class, release_digest
```

`applicability_state` is `applicable`, `not_applicable`, or `unresolved`. A requirement may be applicable but unmapped. An unsupported check stays in the plan with its limitation; it is not dropped from the denominator.

Output is a compiled evidence profile plus:

* Requirement-to-evidence matrix.
* Source and capture obligations.
* Required proof-demand bindings where used.
* Calculation, decision, timing, and export contracts.
* Machine validation report.
* Human-readable uncovered and unresolved requirements.

No output is named a compliance certificate.

### State machine and failure semantics

```text
draft -> review_required -> approved_for_scope -> active_version
review_required -> draft
active_version -> superseded | withdrawn
```

These are the service lifecycle states in the map. Validation, compilation, review rejection, and release are operation-level substates/events; a released profile corresponds to `active_version`. Service map: `canon/surfaces/surface-map.json`

Rules:

* Unresolved critical applicability, missing population policy, missing required trust policy, unsupported mandatory checks, or conflicting requirement IDs block release for an operational profile.
* A discovery-only draft MAY remain inspectable with gaps. It cannot be selected for an accepted enforcement installation.
* External ruleset retrieval failures do not substitute a different version. A retained approved version may be used only inside its declared validity policy.
* A ruleset whose content changes under the same identifier is a digest conflict and requires review.
* A demand declared after known submission cannot be displayed as a pre-submission requirement.
* A demand with no known submission time shows temporal ordering as unconfirmed until linked transmission evidence is available.
* A profile amendment never changes the interpretation of an old case in place.

### Authorization, privacy, and trust boundary

Profile authors, approvers, source owners, and trust administrators MUST have separate permissions. A profile author MUST NOT self-approve a separation-of-duties requirement that the profile itself marks as requiring another role.

The service MUST retain requirement text only when permitted. Restricted ruleset content may remain in a tenant repository with a digest, authorized locator, and export limitation. Missing text can block independent interpretation without invalidating an authentic mapping record.

Trust-key enrollment and revocation follow “Shared trust, authority, tenant, and privacy architecture.” A profile approval's historical signature and the actor's authority at release time are checked separately. A revoked approval credential does not rewrite the historical profile; it triggers a current-reliance review under the effective-time policy.

### Packaging and readiness

Package the service as a profile authoring workspace, compiler/library, version registry, and exportable integration contract. Optional managed mapping work is a separately scoped service, not an implied legal opinion.

Production dependencies: approved ruleset ownership, source contracts, tested verifier adapters, profile review controls, authenticated release workflow, tenant isolation, and a retained compatibility test corpus. Initial discovery does not depend on these being installed for any customer.

P0: versioned profiles, explicit gaps, valid identity references, immutable release bytes, population and trust policies, and the “Acceptance criteria and independent challenge” Studio tests. P1: change-impact previews, profile comparison, reusable obligation templates, and migration assistance.

## Counterparty Reconciliation

**Service ID:** `counterparty-reconciliation`

### Buyer value and jobs

This service gives two or more parties a shared case without forcing them into a shared conclusion. It helps them distinguish different records, different counting rules, timing gaps, and genuine disagreement.

Core jobs:

1. Admit each party's observations with its own provenance and authority.
2. Establish the expected population and event identity rules.
3. Compare normalized fields under an agreed rule and retained source precedence policy.
4. Inspect missing, conflicting, late, and amended evidence.
5. Record independent decisions on a precise case/result version.
6. Preserve disagreement and export each party's permitted reproduction package.

### Technical differentiator

The proposed differentiator is a **dual-source, version-bound reconciliation ledger** with distinct calculation and acceptance planes. The calculation plane can reproduce a count or comparison even while the acceptance plane remains disputed. A correction changes affected calculations and explicitly invalidates their applicability to prior acceptance, without erasing either party's historical position.

Selective disclosure is part of the case model. A party can verify shared commitments while seeing only authorized field openings. The product MUST state which comparisons remain unreproducible without additional disclosure.

### Canon composition and proof ceiling

The current `custody.handoff` verifier checks different `key_id` strings and the required constituent presentations over handoff terms; its distinct-presenting-keys gate does not resolve and compare the two public-key fingerprints. Distinct key material and organizational independence therefore require separate qualified checks. Its adverse `custody_not_established` result preserves a disagreement in supplied terms, and its custody acceptance is not general acceptance of a reconciliation outcome. Custody handoff implementation: `hive-verifier-api/src/typed/custody-handoff.js`

The target service adapter MUST resolve both accepted issuer aliases, compare public-key fingerprints, and reject a distinct-key requirement if those fingerprints are equal. The protected canonical verifier is intentionally unchanged; this is a dependency qualification, not a repaired independent-key runtime verifier. That target adapter check does not modify or claim stronger behavior from the canonical verifier. Different fingerprints still require a separate assessment of organization, operator relationship, custody, and authority before any independence claim.

`ledger.parity` compares two committed field sets and observation times; it does not establish the accuracy of those source records or decide which side is right. Ledger parity implementation: `hive-verifier-api/src/typed/ledger-parity.js`

`divergence.record` retains supplied assertion and observation separately and computes their comparison, without proving either value true or identifying the cause. Divergence schema: `hive-verifier-api/src/typed/schemas/divergence-record-v1.json`

Use `supersession.receipt`, `sequence.attestation`, `disclosure.presentation`, and authority evidence where applicable. `mandate.crossacceptor` can support a bounded contribution/coverage question, but does not prove the complete expected population, institutional independence, or authorization. Current registry: `canon/registry/hive-canon-registry.json`

### Inputs and outputs

```text
ReconciliationCase:
  case_id, revision, profile_digest, population_snapshot_ref
  party_roles[]: party_id, role, authorized_deciders, trust_policy_ref
  observations[]:
    party_id, source_ref, logical_event_id, attempt_id, source_cursor
    event_time, observed_at, ingested_at, original_bytes_ref
    declared_fields, normalization_version, evidence_refs[]
  source_precedence_policy, matching_rule, counting_rule, tolerance_rule
  calculation_run_ref, differences[], unresolved_items[]
  required_decisions[], decision_policy_version, closure_rule
```

Each difference MUST identify affected logical events, field paths, source classes, observation times, comparison rule, and status. Do not infer blame from `missing_on_party_b` or from a timing difference.

`PartyDecision` MUST bind:

```text
decision_id, object_version, tenant_scope_id, decision_audience
decision_profile_id, decision_profile_version
case_id, case_revision, case_snapshot_digest
calculation_run_digest, profile_digest, decision_scope
party_id, actor_id, role, authority_ref
decision, reason_code, permitted_reason_text_ref
decided_at, effective_at, expires_at_if_any
supersedes_decision_id, challenge_nonce, authentication_evidence
```

`tenant_scope_id` is a stable privacy-safe tenant binding issued under the relying party's authenticated scope policy, not a user-editable display name. `decision_audience` is the exact intended relying service/party context, not a wildcard. Both, together with the decision profile ID/version, MUST be included in the decision digest and signed body. An offline recipient must compare these signed fields with its independently configured expected tenant, audience, and profile; it cannot rely on the originating API URL to supply the missing scope. Identical local case, party, and actor IDs in another tenant do not authorize reuse.

Authentication MUST be independently checkable at the claimed level. An application-session click with only a Hive audit record is `operator_recorded`; a retained party signature is `party_signed`; a signed delegated service action carries its authority chain. None becomes a new canonical primitive by being included in an export.

For portable party-signed decisions, “Interoperability, canonical bytes, and version governance” defines the proposed application signing profile. A local reference MAY demonstrate distinct synthetic decisions, but MUST label the parties and their keys as synthetic and operator-controlled.

### State machine and failure semantics

```text
collecting -> ready_to_calculate -> calculated -> pending_acceptance
pending_acceptance -> accepted | disputed
any retained revision -> superseded(new revision)
```

These are the map's service states; escalation, missing observations, and unresolved closure are detailed reasons and party-decision states. Service map: `canon/surfaces/surface-map.json`

Party decisions have independent lifecycles. Overall `accepted` requires the exact current required-party set and quorum rule, authorized decisions bound to the same case revision, and no unresolved mandatory scope condition. The catalog's `accepted_case_rate` specifically requires every required authorized party, even if a particular workflow also supports a separate quorum-based closure measure.

Rules:

* Missing observations create gaps, not zero amounts or implied agreement.
* Multiple receipts for one attempt are deduplicated by stable identity and byte comparison; conflicting bytes are quarantined.
* Asynchronous source windows require explicit tolerance. A window exceeded state is not a decisive disagreement about underlying facts.
* A party can reject a calculation whose bytes verify. The rejected state is not a signature failure.
* A decision about revision N remains valid evidence of that historical decision, but is not acceptance of revision N+1.
* Withdrawal or reversal is another authenticated decision. It does not delete the original.
* If a party cannot verify permitted source openings, the result states `not_reproduced_by_party`, even if the service reproduced it.
* An unavailable source cannot be replaced with another party's view without naming the substitution and its consequences.

### Authorization, privacy, and key independence

Each party MUST control its own decision authorization policy. A case administrator may invite reviewers and request decisions, but cannot impersonate another party or manufacture acceptance.

Distinct key IDs are insufficient. Compare public-key fingerprints, organization bindings, key custody, operator relationship, and delegated authority. Two keys controlled by Hive may demonstrate signature mechanics but do not establish external independence. A same-key bilateral case MUST NOT be described as independently accepted.

Private differences and reasons MUST be visible only to authorized roles. Public exports MUST not reveal raw account identifiers, low-entropy value commitments, identities, or rejected confidential field values through error messages.

Revocation is evaluated for observation signatures, decision signatures, and actor authority separately. An offline reviewer receives historical trust snapshots and a warning when current status cannot be established.

### Packaging and readiness

Package as a shared case workspace, source admission API, deterministic reconciliation runner, party decision inbox, and recipient-specific exports. Do not bundle payment authority or settlement execution into reconciliation.

Production dependencies: authenticated source access on each participating side, agreed population and event identity rules, approved normalization/calculation, participant authority enrollment, customer-controlled or explicitly delegated decision keys, dispute routing, and correction policy.

P0: one fully reproducible bounded case, separate decisions, missing/conflicting/corrected cases, access isolation, and portable history. P1: additional parties, configurable quorum, bulk case grouping, escalation workflow, and recipient comparison views.

## Decision Evidence Graph

**Service ID:** `decision-evidence`

### Buyer value and jobs

The graph makes a result inspectable. A reviewer can move from the displayed decision to the claim, field, document region, transformation, rule, model context, and retained evidence that supplied it.

Core jobs:

1. Bind the exact supplied sources and extracted regions.
2. Record transformations and their input/output commitments.
3. Check link structure and typed receipts.
4. Run a disclosed semantic evaluator where that capability is enabled.
5. Reproduce supported deterministic calculations.
6. Identify which outputs are affected by a missing, altered, or corrected input.
7. Export the permitted evidence closure rather than a screenshot of a graph.

### Technical differentiator

The proposed differentiator is a **typed dependency graph with separate proof and evaluator planes**. Structural link checking establishes that references and commitments connect. Semantic evaluation records whether a named method judges a passage to support a claim. Calculation replay establishes what a pinned executable produces from supplied inputs. None substitutes for the others.

The graph SHOULD support incremental invalidation and isolated what-if replay. Removing one required source marks exactly the dependent results stale or blocked; unaffected results retain their own evidence lineage. A counterfactual replay is a new synthetic branch, not a correction to the original case and not evidence of what actually happened.

### Canon composition and proof ceiling

`sigr.gca` recomputes recorded claim references, strengths, root, and grounded count. It does not establish that a passage supports a claim or that a grounding method is sound. GCA implementation: `hive-verifier-api/src/typed/sigr-gca.js`

`afir.ocr.docproof` is extraction provenance, not a guarantee that the extracted value is correct. `decision.provenance` links recorded transformations and can identify a broken link or changed value commitment, but explicitly does not re-execute the pipeline. Current registry: `canon/registry/hive-canon-registry.json` Decision provenance schema: `hive-verifier-api/src/typed/schemas/decision-provenance-v1.json`

As a conditional extension, not a selected Decision Evidence Graph dependency, `proof.transition` supports a predeclared transition table and admitted input sequence. Full verification requires the actual input envelopes and their cryptographic verification, while the signed table does not establish correct business logic or a downstream effect. Proof transition schema: `hive-verifier-api/src/typed/schemas/proof-state-transition-v1.json`

Source-specific profiles MAY add `sigr.mir`, `sigr.manifest`, `assembly.receipt`, `numeric.lineage`, `cache.epoch`, `entropy.custody`, and `s2s.signature`; measurement and replay profiles MAY add the appropriate evaluation, performance, analysis, or control contracts. Their names do not upgrade the graph beyond their individual boundaries. Current registry: `canon/registry/hive-canon-registry.json`

### Inputs and outputs

```text
EvidenceGraph:
  graph_id, revision, case_revision, profile_digest
  nodes[]:
    node_id, kind, content_digest, artifact_ref, source_class
    schema_ref, canonical_ref_if_any, access_state
  edges[]:
    edge_id, from_node, to_node, relation, selector
    method_ref, declared_by, evidence_ref, status
  claims[], structural_check_results[], evaluator_runs[], replay_runs[]
  required_closure, included_closure, withheld_closure, missing_closure
```

Node kinds include source, region, extracted field, normalized value, external enrichment, transformation, rule, claim, decision, model context, and receipt. Edge relations are a closed profile vocabulary such as `extracted_from`, `consumes`, `produces`, `declared_support_for`, `evaluated_support_for`, `authorized_by`, `supersedes`, and `included_in`.

`declared_support_for` MUST NOT be rendered as `evaluated_support_for`. A graph's existence does not prove causation.

Selectors MUST bind the exact source representation: byte offsets for text, page/render-profile plus bounding box for documents, or declared timestamp/segment coordinates for supported media. Changed source bytes invalidate selectors unless a new explicit mapping is produced.

Additional `SemanticAssessment` fields:

```text
assessment_id, graph_revision, claim_ids, support_region_refs
evaluator_id, evaluator_operator, relationship_class
method_id, method_version, executable_or_model_digest
rubric_digest, prompt_or_config_digest, input_set_digest
result_per_claim: supported | contradicted | insufficient | abstained | error
uncertainty: method, value_if_meaningful, scale, limitations
run_id, started_at, completed_at, nondeterminism_parameters
human_review_ref, supersedes_assessment_ref
```

If the evaluator is unavailable or absent, return `not_evaluated` at the service level. Do not convert the GCA's declared support strength into a calibrated probability or use it as an evaluator result.

### State machine and failure semantics

```text
captured -> linked -> structurally_checked -> evaluation_pending -> evaluated
structurally_checked | evaluated -> challenged
any retained revision -> superseded(new revision)
```

These are the map's service states. Structural checks, evaluations, and replays are separate run states and may proceed independently; a replay run can be pending, reproduced, different, blocked, or stale without inventing another service lifecycle state. Service map: `canon/surfaces/surface-map.json`

Rules:

* A missing source blocks only the checks that require it, while the omission remains visible at case level.
* A cycle in a graph declared as an acyclic calculation plan is invalid. Legitimate iterative workflows require an explicit iteration/unrolling profile.
* An evaluator crash is `error`; inability to decide is `abstained`; missing evidence is `insufficient`.
* A changed model, prompt, rubric, or retrieved context creates a different evaluation run even if the displayed answer is identical.
* Nondeterministic evaluation preserves original outputs and parameters. Re-running it is not guaranteed to reproduce the original judgment.
* A replay runner MUST execute in a resource-bounded environment without granting evidence content network, file-system, or tool authority.
* A cached result MUST bind input closure, evaluator/rule digest, graph revision, and trust-policy snapshot. A bare claim ID is not a safe cache key.

### Authorization, privacy, and evaluator trust

Source material is untrusted data, including instructions embedded in documents. It cannot authorize tools, change verifier configuration, enroll a key, or override a rubric.

The service MUST enforce per-node and per-edge access rules. It may reveal that required evidence is withheld without disclosing its content or a sensitive locator. Export planning MUST make the resulting replay limitation explicit.

Evaluator identity, operator relationship, and competence claims are separate. Same-operator evaluation is labeled accordingly. An independent evaluator requires evidence of the relationship and custody boundaries, not another key under the same account.

Trust and revocation apply to original sources, typed receipts, evaluator statements, and authority independently. A newly revoked source key marks affected current-reliance paths for reevaluation without deleting the historical graph.

### Packaging and readiness

Package as an evidence viewer, graph API, typed adapter library, supported replay runner, evaluator interface, and dependency-closure exporter. Semantic evaluation is an explicitly enabled module, not a hidden promise of the basic signature/lineage service.

Production dependencies: stable source selectors, permitted source retention, sandboxed execution, evaluator disclosure and validation, deterministic-rule packaging, unsupported-node behavior, and adversarial content tests.

P0: linked evidence, separate structural/evaluator/replay results, dependency invalidation, access-safe export, and missing/altered/unsupported fixtures. P1: incremental recomputation, competing evaluator comparison, isolated counterfactual branches, and visual graph navigation at scale.

## Action Boundary

**Service ID:** `action-boundary`

### Buyer value and jobs

Action Boundary is for an operator who needs evidence requirements to control a particular effect, not merely describe it afterward. The service must name the effect precisely, identify every allowed execution path, and demonstrate that its control sits on those paths.

Core jobs:

1. Bind authority, policy, prerequisites, and intended action before execution.
2. Refuse when required evidence, authority, trust, or timing conditions are not met.
3. Reserve and consume a bounded authorization without permitting duplicates or altered payloads.
4. Execute only through a qualified adapter.
5. Record what is known about the effect afterward, including unknown outcomes.
6. Detect bypasses and reconcile attempts with an independently defined effect population.
7. Recover without repeating an effect whose outcome is uncertain.

### Operating modes

| Mode | What it does | What it cannot claim |
| :--- | :--- | :--- |
| `synthetic` | Runs controlled fixtures and may protect a real local reference mutation | External integration, customer effect blocking, or production coverage |
| `observe` | Records supplied events after or alongside execution | Prevention or refusal at the customer's effect boundary |
| `shadow` | Computes what a policy would have allowed or refused without owning execution | Actual blocking |
| `enforce` | Controls the named effect through a qualified executor and policy | Control over undeclared routes, other effects, or compromised external systems |

The mode MUST be fixed in the boundary configuration and visible on every attempt, result, export, and metric. UI toggles cannot promote a deployment from shadow to enforce.

### Technical differentiator

The proposed differentiator is an **evidence-bound execution reservation**: the check binds immutable action bytes, policy version, authority snapshot, expiry, nonce, and execution boundary. A commit-time fence rechecks required conditions and atomically consumes the authorization before the effect is admitted.

This closes a specific time-of-check/time-of-use gap only when the effect endpoint cannot bypass the fence. It does not create a general exactly-once guarantee across an arbitrary external system. A downstream system without idempotency, fencing, status lookup, or a transactional commit boundary may remain unsuitable for a strong enforcement claim.

### Canon composition and proof ceiling

`imprimatur.clearance` combines four supplied preconditions, computes its clearance result, and checks expiry; it does not prove the supplied evidence is accurate or that later inference ran only after clearance. Imprimatur schema: `hive-verifier-api/src/typed/schemas/imprimatur-clearance-v1.json`

The four named conditions are `model_approved`, `inputs_eligible`, `context_permitted`, and `boundary_authorized`; a generic action integration must use this contract only where that shape genuinely fits, not rename arbitrary conditions into misleading model terminology. Imprimatur schema: `hive-verifier-api/src/typed/schemas/imprimatur-clearance-v1.json`

`proof.transition.effect_gate` is a recorded authorization declaration, not evidence that an effect happened. `effect.closure` binds an observed outcome and required evidence references, without establishing the accuracy of those external references. Transition schema: `hive-verifier-api/src/typed/schemas/proof-state-transition-v1.json` Effect closure schema: `hive-verifier-api/src/typed/schemas/effect-closure-v1.json`

The seven typed upstream contracts are `usap.pbs`, `usap.refusal`, `usap.howler`, `usap.perimeter`, `usap.diurnal`, `usap.egress`, and `usap.forensic`; their current public boundaries do not establish the corresponding device, kernel, policy, classifier, or operational integrations. Current registry: `canon/registry/hive-canon-registry.json` Honesty contract registry: `hive-verifier-api/src/typed/honesty-contracts-registry.js`

A new installed adapter can supply additional evidence, but cannot change an old primitive's fixed boundary or retroactively strengthen old receipts. If no existing typed contract fits the action, retain the proposed application attempt and executor evidence with explicit authentication and a schema gap; do not fabricate a canon receipt type.

### Inputs and outputs

```text
BoundaryConfiguration:
  boundary_id, version, tenant_id, mode, owner
  controlled_effect: operation, destination, resource_scope, payload_schema
  authorized_paths[], prohibited_paths[], bypass_inventory
  executor_identity, credential_custody, downstream_idempotency_contract
  policy_digest, authority_policy_ref, trust_policy_ref
  prerequisite_checks[], input_freshness_limits, clock_policy
  nonce_policy, reservation_ttl_policy, commit_fence_policy
  outage_policy, recovery_policy, break_glass_policy
  installation_acceptance_ref, resource_limits

BoundaryAttempt:
  logical_action_id, attempt_id, boundary_version, action_bytes_digest
  action_summary, expected_effect_population_ref
  requester_identity, authority_chain_refs, scope, audience
  evidence_refs[], evaluated_policy_digest, trust_snapshot_digest
  issued_at, not_before, expires_at, nonce, idempotency_key_digest
  prerequisite_results[], decision, refusal_reasons[]
  reservation_id, fence_token, consumed_at
  effect_status, downstream_operation_ref, effect_evidence_refs[]
```

The authorization binds the exact operation, destination, resource, payload, quantity or budget if applicable, tenant, and executor audience. An unbound mutable URL, model selector, beneficiary, or output path is a bypass risk.

Possible effect states are `not_attempted`, `admitted`, `in_flight`, `confirmed_completed`, `confirmed_failed`, `outcome_unknown`, and `reversed_with_evidence`. An API acknowledgement is not automatically completion.

### State machine

The published service lifecycle uses `requested`, `evidence_pending`, `authorized`, `refused`, `authorization_consumed`, `effect_observed`, `effect_unknown`, and `reconciled`. Service map: `canon/surfaces/surface-map.json`

The following more detailed state machine belongs to the proposed attempt/executor object, not the catalog's `state_machine` field. `reserved` projects to `authorized`, `consumed` to `authorization_consumed`, confirmed outcomes to `effect_observed` with evidence detail, and `outcome_unknown` to `effect_unknown`.

```text
received -> validating
validating -> refused | awaiting_evidence | reserved
reserved -> expired | cancelled | commit_check
commit_check -> refused | consumed
consumed -> executing
executing -> confirmed_completed | confirmed_failed | outcome_unknown
outcome_unknown -> reconciled_completed | reconciled_failed | unresolved
confirmed_completed -> reversal_requested -> reversed_with_evidence
```

Mandatory ordering:

1. Validate authorization, prerequisites, profile, clock, and exact action.
2. Persist the attempt and reserve its logical action under the tenant/boundary idempotency key.
3. At commit, recheck mutable authority, revocation freshness, expiry, resource version, and policy epoch.
4. Atomically consume the reservation or use an equivalent qualified fence.
5. Invoke the effect using the bound downstream idempotency/fence token.
6. Retain observed response and determine the outcome under the adapter's evidence contract.
7. Emit or collect closure evidence only after the corresponding observation exists.

A final outcome receipt cannot be a prerequisite for its own action. Evidence prerequisites and effect closure are different stages.

### Failure, bypass, time, and replay behavior

* In enforce mode, missing mandatory evidence, unavailable signer where required, unknown authority, stale mandatory revocation data, expired clearance, or an unsafe clock causes refusal or a non-executing pending state.
* In observe mode, the same failure records an evidence gap and does not imply the external action stopped.
* An expired reservation cannot be revived by replaying the original request. A new evaluation may issue a new reservation if policy permits.
* A duplicate execute request returns the existing logical action state. It never deliberately submits a second external effect to resolve uncertainty.
* A timeout after submission becomes `outcome_unknown` until an authorized status lookup or reconciliation establishes more.
* A crash after reservation consumption but before effect submission may be recoverable through the downstream idempotency contract. Without that contract, the recovery owner must reconcile before retrying.
* Queue residence time consumes the same freshness and expiry budgets as normal execution.
* Clock rollback or drift outside the profile's allowance blocks enforcement until a trusted time basis is restored.
* Authority revoked between validation and commit is checked at the fence. If the integration cannot observe revocation within its agreed bound, the scope of its enforcement claim must say so.
* Direct credentials, alternate endpoints, operator consoles, scheduled jobs, cached capabilities, network retries, and privileged maintenance routes belong in the bypass inventory.
* Break-glass execution is a separately authorized mode with durable reason, actor, scope, and evidence gap. It is not counted as a normal policy pass.
* Late effect evidence creates a new closure observation without changing the original execution decision time.

### Authorization, privacy, and key custody

Only the executor may hold downstream effect credentials. Requesters receive scoped attempt references, not reusable service credentials. Separate profile administration, authority issuance, executor operation, trust administration, and audit permissions.

Use customer-controlled or explicitly delegated signing keys where authority requires them. A receipt signer cannot grant itself the customer's action authority. Key revocation and authority revocation are separate inputs.

Action summaries MUST avoid exposing sensitive payloads. Operators may inspect refusal classes while raw evidence remains restricted. Logs must never retain downstream secrets, signing seeds, or full confidential action bodies.

### Packaging and readiness

Package as a boundary SDK, policy/evidence adapter, executor integration, attempt ledger, and operations runbook. Integration work is scoped per controlled effect and execution environment. A general-purpose hosted clearance endpoint is not the finished service.

Production dependencies: a named effect owner, complete path inventory, constrained downstream credentials, atomic or fenced commit behavior, idempotency/status semantics, authenticated authority, trusted clock policy, revocation delivery, tested outage behavior, and recovery drills.

P0: real bounded effect protection in the claimed environment, no undocumented bypass in the tested inventory, refusal and replay tests, timeout recovery, exact action binding, and separate closure evidence. P1: shadow policy comparison, controlled rollout, approved budget/constraint profiles, and independently observed bypass reconciliation.

## Portable Trust

**Service ID:** `portable-trust`

### Buyer value and jobs

Portable Trust makes the evidence useful after a session, commercial relationship, or hosting service ends. The recipient keeps the permitted records, a supported checker, and the trust assumptions needed to understand the result.

Core jobs:

1. Plan the package required for a stated verification or replay purpose.
2. Preserve original signed artifacts and required application evidence.
3. Include supported schemas, checker dependencies, instructions, and test vectors.
4. Let the recipient choose or pin trust material separately from the package under test.
5. Verify locally with explicit historical and current-trust distinctions.
6. Preserve correction, custody, disclosure, and retention history.
7. Reassess trust after key rotation, revocation, or algorithm retirement without silently rewriting history.

### Technical differentiator

The proposed differentiator is a **purpose-specific evidence closure package with dated trust evaluation**. Export planning starts from a requested claim such as “reproduce this count” or “check this final-state assertion” and identifies exactly which receipts, source openings, executable rules, trust material, and chronology are needed.

The package can be complete for signature checking but incomplete for replay. That distinction is a first-class result, not a footnote.

### Canon composition and proof ceiling

`proof.transition.portable` authenticates an exporting signer's bounded final-state assertion; it does not verify the source container's signature or replay omitted inputs. Full transition replay is a conditional Portable Trust extension, not selected support implied by its catalog array: it requires a separately admitted `proof.transition` source container, actual input envelopes, and a qualified full-check adapter. Portable transition schema: `hive-verifier-api/src/typed/schemas/proof-transition-portable-v1.json` Transition schema: `hive-verifier-api/src/typed/schemas/proof-state-transition-v1.json`

`transparency.checkpoint` has a scoped log-root, path, consistency, and timestamp-token boundary over supplied material, but does not establish a complete log, exclude another log, or chain the token's certificate to the relying party's trust anchor. Current registry: `canon/registry/hive-canon-registry.json`

`receipt.registry.sovereign` does not establish a governmental or jurisdictional authority relationship. `replay.disclosurefree` does not itself inspect a replayed payload for forbidden fields. Current registry: `canon/registry/hive-canon-registry.json`

The typed key resolver distinguishes trusted service keys, caller-supplied integrity-only keys, and public example keys; public example keys do not establish real events. Typed keyring: `hive-verifier-api/src/typed/keyring.js`

### Package contract

The proposed portable package is a deterministic directory manifest plus retained files. A ZIP or other container may transport it, but archive compression metadata is not the evidence identity.

```text
package-manifest.json:
  package_format_version, package_id, case_id, case_revision
  profile_digest, purpose, export_created_at, exporter_identity
  root_manifest_digest, digest_profile, signature_profile_if_any
  files[]: path, byte_length, media_type, digest_algorithm, digest
  artifacts[]: original_envelope_profile, schema_ref, canonical_ref
  requested_checks[], supported_checks[], unsupported_checks[]
  required_dependency_closure[], included_refs[], omitted_refs[]
  omission_reason, affected_checks, retrieval_authority_if_any
  trust_material_refs[], trust_acquisition_instructions
  checker_ref, checker_build_digest, dependency_manifest_ref
  source_revision, build_recipe_ref, license_notices_ref
  retention_and_disclosure_profile, correction_history_refs
  fixture_mode, limitations
```

Package contents SHOULD use stable logical directories for originals, authorized sources, application records, rules, schemas, trust snapshots, checker code, tests, reports, and instructions. The manifest MUST cover every security-relevant file. A checker MUST reject ambiguous duplicate paths, traversal paths, symlinks that escape the package, and unlisted executable content.

The package digest is computed over the manifest's declared canonical form excluding only its own digest and detached signature fields as specified by its version. Every excluded field is explicitly enumerated. Files are referenced by their exact-byte digests and lengths. Unreferenced files cannot influence verification.

### Verification pipeline

1. Validate archive and resource limits without executing package code.
2. Parse the manifest under a pinned format version.
3. Recompute file and manifest digests.
4. Select a supported checker from locally trusted code, not arbitrary code supplied by an untrusted package.
5. Validate each original envelope using its own profile and exact signed bytes.
6. Resolve expected signer identities from independently selected trust policy.
7. Evaluate key validity, revocation, authority, and time under the declared check mode.
8. Run applicable typed checks with required constituent artifacts.
9. Reproduce permitted calculations in a sandbox where supported.
10. Report coverage, party decisions, semantic assessments, omissions, and effect evidence separately.
11. Save a VerificationReport tied to package, checker, and trust-policy digests.

A hash-only input MAY look up a public sample. It cannot be labeled verification. A recipient must hold the relevant bytes, signature, algorithm/profile, trusted key material, and required replay inputs for the checks being claimed.

### State machine and failure semantics

The published service lifecycle uses `assembled`, `manifest_checked`, `trust_checked`, `integrity_checked`, `replayed`, `partially_verifiable`, and `rejected`. Service map: `canon/surfaces/surface-map.json`

The export job has a separate lifecycle below. A package can reach `partially_verifiable` with authentic retained receipts while the requested full replay remains blocked.

```text
export_requested -> planning -> awaiting_permissions | assembling
assembling -> package_ready | export_failed
package_ready -> transferred -> recipient_check
recipient_check -> checked | partially_checked | blocked | error
checked -> reassessment_due
```

Rules:

* Permission denial does not cause a hidden partial “complete” package.
* A package missing a source may pass the signatures it contains while failing completeness for the requested replay purpose.
* Unknown algorithms and unavailable profile implementations return `unsupported`, not cryptographic invalidity.
* A supplied attacker key may make a signature mathematically valid, but cannot establish the expected issuer.
* A package cannot enroll its own trust anchors by including them in a `trust` directory.
* Network failure cannot silently change a current-trust request into a current-success result based on a stale snapshot.
* Offline verification must work in a fresh supported environment with Hive unavailable, not only in a browser that previously loaded all dependencies.
* Redacted evidence remains a derived view. The checker must never treat rewritten bytes as the original signed payload.
* A cached verification result is invalidated by changed package bytes, checker version, trust policy, check time, or requested scope.

### Authorization, privacy, and trust lifecycle

The default confidential-evidence path is local checking. Hosted upload requires explicit authorization for the selected case, recipient, region, retention policy, and check purpose.

Recipient access does not imply public access. Export links must be authorized, bounded, and revocable before download; revocation cannot claw back copies already held by an authorized recipient. The package must state permitted use and retention without pretending a cryptographic control can delete every copy.

“Shared trust, authority, tenant, and privacy architecture” defines historical trust, current trust, revocation, and rotation. Portable Trust owns the shared implementation but each service owns the authority meaning of its own records.

### Packaging and readiness

Package as a local checker, export planner, portable evidence format, trust administration module, and optional authorized hosted verification. Retrieval, storage, integration support, and archival maintenance are separate service commitments.

Production dependencies: approved redistribution rights, a reproducible checker build, pinned dependencies and schemas, independently provisioned trust roots, recipient compatibility tests, disclosure validation, retention policy, and recovery/export drills.

P0: a fresh offline supported check, tamper and missing-input failures, trust separation, original-byte preservation, explicit omitted-input limits, and a complete checker supply-chain manifest. P1: trust refresh tooling, long-lived archive migration, multiple independent checker implementations, and recipient-managed verification policy.

## Shared trust, authority, tenant, and privacy architecture

This section is mandatory for every integrated service. A local synthetic reference demonstrates only its documented subset.

### Trust is a policy decision

The relying party MUST select a trust policy independently of the artifact being checked. The policy binds:

```text
trust_policy_id, version, policy_digest, owner
accepted_profile_versions, allowed_algorithms, prohibited_downgrades
issuers[]:
  key_id, public_key_fingerprint, algorithm, key_epoch
  organization_binding, operator_relationship, custody_class
  allowed_purposes, canonical_types_or_application_profiles
  tenant_and_resource_scope, not_before, not_after
  enrollment_evidence, authority_chain_refs
revocation_sources[], snapshot_signature_policy, freshness_policy
time_source_policy, clock_drift_policy, compromise_effective_time_policy
historical_validation_policy, current_reliance_policy
```

Signature integrity, expected issuer identity, institutional independence, actor authority, and current trust status are separate checks. A signature that verifies against a key supplied with the package does not establish that the key belongs to the expected issuer.

Key enrollment requires an authenticated out-of-band identity/ownership check and approval by a trust administrator. A key ID is a lookup name, not identity evidence. Distinct key IDs resolving to the same key fingerprint MUST be detected.

### Key lifecycle

```text
proposed -> enrolled -> active -> retiring -> retired
active | retiring -> suspended | revoked
suspended -> active only by a new authorized policy event
```

* Enrollment and activation record purpose, scope, owner, custody, validity interval, and evidence.
* Rotation creates a new key epoch and explicit overlap policy. A newly received key cannot replace an old trust anchor merely because it claims to be a successor.
* Retirement stops new authorized use under policy but can preserve historical verification.
* Revocation records reason, effective time, publication time, known compromise interval, issuer, and authenticated distribution evidence.
* A compromise investigation with unknown onset produces an uncertainty interval. Do not invent a precise safe-before timestamp.
* Revocation of a signing key and revocation of a person's business authority are different events.
* A service's trust snapshot cannot establish revocation facts beyond its collection and validity interval.
* A key-misuse incident triggers dependency-based identification of affected cases, decisions, evaluations, and permits.

The canonical `authority.revocation` receipt classifies supplied temporal evidence; it does not establish that a revocation was authorized, delivered, or legally effective. The integration's live revocation-control system is therefore a separate dependency. Current registry: `canon/registry/hive-canon-registry.json`

### Offline as-of semantics

Every verification request MUST choose one of:

1. `historical_as_of`: evaluate with authenticated evidence available as of a stated time under a pinned historical policy.
2. `current`: evaluate current reliance using trust material satisfying the policy's freshness requirement.
3. `integrity_only`: check supported bytes and signatures without asserting expected-issuer trust or business authority.

The report MUST retain:

```text
verification_time, requested_mode, requested_as_of
artifact_claimed_time, accepted_time_evidence
trust_snapshot_time, trust_snapshot_valid_until
revocation_information_through, clock_source, clock_uncertainty
historical_trust_result, current_trust_result
not_checked_after, limitation_reasons
```

An offline checker can establish “valid under this accepted snapshot as of T” if the required evidence exists. It cannot establish that no later revocation occurred. A current-mode check with stale trust returns `trust: unknown`, even if integrity passes. It MUST NOT silently label the result currently trusted.

An issuer-controlled timestamp alone may be insufficient to prove signing preceded a compromise. Historical acceptance depends on the pinned policy's accepted chronology evidence, not merely the timestamp printed in the signed object.

### Tenant and role enforcement

All integrated APIs enforce tenant and object authorization on the server. User-controlled `tenant_id`, storage path, case ID, or key ID cannot override authenticated scope.

Required role separations:

| Role | Allowed responsibility | Prohibited implicit authority |
| :--- | :--- | :--- |
| Profile author | Draft and compile requirements | Release another role's approval |
| Profile approver | Approve a frozen profile scope | Change signed source evidence |
| Source adapter | Submit evidence from its configured source | Approve business acceptance |
| Calculator/evaluator | Produce attributed results | Impersonate a counterparty |
| Party decider | Decide for a specific party and scope | Decide for another party without explicit delegation |
| Executor | Consume bounded permits and invoke its effect | Grant itself requester authority |
| Trust administrator | Enroll, rotate, revoke scoped keys | Rewrite historical signatures |
| Export custodian | Package permitted retained evidence | Expand recipient disclosure permissions |
| Auditor | Read authorized history and challenge results | Mutate or silently close cases |

Service-to-service identities use short-lived credentials scoped by operation and audience. Mint authorization and verification permission are separate. Public discovery exposes only safe metadata and fixed synthetic material.

The typed signer source requires real Ed25519 signing material and does not provide an unsigned fallback; adapters must preserve the specific route's authentication and signer-configuration behavior rather than assume every mint route has identical permissions. Typed signer: `hive-verifier-api/src/typed/signer.js` Current registry: `canon/registry/hive-canon-registry.json`

### Privacy and selective disclosure

1. Encrypt retained private evidence and isolate tenant keys, authorization checks, indexes, caches, queues, and exports.
2. Prefer local or customer-held processing when evidence cannot leave the source environment.
3. Treat digests and metadata as potentially sensitive. Low-entropy values can be guessed; use profile-defined salted/keyed commitments where appropriate and retain authorized openings separately.
4. Do not fetch arbitrary artifact URLs from evidence. Allowlist source adapters and destinations; reject internal-network or credential-bearing locators.
5. Never include private evidence in public telemetry, shared fixtures, page source, browser error tracking, or analytics events.
6. A redaction produces a derived presentation with its own digest and relation to original bytes. It does not preserve the original signature over modified content.
7. A recipient receives a purpose-specific dependency closure and an explicit omission list. A withheld dependency may prevent independent replay.
8. Export and deletion permissions are distinct. A right to review does not imply the right to publish.
9. Retention holds, deletion requests, backup retention, and recipient copies are separately tracked. Conflicting policy obligations require an authorized decision rather than silent deletion.

## Interoperability, canonical bytes, and version governance

### No universal reserialization

The typed Ed25519 implementation computes SHA-256 over its own canonical signed body, then signs the ASCII string `hive-receipt <receipt_id> <payload_sha256> <ts>`; it preserves array order, recursively orders object keys through its implementation, removes whitespace, and escapes non-ASCII code units. Its source also warns about integer versus decimal-number interoperability. Typed canonicalization: `hive-verifier-api/src/typed/canon.js`

The new local reference uses a different, bounded `Hive Canon JSON v1` encoding and explicitly does not identify that encoding as RFC 8785. Its case, bundle, token, and trust formats are reference application formats, not the canonical typed receipt envelope. Reference encoding: `canon/surfaces/reference/encoding.mjs` Reference guide: `canon/surfaces/reference/README.md`

Builders MUST:

* Preserve original byte files and original envelope type/profile names.
* Dispatch to the exact profile rather than “try verifiers until one returns true.”
* Preserve a distinction between a raw-file digest and the digest the envelope signature covers.
* Never apply the reference encoder to an existing typed envelope and call it canon verification.
* Never strip fields, repair malformed input, normalize Unicode, reorder arrays, or round numbers before checking a signed object.
* Reject duplicate JSON keys before an ordinary parser can erase them.
* Use profile-specific vectors for non-ASCII strings, supplementary characters, numeric-looking keys, control characters, integer boundaries, malformed encodings, and timestamp forms.
* If existing producer/checker implementations disagree on edge-case canonical bytes, report unsupported interoperability for that case and fix it through versioned governance. Do not silently choose a convenient byte representation.

### Proposed application signing profile

Where a portable party decision needs its own signature and no existing canonical contract matches, use an explicitly versioned **application** signing profile, not a fabricated receipt type.

Proposed `case-decision-signature/1`:

1. The decision body contains the required `PartyDecision` fields in Counterparty Reconciliation, including `tenant_scope_id`, `decision_audience`, `decision_profile_id`, and `decision_profile_version`, excluding only the detached signature object. No signed tenant binding may be inferred from transport context or omitted as redundant.
2. The profile selects a bounded canonical encoding with published test vectors; version 1 should use a separately pinned application encoder rather than imply the typed envelope's encoding.
3. Compute `body_digest` over those canonical bytes.
4. Sign an unambiguous UTF-8 message containing the literal domain `hive-case-decision/v1`, a newline, and the lowercase body digest.
5. Store `profile`, `algorithm`, `key_id`, `key_epoch`, `body_digest`, and signature bytes in a detached signature object.
6. The trust policy binds the expected key, party, role, tenant scope, intended audience, and profile; the decision body binds the same tenant/audience/profile, case, revision, scope, nonce, and validity. The recipient compares each signed binding against its expected context before accepting the decision.

This is a **proposed product-level authentication contract**, not installed support, a new primitive count, or the reference fixture's existing acceptance format. A schema, conformance vectors, security review, and independent party key provisioning are required before using it for actual counterparty acceptance.

A profile approval or export manifest may use an analogous separately domain-bound application signature only after its own versioned review. Never reuse a signature from one object purpose as authority for another.

### Adapter conformance manifest

Each accepted adapter MUST declare:

```text
adapter_id, version, owner, build_digest, source_revision
input_envelope_profiles[], canonical_types[], schema_digests[]
canonical_byte_profile, supported_algorithms, strict_parse_limits
verification_level: envelope | typed_self_checks | full_constituent_checks
required_constituents[], supported_replay_operations[]
trust_resolver_contract, authority_semantics, clock_semantics
network_dependencies[], offline_supported_operations[]
proof_ceiling, unsupported_cases, error_mapping
positive_vector_refs[], negative_vector_refs[], acceptance_report
```

A format can be accepted for preservation without being accepted for verification. A checker can verify one profile without being a general verifier for all canon entries.

### Version and migration policy

Use separate versions for the service map, service API, application schema, primitive schema, rule, evaluator, trust policy, export package, and checker build.

* Patch: implementation correction that does not change normative bytes or accepted meaning; regression vectors must show compatibility.
* Minor: optional capability or additive noncritical metadata under an explicit extension rule; no silent new required field.
* Major: changed signed bytes, required semantics, enum interpretation, calculation behavior, or trust meaning.

A schema URL alone is not a sufficient version pin. Retain its content digest and the exact bytes used. Never retrieve a newer schema during offline checking and apply it to an old package without explicit migration.

Migration produces a new application object and a declared relation to the old object. Original signed artifacts remain unchanged. Compare old and new results, document affected cases, and obtain fresh decisions where accepted scope changes.

Governance roles: canon steward reviews type identity and ceilings; adapter owner maintains vectors; security owner reviews parsing, algorithms, and trust; product owner approves public wording; integration owner accepts the deployed boundary. A compatibility decision requires a retained report, not only a code merge.

## Operations, observability, load, recovery, and retention

### Durable admission and processing

An integrated service MUST acknowledge durable evidence admission only after original bytes and the event-log reference are recoverable. Use transactional metadata plus an outbox or an equivalent tested protocol to prevent a committed case event from referencing an uncommitted artifact.

At-least-once delivery is acceptable for evidence transport when identity and idempotency make processing deterministic. Do not promise exactly-once external effects from queue semantics.

Case projection:

* Partition by tenant and case, not by a global shared mutable counter.
* Assign monotonic sequence numbers within the case.
* Retain upstream source cursors separately from internal event order.
* Rebuild projections from the event log with pinned code and rule versions.
* Expose projection checkpoint and freshness on every response.
* Do not render a partly rebuilt snapshot as an accepted current revision.

A stream reconnect resumes from a cursor. If the cursor is outside retention, return `cursor_expired` and require an authorized snapshot plus gap acknowledgement. Never silently substitute synthetic events or reset a sequence while leaving a live label visible.

### Load envelope and backpressure

Every operational profile MUST define tested limits for:

* Request bytes, artifact bytes, archive expansion, JSON nesting, array length, string length, and graph nodes/edges.
* Batch size, concurrent requests, evaluator runtime, replay CPU/memory, signature work, and export size.
* Queue depth and residence time, source outage buffering, retry count/backoff, and per-tenant fair-use isolation.
* Key-resolution and revocation dependency latency, accepted trust-cache age, and effect-reservation duration.

No speculative capacity target is assigned here. The integration owner must establish a controlled load regime, record hardware/runtime/configuration, measure saturation and recovery, and publish the accepted envelope before the `operational` tier.

Reject excess work before expensive parsing where possible. Return a clear admission result and bounded retry guidance. A queued action cannot outlive its authority merely because the service is overloaded.

### Observable evidence, not vanity counters

Each event SHOULD include a privacy-safe tenant reference, request/operation ID, case and revision, profile/rule/checker digests, boundary ID, outcome reason, elapsed duration, source mode, source cursor, and trace correlation.

Operational telemetry MUST cover:

* Admission, validation, typed-check, trust, calculation, evaluator, and export failures separately.
* Source lag, late events, population gaps, withheld evidence, and incomplete dependency closures.
* Case projection lag and stale reads.
* Party-decision latency and stale acceptance.
* Gate refusals, replay attempts, bypass detections, reservation expiry, and unknown effects.
* Revocation freshness, key-resolution failures, and unexpected key epochs.
* Retention jobs, legal holds, failed deletions, restore jobs, and package verification drift.

Store evidence digests and reason codes rather than raw sensitive payloads. A trace is diagnostic data, not automatically part of the proof. If an operational observation is relied upon as evidence, retain and authenticate it under an explicit contract.

### Failure recovery

| Failure | Required behavior |
| :--- | :--- |
| Source unavailable | Persist a gap and source cursor; retry under policy; never fabricate coverage. |
| Verifier unavailable | Keep evidence unverified/unavailable; do not use a cached success for different bytes. |
| Evaluator unavailable | Preserve structural results; label semantic assessment not run or errored. |
| Signer unavailable | Do not emit fake or unsigned receipts under a signed profile; retain pending work according to policy. |
| Partial artifact write | Quarantine uncommitted data; never advertise a package-ready state. |
| Projector failure | Serve a dated retained snapshot or explicit unavailability; rebuild from the log. |
| Gate crash before admission | No effect is authorized; retry with the same operation identity. |
| Gate crash after possible submission | Treat outcome as unknown until reconciled; do not issue an unsafe repeat. |
| Trust distribution outage | Apply the declared freshness policy; fail closed where current trust is mandatory. |
| Region loss or storage corruption | Restore original bytes, keys/metadata under approved custody, event logs, policy versions, and replay state; verify digests before resuming reliance. |

Operational acceptance requires measured recovery-point and recovery-time objectives chosen by the owner, tested restore evidence, and a runbook for evidence lost outside the accepted recovery window. Do not declare zero data loss or uninterrupted service without that evidence.

The replay ledger for an enforced effect must survive the same failures as the effect's admission contract. A memory-only gate cannot satisfy this production dependency.

### Retention and evidence portability

Define retention separately for original artifacts, source openings, application decisions, signed receipts, derived graphs, trust snapshots, operational logs, backups, exports, and execution replay state.

Retention policy MUST specify owner, scope, start event, duration or event-based rule, hold behavior, deletion authority, grace period, recipient obligations, and minimum retained material for the promised checks. Record what verification becomes impossible after a source opening is removed.

`retention.policy` records a declared policy commitment, while `retention.purge` evaluates supplied deletion evidence against a declared policy timeline; neither proves every copy has been removed. Current registry: `canon/registry/hive-canon-registry.json`

Evidence portability MUST include a customer exit procedure: enumerate retained case revisions, export permitted originals and histories, provide checker and trust instructions, validate a sample with the recipient, and record unresolved export gaps. Evidence custody is not custody of funds.

### Checker and package supply chain

Before operational acceptance, retain:

* Source revision, build recipe, reproducible dependency lock, compiler/runtime versions, and dependency inventory.
* Checker artifact digest, release authentication, supported profiles, security review, and license notices.
* Schema and vector digests, fixture fingerprints, expected negative outcomes, and test environment.
* A complete export manifest and an explicit list of code that may execute.
* A patch and security-notification procedure for recipients holding old checker versions.
* A policy for vulnerable dependencies and retired algorithms that preserves historical evidence while qualifying current reliance.

An archive can prove its included files match its own manifest without proving the manifest or checker is trustworthy. Obtain trusted checker code and release authentication through a separately accepted channel.

## Threat model and mitigations

Threat actors include a dishonest producer, a mistaken reviewer, a compromised source adapter, a malicious tenant, an attacker controlling a package, an overprivileged operator, and an unavailable or compromised dependency. The design also treats ordinary races, clock drift, and data loss as risks.

| Threat | Impact | Mandatory mitigation | Residual boundary or test |
| :--- | :--- | :--- | :--- |
| Signed false source statement | False content appears trustworthy | Separate source class, integrity, authority, and substantive evaluation | No signature proves source truth; challenge with contradictory authentic evidence |
| Denominator laundering | Missing events disappear from coverage | Predeclared population method and retained snapshot; unexpected-event count | Completeness remains unknown outside that source boundary |
| Same key under two names | Fake bilateral independence | Fingerprint comparison plus organization/custody assessment | Two keys under one operator remain same-operator evidence |
| Self-authorizing package key | Attacker passes its own signature check | Separate trust bootstrap and purpose-bound key registry | Integrity-only check may pass while trust fails |
| Wrong-tenant reference | Evidence or decisions leak across tenants | Server-side object authorization and tenant-scoped caches/queues | Test guessed IDs, export URLs, cursors, and shared hashes |
| Parser ambiguity | Different checkers sign or interpret different content | Strict parse, duplicate-key rejection, profile-specific canonical bytes | Cross-language vectors and unsafe-number rejection |
| Algorithm/profile downgrade | Unsupported strong requirement becomes weaker pass | Pin mandatory profile; no fallback on failure | Unsupported stays unsupported |
| Stale acceptance replay | Old agreement appears current | Bind decision to case/result/profile digests and revision | Old decision remains historical evidence only |
| Source correction concealment | History is overwritten | Append-only revisions and supersession links | Retention deletions must state their scope and limitations |
| Prompt or document injection | Source text controls evaluator or tools | Treat source as data; sandbox evaluator; fixed rubric and tool permissions | Evaluate adversarial documents and output schema violations |
| Graph poisoning | Missing or cyclic dependencies appear supported | Closed edge vocabulary, reference validation, cycle policy, closure analysis | Partial graph cannot claim full downstream impact |
| Untrusted evidence locator | Credential theft or internal network access | No arbitrary fetch; allowlisted authenticated adapters | Report unavailable rather than follow unsafe references |
| TOCTOU mutation | Authorized action changes before execution | Exact payload/destination binding and commit-time fence | Requires tested control at the actual effect endpoint |
| Nonce replay or concurrency race | Duplicate effect | Durable atomic consume, downstream idempotency, scoped nonce | Local in-memory tests do not establish restart safety |
| Alternate execution route | Gate is bypassed | Credential confinement and complete path inventory | Unknown routes prevent a global prevention claim |
| Stale revocation or clock rollback | Expired authority used | Freshness bounds, authenticated snapshots, trusted time policy | Offline current-trust uncertainty remains explicit |
| Downstream timeout | Effect repeated while prior result unknown | Unknown-outcome state and authorized status reconciliation | No blind retry where downstream idempotency is absent |
| Log fork or selective disclosure | One party sees an incomplete history | Retained checkpoints, consistency checks where supported, recipient challenges | Supplied checkpoint does not prove no other log exists |
| Redaction leak | Confidential fields appear in export or telemetry | Allowlist projection, independent field-diff test, recipient-specific packages | Signed disclosure claims alone do not perform leakage inspection |
| Archive bomb or hostile checker | Resource exhaustion or arbitrary execution | Size/expansion limits, safe paths, no untrusted executable loading | Package can be retained without execution |
| Operator key compromise | Forged evidence appears authentic | Separated key custody, scoped issuance, revocation, impact analysis | Historical safety depends on accepted time evidence |
| Silent telemetry loss | Operational metric overstates success | Expected-work denominator, gap counters, reconciliation | Unknown capture invalidates affected rates |

An independent challenge report MUST list tested threats, exact environment, findings, remediation, and unresolved limits. A second reviewer employed by the same operator is useful review, but is not automatically an independent organization or an accredited audit.

## Acceptance criteria and independent challenge

### Catalog requirements

The following IDs and priorities are synchronized with `shared_requirements` and each service's `acceptance_tests`. They are normative test requirements, not claims that the reference engine currently passes every production requirement. Service map: `canon/surfaces/surface-map.json`

#### Shared catalog criteria

| ID | Priority | Given | When | Then |
| :--- | :--- | :--- | :--- | :--- |
| SH-01 | P0 | Existing signed fixtures and canonical identities | the release is built and compared | Existing signed type strings, bytes, schemas, fixture fingerprints, and canonical anchors are unchanged. |
| SH-02 | P0 | A case revision with pinned inputs, rule, and checker | a calculation, export, or party decision is produced | Every calculation, export, and party decision identifies the same case revision, input digest, rule digest, and checker profile. |
| SH-03 | P0 | An unknown denominator, absent source, unsupported algorithm, stale trust, or unavailable dependency | the selected service evaluates the case | Unknown denominator, absent source, unsupported algorithm, stale trust, and unavailable dependency never become a passing result. |
| SH-04 | P0 | A case with mixed outcome dimensions | the API and UI display results | Integrity, trust, coverage, calculation, acceptance, and effect are displayed separately without a misleading aggregate success badge. |
| SH-05 | P0 | A package with supplied key material and a separately selected trust policy | verification runs | A key supplied inside a package cannot authorize itself. Trust purpose, key epoch, validity interval, revocation state, and offline as-of limits are explicit. |
| SH-06 | P0 | An accepted historical case and a correction | the correction is admitted | Corrections reference the original record and reason. Earlier bytes remain inspectable and prior acceptance does not silently transfer to the new revision. |
| SH-07 | P0 | Inputs at and beyond each schema boundary | parsing and validation run | Schemas bound sizes, safe integer ranges, identifiers, timestamps, nesting, duplicate keys, unknown fields, graph cycles, and invalid references. Ambiguous input is rejected. |
| SH-08 | P0 | An integrated tenant service or the public synthetic reference | data is admitted, viewed, or exported | An integrated service enforces tenant scope and roles server-side; its public reference accepts synthetic fixtures only and makes no customer-source calls. |
| SH-09 | P0 | A retained supported package and independently selected trust | Hive is unavailable | A retained package, separate trust configuration, pinned checker, file manifest, and instructions reproduce the declared checks with Hive unavailable. |
| SH-10 | P0 | A displayed metric or performance result | a reviewer opens its evidence | Every metric identifies its unit, numerator, denominator, interval, rule revision, and evidence references. Replay performance is never advertised as production capacity. |
| SH-11 | P0 | Existing buyer files and a canon discovery change | the release is built and exercised | 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. |
| SH-12 | P0 | An implementation requesting operational acceptance | load, outage, partial-write, and recovery tests run | Production admission defines backpressure, retries, idempotency, out-of-order input, revocation, partial writes, disaster recovery, and retention behavior before operational acceptance. |
| SH-13 | P1 | A new adapter and retained original signed bytes | version-specific conformance vectors run | A new adapter preserves original signed bytes and passes version-specific conformance vectors. Unsupported versions fail closed without silent downgrade. |
| SH-14 | P1 | A qualified independent recipient with a declared challenge | the recipient exercises an accepted profile | An independent recipient can supply a challenge, run an accepted profile, and retain negative results without relying on the issuer's dashboard. |

#### Evidence Contract Studio catalog criteria

| ID | Priority | Given | When | Then |
| :--- | :--- | :--- | :--- | :--- |
| EC-01 | P0 | an unknown applicability decision | the profile is evaluated | the requirement remains unresolved and cannot increase the covered count |
| EC-02 | P0 | a referenced evidence source is missing | the case is evaluated | the obligation names the missing source and produces an incomplete result |
| EC-03 | P0 | a changed rule version | a previous case is inspected | the original rule remains pinned and a new result requires a new revision |
| EC-04 | P1 | a new source adapter | the profile conformance vectors run | all required positive and negative vectors pass before adapter admission |

#### Counterparty Reconciliation catalog criteria

| ID | Priority | Given | When | Then |
| :--- | :--- | :--- | :--- | :--- |
| CR-01 | P0 | two consistent attempts for one logical event | the agreed deduplication rule runs | attempt count rises while logical count stays one |
| CR-02 | P0 | conflicting records with valid signatures | the case is checked | integrity can pass while reconciliation remains disputed |
| CR-03 | P0 | acceptance of revision one | a material correction creates revision two | the earlier decision is retained and revision two awaits its own decision |
| CR-04 | P1 | a delayed authorized observation | the late-data rule admits it | a new case revision is created without changing previous exports |

#### Decision Evidence Graph catalog criteria

| ID | Priority | Given | When | Then |
| :--- | :--- | :--- | :--- | :--- |
| DE-01 | P0 | a signed reference to an unrelated passage | only structural checking runs | no semantic-support or truth claim is emitted |
| DE-02 | P0 | a cycle or unresolved graph edge | the package is evaluated | the structural check fails with the offending identifiers |
| DE-03 | P0 | an altered required evidence node | replay runs | the input digest and affected result change and prior acceptance cannot carry over |
| DE-04 | P1 | a qualified evaluator result | a reviewer opens the claim | method, version, inputs, uncertainty, and assessment scope are visible separately from the signature |

#### Action Boundary catalog criteria

| ID | Priority | Given | When | Then |
| :--- | :--- | :--- | :--- | :--- |
| AB-01 | P0 | an authorization bound to payload A | payload B is submitted | the controlled effect is refused and the mismatch is recorded |
| AB-02 | P0 | a consumed authorization | the same or concurrent request is retried | no additional controlled effect occurs |
| AB-03 | P0 | revoked, expired, or unresolvable authority | enforced admission runs | the action is refused or blocked according to the explicit fail-closed policy |
| AB-04 | P0 | an observational sidecar | evidence collection fails | the result is an evidence gap, not a claim that the customer's action was blocked |

#### Portable Trust catalog criteria

| ID | Priority | Given | When | Then |
| :--- | :--- | :--- | :--- | :--- |
| PT-01 | P0 | a complete retained supported package and separate trusted key | Hive is unavailable | the pinned checker reproduces supported checks without network access |
| PT-02 | P0 | a package that substitutes its own key | verification runs | the substituted key does not become trusted |
| PT-03 | P0 | an unsupported mandatory signature profile | the package is checked | unsupported is returned with no fallback to a weaker successful check |
| PT-04 | P0 | valid as-of trust but unavailable current revocation data | offline verification runs | the result states its as-of limit and does not assert current non-revocation |

### Additional end-to-end criteria

These local architecture IDs supplement, and do not replace, the catalog IDs.

| ID | Priority | Given | When | Then |
| :--- | :--- | :--- | :--- | :--- |
| AX-01 | P0 | A selected case revision and fixed profile | A user opens any of the five views and exports | Case, input, rule, decision, and checker identities agree across views and package |
| AX-02 | P0 | An established empty expected population | Coverage is calculated | Denominator is zero, ratio is null, reason is empty population, and no 100 percent badge appears |
| AX-03 | P0 | Two key IDs resolving to the same public key | Bilateral evidence or party signatures are assessed | Key aliasing is detected and independence is not asserted |
| AX-04 | P0 | Two distinct keys controlled by one operator | The reference demonstrates two parties | Cryptography may pass but the relationship remains synthetic or same-operator |
| AX-05 | P0 | A valid portable final-state proof with omitted constituent receipts | Full transition replay is requested | Assertion integrity can pass but full replay remains blocked with the required input list |
| AX-06 | P0 | A service or browser has no previously cached dependencies | The supported offline package is opened with network disabled | Required supported checks run locally or report the precise unsupported environment without network fallback |
| AX-07 | P0 | A source event arrives after the closed window | The late-data policy admits it | A new revision is created with original event time, late ingestion time, recalculation, and stale prior acceptance |
| AX-08 | P0 | A reserved action and a changed destination | Commit is requested | The effect is refused and the mismatch is retained |
| AX-09 | P0 | Authority is revoked between validation and commit | A qualified enforced adapter reaches its fence | The current policy is applied before effect admission; no old precheck alone authorizes |
| AX-10 | P0 | An external submission may have occurred before timeout | Recovery runs | Outcome becomes unknown and no second effect is submitted until the idempotency/status contract makes retry safe |
| AX-11 | P0 | A crash after authorization consumption | The accepted production adapter restarts | Durable replay state prevents an unauthorized second effect and preserves the recovery decision |
| AX-12 | P0 | A user lacks permission to a required evidence node | Graph inspection or export runs | Content and sensitive locator are withheld while the resulting limitation remains explicit |
| AX-13 | P0 | A malformed package with duplicate keys, unsafe numbers, traversal paths, or excess nesting | Parsing and package admission run | Input is rejected deterministically before it can influence calculation or execution |
| AX-14 | P0 | A claimed current verification with expired trust information | Network is unavailable | Integrity may be reported but current trust is unknown and no current non-revocation claim appears |
| AX-15 | P0 | A source adapter or evaluator is unavailable | The UI refreshes | The last retained result is dated stale or blocked, never silently replaced by synthetic success |
| AX-16 | P0 | A submitted hash without evidence bytes | A user requests verification | The UI labels lookup separately and requests a package for actual checking |
| AX-17 | P0 | Different application and typed-envelope byte profiles | A checker dispatches an artifact | Only the exact supported profile is used; reserialization never repairs a signature |
| AX-18 | P0 | A public discovery page | A visitor runs every available scenario | Only labeled synthetic fixtures are processed; no customer-source calls, credentials, or external effects occur |
| AX-19 | P0 | Existing registry entries and historical signed fixtures | This release is built | Original entry contents, type strings, anchors, and signed fixture bytes remain unchanged; five services do not increase primitive counts |
| AX-20 | P1 | A ruleset change affecting one requirement | Impact analysis runs | Affected obligations and cases are listed without changing historical results |
| AX-21 | P1 | Two evaluator runs disagree | A reviewer opens the claim | Each method, version, inputs, uncertainty, and attributed outcome remain visible |
| AX-22 | P1 | An authorized recipient's independent challenge package | A qualified checker runs outside the issuer dashboard | Positive and negative results can be retained with exact code, trust, and package digests |
| AX-23 | P1 | An accepted trust key rotation | An old and a new package are checked | Historical and current trust evaluations use their declared epochs without silently replacing anchors |
| AX-24 | P1 | A recipient's retention/export policy | A full customer exit drill runs | Permitted evidence and checker material are retained, omitted items are enumerated, and the recipient records reproduction results |
| AX-25 | P0 target adapter vector | Two accepted issuer aliases resolve to the same public key and the supplied custody presentations use those different aliases | The future distinct-key service adapter evaluates the complete required inputs | The adapter rejects the distinct-key requirement after fingerprint comparison; the canonical key-ID gate is not credited with that protection |
| AX-26 | P0 target signing/profile vector | Two tenants deliberately share identical local case, party, and actor IDs but have different tenant_scope_id values | A recipient checks a decision signed for the other tenant, including without the originating API | The recipient rejects the tenant mismatch before acceptance even if the signature and local IDs match |
| AX-27 | P0 target signing/profile vector | A valid tenant-bound decision for one audience and decision profile | It is replayed under a different audience or profile/version | Recipient-side context checking rejects the mismatch and retains the original decision only as evidence of its original scope |

AX-25 to AX-27 are new **target acceptance requirements**, not claims of shipped adapter checks or passing vectors in the current reference.

### Test evidence protocol

For each test retain ID, priority, applicable tier, implementation revision, fixture/package digest, environment, command or procedure, expected and actual result, observed time, tester, relationship to the builder, and finding status.

The reference suite MUST not mark integrated or operational criteria passed merely because an in-memory analogue passed. It may record `not_applicable_to_reference` with the remaining production dependency.

An independent auditor should receive the immutable package and trust acquisition instructions, not just screenshots. The auditor should select negative inputs, alter a signed field, substitute a key, omit an input, replay a permit, and challenge a stale decision. Unresolved findings remain in the release record.

Accessibility acceptance applies to discovery and review: keyboard navigation, readable focus, non-color-only statuses, usable narrow layouts, and direct access to evidence and limitations. Download links must identify whether they deliver an artifact, a checker, a trust file, or a report.

## Metrics and measurement contracts

### Measurement rules

Every metric MUST carry `metric_id`, unit, value or null, numerator, denominator where applicable, population definition, exclusions, source mode, interval, case/profile/rule version, source references, computed time, and known/unknown reason.

Use event-time intervals for evidence populations and measurement-time intervals for operational samples; identify which applies. Deduplicate by the metric's declared unit, not by whatever IDs happen to be convenient. Unknown and not applicable observations are counted separately, not dropped to improve a percentage.

Do not combine synthetic and production cohorts. A reference timing measures that local operation in that environment, not a capacity promise.

### Exact catalog metric IDs

The following IDs, numerator definitions, denominator definitions, and unknown conditions match the current service map. Operational refinements below preserve those meanings. Service map: `canon/surfaces/surface-map.json`

| Service and metric ID | Name | Numerator | Denominator or unit | Unknown when | Not a claim of |
| :--- | :--- | :--- | :--- | :--- | :--- |
| `evidence-contract` / `requirement_coverage` | Mapped requirements | applicable requirements with an evidence binding and check | all requirements declared applicable in the approved version | applicability is unresolved | percentage legal compliance |
| `evidence-contract` / `capture_coverage` | Evidence capture coverage | eligible logical events with required evidence complete | eligible logical events in the scoped expected population | expected population is not established | received receipts divided by received receipts |
| `counterparty-reconciliation` / `count_delta` | Count difference | producer logical count minus recipient reproduced logical count | not a ratio | one side lacks reproducible permitted inputs | automatic billing adjustment |
| `counterparty-reconciliation` / `accepted_case_rate` | Jointly accepted revisions | eligible current case revisions accepted by every required authorized party | eligible current calculated case revisions | required party set is not fixed | matching signatures |
| `counterparty-reconciliation` / `investigation_effort` | Investigation effort | measured handling minutes for closed comparable cases | closed comparable cases in the same cohort | baseline or case timestamps are unavailable | a synthetic time-saving claim |
| `decision-evidence` / `structural_support` | Structurally linked claims | claims with all required resolvable evidence links | claims requiring support in the scoped version | claim inventory is incomplete | semantic correctness |
| `decision-evidence` / `semantic_assessment` | Assessed semantic support | claims meeting the disclosed evaluator's support test | claims assessed under that evaluator and version | qualified evaluation was not run | signature validity or source truth |
| `decision-evidence` / `change_impact` | Affected decisions | decisions reachable from changed evidence through typed dependency edges | not a ratio | dependency graph is incomplete | proof all downstream effects were captured |
| `action-boundary` / `gate_decisions` | Admission outcomes | allowed, refused, error, and unresolved decisions separately | all eligible attempts at the named boundary | capture of attempts is incomplete | all actions in the customer's environment |
| `action-boundary` / `effect_confirmation` | Confirmed effects in scope | consumed authorizations with valid matching effect evidence | consumed authorizations requiring effect evidence | effect observation is unavailable | global exactly-once assurance |
| `action-boundary` / `enforcement_latency` | Admission latency | measured decision latency distribution | eligible measured decisions per profile and load regime | no controlled measurement exists | simulation replay throughput |
| `portable-trust` / `portable_replay` | Reproducible packages | eligible packages reproducing all required supported checks in a clean recipient environment | eligible packages tested under the stated profile | recipient-side test has not occurred | downloads or website visits |
| `portable-trust` / `trust_freshness` | Trust information age | verification time minus trust snapshot time | not a ratio | no authenticated trust timestamp exists | proof no later revocation occurred |
| `portable-trust` / `retained_completeness` | Required files retained | required manifest files present with matching digests | required files named by the pinned package profile | manifest or profile is untrusted | source completeness |

### Operational refinements

* `requirement_coverage`: count a requirement only when applicability is resolved, an evidence binding exists, and a check is specified. Unresolved applicability makes the overall catalog metric unknown; a separately labeled known-subset count may still be shown.
* `capture_coverage`: numerator requires **all required evidence complete for each eligible logical event**, not merely any observed receipt. “Coverage and event identity”'s simpler observed-event ratio is a separate diagnostic called `observed_event_coverage`, not this catalog metric. Publish both sets if useful.
* `count_delta`: return an integer difference with each party's separately reproduced count and input scope. It is not a percentage or an instruction to adjust money.
* `accepted_case_rate`: count at most one current eligible calculated revision per case in the interval's snapshot. Every required authorized party must have accepted that revision. Pending, rejected, escalated, stale, and missing decisions remain in the denominator when the case is otherwise eligible.
* `investigation_effort`: handling minutes means measured active human work under a predeclared logging method, not wall-clock time waiting for another party. Cohorts must match case complexity and workflow. Missing baseline or unreliable timestamps produce unknown improvement, not zero effort.
* `structural_support`: denominator is the frozen scoped claim inventory requiring support. Numerator requires every mandatory resolvable link. A null support digest or inaccessible required opening does not count as fully linked for recipient reproduction.
* `semantic_assessment`: denominator includes claims with a completed assessment under the named evaluator/version, including contradicted, insufficient, and abstained results. Failed jobs are counted separately and do not become assessed claims. Publish assessment coverage alongside the support ratio to expose cherry-picked evaluation.
* `change_impact`: count distinct reachable decisions using the pinned typed dependency graph. Graph incompleteness makes the full impact count unknown; a known-subgraph count must be labeled bounded.
* `gate_decisions`: maintain separate counts of allowed, refused, error, and unresolved eligible attempts. Their sum must reconcile to the attempt population. Retries and logical actions are separate diagnostic counts. A bypass population not observed by the gate is not part of this denominator.
* `effect_confirmation`: count consumed authorizations only once and require valid matching effect evidence under the adapter profile. Partial or unavailable observation produces unknown where the numerator cannot be established, with known confirmations still displayed separately.
* `enforcement_latency`: retain the duration sample for each eligible measured decision, load regime, clock, start/end definition, queue-time inclusion, and error class. Publish sample count and unmeasured decisions alongside quantiles; do not treat a quantile as a numerator/denominator percentage.
* `portable_replay`: denominator is eligible packages actually tested under the stated profile and recipient environment. Unsupported packages are a separate population; missing required files in an eligible package are failures, not exclusions.
* `trust_freshness`: subtract authenticated snapshot time from verification time, retain clock uncertainty, and reject a misleading negative age caused by an unsafe clock.
* `retained_completeness`: count required manifest files whose exact bytes and lengths match. A complete file set is not proof that the profile requested every relevant source.

### Shared operational and product metrics

| Metric | Numerator | Denominator or unit | Unknown state |
| :--- | :--- | :--- | :--- |
| Evidence admission failure rate | Eligible admitted submissions ending in admission failure | All eligible admitted submissions in the window | Submission population cannot be reconciled |
| Reproduction mismatch rate | Completed deterministic replays whose output differs | Completed comparable deterministic replays under the same rule/profile | Inputs or expected outputs unavailable |
| Unresolved effect rate | Consumed authorizations still outcome-unknown at the cutoff | Consumed authorizations whose observation deadline has passed | Consumption ledger or deadline policy incomplete |
| Stale decision rate | Required current party decisions marked stale | Required current decision slots for eligible case revisions | Required-party set unknown |
| Export completion rate | Authorized export jobs producing all required permitted material | Authorized export jobs due by the measurement cutoff | Job population or permission boundary incomplete |
| Retention restore success | Restored test packages passing required retained checks | Scheduled restore packages actually tested | No restore test or untrusted inventory |
| Reviewer task completion | Reviewers completing the predefined evidence-finding task correctly | Eligible observed task attempts | Task rubric or observations unavailable |
| Repeat scoped use | Eligible organizations returning for another completed scoped case | Eligible organizations with an initial completed scoped case and full follow-up window | Cohort or follow-up incomplete |

Product owner establishes baseline cohorts before asserting improvement. Operations owner defines the accepted load and recovery thresholds. Trust owner defines freshness policy. Report results on a dated agreed interval after baseline collection; do not invent a percentage improvement, service SLO, price, or adoption total in advance.

## Service packaging and readiness tiers

### Packaging without invented pricing

Offer discoverable capabilities, not fictional commercial entitlements.

| Service | Base deliverable | Separately scoped options | Commercial boundary |
| :--- | :--- | :--- | :--- |
| Evidence Contract Studio | Profile workspace, requirement map, compiler contract, export | Managed mapping review, specialized source templates | No legal opinion or universal compliance certification |
| Counterparty Reconciliation | Bounded case workflow, rule reproduction, separate party decisions | Additional parties, dispute operations, source integration | No implicit settlement, payment, or billing authority |
| Decision Evidence Graph | Evidence linkage, graph checks, replay interface | Qualified semantic evaluator, specialized media/model adapters | No default semantic correctness or source-authenticity guarantee |
| Action Boundary | Boundary SDK, executor contract, attempts and outcomes | Qualified effect integration, operations and recovery support | Scope is the accepted effect and environment, not all customer actions |
| Portable Trust | Supported local checker and evidence package | Hosted retrieval, long retention, trust operations, archive migration | No universal hosted verification or storage-forever commitment |

Contract variables should include accepted profiles, environments, tenants, source adapters, artifact volume/size, retention, availability, recovery, support, key custody, effect scope, and recipient export rights. Prices, quotas, free allowances, and commercial guarantees require separate approval and provisioning.

### Exact maturity ladder

The following tier IDs match the service map. A service can be at different tiers for different profiles and operations. Service map: `canon/surfaces/surface-map.json`

| Tier | Required acceptance | Permitted description | Not implied |
| :--- | :--- | :--- | :--- |
| `specified` | Versioned contract, exact canon dependencies, failure semantics, acceptance criteria | Service architecture and discovery are specified | Working runtime or installed integration |
| `reference` | Bounded working implementation, adverse tests, reproducible package, explicit boundary | Local synthetic reference demonstrates listed operations | General compiler, semantic evaluator, independent party participation, durable execution |
| `integrated` | Authorized source owners, authenticated adapters, tenant isolation, trust/retention configuration, effect tests where applicable | Named integration supports a declared scope | Production capacity, continuous availability, customer-wide deployment |
| `operational` | Accepted deployed revision, controlled load/recovery evidence, incident/support process, customer acceptance | Operationally accepted for the named environment and scope | Global availability or performance outside the accepted envelope |
| `independently_exercised` | Qualified separate operator, declared challenge/scope, retained reproducible evidence, unresolved findings | Independently exercised for the stated test | Accreditation, universal correctness, institutional adoption, or broader independence |

Tier promotion MUST identify profile, operation, tenant/environment scope, revision, observed time, evidence, owner, and expiry/review trigger. A critical code, trust, boundary, or dependency change can require reacceptance.

### Per-service production dependencies

| Service | Integration blockers | Operational blockers | Owner |
| :--- | :--- | :--- | :--- |
| Evidence Contract Studio | Approved mappings, scoped compiler, source ownership, signed release authorization | Migration governance, retained rules, measured compile behavior, support | Profile owner and canon steward |
| Counterparty Reconciliation | Party-specific sources, authority and key custody, event identity, dispute rules | Volume behavior, late/corrected event recovery, participant service agreement | Case owner and each party |
| Decision Evidence Graph | Source permissions, selector stability, graph schema, evaluator qualification where claimed | Sandboxing, resource limits, evaluator drift policy, reproducible builds | Evidence/evaluator owner |
| Action Boundary | Effect path inventory, credential confinement, atomic replay state, authority and revocation contract | Durable restart safety, bypass/load tests, unknown-outcome recovery, incident control | Effect owner and security owner |
| Portable Trust | Trust distribution, supported checker profiles, redistribution permissions | Recipient reproduction, retention/restore drills, dependency lifecycle | Trust and evidence custodians |

“Blocked for production” does not mean “hidden from canon.” It means the service remains discoverable with its present tier and next acceptance requirement.

## Reference implementation boundary and build sequence

### What the reference is

The reference guide describes a fixed neutral synthetic case engine with `evaluateCase`, `verifyPackage`, `createLocalGate`, strict parsing, canonicalization, and SHA-256 helpers; its local effect is an in-memory event, not an external action. Reference guide: `canon/surfaces/reference/README.md` Reference engine: `canon/surfaces/reference/engine.mjs`

Its case format includes a separately declared synthetic expected population, records, attempts, evidence, fixed rule, and a version-bound acceptance object; the outer signature binds the complete case, but the example does not collect independently controlled real-party signatures. Reference guide: `canon/surfaces/reference/README.md`

These are reference application formats and fixtures. They do not mint five new canonical types, prove the production APIs in “Discovery, proposed manifest, and API contract” exist, or establish current acceptance of the canonical typed endpoints.

In particular, importing and checking `hive.reference.*` application objects does not exercise the canonical receipt verifiers listed on the service cards. The operation inventory at `canon/surfaces/operations.json` must make that separation explicit. General compiler, semantic-evaluator, independently authenticated party-decision, and durable external-executor operations remain separately specified until their own executable and acceptance evidence exist.

### Reference result adapter

The reference's return fields are not the proposed hosted case API. Preserve its versioned output and adapt it explicitly for discovery.

| Reference output | Discovery interpretation | Restriction |
| :--- | :--- | :--- |
| `evaluateCase(...).valid` | Structural validity of the local case input | Not a package signature or whole-product verification result |
| `status: ready` | Fixed local calculation is ready | Not production readiness |
| `coverage.status: known` | A declared synthetic denominator exists | Compute complete/incomplete from required evidence; do not map known directly to complete |
| `requirements.status` | Fixed synthetic evidence obligations | Not a general requirements compiler |
| `reconciliation.status` | Local deterministic comparison state | Not independent counterparty agreement |
| `support.status` | Structural references only | Never semantic support |
| `acceptance.status: current` | Synthetic acceptance object binds the current reference case | Not independently supplied business acceptance |
| `gate.eligible` | Local calculation eligibility | Not authorization to execute before signature/trust/token checks |
| `verifyPackage(...).integrity`, `.trust`, `.replay` | Separate supported package check results | Map supported states through an explicit adapter; do not flatten them into one badge |
| `createLocalGate(...).execute(...)` | Bounded in-memory effect test | No durable restart protection or external control claim |

The fields and limitations above come from the reference interface, not an assertion that all final regression tests have passed. Reference guide: `canon/surfaces/reference/README.md` Reference handoff: `canon/surfaces/reference/PARENT_API_HANDOFF.txt`

The outward acceptance adapter MUST NOT convert `current` directly into authenticated acceptance. Before the reference outer signature and trust checks complete, report `acceptance: pending` with `recorded_only` and `authentication_not_checked`; on authentication failure retain the recorded claim with a specific failure reason. A positive authenticated reference result is labeled **synthetic operator-recorded acceptance**, not independent party acceptance. Production decisions depend on their own signatures and authority, not on unrelated evidence passing integrity.

The reference fixture expectation for a revoked or tampered package can still show a ready pure calculation and `gate.eligible: true`; actual package trust/integrity and signed-token checks must deny execution. That distinction is intentional and MUST survive UI projection. Fixture expectations: `canon/surfaces/reference/fixture-expectations.json` Reference handoff: `canon/surfaces/reference/PARENT_API_HANDOFF.txt`

The map's `reference_status` and the reference worker's retained test artifacts are the authority for current local test claims. This document does not predeclare test counts, passing suites, completed packaging, or operational acceptance.

### Build sequence

1. Publish the five accurate canon discovery entries and separate service map, preserving primitive identity and buyer scope.
2. Deliver the fixed synthetic vertical slice with normal, retry, missing, conflict, correction, denial, unknown coverage, revoked trust, stale acceptance, tampered, and unsupported scenarios.
3. Verify local package signatures and offline replay, and qualify the bounded in-memory effect against its own stated tests.
4. Publish exact reference capabilities and unresolved limitations; do not imply the advanced target architecture is all implemented.
5. Implement shared durable case, profile, trust, and artifact services behind proposed contracts.
6. Qualify one authenticated source/reconciliation/recipient workflow with explicit ownership and acceptance.
7. Add semantic evaluation or an external effect boundary only under their separate qualification requirements.
8. Measure operations, recovery, retention, and recipient challenge before operational promotion.

Steps 5 to 8 are acceptance work for production features, not a reason to delay steps 1 to 4 or make all five services depend on a prospect pilot.

## Open decisions, canonical conflicts, and release audit

### Decisions needing owners

| Decision | Owner | Blocking scope | Required resolution |
| :--- | :--- | :--- | :--- |
| Exact hosted resource API and deployment host | API owner | Hosted integration only | Implement and test method/path/schema/auth/version contract; keep proposed until then |
| General obligation compiler language | Profile owner and security | General Studio integration | Closed declarative grammar, resource limits, deterministic vectors, no arbitrary code execution |
| Portable party decision authentication | Each party and security | Real separate acceptance | Approve application signing profile or compatible existing party format; provision independent authority |
| Semantic evaluator qualification | Evaluation owner | Semantic-support claim | Method/version, evidence, uncertainty, relationship, validation, error and abstention policy |
| Effect endpoint and replay persistence | Effect owner | Enforced external action | Named boundary, path inventory, atomic/durable state, status and recovery contract |
| Time and revocation freshness | Trust owner and effect owner | Current-trust and enforcement claims | Authenticated distribution, accepted uncertainty, outage behavior, measured propagation |
| Rule and source retention | Data owner and custodian | Long-term reproduction | Permitted retention/openings, holds, export, deletion consequences |
| Cross-language canonicalization edge cases | Canon steward | New interoperable producer | Run vectors against exact implementations; version any incompatibility rather than repair bytes |
| Capacity and recovery thresholds | Operations owner | Operational tier | Controlled measurements and approved objectives, no inherited demo numbers |
| Independent exercise | Release owner and qualified recipient | Independent-exercise claim | Separate operator, challenge plan, reproducible evidence, retained findings |

### Resolved architecture conflicts

* Five service IDs are discovery compositions; they do not change the primitive inventory.
* Demand is requester-controlled evidence specification, not gateway arrival or runtime enforcement.
* Canon entries with no type remain anchor-addressed composites or external services.
* A typed facade cannot inherit the stronger behavior of an older, different envelope profile.
* A link to a source is not a semantic evaluator result.
* A calculation is not party acceptance, and same-operator keys are not external independence.
* Pre-effect evidence and post-effect outcome are ordered, separate artifacts.
* A local in-memory gate is a real bounded reference mechanism but not a durable external enforcement integration.
* Hash lookup is retrieval, not verification.
* Offline as-of trust is not current non-revocation.
* A reference application package is not a canonical typed receipt.
* Public canon discovery does not alter a buyer engagement or authorize a source adapter. Existing engagement pages, pitches, source configurations, and shared assets remain unchanged. The new services must not be cross-sold through protected buyer demos. Inherited canon metadata remains discovery context, not an adoption or endorsement claim.

### Release audit checklist

The release owner MUST independently check the following before promoting claims:

1. Resolve every `composition_anchors` entry against the unchanged primitive entries; validate names, IDs, categories, and ceilings.
2. Keep `surface-map.json`, this document, and UI labels consistent for service names, lifecycle states, metric IDs, and acceptance IDs.
   Resolve selected service and shared-layer memberships against `canon-bindings.json`, and implementation claims against `operations.json`.
3. Confirm `registry-coverage.json` retains every original entry, including specialties with no assigned surface.
4. Check all artifact links and verify offline packages from a fresh supported environment.
5. Compare reference claims to actual tests and operation scope, not screenshots or anticipated outcomes.
6. Exercise missing, conflicting, corrected, unsupported, revoked, altered, replayed, and stale-decision paths.
7. Verify no private/unfiled details, real customer evidence, production secrets, or unauthorized external calls appear in the public reference.
8. Verify existing buyer files and shared assets remain byte-identical within this task's scope.
9. Record unresolved findings and keep affected operations at the appropriate lower tier.

This document is an architecture and acceptance contract. It is not an independent audit certificate, a release test report, or a declaration that every specified runtime component was implemented in this release.

## Appendix A. Whole-canon coverage without flattening specialties

The full canon remains the primitive and component inventory. The five services are entry points into it, not a replacement taxonomy that forces every specialty into a selected case.

The release coverage map records every registry entry and its selected service/shared-layer assignments; an empty `surface_ids` array means the specialty remains in the canon without an explicit service dependency in this release. It does not mean the entry was removed or its acceptance upgraded. Registry coverage map: `canon/surfaces/registry-coverage.json`

### Before, during, and after

| Phase | Shared layer IDs from the service map | Product use | Boundary |
| :--- | :--- | :--- | :--- |
| Before | `demand`, `authority` | Scope requirements, identity, permitted operations, prerequisites, and trust | A requirement or authority record does not prove later fulfillment |
| Before and during | `capture` | Bind supplied sources, population snapshots, document/media regions, and source context | Source authenticity and complete capture require their own evidence |
| During | `execution`, `evaluation` | Record serving state, transformations, support, calculations, policy decisions, and effects | Recorded declarations do not install control or establish physical causation |
| During and after | `reconciliation` | Compare observations, order events, preserve differences and corrections, record party decisions | Calculated agreement is not business acceptance |
| After and continuing | `portability` | Retain, disclose, verify, replay, challenge, rotate trust, and manage retention | Offline and archival checks are bounded by supplied material and dated trust |

The shared-layer IDs and selected anchors are defined in the separate map. Specialty instruments for document regions, media, devices, agent activity, measurement, financial evidence, and economic rails remain optional profile-specific routes rather than mandatory dependencies of every service. Service map: `canon/surfaces/surface-map.json` Current registry: `canon/registry/hive-canon-registry.json`

### Complete registry identity index

The following index is generated from the inspected registry's public entries. It preserves exact anchors, types, and categories. It is an inventory, not a claim that every entry is implemented by the five-service reference or suitable for every buyer job. Current registry: `canon/registry/hive-canon-registry.json`

#### `typed_receipt_contract`: 105 entries

| Exact canonical type | Exact anchor |
| :--- | :--- |
| `absence.scope` | `absence-scope` |
| `admission.binding` | `admission-binding` |
| `afir.ocr.docproof` | `afir-ocr-docproof` |
| `afir.s3` | `afir-s3` |
| `afir.stream` | `afir-stream` |
| `agent.coalition` | `agent-coalition` |
| `agent.metamorphosis` | `agent-metamorphosis` |
| `analysis.replay` | `analysis-replay` |
| `assembly.receipt` | `assembly-receipt` |
| `authority.carriage` | `authority-carriage` |
| `authority.delegation` | `authority-delegation` |
| `authority.qualification` | `authority-qualification` |
| `authority.revocation` | `authority-revocation` |
| `authorization.decision` | `authorization-decision` |
| `binding.uncertainty` | `binding-uncertainty` |
| `perf.attestation` | `bpa-attestation` |
| `perf.budget` | `bpa-budget` |
| `cache.epoch` | `cache-epoch` |
| `capability.exercise` | `capability-exercise` |
| `capture.commitment` | `capture-commitment` |
| `causal.path` | `causal-path` |
| `cloazk.warden` | `cloazk-warden` |
| `conduct.record` | `conduct-record` |
| `control.replay` | `control-replay` |
| `corpus.commitment` | `corpus-commitment` |
| `custody.handoff` | `custody-handoff` |
| `decision.provenance` | `decision-provenance` |
| `delegation.attenuation` | `delegation-attenuation` |
| `determinism.class` | `determinism-class` |
| `directory.state` | `directory-state` |
| `replay.disclosurefree` | `disclosure-free-replay` |
| `disclosure.presentation` | `disclosure-presentation` |
| `usap.diurnal` | `diurnal-bond` |
| `divergence.attestation` | `divergence-attestation` |
| `effect.closure` | `effect-closure` |
| `effect.quiescence` | `effect-quiescence` |
| `usap.egress` | `egress-bond` |
| `entropy.custody` | `entropy-custody` |
| `erasure.receipt` | `erasure-receipt` |
| `eval.administration` | `eval-administration` |
| `eval.attestation` | `evar` |
| `fault.attribution` | `fault-attribution` |
| `usap.forensic` | `forensic-rail` |
| `stream.attestation` | `foretoken` |
| `hivebound.envelope` | `hivebound-envelope` |
| `hiveseal.qpuf` | `hiveseal-qpuf` |
| `usap.howler` | `howler-sae` |
| `voting.verifiable` | `hvvs` |
| `imprimatur.clearance` | `imprimatur` |
| `inkframe.nonmutation` | `inkframe-non-mutation` |
| `intent.affirmation` | `intent-affirmation` |
| `intent.verifiability` | `intent-verifiability` |
| `jurisdictional.clearance` | `jurisdictional-clearance` |
| `knowledge.timestamp` | `knowledge-timestamp` |
| `ledger.parity` | `ledger-parity` |
| `mandate.aggregate` | `mandate-aggregate` |
| `mandate.conformance` | `mandate-conformance` |
| `mandate.crossacceptor` | `mandate-crossacceptor` |
| `mandate.crossreference` | `mandate-crossreference` |
| `mandate.evaluation` | `mandate-evaluation` |
| `meter.witness` | `meter-witness` |
| `model.change` | `model-change` |
| `divergence.record` | `multi-source-divergence` |
| `numeric.lineage` | `numeric-lineage` |
| `origin.raster` | `origin-raster` |
| `origin.proof` | `originproof` |
| `parametric.trigger` | `parametric-trigger` |
| `usap.pbs` | `pbs` |
| `usap.perimeter` | `perimeter-bond` |
| `portfolio.exposure` | `portfolio-exposure` |
| `ppr.wearable` | `ppr` |
| `proof.prefill` | `proof-pre-fill` |
| `proof.transition` | `proof-transition` |
| `proof.transition.portable` | `proof-transition-portable` |
| `recovery.determination` | `recovery-determination` |
| `usap.refusal` | `refusal-ledger` |
| `render.profile` | `render-profile` |
| `retention.policy` | `retention-policy` |
| `retention.purge` | `retention-purge` |
| `routing.receipt` | `routing-receipt` |
| `royalty.provenance` | `royalty-provenance` |
| `s2s.signature` | `s2s` |
| `safety.envelope` | `safety-envelope` |
| `screening.attestation` | `screening-attestation` |
| `sequence.attestation` | `sequence-attestation` |
| `settlement.feed` | `settlement-feed` |
| `sigr.bill` | `sigr-bill` |
| `sigr.bond` | `sigr-bond` |
| `sigr.cachesign` | `sigr-cachesign` |
| `sigr.chain` | `sigr-chain` |
| `sigr.consensus` | `sigr-consensus` |
| `sigr.gca` | `sigr-gca` |
| `sigr.gitm` | `sigr-gitm` |
| `sigr.manifest` | `sigr-manifest` |
| `sigr.mir` | `sigr-mir` |
| `sls.metering` | `sls-metering` |
| `receipt.registry.sovereign` | `sovereign-receipt-registry` |
| `stage.replay` | `stage-replay` |
| `proof.demand` | `stipryn` |
| `structural.lateration` | `structural-lateration` |
| `submission.attestation` | `submission-attestation` |
| `supersession.receipt` | `supersession-receipt` |
| `tolerance.bond` | `tolerance-bond` |
| `transparency.checkpoint` | `transparency-checkpoint` |
| `verdict.custody` | `verdict-custody` |

#### `external_operational_service`: 16 entries

| Exact canonical type | Exact anchor |
| :--- | :--- |
| `afir.route` | `afir` |
| `amplify.certified_call` | `amplihive` |
| `gateway.countersignature` | `carnac` |
| `audit.hashhistory` | `hahs` |
| No canonical signed type | `hive-passport` |
| `receipt.settlement` | `hive-receipt` |
| `inkframe.v1` | `inkframe-v1` |
| No canonical signed type | `mcp-relay-layer` |
| `media.origin` | `media-origin-receipt` |
| `flow.protection` | `protected-flow` |
| `receipt.reduction` | `r3pv` |
| `discrimination.sixhop` | `shod` |
| `message.sealedstate` | `smsh` |
| `zk.spectral` | `spectralzk` |
| No canonical signed type | `typed-signer` |
| `viewkey.disclosure` | `viewkey` |

#### `product_composite_system`: 13 entries

| Exact canonical type | Exact anchor |
| :--- | :--- |
| No canonical signed type | `canon-tiers` |
| No canonical signed type | `carnac-director` |
| No canonical signed type | `carnac-gateway` |
| No canonical signed type | `carnac-governance` |
| No canonical signed type | `hive-customer-console` |
| No canonical signed type | `hive-ledger` |
| No canonical signed type | `morso` |
| No canonical signed type | `proof-credit` |
| No canonical signed type | `protected-flow-fleets-composite` |
| No canonical signed type | `provable-machines` |
| No canonical signed type | `smartagent-route-graph` |
| No canonical signed type | `standard-units-glossary` |
| No canonical signed type | `xcalibur` |


Optional custody, settlement, payment, credit, and economic components are not required for off-chain evidence review, reconciliation, or local verification. Their own ownership, authorization, and production acceptance must be qualified separately. A composite label or glossary page must never be counted as a signed primitive.