Distributed Cognitive Network

Volume IV

Actum Verifiable Cognition Profile 0.1

80. Purpose

This section defines the two foundational Acts from which all higher cognitive history is derived.

Every PromotionAct, CompilationAct, PublicationAct, and SettlementAct ultimately depends on:

ExecutionAct

EvaluationAct

Execution establishes:

something happened.

Evaluation establishes:

someone measured what happened.

Everything else builds upon those two facts.

81. ExecutionAct

An ExecutionAct records a single completed realization of a requested cognitive capability together with the authority under which it executed, the evidence supporting it, the resulting state transition, and the commitments necessary for replay-resistant historical reconstruction.

An ExecutionAct does not claim:

that the answer is objectively correct;
that the execution should be trusted;
that the result should become System 1.

It records only:

the requested capability;
the execution;
supporting evidence;
resulting commitments;
authority;
provenance.

82. ExecutionAct Semantics

Conceptually:

Prior State
      │
      │
Capability Requirement
      │
      ▼
Execution
      │
Evidence
      │
Authority
      │
      ▼
Proposed State Transition

This is the canonical VSTP specialization.

83. ExecutionAct Lifecycle

An ExecutionAct SHALL progress through:

created
    ↓
executing
    ↓
completed
    ↓
evidence_attached
    ↓
verified
    ↓
finalized

Possible terminal failure states:

aborted

expired

invalid_evidence

rejected

superseded

84. Canonical ExecutionAct Schema

{
  "schema": "actum.execution.v1",

  "version": "1.0.0",

  "act_id": "act:execution:...",

  "subject": {
    "type": "CapabilityExecution",
    "id": "execution:..."
  },

  "intent": {
    "capability_requirement": "...",
    "objective_commitment": "sha256:..."
  },

  "authority": {},

  "prior_state": {
    "commitment": "sha256:..."
  },

  "result_state": {
    "commitment": "sha256:..."
  },

  "transition_patch": {
    "commitment": "sha256:..."
  },

  "execution": {
    "mode": "remote",
    "execution_class": "...",
    "bindings": []
  },

  "evidence_graph": {},

  "assurance": {},

  "nullifier": "...",

  "issuer": "...",

  "created_at": "...",

  "content_hash": "...",

  "semantic_hash": "..."
}

85. Prior State

Execution SHALL reference the state that existed before execution.

The state MAY include:

SurrealDB world state

repository state

conversation state

medical state

workflow state

graph state

The state itself SHOULD remain external.

ExecutionAct stores only the commitment.

86. Result State

Likewise:

result_state_commitment

represents the post-execution world.

This permits deterministic auditing without exposing private state.

87. Transition Patch

The semantic difference between states SHOULD be represented separately.

Conceptually:

Before

↓

Patch

↓

After

Patch commitment enables:

replay
audit
verification
synchronization

88. Capability Binding

Execution SHALL record the concrete realization of abstract capabilities.

Example:

CapabilityRequirement

↓

ExpertBinding

↓

Execution

Example bindings:

reasoning

↓

Verified GPT flagship

critic

↓

local artifact

retrieval

↓

organization search service

These belong to the episode, not the template.

89. Evidence Graph

Execution SHALL reference an EvidenceGraph rather than embedding proof material.

Possible nodes:

TLSNotary

TEE

Evaluation

Human signature

Runtime receipt

ZeroK proof

Benchmark

Certificate

Execution merely references those nodes.

90. Assurance Vector

Execution SHALL expose:

provider

model

authority

execution

request binding

response binding

artifact binding

freshness

privacy

finality

Each dimension SHALL remain independent.

91. Provider Identity

Where provider identity matters commercially,

ExecutionAct SHOULD distinguish:

claimed

verified

cryptographically verified

These are not equivalent.

92. Model Identity

Likewise:

claimed

authenticated

cryptographically evidenced

Execution SHALL avoid implying stronger guarantees than evidence supports.

93. Authority

Authority SHALL reference:

principal

delegation

scope

policy

expiry

Execution without authority is still historically meaningful.

It simply should not authorize side effects.

94. Side Effects

ExecutionAct SHOULD normally represent:

proposal

rather than:

mutation

The mutation occurs only after separate authorization.

95. Execution Modes

Version 1 recognizes:

local

remote

human

hybrid

artifact

Future versions may extend.

96. Hybrid Execution

An execution MAY involve multiple experts.

Example:

Local artifact

↓

Remote reasoning

↓

Human approval

↓

Local synthesis

ExecutionAct records the whole graph.

97. Nested Executions

Execution MAY invoke further executions.

Nested executions SHALL be separate Acts.

The parent references children.

Children reference parent.

98. Failure

Failure is first-class.

Execution SHALL record:

timeout

validation failure

provider unavailable

evidence failure

authority denied

execution rejected

Failures become valuable historical data.

99. Execution Replay

Execution SHALL be replay-resistant.

Execution Nullifier:

Conceptually:

Execution Challenge

+

Evidence Commitment

+

Assignment

+

Execution Result

Changing any element changes the nullifier.

100. Execution Finality

Finality means:

this execution became part of immutable Actum history.

It does NOT imply:

truth.

101. EvaluationAct

Definition

EvaluationAct records an assessment of:

execution;
artifact;
expert;
template;
K-line;
benchmark;
compilation.

Evaluation never modifies the evaluated object.

It creates additional evidence.

102. Evaluation Philosophy

Execution answers:

What happened?

Evaluation answers:

How well did it satisfy a defined protocol?

103. Evaluation Subject

Evaluation SHALL reference exactly one subject.

Examples:

ExecutionAct

Artifact

Template

Expert

Compilation

Composite evaluations are represented by multiple EvaluationActs.

104. Canonical Evaluation Schema

{
  "schema":"actum.evaluation.v1",

  "act_id":"...",

  "subject":{

      "type":"ExecutionAct",

      "id":"..."
  },

  "protocol":{

      "id":"evaluation:..."
  },

  "environment":{},

  "distribution":{},

  "metrics":{},

  "evidence_graph":{},

  "assurance":{},

  "authority":{},

  "issuer":"...",

  "created_at":"..."
}

105. Evaluation Protocol

Every evaluation SHALL reference:

Protocol

Version

Environment

Distribution

Without protocol,

evaluation is meaningless.

106. Metrics

Metrics SHOULD remain structured.

Example:

accuracy

precision

recall

latency

energy

cost

calibration

robustness

Avoid free-text scores.

107. Environment

Evaluation SHALL define:

hardware

runtime

software

configuration

dependencies

Environment drift is one reason K-lines decay.

108. Distribution

Evaluations SHALL define:

dataset commitment

sampling

coverage

population

This avoids meaningless universal quality claims.

109. Evaluation Evidence

Evaluation MAY itself possess evidence.

Examples:

benchmark

human review

TLS proof

TEE

ZeroK

external certification

Evaluation therefore participates in the EvidenceGraph.

110. Independent Evaluations

Several EvaluationActs MAY exist for the same subject.

This is expected.

Example:

Hospital A

↓

Evaluation

Hospital B

↓

Evaluation

University C

↓

Evaluation

Promotion policies decide how many independent evaluations are required.

111. Evaluation Finality

Finality means:

the evaluation happened.

Not:

the evaluation is universally correct.

112. Execution → Evaluation

Execution produces:

ExecutionAct

Evaluation produces:

EvaluationAct

The graph:

Execution

↓

Evaluation A

↓

Evaluation B

↓

Evaluation C

is the foundation for promotion.

113. Act Relationships

Execution SHALL support:

SUPPORTED_BY

GENERATED

Evaluation SHALL support:

EVALUATES

SUPPORTED_BY

Later Acts will extend these.

114. Promotion Preconditions

Promotion SHALL NOT reference raw executions directly.

It references:

EvaluationActs

This separates:

execution

from

judgement.

115. Why Separate Evaluation?

Without separation,

future evaluation protocols cannot reinterpret history.

With separate EvaluationActs,

new methodologies can revisit old executions.

That is essential for scientific progress.

116. Strategic Importance

ExecutionActs create the immutable historical record of cognition.

EvaluationActs create the immutable historical record of how that cognition was measured.

Those two layers together form the empirical foundation upon which every future K-line, compilation, artifact, promotion, economic reward, and piece of cognitive capital is built.

Everything else in the architecture is downstream of these two canonical Acts.

Keyboard shortcuts

Distributed Cognitive Network