Distributed Cognitive Network
Volume II — K-Line Protocol 0.1
Normative Object Model, Activation Semantics, Evaluation, Federation, and Cognitive Compilation
1. Scope
This document defines the normative protocol for representing, executing, evaluating, sharing, compiling, decaying, and superseding K-lines.
A K-line is a reusable organization of cognition for addressing a class of situations.
This protocol defines:
KLineTemplateKLineEpisodeKLineArtifactCapabilityRequirementExpertBindingEvaluationProtocolEvaluationClaimActivationPlanPromotionRecordCompilationRecordSupersessionRecord- federation metadata
- graph execution semantics
- lifecycle semantics
- trust and admissibility semantics
- System-1/System-2 transition rules
This protocol does not define:
- economic matching;
- asset settlement;
- expert-market pricing;
- remote execution evidence formats;
- generic authorization systems;
- transport protocols.
Those are delegated respectively to Actum Compute, Actum, TLSNotary/attestation systems, authority systems, MCP, A2A, and related infrastructure.
2. Design Principles
The K-Line Protocol SHALL preserve the following principles.
2.1 Cognitive structure over vendor identity
A reusable K-line SHOULD encode cognitive capability requirements rather than fixed commercial providers.
Concrete providers and models SHALL be recorded in episodes.
2.2 Semantic stability
A K-line's meaning SHOULD remain stable while its implementation evolves.
This is why templates, episodes, and artifacts are distinct.
2.3 Local sovereignty
No remotely published K-line becomes active automatically.
A local Mind SHALL make an explicit trust and activation decision.
2.4 Provenance is not truth
Signed provenance, Actum finality, and execution evidence establish that claims were made or executions occurred.
They do not establish universal correctness.
2.5 System 1 is provisional
Promoted cognition remains subject to monitoring, decay, revalidation, demotion, supersession, and reopening.
2.6 System 2 may reject precedent
No K-line SHALL be treated as mandatory merely because it was previously successful.
2.7 Cognition and authority are separate
A K-line MAY state that a capability requires authority.
It SHALL NOT itself grant that authority.
3. Normative Terminology
The terms MUST, MUST NOT, SHALL, SHALL NOT, SHOULD, SHOULD NOT, and MAY are normative.
4. Core Object Hierarchy
The canonical hierarchy is:
KLineTemplate
│
├── executed as
│
▼
KLineEpisode
│
├── evaluated by
│
▼
EvaluationClaim
│
├── may contribute to
│
▼
PromotionRecord
│
├── may be compiled into
│
▼
KLineArtifact
│
├── evaluated / monitored
│
├── superseded
│
└── reopened into System 2
5. Canonical Identity Model
Three forms of identity SHALL be distinguished.
5.1 Object ID
An immutable authored identifier.
Example:
kline:template:01JAB...
Object IDs allow authored lineage even if content changes through new versions.
5.2 Content Hash
A cryptographic digest over canonical serialization.
Example:
sha256:84ab...
This identifies exact content.
Two objects with different bytes MUST have different content hashes except in the event of cryptographic collision.
5.3 Semantic Fingerprint
A non-authoritative similarity representation.
It MAY be produced by:
- embeddings;
- graph fingerprints;
- learned representations;
- symbolic feature signatures;
- domain-specific signatures.
Semantic fingerprints MUST NOT be used as cryptographic identity.
6. Canonical Serialization
All protocol objects SHALL support deterministic canonical serialization.
A compliant implementation SHOULD use:
UTF-8
sorted object keys
explicit null policy
normalized numeric encoding
RFC 3339 timestamps
canonical URI representation
The protocol SHALL define:
canonical_hash(object)
as:
SHA-256(canonical_serialization(object))
Implementations MAY additionally support stronger hashes, but SHA-256 compatibility SHOULD remain available.
7. KLineTemplate
7.1 Purpose
KLineTemplate defines the reusable semantic and cognitive topology of a K-line.
It describes:
For this class of situation, what cognition should become active, in what structure, under what constraints, and how should success be assessed?
It SHOULD avoid unnecessarily fixing exact suppliers.
7.2 Schema
{
"schema": "kline.template.v1",
"id": "kline:template:...",
"version": "1.0.0",
"name": "inherited-cardiomyopathy-workup",
"description": "Reusable cognitive topology for investigating suspected inherited cardiomyopathy.",
"publisher": "did:example:publisher",
"trigger": {},
"preconditions": [],
"inputs": {},
"outputs": {},
"graph": {
"nodes": [],
"edges": []
},
"context_policy": {},
"authority_requirements": [],
"budget_policy": {},
"validation": {},
"fallbacks": [],
"lifecycle": {},
"lineage": {},
"semantic_fingerprint": {},
"created_at": "...",
"content_hash": "sha256:..."
}
8. Trigger Specification
Triggers determine when a K-line is considered relevant.
A trigger MAY contain:
semantic signatures
symbolic predicates
state predicates
event types
goal patterns
context conditions
novelty bounds
temporal constraints
Example:
{
"semantic": {
"description": "Possible inherited cardiomyopathy",
"threshold": 0.82
},
"predicates": [
"patient.has_left_ventricular_hypertrophy == true"
]
}
Triggers identify relevance, not automatic execution authority.
9. Preconditions
Preconditions define conditions that MUST hold before activation.
Examples:
required input exists
minimum context completeness
network availability
device capability
required consent
required local data
jurisdiction constraints
A failed precondition SHALL prevent direct activation unless a defined fallback exists.
10. Graph Model
A K-line SHALL be represented as a typed directed graph.
10.1 Node Types
Protocol v1 defines the following base node classes:
capability
artifact
transform
decision
validation
aggregation
memory_read
memory_write_proposal
authority_check
fallback
terminal
Extensions MAY define additional node types.
10.2 Capability Node
A capability node requests cognition from an expert, artifact, local component, or Actum Compute resolution.
Example:
{
"id": "reasoner",
"type": "capability",
"requirement": {
"capability": "general_reasoning",
"minimum_quality": 0.91,
"required_evidence": [
"verified_execution"
],
"privacy": {
"remote_allowed": true
}
}
}
10.3 Artifact Node
An artifact node binds to a known implementation.
Example:
{
"id": "local_classifier",
"type": "artifact",
"artifact_id": "kline:artifact:..."
}
Artifact nodes SHOULD be used when a specific implementation is part of the intended behavior.
10.4 Decision Node
Decision nodes select downstream paths based on state.
Decision functions MUST be deterministic given their declared inputs unless explicitly marked stochastic.
10.5 Validation Node
A validation node checks whether an intermediate or final output satisfies defined criteria.
Validation MAY invoke external capability requirements.
10.6 Memory Write Proposal
K-line execution SHOULD NOT directly mutate shared Mind state.
Instead:
execution
↓
state proposal
↓
validation / authority
↓
signed patch
↓
SurrealDB
A memory_write_proposal node therefore emits a proposed patch.
11. Graph Edges
Edges define:
- control flow;
- data flow;
- conditions;
- failure routes;
- validation dependencies.
Example:
{
"from": "rare_disease",
"to": "critic",
"condition": "output.confidence < 0.95",
"mapping": {
"candidate_diagnoses": "$.rare_disease.output"
}
}
Cycles MAY be allowed but MUST declare:
maximum iterations
termination condition
budget limit
Unbounded loops are non-conformant.
12. CapabilityRequirement
CapabilityRequirement is the primary abstraction between cognition and supplier resolution.
Schema:
{
"schema": "kline.capability-requirement.v1",
"capability": "software_engineering",
"input_schema": {},
"output_schema": {},
"quality": {
"minimum": 0.94,
"metric": "evaluation:software-engineering-v3"
},
"evidence": {
"required": [
"provider_authenticated",
"request_response_bound"
]
},
"trust": {
"minimum_level": "trusted"
},
"privacy": {
"remote_allowed": true,
"confidential_execution_required": false
},
"jurisdiction": {
"allowed": [],
"denied": []
},
"latency": {
"maximum_ms": 90000
},
"cost": {
"maximum": {
"amount": "4.00",
"currency": "EUR"
}
},
"energy": {
"preference": "minimize"
},
"execution_location": [
"local",
"remote"
],
"fallback": {}
}
13. Capability Resolution
A CapabilityRequirement MAY be resolved by:
- local artifact;
- local expert;
- cached remote expert;
- Actum Compute;
- another Mind;
- deterministic tool;
- human expert.
Resolution SHALL produce an ExpertBinding.
14. ExpertBinding
Schema:
{
"schema": "kline.expert-binding.v1",
"requirement_hash": "sha256:...",
"expert_id": "expert:...",
"artifact_id": null,
"capabilities": [
"software_engineering"
],
"expected_quality": 0.96,
"evidence_class": [
"tlsnotary"
],
"trust_class": "trusted",
"price": {
"amount": "2.30",
"currency": "EUR"
},
"expected_latency_ms": 35000,
"binding_time": "...",
"resolver": "actum-compute"
}
Bindings are late-bound execution facts and SHALL normally belong to episodes rather than templates.
15. Admissibility
Before optimization, candidate bindings SHALL pass admissibility.
Define:
[ A(e,r,c) ]
for expert candidate (e), requirement (r), and context (c).
A candidate is admissible only if:
policy allows it
required authority is satisfiable
trust threshold satisfied
evidence class satisfied
privacy policy satisfied
jurisdiction satisfied
quality floor satisfied
Only admissible candidates proceed to optimization.
16. Routing Objective
Among admissible candidates, the Cognitive Kernel MAY optimize:
[ U(e)= Q(e) -\lambda C(e) -\mu L(e) -\rho R(e) -\eta E(e) ]
where:
- (Q) = expected quality;
- (C) = economic cost;
- (L) = latency;
- (R) = contextual risk;
- (E) = energy.
Weights are local Mind policy and MUST NOT be globally fixed.
17. ActivationPlan
Before execution, the Cognitive Kernel SHOULD materialize an ActivationPlan.
Schema:
{
"schema": "kline.activation-plan.v1",
"template_id": "kline:template:...",
"template_hash": "sha256:...",
"trigger_match": {},
"context_commitment": "sha256:...",
"bindings": [],
"execution_mode": "system1",
"estimated_cost": {},
"estimated_latency_ms": 0,
"estimated_energy": null,
"authority_requirements": [],
"validation_plan": {},
"created_at": "..."
}
An ActivationPlan represents intended execution.
The eventual Episode represents actual execution.
18. System-1 Activation
A K-line MAY execute through System 1 when:
template is promoted
artifact/bindings satisfy policy
trigger confidence exceeds threshold
novelty below escalation threshold
required evaluations remain valid
no decay/revalidation gate blocks execution
authority requirements are satisfied
System-1 execution SHOULD prefer low-cost compiled artifacts when quality constraints are maintained.
19. System-2 Escalation
System 2 SHALL be available when any of the following occurs:
no matching K-line
low trigger confidence
novelty too high
unexpected intermediate result
validation disagreement
artifact quality degraded
trust conflict
environment drift
execution anomaly
repeated System-1 failure
policy requires deliberation
20. Novelty and Surprise
Implementations SHOULD compute a novelty/surprise signal:
[ N(q,c,K) ]
Inputs MAY include:
- semantic distance from prior episodes;
- graph mismatch;
- distribution drift;
- disagreement among experts;
- prediction error;
- validation failure;
- unfamiliar context state.
Novelty above local threshold SHOULD cause System-2 escalation.
21. KLineEpisode
KLineEpisode records one actual execution.
Schema:
{
"schema": "kline.episode.v1",
"id": "kline:episode:...",
"template_id": "kline:template:...",
"template_hash": "sha256:...",
"activation_plan_hash": "sha256:...",
"trigger": {},
"context_commitment": "sha256:...",
"bindings": [],
"execution": {
"started_at": "...",
"completed_at": "...",
"mode": "system2",
"nodes": []
},
"inputs_commitment": "sha256:...",
"outputs_commitment": "sha256:...",
"evidence": [],
"cost": {},
"latency_ms": 0,
"energy": null,
"outcome": {},
"evaluation_claims": [],
"actum_receipt": null,
"created_at": "...",
"content_hash": "sha256:..."
}
22. Episode Node Record
Each executed graph node SHOULD produce a record containing:
node ID
input commitment
resolved expert/artifact
execution timestamps
output commitment
evidence references
cost
latency
status
error/fallback information
This enables causal analysis of successful and failed trajectories.
23. Execution Evidence
An Episode MAY reference:
- TLSNotary evidence;
- TEE attestation;
- model hash attestation;
- signed local runtime receipt;
- human signature;
- test results;
- deterministic replay;
- ZeroK proof;
- Actum execution receipt.
The K-Line Protocol does not define those evidence formats.
It defines their relationship to episodes.
24. EvaluationProtocol
Schema:
{
"schema": "kline.evaluation-protocol.v1",
"id": "evaluation:protocol:...",
"name": "...",
"subject_types": [
"template",
"artifact",
"expert",
"episode"
],
"distribution": {
"commitment": "sha256:...",
"description": "..."
},
"sampling": {},
"metrics": [],
"scorer": {},
"contamination_policy": {},
"environment": {},
"minimum_samples": 0,
"acceptance": {},
"publisher": "...",
"created_at": "...",
"content_hash": "sha256:..."
}
25. EvaluationClaim
Schema:
{
"schema": "kline.evaluation-claim.v1",
"id": "evaluation:claim:...",
"subject": {
"type": "artifact",
"id": "kline:artifact:...",
"hash": "sha256:..."
},
"protocol": {
"id": "evaluation:protocol:...",
"hash": "sha256:..."
},
"distribution": {
"commitment": "sha256:..."
},
"environment": {},
"result": {
"metrics": {}
},
"evidence": [],
"evaluator": "did:example:evaluator",
"issued_at": "...",
"expires_at": null,
"actum_receipt": null,
"content_hash": "sha256:..."
}
An implementation MUST NOT treat one claim as universal evidence across unrelated distributions.
26. Promotion
Promotion is the transition from candidate cognition into eligible System-1 cognition.
Promotion SHALL be policy-driven.
A promotion policy MAY require:
minimum number of episodes
minimum number of independent evaluations
minimum success probability
maximum failure rate
required evaluator trust
environment coverage
absence of unresolved anomalies
27. PromotionRecord
{
"schema": "kline.promotion.v1",
"template_id": "kline:template:...",
"from_state": "validated",
"to_state": "promoted",
"basis": {
"episodes": [],
"evaluation_claims": []
},
"policy": "policy:kline-promotion-v1",
"authority": "...",
"promoted_at": "...",
"actum_receipt": null
}
Promotion SHALL NOT imply permanent validity.
28. KLineArtifact
Schema:
{
"schema": "kline.artifact.v1",
"id": "kline:artifact:...",
"template_id": "kline:template:...",
"template_hash": "sha256:...",
"artifact_type": "local_model",
"implementation": {
"runtime": "...",
"target": "...",
"content_hash": "sha256:..."
},
"requirements": {
"hardware": [],
"software": [],
"memory": null,
"network": null
},
"quality_claims": [],
"privacy": {},
"authority_requirements": [],
"cost_profile": {},
"latency_profile": {},
"energy_profile": {},
"compiler_lineage": {},
"publisher": "...",
"lifecycle": {},
"created_at": "...",
"content_hash": "sha256:..."
}
29. Artifact Types
Protocol v1 recognizes:
workflow
local_model
remote_workflow
classifier
ruleset
deterministic_program
hybrid
mobile_reflex
prompted_agent
graph_executor
Implementations MAY define extensions.
30. Cognitive Compiler Interface
The Cognitive Compiler SHALL accept:
template
successful episodes
evaluation requirements
optimization targets
deployment constraints
and return one or more candidate artifacts.
Conceptual interface:
compile(
KLineTemplate,
EpisodeSet,
Constraints,
Objective
) → ArtifactCandidates
31. TopologyCompiler
The TopologyCompiler searches for simpler cognitive graphs.
Possible operations include:
remove redundant node
merge nodes
replace parallel reasoning with deterministic decision
reduce repeated verification
cache stable intermediate result
replace generic expert with specialist
collapse stable branch
Every candidate topology MUST be re-evaluated.
32. ArtifactCompiler
The ArtifactCompiler changes implementation while preserving semantics.
Possible transformations include:
remote experts → local model
large model → distilled model
LLM chain → classifier
agent workflow → deterministic program
network retrieval → cached structured knowledge
multi-agent reasoning → single specialist artifact
Compiled output MUST NOT be promoted solely because it is cheaper.
Quality constraints remain authoritative.
33. CompilationRecord
{
"schema": "kline.compilation.v1",
"source_template": "kline:template:...",
"source_episodes": [],
"compiler": {
"id": "...",
"version": "..."
},
"optimization": {
"targets": [
"cost",
"latency",
"energy"
],
"quality_floor": 0.95
},
"produced_artifacts": [],
"evaluation_claims": [],
"created_at": "...",
"actum_receipt": null
}
34. Lifecycle
Templates and artifacts SHALL expose lifecycle status.
Recommended states:
candidate
validated
promoted
active
degraded
revalidation_required
superseded
revoked
archived
35. Decay
A Mind SHOULD support confidence decay.
Decay MAY depend on:
time
distribution drift
environment drift
expert changes
model changes
evaluation age
failure observations
superseding evidence
A simple implementation MAY use:
[ confidence_t
confidence_0 e^{-\lambda t} ]
but protocol semantics do not mandate a mathematical form.
36. Revalidation
A K-line or artifact SHOULD enter revalidation_required when:
validity window expires
provider behavior changes
model identity changes materially
input distribution drifts
failure surprise exceeds threshold
evaluation protocol becomes obsolete
artifact runtime changes
Revalidation returns it to active or results in degradation/supersession/revocation.
37. Supersession
A new K-line or artifact SHOULD supersede rather than erase prior history.
Schema:
{
"schema": "kline.supersession.v1",
"subject": "kline:artifact:A",
"superseded_by": "kline:artifact:B",
"reason": "quality_and_energy_improvement",
"evidence": [],
"effective_at": "...",
"actum_receipt": null
}
Historical episodes MUST remain attributable to the implementation actually used.
38. Failure Surprise
Implementations SHOULD track mismatch between expected and observed performance.
Define conceptually:
[ S = f( expected_quality, observed_quality, confidence, context_distance ) ]
Large surprise SHOULD increase:
revalidation pressure
System-2 escalation probability
artifact demotion probability
39. Higher-Order K-Lines
A K-line MAY activate other K-lines as cognitive primitives.
Example:
K521
├── K1
├── K2
├── K3
└── K4
This enables hierarchical cognition.
Nested K-lines MUST preserve:
- input/output typing;
- authority constraints;
- evidence requirements;
- failure semantics.
40. Recursive Composition
System 2 MAY create candidate higher-order K-lines by composing existing K-lines.
This process SHALL be treated as new cognition and MUST undergo evaluation before System-1 promotion.
Composition does not inherit universal validity from its components.
41. Federation
K-lines are shareable across Minds.
Federation SHOULD support:
publish
discover
fetch
verify
evaluate
fork
supersede
cache
block
No remote federation operation SHALL automatically activate a K-line locally.
42. Federation Descriptor
{
"schema": "kline.federation-descriptor.v1",
"subject": {
"id": "kline:template:...",
"hash": "sha256:..."
},
"publisher": "did:example:publisher",
"availability": {
"protocols": [
"a2a",
"https"
]
},
"evidence": [],
"evaluation_claims": [],
"licensing": {},
"published_at": "...",
"actum_receipt": null
}
43. Local Trust View
Each Mind SHOULD maintain a local trust state independent of global publication.
Example:
{
"subject": "kline:template:...",
"status": "experimental",
"publisher_trust": 0.82,
"evaluation_trust": {
"evaluation:claim:1": 0.94
},
"local_experience": {
"episodes": 12,
"success": 11
},
"policy": {
"allow_system1": false,
"allow_system2": true
}
}
Trust is contextual and SHOULD NOT be globally standardized into a single universal score.
44. Imports
Importing a K-line SHOULD resemble importing executable supply-chain content.
Implementations SHOULD verify:
publisher identity
content hash
lineage
evaluation claims
artifact integrity
authority requirements
dependencies
known revocations
A Mind MAY sandbox imported K-lines in System 2 before allowing System-1 promotion.
45. Poisoning Resistance
Federated implementations SHOULD protect against:
Sybil publishers
fabricated evaluations
benchmark contamination
mass popularity manipulation
malicious graph payloads
stale dependencies
expert collusion
semantic spoofing
Actum provenance can assist but MUST NOT be treated as proof of correctness.
46. Actum Integration
Kline MAY anchor protocol-level acts on Actum.
Recommended act classes:
KLineEpisodeAct
EvaluationClaimAct
PromotionAct
CompilationAct
ArtifactPublicationAct
SupersessionAct
RevocationAct
Actum records durable evidence and lineage.
Kline retains cognitive interpretation.
47. Actum Compute Integration
The K-Line Protocol invokes Actum Compute through capability resolution.
The normative boundary is:
Kline:
what cognition is required?
Actum Compute:
who or what can supply it,
under what terms and evidence?
The exchange SHOULD NOT decide whether a K-line is cognitively appropriate.
48. Expert Episodes Through Actum Compute
A remote expert binding may generate:
ComputeOffer
JobIntent
JobAssignment
ExecutionAct
SettlementAct
The KLineEpisode SHOULD reference the corresponding execution evidence and Actum receipts.
49. Evaluation Market Integration
Kline MAY request evaluation as a capability.
Example:
{
"capability": "evaluate_kline",
"requirements": {
"protocol": "evaluation:protocol:...",
"minimum_independent_evaluators": 3
}
}
Actum Compute may procure evaluators.
Kline decides whether the resulting claims satisfy promotion policy.
50. Artifact Market Integration
A KLineArtifact MAY be:
private
public
free
licensed
subscription-based
per-execution
royalty-bearing
organization-restricted
Economic semantics belong to Actum Compute, not the K-Line Template itself.
51. Authority Boundary
A graph may declare:
{
"requires": {
"capability": "send_email",
"authority": "delegated"
}
}
But execution requires an external authorization decision.
The K-line SHALL NOT infer authorization from historical success.
52. State Mutation Boundary
K-lines SHOULD operate through proposal-based state mutation.
Preferred model:
read state
↓
reason
↓
propose patch
↓
validate
↓
authorize
↓
commit
Direct uncontrolled mutation is discouraged.
53. SurrealDB Reference Model
A reference SurrealDB implementation MAY use:
kline_template
kline_episode
kline_artifact
capability_requirement
expert_binding
activation_plan
evaluation_protocol
evaluation_claim
promotion_record
compilation_record
supersession_record
federation_descriptor
trust_view
Relationships MAY include:
IMPLEMENTS
EXECUTED_AS
EVALUATED_BY
PROMOTED_FROM
COMPILED_INTO
SUPERSEDES
FORKED_FROM
REQUIRES
BOUND_TO
PUBLISHED_BY
TRUSTED_BY
54. Example Cognitive Graph
┌──────────────────┐
│ phenotype_extract│
└────────┬─────────┘
│
▼
┌─────────────────────┐
│ cardiomyopathy_reason│
└──────────┬──────────┘
│
┌────────────┴────────────┐
▼ ▼
rare_disease evidence_search
│ │
└────────────┬────────────┘
▼
independent_critic
│
▼
validation
│
┌──────┴──────┐
▼ ▼
accept System 2
Each cognitive node describes a capability requirement.
Each Episode records actual bindings.
55. Example Template
{
"schema": "kline.template.v1",
"id": "kline:template:cardiomyopathy-001",
"version": "1.0.0",
"name": "Inherited Cardiomyopathy Investigation",
"trigger": {
"semantic": {
"description": "suspected inherited cardiomyopathy",
"threshold": 0.84
}
},
"graph": {
"nodes": [
{
"id": "phenotype",
"type": "capability",
"requirement": {
"capability": "clinical_phenotype_extraction",
"quality": {
"minimum": 0.95
}
}
},
{
"id": "reasoning",
"type": "capability",
"requirement": {
"capability": "cardiomyopathy_reasoning",
"quality": {
"minimum": 0.96
},
"evidence": {
"required": [
"verified_execution"
]
}
}
},
{
"id": "rare",
"type": "capability",
"requirement": {
"capability": "rare_disease_specialist",
"quality": {
"minimum": 0.94
}
}
},
{
"id": "critic",
"type": "validation",
"requirement": {
"capability": "independent_clinical_critique"
}
}
],
"edges": [
{
"from": "phenotype",
"to": "reasoning"
},
{
"from": "reasoning",
"to": "rare"
},
{
"from": "rare",
"to": "critic"
}
]
},
"lifecycle": {
"status": "candidate"
}
}
56. Example Episode
{
"schema": "kline.episode.v1",
"id": "kline:episode:E923",
"template_id": "kline:template:cardiomyopathy-001",
"bindings": [
{
"node": "phenotype",
"expert_id": "artifact:local-phenotype-v4"
},
{
"node": "reasoning",
"expert_id": "expert:frontier-reasoner-381",
"evidence": [
"actum:execution:..."
]
},
{
"node": "rare",
"expert_id": "expert:fabry-specialist-14b"
},
{
"node": "critic",
"expert_id": "expert:clinical-critic-91"
}
],
"outcome": {
"status": "success"
},
"cost": {
"amount": "3.82",
"currency": "EUR"
},
"latency_ms": 28100
}
57. System-1 Compilation Example
Initial System-2 topology:
frontier reasoning
+
rare-disease expert
+
literature retrieval
+
critic
+
human review
After repeated validation:
specialist workflow
+
critic
After Artifact Compilation:
local specialist model
+
deterministic confidence gate
Final mobile artifact:
on-device classifier
+
rules
+
System-2 escalation if uncertain
The semantic K-line remains identifiable through the entire lineage.
58. Conformance Requirements
A conformant K-Line Protocol implementation MUST:
- distinguish Template, Episode, and Artifact;
- support immutable episode recording;
- support canonical hashing;
- support typed graph execution;
- support CapabilityRequirements;
- record concrete expert bindings in episodes;
- keep cognition separate from authority;
- support lifecycle status;
- support supersession without destructive history deletion;
- support evaluation claims tied to protocols;
- support System-2 escalation;
- prevent automatic activation of imported federated K-lines;
- maintain local trust decisions;
- support compiled artifacts;
- preserve lineage between cognition and artifacts.
59. Recommended Conformance Requirements
A mature implementation SHOULD additionally:
- support Actum anchoring;
- support Actum Compute capability resolution;
- support ZeroK-verifiable evaluation claims;
- support expert-execution evidence;
- support confidence decay;
- support novelty detection;
- support mobile artifacts;
- support higher-order K-lines;
- support local re-evaluation;
- support evaluation markets.
60. Security Considerations
K-lines constitute executable cognitive supply-chain content.
Threats include:
malicious graph logic
poisoned templates
malicious artifacts
false quality claims
forged evaluations
dependency substitution
model/provider downgrade
authority confusion
data exfiltration
prompt injection
state poisoning
benchmark gaming
collusion
A conformant runtime SHOULD treat external K-lines as untrusted until locally evaluated or trusted according to policy.
61. Privacy Considerations
KLineEpisodes may contain extremely sensitive context.
Implementations SHOULD support:
commitment-only publication
selective disclosure
private local episodes
ZeroK evaluation proofs
redacted expert identities
private input/output commitments
Federation SHOULD default to sharing the minimum data needed for the intended claim.
62. Economic Neutrality
The K-Line Protocol SHALL NOT require a specific economic model.
K-lines MAY be:
public goods
open source
licensed
royalty-bearing
private
organization-owned
marketed through Actum Compute
Economic terms belong outside the semantic template.
63. Reference Cognitive Lifecycle
The normative lifecycle is:
UNKNOWN PROBLEM
│
▼
SYSTEM 2 DISCOVERY
│
▼
SUCCESSFUL EPISODE
│
▼
REIFY TEMPLATE
│
▼
EVALUATE
│
▼
VALIDATE
│
▼
PROMOTE
│
▼
SYSTEM 1
│
▼
COMPILE
│
▼
ARTIFACT
│
▼
DEPLOY
│
▼
MONITOR
│
┌────┼─────────┐
▼ ▼ ▼
good drift failure
│ │ │
│ ▼ ▼
│ revalidate reopen S2
│
└──────────────► reinforce
64. Architectural Definition
A K-line is:
A typed, reusable, evidence-bearing cognitive topology that describes how a class of situations should activate capabilities, context, validation, and control flow, while remaining independent from the particular expert implementations used in any single execution.
A KLineEpisode is:
An immutable record of one concrete realization of a K-line, including actual expert bindings, execution evidence, cost, latency, context commitments, and outcome.
A KLineArtifact is:
A compiled executable implementation of a K-line optimized for a target environment while preserving required semantic and quality constraints.
Together they define the core unit of reusable cognition in the Distributed Cognitive Network.
65. Strategic Objective
The system should continuously transform:
novel cognition
↓
successful episode
↓
K-line
↓
validated cognitive capital
↓
compiled artifact
↓
cheap System-1 cognition
The long-term objective is not to eliminate System 2.
It is to continuously move solved regions of the problem space from expensive discovery into efficient reusable cognition, allowing scarce expert capacity to migrate toward the frontier.
The next artifact should be Volume III — Actum Compute Protocol 0.2, which will define the network market around CapabilityRequirement, ExpertOffer, ArtifactOffer, matching, execution assurance classes, TLSNotary evidence, evaluation procurement, pricing, settlement, and how Agent Plugins expose the whole thing to Codex and other agents.