Distributed Cognitive Network
Volume VII — Cognitive ABI Specification 0.1
Part 2 — Invocation Semantics, Lifecycle, Authority, Evidence, Errors, and Asynchrony
16. Scope
This part defines the runtime semantics of Cognitive ABI messages. Part 1 defines the canonical object families; this part defines how conformant components exchange those objects without losing causality, authority, evidence requirements, lifecycle state, or failure meaning.
The ABI is semantic rather than transport-specific. A local function call, an MCP tool invocation, an A2A exchange, an in-process artifact call, and an Actum Compute job may all implement the same ABI transition.
17. Invocation model
Every cognitive invocation SHALL be modeled as a bounded transition:
Request
↓
Admission
↓
Execution
↓
Result or Failure
↓
Validation
↓
Episode / Event
A component MUST NOT treat receipt of a request as proof that the request is admissible, authorized, affordable, safe, or executable.
18. Admission
Before execution, the receiving component SHALL evaluate the requirements it is responsible for enforcing. These MAY include:
schema compatibility
authority availability
resource availability
privacy constraints
evidence capability
deadline feasibility
budget feasibility
execution-mode compatibility
Admission has three normative outcomes:
accepted
rejected
accepted_with_declared_constraints
A component MUST NOT silently weaken a mandatory requirement in order to admit work.
19. Invocation lifecycle
A cognitive invocation SHOULD expose the following lifecycle where applicable:
created
↓
admitted
↓
queued
↓
running
↓
waiting
↓
completed
↓
validated
Terminal alternatives include:
rejected
cancelled
expired
failed
superseded
Transitions SHALL be monotonic except for explicit retry, resume, or supersession semantics.
20. Correlation and causation
Every message SHALL carry both correlation_id and causation_id when those concepts apply.
correlation_id identifies a larger cognitive process. causation_id identifies the immediate causal predecessor.
A nested execution therefore remains reconstructable without requiring one global trace implementation.
Example:
Goal G
↓ msg-1
CapabilityRequirement R
↓ msg-2
Execution E
↓ msg-3
PatchProposal P
All messages share one correlation identifier, while each message records its direct cause.
21. Idempotency
Any ABI operation capable of causing durable work, economic reservation, external execution, or state proposal SHOULD support an idempotency key.
A conformant implementation MUST ensure that replay of the same accepted idempotent request does not create duplicate semantic side effects.
Idempotency does not replace Actum nullifiers for settlement or other replay-sensitive finalized Acts.
22. Cancellation
Cancellation SHALL be explicit.
A cancellation request SHOULD identify:
{
"schema": "dcn.cancellation-request.v1",
"execution_id": "execution:...",
"reason": "user_cancelled",
"authority_ref": "authority:...",
"requested_at": "..."
}
A component receiving cancellation SHALL report whether cancellation was:
accepted
already_completed
not_cancellable
authority_denied
unknown_execution
Partial outputs MAY be returned but MUST remain marked partial.
23. Deadlines and expiry
A deadline is a semantic constraint rather than scheduling advice.
If a component cannot satisfy a mandatory deadline, it SHOULD reject the invocation before expensive execution begins.
Expired authority, quotes, bindings, or evidence challenges SHALL NOT be silently refreshed by the component performing execution unless the protocol explicitly grants that responsibility.
24. Authority propagation
Authority SHALL propagate by reference, not by implication.
A child invocation MUST NOT inherit broader authority than its parent.
If parent authority is represented by scope A, every derived child scope A_child MUST satisfy:
A_child ⊆ A
Components MAY further attenuate authority.
They MUST NOT amplify it.
25. Authority request
When necessary authority is absent, the component SHOULD return an AuthorityRequirement rather than guessing or performing the side effect.
{
"schema": "dcn.authority-requirement.v1",
"capability": "send_email",
"requested_scope": {},
"reason": "required_for_proposed_transition",
"continuation_ref": "continuation:..."
}
The Cognitive Kernel or an authority adapter MAY satisfy the requirement and resume execution.
26. Evidence requirements
Evidence requirements SHALL be declared before execution whenever the evidence class affects admissibility, price, routing, or settlement.
Example:
{
"required": [
"provider_authenticated",
"request_bound",
"result_bound"
],
"minimum_assurance_profile": "VERIFIED_BOUND"
}
A provider MUST NOT claim stronger evidence than it can actually produce.
27. EvidenceGraphRef
The ABI represents execution evidence through an EvidenceGraphRef rather than embedding arbitrary proof payloads.
{
"schema": "dcn.evidence-graph-ref.v1",
"graph_id": "evidence-graph:...",
"root_commitment": "sha256:...",
"required_nodes": [],
"availability_refs": []
}
The graph MAY reference TLSNotary evidence, ZeroK proofs, runtime signatures, TEEs, human attestations, evaluation evidence, certificates, or prior Acts.
The ABI does not reinterpret the semantics of those evidence protocols.
28. Assurance propagation
Components SHALL preserve assurance granularity.
A binary verified=true field is non-conformant when the underlying protocol exposes distinct assurance dimensions.
The canonical assurance dimensions include, where applicable:
identity
authority
provider
model
request_binding
response_binding
result_binding
artifact_binding
freshness
privacy
replay_resistance
finality
A downstream component MUST NOT strengthen an assurance dimension without new evidence.
29. Result classes
An execution can produce one or more semantic result classes:
answer
artifact
patch_proposal
decision
observation
evaluation
capability_requirement
continuation
A result MAY contain several classes simultaneously.
A side-effecting result SHOULD be represented as a PatchProposal or explicit external-action proposal rather than an undocumented effect.
30. PatchProposal ABI contract
A PatchProposal SHALL reference the state snapshot against which it was generated.
{
"schema": "dcn.patch-proposal.v1",
"patch_id": "patch:...",
"base_state_commitment": "sha256:...",
"operations": [],
"justification_refs": [],
"required_authority": [],
"expected_effects": [],
"confidence": 0.94,
"origin_execution": "execution:..."
}
Receipt of a PatchProposal never implies commitment.
31. ValidationResult
Validation SHALL be represented separately from generation.
{
"schema": "dcn.validation-result.v1",
"subject_ref": "patch:...",
"status": "accepted",
"checks": [],
"evidence_refs": [],
"required_followups": []
}
A validator MUST NOT silently rewrite a proposal and report the rewritten object as though it were the original.
32. Asynchronous execution
The ABI SHALL support asynchronous execution.
An accepted invocation MAY return:
{
"status": "accepted",
"execution_id": "execution:...",
"continuation_ref": "continuation:..."
}
The caller can then receive or retrieve subsequent RuntimeEvents and the final ExecutionResult.
Transport bindings MAY implement this through callbacks, streams, polling, subscriptions, queues, or A2A messaging.
33. Continuations
A continuation represents resumable cognitive work whose semantic process identity must survive suspension.
{
"schema": "dcn.continuation.v1",
"continuation_id": "continuation:...",
"correlation_id": "corr:...",
"checkpoint_ref": "checkpoint:...",
"waiting_for": [],
"expires_at": null
}
Continuations MUST NOT contain transferable secrets unless an explicit security profile defines their protection.
34. Streaming
Streaming is an optional transport feature, not a distinct cognitive semantic.
Intermediate streamed material SHALL be classified as one of:
progress
partial_result
observation
proposal
final_result
Only a declared final_result satisfies an invocation unless the request explicitly allows partial completion.
35. RuntimeEvent
Runtime events provide transport-neutral observation of cognitive execution.
{
"schema": "dcn.runtime-event.v1",
"event_id": "event:...",
"event_type": "ExecutionCompleted",
"correlation_id": "corr:...",
"causation_id": "msg:...",
"subject_ref": "execution:...",
"payload": {},
"occurred_at": "..."
}
Events MAY be persisted locally or anchored through protocol-specific Acts when their significance requires durable verification.
36. Failure model
Failure SHALL be explicit and typed.
Version 0.1 defines these top-level failure classes:
INVALID_REQUEST
INCOMPATIBLE_SCHEMA
ADMISSION_REJECTED
AUTHORITY_REQUIRED
AUTHORITY_DENIED
POLICY_DENIED
CAPABILITY_UNAVAILABLE
RESOURCE_EXHAUSTED
BUDGET_EXCEEDED
DEADLINE_EXCEEDED
PRIVACY_CONSTRAINT
EVIDENCE_UNAVAILABLE
EXECUTION_FAILED
VALIDATION_FAILED
DEPENDENCY_FAILED
CONFLICT
CANCELLED
INTERNAL_ERROR
Extensions MAY add domain-specific subclasses without changing the top-level meaning.
37. ErrorEnvelope
{
"schema": "dcn.error-envelope.v1",
"error_id": "error:...",
"class": "CAPABILITY_UNAVAILABLE",
"code": "NO_ADMISSIBLE_BINDING",
"message": "No candidate satisfied the mandatory evidence profile.",
"retryable": true,
"retry_after": null,
"details": {},
"caused_by": [],
"required_action": null
}
Errors MUST NOT expose secrets merely to improve diagnostics.
38. Retry semantics
Retry policy SHALL depend on failure class.
Examples:
network/transient dependency → MAY retry
authority required → WAIT for authority
policy denied → MUST NOT retry unchanged
invalid schema → MUST NOT retry unchanged
no admissible expert → MAY resolve alternatives
validation failure → MAY escalate to System 2
A retry that changes provider, artifact, model, authority, or evidence class SHALL create a new concrete binding record.
39. Partial failure
Composite cognition MAY partially succeed.
A composite result SHALL declare which nodes completed and which failed. It MUST NOT present partial completion as total success.
The Cognitive Kernel decides whether to retry, substitute, accept degraded output, or reopen System 2 according to the K-line and local policy.
40. Version negotiation
Every component SHALL declare supported ABI versions.
Negotiation SHOULD select the highest mutually supported version that satisfies required features.
A component MUST reject a message whose mandatory semantics it cannot preserve.
Unknown optional extension fields MAY be ignored only when the extension is explicitly marked optional.
41. Extension namespaces
Extensions SHALL use namespaced identifiers.
Example:
org.example.medical.calibration.v1
actum.compute.quote-extension.v1
Extensions MUST NOT redefine normative core fields with incompatible semantics.
42. Security invariant
The Cognitive ABI carries cognition across process, device, organizational, and network boundaries. Therefore every implementation SHALL preserve this invariant:
Semantic interoperability never implies authority interoperability.
A component may understand a requested action perfectly and still lack permission to perform it.
43. Part 2 conformance
A conformant implementation of Part 2 MUST:
- expose explicit invocation lifecycle state;
- preserve correlation and causation;
- propagate authority by reference and without amplification;
- declare evidence requirements before evidence-dependent execution;
- preserve assurance granularity;
- support typed failures;
- distinguish proposals from committed side effects;
- support asynchronous completion or explicitly declare synchronous-only limitations;
- prevent idempotent request replay from duplicating semantic effects;
- reject incompatible mandatory semantics rather than silently degrading them.