# Organizational evidence attestation specification

**Status:** fail-closed format specification. No attestation, identity, key,
signature, organization, contact, agreement, or acceptance is supplied by this
document.

## Trust bootstrap

`config/trusted-identities.json` is intentionally `unconfigured` with no
identities. Before a future readiness attempt, authorized humans must review a
candidate-bound registry containing opaque identity IDs derived from Ed25519
public keys, opaque organization IDs, exact allowed-role enums, and authority
evidence links. The checker verifies each identity ID against its key and
rejects undeclared roles. Ten mandatory internal roles must have distinct
trusted identities; preparer, independent reviewer, organization authorizer,
and partner authorizer must also be distinct.

Every identity must prove control of its exact Ed25519 key by signing the
canonical `vaultfire-partner-readiness-key-ownership-v1` payload containing its
identity, organization, roles, membership, authority, and external-attestation
binding. The registry stores the payload SHA-256 and detached signature; the
checker recomputes and verifies both.

## One file per claim

Each of the 25 claim IDs has exactly one canonical file:

`pr10/partner-package/evidence/organizational/attestations/<lowercase-id>.json`

Files, IDs, and SHA-256 digests must all be unique. Paths must be normalized
POSIX repository-relative paths with no `.`, `..`, backslash, symlink, escape,
or unapproved extension. Every claim uses exact keys:

- schema version, evidence ID, claim type;
- candidate ID and scope SHA-256;
- opaque subject and partner organization IDs;
- canonical RFC3339 UTC issuance, approval, expiry;
- trusted approver identity and exact role;
- opaque controlled-system reference;
- exact claim-specific semantic statement;
- exact path/SHA-256 artifact references;
- signed-payload SHA-256 and Ed25519 signature.

The checker recomputes every digest, parses evidence with duplicate-key
rejection, verifies signature and key identity, applies per-claim role and
artifact predicates, and requires:

`candidate created <= issued <= approved <= readiness signed <= asOf <= now`

Approvals expire after at most 366 days and must be no older than 30 days for a
readiness decision. The ready manifest and canonical operations status must
each be fresh within 24 hours.

## Typed resolved artifacts

Digest-shaped assertions are not sufficient. Critical claims resolve to unique
tracked JSON blobs and are validated with exact Draft 2020-12 schemas plus
semantic cross-checks. Test evidence contains a nonempty array of exact test
objects; every `passed` value is the Boolean `true`, assertion counts are
positive integers, the failure count is zero, and suite, candidate, commit,
tree, scope, and log digests agree. Commercial agreements, controlled contact
matrices, liability decisions, privacy-portability records, canonical
operations, and signature sets each have mandatory type-specific fields.

The phase-two artifact manifest enumerates every trust, claim, objective,
supporting, and resolved blob at the evidence commit. Phase-two blobs never
embed that manifest's digest or the evidence commit/tree. A later phase-three
envelope binds those already-created values and carries exact-role detached
signatures. The final commit changes only that envelope, creating a finite
source-to-evidence-to-attestation history with no fixed point.

The signature-set resolver derives the required two-organization set and exact
four signer identities, roles, keys, and authority references from the manifest
and pinned trust policy. It requires four of four unique valid signatures and
rejects missing, extra, substituted, cross-organization, or wrong-role signers.

## Commercial and operational semantic closure

An executed commercial-agreement record must contain the actual bilateral
legal-party names and external identity-attestation references, governing law
and venue, exact canonical module/route/action/deployment/rollout scope, Base
network, bounded duration, pull-only commercial terms, bounded-liability and
privacy artifact digests, pause-safe exit and termination terms, selected
support tier, security and incident obligations, change controls, and exact
authorized subject/partner signers and keys. The validator cross-binds those
links to the other objective artifacts for the same candidate.

Security, incident, support, and change acceptances resolve to their exact
tracked versioned package policies. Each includes exact candidate/scope,
subject and partner organizations, role-owned channel, policy digest, mandatory
controls, and detached approvals by the assigned operational owner and partner
authorized signatory.

The contact matrix derives seven required function/role/identity bindings from
the manifest and externally attested trust registry, including an independent
partner escalation path. Channel types are closed-enum values, every route has
a reachability-test digest, and reuse across required functions is prohibited.

Privacy portability resolves a separate unique unlinkability-test artifact
with exact candidate commit/tree/scope, Base-only threat model, non-surveillance
methodology, strict all-passing tests, consistent counts, and explicit
non-linkability predicates. Liability acceptance is restricted to the exact
subject and partner authorized signers with matching organizations, keys,
authority references, payloads, and signatures.

## No monolithic activation

A ready scope selects exactly one module from the canonical open module spec,
one action class, and one non-wildcard route ID. Every other canonical module
must appear in `deniedModules`. `all`, `*`, `all-v3`, `everything-v3`, aggregate
evidence, and an “everything V3” approval are rejected.
# Sixth-audit semantic evidence controls

Positive readiness additionally requires all of the following:

- Each contracting organization appears once in the externally signed trusted
  registry and resolves to a digest-pinned, independent legal-entity
  verification outside the candidate repository. The verification binds the
  exact normalized legal name, jurisdiction, registration reference, active
  status, issuer class, issuer, validity interval, and authority signature.
- Incident acceptance resolves its exercise digest to a strict tracked
  candidate-, commit-, tree-, and scope-bound exercise record. Required
  operational and partner roles, exercised channels, scenario, ordered
  timestamps, assertions, outcomes, and failures are machine checked.
- Each required contact function uses an allowlisted channel type and resolves
  a unique tracked reachability test for the exact candidate, scope, function,
  role, identity, organization, channel, delivery, acknowledgment, and test
  time.
- Unlinkability evidence uses the fixed threat model and methodology IDs,
  minimum statistical sample and pair counts, confidence and false-link
  bounds, committed seed/corpus/command digests, three required adversarial
  tests, and unique tracked per-test and combined logs. Every log is parsed and
  cross-bound to the exact candidate, source commit, tree, scope, chain, test,
  method, sample count, and result.
- Liability values use canonical smallest-unit identifiers. Per-event cap must
  not exceed aggregate cap; aggregate cap must equal per-event cap multiplied
  by the stated maximum covered events; maximum loss must equal aggregate cap;
  reserve must cover maximum loss. Remedies and residual-liability terms must
  be substantive, not placeholders.

These controls do not establish an entity, identify an actual person, accept a
partner agreement, or provide legal advice. The checked-in package remains
blocked until genuine external authority, evidence, assignments, acceptance,
and signatures exist.

## Seventh-audit resolved-evidence controls

Human identity and legal-entity existence have independent trust roots.
`config/trust-root-policy.json` can pin only an external human-identity
authority. `config/legal-registry-trust-policy.json` can pin only an external
legal-registry authority, including its exact issuer ID. Neither environment
variable can replace or override the tracked path, ID, class, or digest. Both
checked-in policies are disabled. A legal verification must resolve a separate
external registry-response file, verify the pinned legal-registry signature,
and exactly match the contracting organization, legal name, jurisdiction,
registration reference, active status, issuer, and fresh validity interval.

Unlinkability conclusions are derived rather than asserted. The verifier
resolves the actual base64-carried seed opening, challenge corpus, and command,
checks their content digests and corpus count, resolves unique per-test and
combined logs and transcripts, sums component samples/pairs/false links,
requires exact combined equality, recomputes the false-link rate, and computes
a deterministic one-sided Hoeffding upper confidence bound. Both the observed
rate and upper bound must fit the configured maximum before `nonLinkable=true`
can contribute to readiness.

Incident exercises name exact assigned identities, roles, and organizations;
reference the exact contact-control matrix; exercise the incident, security,
and partner-escalation channels; and resolve unique typed objective logs whose
participants, channels, assertions, outcomes, and timestamps fit inside a
fresh candidate-bound exercise. Contact reachability wrappers resolve unique
receipts signed by the exact assigned channel controller. Receipt payloads
bind the candidate, commit, tree, scope, function, role, identity,
organization, channel type, nonce, delivery, acknowledgment, and elapsed time.

Strictly bounded liability means no uncapped category. All five enumerated
liability categories carry a maximum in the agreement's exact smallest unit;
their cumulative allocation cannot exceed maximum loss. Remedy maxima stack
within, and in total cannot exceed, the aggregate cap. Maximum loss equals the
aggregate cap and reserve covers it. This machine rule is an evidence
consistency control, not legal advice or a substitute for counsel.

## Closed unlinkability execution protocol (v2)

Unlinkability evidence is not a survey or a self-attested result. The canonical
runner accepts only an exact-candidate execution context and a content-addressed
challenge corpus. It accepts no observed relationship, result digest, partial
output selection, or caller-generated output file. For every challenge it
computes the candidate outputs, expected and observed relationship, and
row digest. The readiness checker repeats those computations independently and
requires exact equality and complete corpus coverage.

Each corpus side has a content ID derived from its complete canonical content.
Each pair ID is derived from its test class and the sorted two content IDs;
reversed and repeated pairs are one challenge and are rejected. All SHA-256
values are lowercase 64-hex strings. Unknown fields and encodings fail closed.

The seed is the 32-byte output of a separately pinned, independently operated,
Ed25519-authenticated public-randomness authority after the candidate source and
evidence commit/tree are frozen. The signed receipt and seed commitment bind the
candidate ID, source commit/tree, evidence commit/tree, scope, runner, corpus,
evaluation context, beacon authority and round. The policy is currently
**disabled and unpinned** because no genuine external randomness authority has
been established. Therefore positive readiness remains structurally blocked;
no person, authority, execution, or result is inferred.

## Typed incident assertions

Incident objective evidence uses five closed event records: detection event,
triage record, escalation receipt, containment record, and partner notification.
Opaque byte payloads are forbidden. Each record has objective-specific identity,
channel, timestamp, action and digest fields. The checker derives the event and
assertion IDs, orders timestamps, binds participants and exercised contacts, and
verifies an assigned participant's Ed25519 controller receipt over the exact
event. A generic file, digest label, or one-byte payload cannot satisfy an
incident objective.
