Distributed Cognitive Network

Volume VII — Cognitive ABI Specification 0.1

Part 3 — Conformance, Capability Negotiation, Versioning, and Reference Interaction Patterns

41. Purpose

This part defines how independently implemented DCN components determine whether they can interoperate, negotiate compatible contracts, preserve semantic guarantees across versions, and demonstrate conformance.

The Cognitive ABI is useful only if interoperability can be tested rather than asserted.

42. Conformance Classes

Version 0.1 defines the following conformance classes:

ABI Core
Runtime Host
Cognitive Component
Capability Resolver
Execution Provider
Evaluator
Compiler
Transport Binding
Agent Plugin Package

An implementation MAY conform to more than one class.

A conformance claim MUST identify the exact ABI version and conformance classes claimed.

43. ABI Core Conformance

An ABI Core implementation MUST:

parse and emit the common envelope;
preserve correlation and causation identifiers;
validate canonical object schemas;
preserve unknown extension fields according to extension policy;
represent explicit failure using ErrorEnvelope;
preserve authority and evidence requirements without silent relaxation;
support version negotiation;
expose conformance metadata.

44. Runtime Host Conformance

A Runtime Host is an environment such as the DCN Runtime that coordinates cognitive components.

A conformant Runtime Host MUST:

apply local admissibility policy before binding execution;
distinguish capability resolution from capability execution;
distinguish execution success from authorization to commit a state change;
preserve the exact ExpertBinding used by an execution;
preserve causal lineage sufficient to construct a KLineEpisode;
isolate component failures from authoritative world state;
support cancellation and deadlines;
expose runtime events through a defined event interface.

A Runtime Host SHOULD support checkpointing and asynchronous execution.

45. Cognitive Component Conformance

A Cognitive Component MUST expose a ComponentDescriptor and MUST declare each supported semantic capability.

For each capability it MUST declare:

capability identifier
input schema
output schema
supported ABI versions
execution mode
side-effect class
evidence capabilities
authority requirements
resource profile or unknown marker

A component MUST NOT claim a capability merely because an underlying tool has a similarly named operation.

Capability identity is semantic.

46. Side-Effect Classes

The ABI defines four baseline side-effect classes:

pure
observational
proposal_only
externally_effectful

pure components produce outputs without observing or changing external state.

observational components may read external state but do not change it.

proposal_only components may propose changes through PatchProposal but cannot commit them.

externally_effectful components can cause effects outside the Mind and therefore MUST declare explicit authority requirements.

A Runtime Host MUST NOT infer a weaker side-effect class than the component declares.

47. Capability Negotiation

Negotiation begins with a CapabilityRequirement and one or more ComponentDescriptor or market offers.

The process is:

CapabilityRequirement
        ↓
Discover candidates
        ↓
Schema compatibility
        ↓
Policy admissibility
        ↓
Evidence compatibility
        ↓
Authority compatibility
        ↓
Resource/budget compatibility
        ↓
Candidate ranking
        ↓
ExpertBinding

Filtering MUST precede utility optimization.

A candidate that violates a mandatory requirement is inadmissible regardless of price or expected quality.

48. Schema Compatibility

Two schemas are compatible when the consumer can safely interpret every output required by the contract and the provider can safely interpret every required input.

Implementations SHOULD use explicit schema identifiers and versions rather than structural guessing.

A resolver MUST NOT silently coerce incompatible semantic units, identity domains, authority scopes, or privacy classifications.

Adapters MAY perform transformations when the transformation itself is declared as a component and can be included in lineage.

49. Capability Composition

A requirement MAY be satisfied by a composition rather than a single provider.

Example:

software_engineering.secure_review
        ↓
code_review
   +
dependency_analysis
   +
independent_critic

The composed resolution MUST expose the resulting topology, aggregate evidence properties, aggregate resource estimate, and any new failure modes.

Composition itself MAY be represented by a K-line.

50. Version Negotiation

Every ABI participant MUST declare supported ABI versions.

Negotiation selects the newest mutually supported version that satisfies local policy.

Example:

{
  "supported": [
    "dcn.cognitive-abi.v1"
  ],
  "extensions": [
    "dcn.ext.streaming.v1",
    "dcn.ext.zk-evidence.v1"
  ]
}

Failure to identify a mutually acceptable version MUST produce an explicit compatibility error.

51. Compatibility Rules

Within a major ABI version:

new optional fields MAY be added;
new optional enum values MAY be added only where the schema declares open enumeration;
mandatory field semantics MUST NOT change;
existing field meanings MUST NOT be weakened;
security, authority, privacy, and evidence semantics MUST NOT be silently relaxed.

A breaking semantic change requires a new major ABI version.

52. Extension Model

Extensions use namespaced identifiers.

Example:

dcn.ext.streaming.v1
dcn.ext.confidential-compute.v1
dcn.ext.zk-evidence.v1
org.example.specialist-metadata.v1

An extension MUST define whether it is:

optional
required_for_execution
required_for_verification

Unknown optional extensions MAY be ignored while preserving their data where forwarding is required.

Unknown required extensions MUST cause negotiation failure.

53. Error Taxonomy

The baseline error taxonomy includes:

INVALID_MESSAGE
UNSUPPORTED_ABI_VERSION
UNSUPPORTED_EXTENSION
SCHEMA_MISMATCH
CAPABILITY_UNAVAILABLE
NO_ADMISSIBLE_PROVIDER
AUTHORITY_REQUIRED
AUTHORITY_DENIED
POLICY_DENIED
PRIVACY_CONSTRAINT_UNSATISFIED
EVIDENCE_CONSTRAINT_UNSATISFIED
BUDGET_EXCEEDED
DEADLINE_EXCEEDED
EXECUTION_FAILED
VALIDATION_FAILED
CONFLICT
CANCELLED
PROVIDER_UNAVAILABLE
INTERNAL_ERROR

Implementations MAY define namespaced subcodes.

54. Retry Semantics

Errors MUST declare whether retry is potentially meaningful.

Recommended classes:

never
same_binding
new_binding
replan
human_required

For example, PROVIDER_UNAVAILABLE may permit new_binding, while AUTHORITY_DENIED normally does not permit automatic retry.

55. Cancellation

Every long-running execution SHOULD support cancellation.

Cancellation MUST identify the execution and SHOULD include a reason.

A cancelled component MUST stop creating new externally effectful operations as soon as practical and MUST return any partial results or evidence that policy permits to retain.

Cancellation does not erase already finalized external effects.

56. Idempotency

Externally effectful operations MUST expose an idempotency or replay-control mechanism appropriate to the transport and effect domain.

The ABI envelope's message_id is not by itself sufficient to guarantee economic or external-effect replay protection.

Actum nullifiers, provider idempotency keys, or equivalent mechanisms MAY be bound into the execution lineage.

57. Streaming

Streaming is an optional ABI extension.

A stream MUST remain bound to one execution_id and MUST distinguish:

partial_output
progress
evidence_fragment
usage_update
terminal_result
terminal_error

Partial output MUST NOT be treated as a completed ExecutionResult.

58. Human Components

Humans MAY participate as ABI components through an adapter.

The adapter MUST preserve:

human role or pseudonymous identity commitment as policy permits;
requested capability;
supplied context;
response commitment;
evaluation and evidence references;
authority boundaries.

The ABI does not assume cognition is machine-generated.

59. Local Artifact Interaction Pattern

Cognitive Kernel
      ↓ CapabilityRequirement
Local Resolver
      ↓ CapabilityResolution
Artifact Binding
      ↓ ExecutionRequest
Local Artifact
      ↓ ExecutionResult
Validator
      ↓ ValidationResult
Episode Recorder

No market interaction is required.

60. Remote Expert Interaction Pattern

Cognitive Kernel
      ↓ CapabilityRequirement
Actum Compute Adapter
      ↓ candidate offers
Cognitive Kernel
      ↓ ExpertBinding
Remote Provider Adapter
      ↓ ExecutionRequest
Remote Expert
      ↓ output + evidence
Provider Adapter
      ↓ ExecutionResult
Evaluator / Validator
      ↓
KLineEpisode + optional Actum ExecutionAct

The provider adapter translates transport details without changing the semantic ABI contract.

61. K-Line Execution Pattern

A K-line activation MAY generate several capability requirements.

KLineTemplate
      ↓ activation
CapabilityRequirement A ──→ Binding A
CapabilityRequirement B ──→ Binding B
CapabilityRequirement C ──→ Binding C
      ↓
Execution graph
      ↓
Results
      ↓
Validation
      ↓
KLineEpisode

The episode MUST preserve the actual bindings rather than only the template requirements.

62. Compilation Interaction Pattern

Episodes + Evaluations
        ↓
CompilationRequest
        ↓
Compiler Society
        ↓
ArtifactCandidate
        ↓
EvaluationRequest
        ↓
EvaluationResult
        ↓
Publication / Promotion protocol

The ABI transports compilation work; Volume VI defines compilation semantics.

63. Agent Plugin Conformance Profile

An Agent Plugin package MAY expose one or more ABI components.

A conformant package SHOULD include a machine-readable mapping from plugin-exposed skills or MCP tools to Cognitive ABI capabilities.

Conceptually:

{
  "cognitive_abi": "dcn.cognitive-abi.v1",
  "components": [
    {
      "component_id": "component:example",
      "descriptor": "./dcn/component.json",
      "bindings": {
        "mcp": "./mcp.json"
      }
    }
  ]
}

The exact portable packaging mechanism is defined by the applicable Agent Plugins specification. The Cognitive ABI profile does not redefine plugin manifests or credential handling.

Installing a plugin MUST NOT be interpreted as granting the component authority to perform side effects.

64. MCP Binding Profile

MCP MAY transport Cognitive ABI capability invocations.

A mapping MUST identify:

ABI capability
MCP tool/resource/prompt binding
input transformation
output transformation
error mapping
evidence mapping
side-effect class

MCP discovery does not replace semantic capability declaration.

65. A2A Binding Profile

A2A MAY transport cognition involving autonomous remote agents or Minds.

The binding MUST preserve execution identity, authority requirements, context commitments, evidence requirements, cancellation semantics, and terminal result state.

A2A autonomy does not override local activation sovereignty.

66. Actum Binding Profile

The ABI itself is not a ledger protocol.

Where durable verifiable history is required, a Runtime Host MAY derive or reference Actum Acts from ABI interactions.

The binding MUST preserve commitments sufficient to connect an Actum Act to the corresponding ABI execution without requiring private payload disclosure.

67. Conformance Test Categories

The reference conformance suite SHOULD contain at least:

envelope tests
schema tests
version-negotiation tests
extension tests
capability-negotiation tests
authority-preservation tests
evidence-preservation tests
privacy-constraint tests
error-mapping tests
cancellation tests
idempotency/replay tests
transport-binding tests
K-line lineage tests
compilation-lineage tests

Security-sensitive negative tests are mandatory for a production conformance claim.

68. Golden Interaction Traces

The project SHOULD publish canonical interaction traces that conforming implementations can replay.

Each trace SHOULD include:

input messages
expected state transitions
expected output messages
allowed nondeterministic fields
expected errors for invalid variants

Golden traces provide a language-neutral interoperability target.

69. Language Bindings

The normative ABI is language-neutral.

Reference bindings SHOULD be generated or maintained for at least:

Rust
TypeScript
Swift

Bindings MUST preserve canonical field semantics and MUST NOT introduce language-specific behavior into the protocol definition.

70. Schema Registry

Canonical schemas SHOULD live under a versioned repository namespace such as:

schemas/cognitive-abi/v1/

Schema identity MUST be stable after publication. Corrections that change semantics require a new schema version.

71. Interoperability Invariant

The central ABI invariant is:

Components may differ in implementation, transport, provider, model, language, and execution environment while preserving the same semantic cognitive contract.

This is what allows the DCN to evolve without binding cognition to today's vendors or agent frameworks.

72. Strategic Consequence

The Cognitive ABI turns the architecture from a collection of compatible ideas into an interoperable platform.

Kline can describe cognition without owning providers. Actum Compute can resolve capabilities without owning cognition. The DCN Runtime can schedule components without knowing their internal implementation. Actum can record verifiable history without becoming the runtime. Agent Plugins, MCP, A2A, local function calls, and future transports can carry the same semantic contracts.

The ABI is therefore the stable waist of the Distributed Cognitive Network: narrow enough to implement across environments, but expressive enough to preserve capability, context, authority, evidence, lineage, evaluation, and learning.

Keyboard shortcuts

Distributed Cognitive Network