Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

DCN Computation Attestation Profile 0.1

This profile defines how DCN represents evidence about the computation that produced an AI result.

Core rule

Evidence MUST state exactly what it establishes. Transport provenance, runtime identity, model identity, and computation correctness are separate claims and MUST NOT be collapsed into one verified boolean.

ComputationAttestation

A ComputationAttestation records:

  • attestation identifier and profile;
  • subject execution;
  • claim type;
  • model identity commitment;
  • input and output commitments;
  • optional runtime binding;
  • proof system and proof reference;
  • verifier and verification result;
  • numeric semantics and privacy properties;
  • limitations and production time.

Baseline claim types are transport_authenticity, runtime_identity, model_identity, computation_correctness, and composite.

Baseline profiles are dcn.ca.transport.v1, dcn.ca.runtime.v1, dcn.ca.model.v1, dcn.ca.inference.v1, and dcn.ca.composite.v1.

Model identity

A model identity SHOULD bind the execution-relevant model family/variant, weight commitment, architecture commitment, quantization or numeric representation, tokenizer, inference implementation, sampling configuration, and adapters where relevant. A model name alone is not cryptographic identity.

Numeric semantics

A computation proof MUST state the arithmetic actually proven. Quantized, fixed-point, approximated, or transformed execution MUST NOT be represented as proof of a different higher-precision computation unless an explicit equivalence argument exists.

Input and output binding

A computation-correctness claim MUST bind the exact input and output covered by the proof. For autoregressive inference this SHOULD include prompt/context commitment, sampling configuration commitment, and output-token commitment. Randomness handling MUST be declared.

Verification result

Verification results are typed as valid, invalid, unsupported, or indeterminate. unsupported and indeterminate MUST NOT be promoted to valid through policy scoring.

Composition

Attestations compose as an Evidence Graph. For example an execution may carry a TLS transcript proving provider-visible request/response, a TEE quote proving runtime identity, a model commitment, and an inference proof binding input/model/output. The composition is no stronger than the statements actually established by its components.

Attestable Gemma profile

The reference implementation defines attestable.gemma.v1 for Gemma inference instrumented by Attestable. It maps to dcn.ca.inference.v1 only when returned evidence cryptographically binds the declared Gemma model identity, input commitment, and output commitment to the proven inference relation.

The adapter MUST fail closed when a required binding is absent or proof verification is invalid/unsupported. Vendor-specific proof payloads are preserved by hash/reference; DCN normalizes the claim without rewriting what the proof establishes.

Capability requirements

A capability requirement MAY require computation assurance independently of ordinary evidence classes. Admissibility filtering MUST occur before cost, latency, or quality optimization.

An expert binding records assurance profiles promised by the provider and the expected model commitment. The execution result links the evidence actually produced. A promise of attestability is not evidence.

Actum

Actum SHOULD anchor commitments to computation attestations, verification results, model identities, proof artifacts, and causal execution lineage when durable third-party verification is required. Raw prompts, outputs, weights, and proof blobs need not be on-chain; content-addressed references and commitments are sufficient.

Actum records finalized evidence claims. It does not replace the proof-system verifier and does not turn proof validity into semantic truth.

Actum Compute

Actum Compute MAY expose attestation as a market dimension, including assurance profile, proof system, expected model commitment, proving latency, and verification cost. A provider that cannot satisfy a mandatory assurance profile is inadmissible regardless of price.

Compiler Society

Attestability is a compilation target. A compiled artifact MAY carry model commitment, proof-compatible execution representation, verifier metadata, evaluation claims, and attestation profile. Such an artifact is self-verifying cognitive capital when its execution can produce independently checkable evidence without trusting the host.

Security requirements

Implementations MUST defend against proof substitution, model/input/output substitution, replay, verifier-key substitution, silent numeric-semantics drift, partial proofs presented as whole-inference proofs, and composite evidence that hides a failed component.

A conformant dcn.ca.inference.v1 implementation MUST include negative tests for wrong model commitment, wrong input commitment, wrong output commitment, modified proof, unsupported verifier, numeric-semantics mismatch, and replayed execution binding.

Verifiable cognition is claim-specific. DCN composes evidence; it never turns provenance, attestation, or cryptographic validity into semantic truth by implication.