Distributed Cognitive Network

Volume IV

Actum Verifiable Cognition Profile 0.1

Part 2

Canonical Act Schemas, Evidence Graph, Assurance Vectors, Lineage, Hashing and Nullifiers

35. Purpose

Part 1 introduced the philosophy.

Part 2 defines the canonical protocol objects.

The objectives are:

• deterministic representation;
• replay resistance;
• cryptographic commitments;
• causal lineage;
• extensible evidence;
• implementation neutrality.

Every compliant implementation SHALL produce identical hashes for identical semantic Acts.

36. Canonical Serialization

All Acts SHALL serialize canonically.

Requirements:

UTF-8

deterministic ordering

explicit null handling

RFC3339 timestamps

canonical floating point

canonical URI normalization

stable array ordering where ordering is semantic

Implementations MAY internally use CBOR, JSON, protobuf, FlatBuffers or another format.

Canonical hashing SHALL always operate on the canonical semantic representation.

37. Act Identity

Every Act possesses three identifiers.

ActID

ContentHash

SemanticHash

37.1 ActID

Globally unique identifier.

Example:

act:execution:01J...

Never reused.

37.2 ContentHash

Represents exact bytes.

SHA256(canonical bytes)

Changing whitespace changes ContentHash.

37.3 SemanticHash

Represents semantic identity.

Fields excluded:

timestamps

display strings

non-semantic metadata

compression

encoding

Changing serialization MUST NOT change SemanticHash.

38. Domain Separation

Every hash SHALL include explicit domain separation.

Example:

H(

"ACTUM_EXECUTION_V1"

||

canonical_object

)

Examples:

ACTUM_EXECUTION_V1

ACTUM_EVALUATION_V1

ACTUM_PROMOTION_V1

ACTUM_COMPILATION_V1

This prevents accidental cross-object collisions.

39. Canonical Act Header

Every Act SHALL begin with:

{
  "schema":"...",
  "version":"1.0.0",

  "act_id":"...",

  "type":"ExecutionAct",

  "issuer":"did:...",

  "created_at":"...",

  "content_hash":"...",

  "semantic_hash":"..."
}

40. Canonical Body

Every Act SHALL contain:

Subject

Intent

Authority

Evidence

PriorState

ResultState

This body is shared by all cognition Acts.

41. Subject

The subject identifies what the transition concerns.

Example:

{
    "type":"KLineArtifact",

    "id":"artifact:...",

    "commitment":"sha256:..."
}

Acts MAY concern multiple subjects.

42. Intent

Intent SHALL describe the requested transition.

Examples:

execute

compile

publish

evaluate

promote

supersede

settle

Intent is immutable.

43. Authority

Authority SHALL reference:

principal

delegation

policy

scope

expiry

Authority SHALL NOT be inferred from evidence.

44. Prior State Commitment

Rather than embedding state,

Acts SHOULD reference:

PriorStateCommitment

Example:

Artifact

candidate

↓

hash

45. Result State Commitment

Likewise:

ResultStateCommitment

represents the state after transition.

46. State Difference

Acts MAY additionally expose:

PatchCommitment

representing the semantic difference.

This enables:

• replay,
• auditing,
• deterministic reconstruction.

47. Evidence Graph

Earlier drafts treated Evidence as a list.

This specification replaces that with:

EvidenceGraph

Conceptually:

Execution

│

├── TLSNotary

│

├── Human review

│

├── ZeroK

│

├── Benchmark

│

└── Previous Act

Evidence becomes composable.

48. Evidence Nodes

Each evidence node contains:

Type

Issuer

Commitment

Confidence

Timestamp

Dependencies

Dependencies permit recursive evidence.

49. Evidence Edge

Edges define:

supports

derived_from

verifies

references

supersedes

contradicts

Contradictory evidence is permitted.

Interpretation belongs elsewhere.

50. Evidence Types

Version 0.1 defines:

TLSNotary

ZeroK

TEE

RuntimeSignature

Evaluation

Human

Benchmark

Certificate

ActReference

Future extensions are expected.

51. Evidence Commitments

Acts SHALL store:

EvidenceCommitment

rather than arbitrary raw payload.

The payload may remain elsewhere.

52. Assurance Vector

A binary:

verified=true

is insufficient.

Every Act SHALL instead expose an:

AssuranceVector

53. Assurance Dimensions

Recommended dimensions:

identity

authority

execution

provider

model

request_binding

response_binding

artifact_binding

evaluation

privacy

freshness

replay_resistance

settlement

finality

Each dimension possesses independent status.

54. Assurance States

Each component MAY be:

unknown

claimed

verified

cryptographically_verified

attested

not_applicable

Avoid collapsing these into one score.

55. Example Assurance Vector

{

"provider":"verified",

"model":"verified",

"request_binding":"verified",

"response_binding":"verified",

"evaluation":"claimed",

"authority":"verified",

"settlement":"pending"

}

56. Trust Vector

Trust is distinct.

Trust belongs to local interpretation.

Example:

publisher

evaluator

expert

artifact

organization

Each has independent trust.

Trust SHALL NOT be embedded into immutable Acts.

57. Confidence

Confidence is not trust.

Confidence estimates:

probability

uncertainty

calibration

coverage

Confidence belongs to evidence.

Trust belongs to Minds.

58. Lineage

Acts form:

Directed Acyclic Graph

Each node references parents.

Example:

Episode

↓

Evaluation

↓

Promotion

↓

Compilation

↓

Artifact

59. Parent References

Every Act MAY declare:

Parents

Example:

{
"parents":[

"act:evaluation:...",

"act:execution:..."

]
}

60. Child Discovery

Children SHALL NOT be embedded.

They are discovered by graph traversal.

This preserves immutability.

61. Multiple Parents

Acts MAY possess multiple parents.

Example:

Compilation

↓

Episode A

Episode B

Episode C

The graph therefore naturally supports many-to-many lineage.

62. Forks

Forks are normal.

Example:

Artifact

↓

Compilation A

↓

Compilation B

No special protocol required.

63. Supersession Graph

Supersession is represented by edges.

Never deletion.

Artifact A

↓

superseded_by

↓

Artifact B

64. Temporal Ordering

Acts possess:

logical order

creation time

finalization time

These are distinct.

65. Finality

Finality SHALL refer to:

inclusion in finalized Actum history.

It SHALL NOT imply:

truth.

66. Nullifiers

Every replay-sensitive Act SHALL include a:

Nullifier

67. Nullifier Domains

Separate nullifier domains.

Examples:

Execution

Settlement

Evaluation

Promotion

Compilation

Cross-domain reuse is prohibited.

68. Execution Nullifier

Conceptually:

H(

Execution

||

Challenge

||

Evidence

||

Result

)

69. Settlement Nullifier

Conceptually:

H(

ExecutionAct

||

Asset

||

Payee

)

Settlement replay is therefore impossible.

70. Promotion Nullifier

Promotion should occur once.

Nullifier:

Template

+

PromotionPolicy

71. Compilation Nullifier

Compilation is distinct.

Repeated compilations are permitted.

Therefore compilation nullifiers include:

Compiler

Template

Constraints

Different constraints produce distinct compilation lineage.

72. Graph Integrity

Every parent reference SHALL reference:

ActID

SemanticHash

This prevents silent substitution.

73. Object Integrity

Referenced objects SHALL use:

ObjectID

ContentHash

allowing mutable metadata without changing semantic identity.

74. Causal Ordering

Acts imply:

Execution

↓

Evaluation

↓

Promotion

not:

Promotion

↓

Execution

The protocol SHALL reject impossible causal ordering.

75. Graph Queries

Typical graph queries:

Where did this artifact come from?

Which evaluations justified promotion?

Which expert produced this episode?

Which settlements followed this execution?

Which K-line generated this artifact?

The protocol is designed for graph traversal rather than table lookup.

76. Canonical Relationships

Version 0.1 defines:

GENERATED

EVALUATED

PROMOTED

COMPILED

SUPERSEDED

PUBLISHED

SETTLED

SUPPORTED_BY

Future extensions remain possible.

77. Evidence Resolution

Consumers SHOULD resolve evidence lazily.

An Act references evidence.

Evidence references proofs.

Proofs reference artifacts.

Nothing is duplicated.

78. Why Graphs?

Traditional ledgers answer:

"What happened?"

Graphs answer:

"Why did it happen?"

That distinction is essential for cognition.

79. Strategic Observation

The history of intelligence is not a chain.

It is a graph.

Actum therefore becomes a graph of cognitive evolution rather than merely a chronological log of transactions.

That is why lineage, evidence, assurance, and causal relationships are first-class protocol objects rather than metadata.