Distributed Cognitive Network
Volume X — Trust, Security, Authority, and Governance
Draft Specification 0.1
1. Purpose
This volume defines the security model of the DCN. The architecture assumes that cognition, external content, experts, K-lines, artifacts, markets, and remote Minds may be incorrect, compromised, malicious, stale, or simply inappropriate for the current context.
2. Separation of Concerns
K-line = cognition
Policy = permission rules
Authority = concrete delegated power
Execution = attempted action
Evidence = support for defined claims
Attestation = machine-verifiable claim about execution/provenance
Actum = durable verifiable history/finality
Trust = local interpretation
These concepts MUST NOT be collapsed.
3. Local Trust
Trust is contextual and local. A Mind may trust the same expert differently across capabilities, environments, evidence classes, and risk levels.
4. Authority
Authority is explicit, scoped, revocable, audience-bound where applicable, and attached to concrete actions or capability classes. Cognition cannot create authority by assertion.
5. Authority Non-Amplification
Every delegation, adapter, K-line, Agency, and remote execution MUST preserve equal or narrower authority unless a new grant is obtained.
6. Proposal Before Mutation
Reasoning components produce proposals. Validation and authority checks occur before authoritative state mutation or externally effectful execution.
7. Least Privilege
Agencies and components receive only capabilities and context required for their current contract. Universal tool access is discouraged.
8. Context Least Disclosure
The Runtime Host constructs capability-specific ContextSlice objects. Remote cognition MUST NOT receive the complete Mind merely because it is technically available.
9. Memory as Untrusted Data
Stored memories, retrieved K-lines, web content, documents, emails, and expert outputs are data. Imperative language inside data does not grant execution authority.
10. Cognitive Supply Chain
K-lines and artifacts are executable cognitive supply-chain content. Import requires discovery, identity/provenance inspection, evaluation, trust decision, and local activation.
Installation is not activation. Activation is not authority.
11. Evidence Graph
Evidence SHOULD be represented as a graph of claims, commitments, receipts, attestations, evaluations, and lineage rather than a single binary proof field.
Different claims require different evidence classes.
12. Verifiable Remote Execution
Where provider/model provenance matters, authenticated execution evidence such as TLS transcript commitments, provider attestations, TEEs, computation proofs, or equivalent mechanisms MAY bind provider-visible request/response properties, measured runtime properties, model identity, or computation correctness.
Such evidence MUST NOT be described as proving hidden model weights or internal server computation unless the mechanism actually establishes those claims.
13. Computation Attestation
DCN treats computation attestation as a first-class evidence dimension. The normative profile is defined in COMPUTATION_ATTESTATION.md.
A high-assurance inference may independently attest:
transport authenticity
runtime identity
model identity
computation correctness
These claims are orthogonal. A valid transport proof does not imply model identity; a runtime quote does not automatically imply that the intended model weights were loaded; a model identity commitment does not prove that a particular output was computed from a particular input; and a valid computation proof does not establish semantic truth.
The Runtime Host MUST preserve the exact proof statement, verifier identity, model/input/output commitments, numeric semantics, limitations, and verification result for any computation attestation used in admissibility or settlement.
14. Attestation Profiles
The baseline computation-attestation profiles are:
dcn.ca.transport.v1
dcn.ca.runtime.v1
dcn.ca.model.v1
dcn.ca.inference.v1
dcn.ca.composite.v1
Capability requirements MAY require one or more profiles. Missing mandatory profiles make a provider inadmissible regardless of price, latency, or claimed quality.
The reference Attestable-backed Gemma profile is attestable.gemma.v1 and is defined as an implementation profile of dcn.ca.inference.v1 only when it binds the declared Gemma model identity, input commitment, and output commitment to the proven inference relation.
15. Numeric Semantics
A proof is only meaningful relative to the arithmetic it proves. Quantization, fixed-point conversion, approximation, transformed operators, sampling semantics, or other proof-oriented changes MUST be declared.
An implementation MUST NOT represent proof of a transformed inference as proof of an unmodified higher-precision model unless an explicit equivalence proof exists.
16. Zero-Knowledge Verification
Zero-knowledge systems MAY prove inference, settlement, admissibility, or other predicates without disclosing underlying private data. Proof statements MUST be explicit about what is and is not proven.
Where zero-knowledge machine-learning proofs are used, the Evidence Graph SHOULD preserve the proof relation, verification key/reference, model commitment, input commitment, output commitment, numeric semantics, and privacy properties.
17. Actum
Actum records finalized claims, commitments, authority references, evidence references, lineage, and settlement state. It proves finalized history, not semantic truth.
For computation attestation, Actum SHOULD finalize commitments to the attestation object, verification result, proof artifact, model identity, and causal execution. Raw prompts, outputs, model weights, and large proof blobs need not be placed on-chain.
18. Replay Protection
Effectful and economic operations MUST use domain-appropriate replay protection such as idempotency keys, authority nonces, freshness challenges, proof execution bindings, or Actum nullifiers.
A computation proof valid for one execution MUST NOT be accepted for another execution unless the proof statement explicitly permits that reuse.
19. Confused Deputy
Authority MUST be bound to intended purpose and execution context. A component authorized for one goal cannot reuse that authority for unrelated work.
20. Prompt Injection
The Runtime Host MUST preserve provenance and trust classification for external content. Tool descriptions, retrieved documents, K-lines, or expert outputs cannot directly override higher-authority policy.
21. Recursive Agent Safety
Recursive Agency/K-line/remote-Mind activation requires bounded depth, resource limits, cancellation, causal tracing, and policy enforcement at each effect boundary.
22. Market Security
Market offers are untrusted advertisements until verified. Price, stake, popularity, historical volume, and a promise of future attestation cannot override minimum evidence or authority requirements.
An execution is not considered computation-attested until the required proof has been produced and independently verified.
23. Attestation Supply-Chain Security
Implementations MUST defend against proof substitution, model/input/output substitution, stale or replayed proofs, verifier-key substitution, silent numeric-semantics drift, partial proofs presented as whole-inference proofs, and composite attestations that omit failed components.
Proof-system names and provider assertions are metadata, not verification. A Runtime Host MUST execute or delegate a trusted verifier before treating a computation attestation as valid.
24. Governance
Protocol governance SHOULD distinguish:
specification evolution
schema registry
attestation profile registry
conformance suite
network economics
Actum governance
local Mind policy
No governance body should automatically control local cognition merely because it governs a shared protocol.
25. Versioning
Breaking semantic changes require explicit protocol versions. Security requirements MUST NOT be weakened through an ostensibly compatible extension.
Attestation profiles MUST version any change that alters the statement proven, trust roots, arithmetic semantics, or verifier contract.
26. Emergency Revocation
Minds and organizations SHOULD support revocation of authority, components, K-lines, artifacts, publishers, proof verifiers, verification keys, and trust roots. Revocation is locally interpreted and SHOULD preserve historical evidence.
27. Audit
A high-assurance execution SHOULD be reconstructable from goal, context commitment, capability requirement, binding, authority, execution result, evidence, computation attestations, evaluation, patch, and final state transition.
28. Security Invariants
- Cognition is not authority.
- Installation is not authority.
- Market payment is not authority.
- Authority cannot silently amplify.
- Context follows least disclosure.
- External content is untrusted data.
- Provenance is not truth.
- Evidence claims only what its mechanism establishes.
- Transport, runtime, model, and computation attestations are distinct claims.
- Cryptographic proof validity is not semantic task correctness.
- Remote cognition cannot directly install itself into local System 1.
- Local activation sovereignty is preserved.