Skip to content

Evidence and Authority

kadubon edited this page Aug 25, 2026 · 1 revision

Evidence and Authority

Closed documents and canonical subjects

Every native v0.6 document has an api_version, a closed kind, typed metadata, a typed spec, and non-authoritative reverse-DNS extensions. Runtime validation maps one model to one generated schema digest. A document that looks similar but changes its recognized shape fails closed rather than being interpreted as an equivalent authority-bearing object.

What a signature binds

CPCF uses DSSE for signed evidence. The canonical protected payload binds at least the schema identity, subject digest, tenant, workspace, principal, role, scope, signing time, policy sequence, and trusted-time receipt. The envelope key identifier is a lookup hint; admitted public keys, pinned identity, the protected payload, trusted time, and policy rules establish authority.

An authoritative reader must recompute signatures, schema identity, source pointers, lifecycle, quorum, and projection chains. A cached validation Boolean is diagnostic information, not a substitute for verification.

Role separation and time

Ordinary attestations are single-principal statements. High-impact decisions require the same subject to be signed by role-separated principals and keys. This is role separation, not threshold cryptography: compromise of every principal required for one decision compromises that decision.

Historical verification distinguishes signing-time validity, later expiry, prospective revocation, and retroactive compromise. A local computer clock cannot establish authoritative expiry or the order needed for preregistration claims; a trusted-time receipt is required.

Source-of-record separation

CPCF's own content-addressed storage, projections, closure, seeds, barriers, and planner results are CPCF objects. External reports are retained as immutable material, but their authoritative meaning stays with the source system. This applies to related systems such as CCR (mission and lease records), PIC (finite checks and certificates), VEK (verifier ecology), and FOST (claims, support, and obligations).

The correct report identifies both the CPCF digest and the external source owner. It does not turn a projection into acceptance by that source owner.

Quarantine before admission

Uploaded bytes initially remain non-authoritative in quarantine. A later signed admission generation, with the required trust and quorum conditions, is needed before an object is treated as authoritative. The same principle applies more strongly to legacy compatibility data: raw bytes can be preserved, but their prior authority is not inherited by v0.6.

Continue with Remote Workspaces for controlled mutations or Review and Reporting for a reviewer-oriented procedure.

Clone this wiki locally