Distributed Cognitive Network

Volume III — Actum Compute Protocol 0.2

Capability Markets, Expert Resolution, Verifiable Execution, Evidence, Economics, and Agent Distribution

1. Scope

This document defines Actum Compute Protocol 0.2, the economic, discovery, procurement, verification, and settlement layer beneath the Kline cognitive architecture.

Actum Compute exists to answer:

Given a cognitive capability requirement, who or what can satisfy it, under what quality, trust, privacy, evidence, latency, availability, and economic conditions?

Actum Compute is not the Cognitive Kernel.

It does not decide what a Mind should think.

It provides a market and execution fabric through which Kline and other clients can acquire scarce cognition.

The protocol supports markets for:

frontier-model execution;
subscription-backed model execution;
API-backed model execution;
local models;
specialist models;
human experts;
K-line artifacts;
evaluation services;
verification services;
trusted data/evidence;
raw compute;
compilation and distillation services.

Actum Compute SHALL use Actum as its canonical verifiable action, evidence, finality, and settlement substrate.

Where appropriate, it SHALL support:

TLSNotary for authenticated remote execution evidence;
Distill-derived evidence processing;
ZeroK for confidential verification;
Agent Plugins for portable distribution;
MCP for capability invocation;
A2A for autonomous agent negotiation.

2. Architectural Role

The canonical relationship is:

KLINE
cognitive layer
    │
    │ CapabilityRequirement
    ▼
ACTUM COMPUTE
intelligence market
    │
    ├── expert discovery
    ├── capability resolution
    ├── pricing
    ├── matching
    ├── execution procurement
    ├── evidence procurement
    ├── evaluation procurement
    └── settlement orchestration
    │
    ▼
ACTUM
verifiable action layer

The normative boundary is:

Kline determines what cognition is required. Actum Compute determines what admissible supply exists and under what terms. Actum proves what verifiably happened.

3. Core Principles

3.1 Capability, not account access

Actum Compute SHALL trade execution capability and cognitive outcomes.

It SHALL NOT define account sharing as a market primitive.

A supplier may use:

a subscription;
an API;
local hardware;
enterprise infrastructure;
a human;
a licensed artifact;

as the implementation behind its offered capability.

The traded object is the contracted execution or artifact.

3.2 Model quality may be part of the contract

Provider and model identity SHALL NOT be hidden when they materially define the execution class.

A buyer MAY request:

provider: OpenAI
model_class: current_flagship_coding
evidence: TLSNotary

or:

capability: software_engineering
minimum_quality: 0.95
provider: unrestricted

The protocol therefore supports both:

provider-neutral capability markets;
provider/model-specific execution classes.

3.3 Evidence is part of the commodity

An execution without evidence and the same execution with strong evidence are distinct market goods.

Examples:

unverified coding execution

provider-authenticated coding execution

provider + model-label authenticated execution

TEE-attested specialist-model execution

fully bound request/result execution

Evidence requirements SHALL be explicit.

3.4 Privacy is selectable

A buyer SHOULD be able to specify privacy requirements independently of execution capability.

Examples:

public execution

pseudonymous execution

confidential input

confidential settlement

hidden expert identity

hidden exact price

private evaluation

3.5 Settlement follows verified acts

Where verification is required, payment SHALL NOT be released solely because a supplier claims completion.

Settlement SHALL be conditioned on the required execution and evidence predicates.

4. Principal Market Objects

Protocol 0.2 defines these core objects:

CapabilityRequirement
ExpertDescriptor
ExpertOffer
ArtifactOffer
EvaluationOffer
EvidenceOffer
ComputeOffer
CapabilityQuote
JobIntent
JobAssignment
ExecutionReceipt
ProviderExecutionEvidence
EvaluationClaim
SettlementIntent
SettlementAct
ReputationClaim

The K-Line Protocol definition of CapabilityRequirement is reused rather than duplicated.

5. ExpertDescriptor

ExpertDescriptor describes a supplier of cognition.

An Expert MAY be:

model;
agent;
workflow;
human;
organization;
K-line artifact;
hybrid system.

Schema:

{
  "schema": "actum.compute.expert.v1",
  "id": "expert:...",

  "operator": "did:example:operator",

  "type": "model",

  "name": "Verified Frontier Coding Expert",

  "capabilities": [
    "software_engineering",
    "debugging",
    "code_review"
  ],

  "execution_classes": [],

  "evidence_classes": [
    "tlsnotary"
  ],

  "privacy_classes": [
    "remote_private"
  ],

  "environments": [
    "remote"
  ],

  "quality_claims": [],

  "attestations": [],

  "metadata": {},

  "created_at": "...",
  "content_hash": "sha256:..."
}

6. ExecutionClass

An ExecutionClass defines characteristics of an execution that materially affect its value.

Example:

{
  "schema": "actum.compute.execution-class.v1",

  "id": "execution-class:frontier-coding-openai",

  "capability": "software_engineering",

  "provider": {
    "required": "openai"
  },

  "model": {
    "requirement": "current_flagship_coding"
  },

  "evidence": {
    "required": [
      "provider_authenticated",
      "model_identifier_authenticated",
      "request_bound",
      "result_bound"
    ]
  },

  "tools": {
    "allowed": true
  },

  "minimum_context": null,

  "privacy": {
    "remote_allowed": true
  }
}

Execution classes MAY be standardized by market participants.

7. ExpertOffer

An ExpertOffer advertises an expert's willingness to execute capability.

Schema:

{
  "schema": "actum.compute.expert-offer.v1",
  "id": "offer:expert:...",

  "expert_id": "expert:...",

  "capabilities": [
    "software_engineering"
  ],

  "execution_classes": [
    "execution-class:frontier-coding-openai"
  ],

  "quality_claims": [],

  "evidence_classes": [
    "tlsnotary"
  ],

  "privacy_classes": [
    "remote_private"
  ],

  "availability": {},

  "capacity": {},

  "reserve_policy": {},

  "pricing": {},

  "jurisdiction": {},

  "settlement": {},

  "expires_at": "...",

  "publisher": "did:example:seller",

  "actum_receipt": null
}

8. Capacity Semantics

Capacity MAY be represented as:

concurrency
time
jobs
compute units
provider allowance estimate
GPU time
token budget
human hours
artifact execution quota

Capacity estimates MAY be probabilistic.

For subscription-backed providers, exact provider allowance may be unknowable.

An offer therefore MAY state:

{
  "capacity": {
    "measurement": "estimated_remaining_fraction",
    "value": 0.62,
    "confidence": 0.74
  }
}

9. Reserve Policy

A supplier MAY reserve capacity for itself.

Example:

{
  "reserve_policy": {
    "minimum_remaining_fraction": 0.30,
    "idle_only": true,
    "max_concurrent_jobs": 1
  }
}

The matcher MUST NOT assign new jobs when accepting the assignment would violate a mandatory reserve policy.

10. Subscription-Backed Execution

Actum Compute MAY support execution in which a supplier uses its own flat-fee subscription.

Normative requirements:

provider authentication remains on the supplier host;
the buyer receives no transferable provider credential;
the supplier exposes execution capability rather than credentials;
the execution worker controls the authenticated provider session;
evidence requirements MAY prove provider/model interaction;
the market does not imply contractual authorization by the upstream provider.

Provider-specific terms remain external constraints.

11. ArtifactOffer

ArtifactOffer distributes compiled cognition.

Schema:

{
  "schema": "actum.compute.artifact-offer.v1",

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

  "artifact": {
    "id": "kline:artifact:...",
    "hash": "sha256:..."
  },

  "template": {
    "id": "kline:template:...",
    "hash": "sha256:..."
  },

  "capabilities": [],

  "target_environments": [
    "ios-arm64"
  ],

  "quality_claims": [],

  "evidence": [],

  "license": {
    "type": "per_execution"
  },

  "pricing": {},

  "publisher": "...",

  "actum_receipt": null
}

Artifacts MAY be:

downloadable;
remotely hosted;
encrypted;
licensed;
per-use;
royalty-bearing.

12. EvaluationOffer

Evaluation is a first-class market service.

Schema:

{
  "schema": "actum.compute.evaluation-offer.v1",

  "id": "offer:evaluation:...",

  "evaluator": "expert:...",

  "supported_protocols": [
    "evaluation:protocol:..."
  ],

  "subject_types": [
    "kline_template",
    "kline_artifact",
    "expert"
  ],

  "independence_claims": [],

  "evidence_classes": [],

  "pricing": {},

  "availability": {}
}

13. EvidenceOffer

Verification providers MAY separately sell evidence services.

Examples:

TLSNotary verification;
TEE attestation;
deterministic replay;
benchmark execution;
human certification;
ZK proof generation.

Schema:

{
  "schema": "actum.compute.evidence-offer.v1",

  "provider": "evidence-provider:...",

  "evidence_class": "tlsnotary",

  "supported_claims": [
    "provider_identity",
    "request_binding",
    "result_binding"
  ],

  "pricing": {},

  "latency": {}
}

14. Raw ComputeOffer

Raw compute remains a valid commodity.

Examples:

GPU minutes
CPU time
secure enclave execution
mobile inference
storage
bandwidth

However raw compute SHALL remain distinct from higher-level expert capability.

15. Capability Resolution

The primary Actum Compute operation is:

resolve(CapabilityRequirement)

which returns candidate suppliers.

Conceptual result:

{
  "schema": "actum.compute.capability-resolution.v1",

  "requirement_hash": "sha256:...",

  "candidates": [
    {
      "offer_id": "offer:...",
      "expert_id": "expert:...",

      "expected_quality": 0.96,

      "price": {
        "amount": "2.40",
        "currency": "EUR"
      },

      "expected_latency_ms": 42000,

      "evidence": [
        "tlsnotary"
      ],

      "privacy": "remote_private",

      "admissibility_evidence": []
    }
  ],

  "resolved_at": "..."
}

Actum Compute SHOULD return several candidates where useful.

Kline retains final selection.

16. Matching

Matching SHALL first enforce hard constraints.

Candidates failing any mandatory constraint MUST be excluded.

Constraints MAY include:

capability
quality
trust
provider
model class
evidence
privacy
jurisdiction
availability
budget
latency
authority
hardware

Only admissible candidates enter economic ranking.

17. Economic Ranking

Market ranking MAY optimize:

[ Score = w_q Q

w_r R

w_e E ]

where:

(Q) = expected quality;
(C) = price;
(L) = latency;
(R) = execution risk;
(E) = energy.

Weights MAY be buyer policy.

Actum Compute SHALL NOT globally impose one universal utility function.

18. CapabilityQuote

Before commitment, a supplier MAY issue a signed quote.

Schema:

{
  "schema": "actum.compute.quote.v1",

  "id": "quote:...",

  "requirement_hash": "sha256:...",

  "offer_id": "offer:...",

  "execution_class": "...",

  "price": {
    "amount": "2.40",
    "currency": "EUR"
  },

  "estimated_latency_ms": 42000,

  "evidence_commitment": {},

  "valid_until": "...",

  "issuer": "...",

  "signature": "..."
}

19. JobIntent

JobIntent represents the buyer's committed request.

Schema:

{
  "schema": "actum.compute.job-intent.v1",

  "id": "job:...",

  "buyer_commitment": "sha256:...",

  "capability_requirement": {
    "hash": "sha256:..."
  },

  "objective_commitment": "sha256:...",

  "input_state_commitment": "sha256:...",

  "required_execution_class": "...",

  "required_evidence": [],

  "privacy_policy": {},

  "maximum_settlement": {
    "amount": "4.00",
    "currency": "EUR"
  },

  "deadline": "...",

  "authorization": {},

  "created_at": "...",

  "actum_receipt": null
}

Private job details SHOULD be committed rather than published when confidentiality is required.

20. JobAssignment

The assignment binds:

job;
supplier;
execution conditions;
price;
evidence challenge;
expiry.

Schema:

{
  "schema": "actum.compute.job-assignment.v1",

  "id": "assignment:...",

  "job_id": "job:...",
  "offer_id": "offer:...",
  "expert_id": "expert:...",

  "execution_class": "...",

  "settlement_amount": {},

  "evidence_requirement": {},

  "execution_challenge": "base64url:...",

  "input_commitment": "sha256:...",

  "expires_at": "...",

  "buyer_commitment": "sha256:...",
  "seller_commitment": "sha256:...",

  "actum_receipt": null
}

21. Execution Challenge

Every evidence-bound assignment SHOULD include a fresh challenge.

The challenge SHALL be unique and short-lived.

It SHALL be cryptographically bound to the assignment.

Conceptually:

[ Challenge = H( AssignmentID \parallel JobCommitment \parallel SellerCommitment \parallel Nonce \parallel Expiry ) ]

The challenge prevents reuse of unrelated prior execution evidence.

22. Execution State Machine

Recommended job states:

OPEN
  ↓
QUOTED
  ↓
FUNDED
  ↓
ASSIGNED
  ↓
EXECUTING
  ↓
PROOF_PENDING
  ↓
VERIFIED
  ↓
DELIVERED
  ↓
SETTLED

Failure states:

EXPIRED
CANCELLED
FAILED
PROOF_REJECTED
DISPUTED
REFUNDED

23. Donor/Expert Worker

A remote execution worker SHOULD own:

sandbox creation
workspace materialization
local credential use
resource limits
network policy
process policy
execution timeout
evidence capture
result commitment
cleanup

The buyer SHOULD submit intent and inputs, not arbitrary control of the supplier's host.

24. Job Isolation

Remote jobs SHOULD run in isolated environments.

At minimum:

separate working directory
process isolation
bounded execution time
explicit filesystem scope
explicit network policy
resource limits
cleanup

Higher-assurance environments MAY use:

VM;
container;
TEE;
disposable machine;
hardware-isolated worker.

25. Provider Credentials

Provider credentials SHALL NOT be part of portable market objects.

Actum Compute SHALL NOT require suppliers to transmit:

session cookies
OAuth refresh tokens
passwords
API keys
account credentials

Credentials remain local to the execution provider unless an upstream provider explicitly defines a transferable delegation mechanism.

26. ProviderExecutionEvidence

Schema:

{
  "schema": "actum.compute.provider-execution-evidence.v1",

  "assignment_id": "assignment:...",

  "execution_challenge": "base64url:...",

  "provider": {
    "identity": "openai",
    "server_name": "..."
  },

  "model": {
    "label": "...",
    "verification": "authenticated_disclosure"
  },

  "request_commitment": "sha256:...",
  "response_commitment": "sha256:...",
  "result_commitment": "sha256:...",

  "evidence_class": "tlsnotary",

  "transcript_commitment": "sha256:...",
  "proof_commitment": "sha256:...",

  "nullifier": "sha256:...",

  "verifier": "...",

  "executed_at": "...",

  "signature": "..."
}

27. Evidence Assurance Vector

Execution SHALL NOT be represented by one ambiguous boolean such as verified=true.

Use an assurance vector.

Example:

{
  "provider_identity": "verified",
  "server_endpoint": "verified",
  "model_identifier": "verified",
  "request_binding": "verified",
  "response_binding": "verified",
  "result_binding": "verified",
  "freshness": "verified",
  "execution_environment": "unverified"
}

This permits precise buyer requirements.

28. TLSNotary Role

TLSNotary MAY provide authenticated evidence for remote provider interaction.

It can establish properties such as:

server identity;
disclosed request fields;
disclosed response fields;
request/response binding;
freshness challenge presence;
model label where included in authenticated traffic.

TLSNotary SHALL NOT be described as proving:

hidden model weights;
undisclosed internal routing;
secret system prompts;
server-side implementation details;
exact internal inference path.

29. Distill-Derived Evidence Gateway

The evidence gateway SHOULD reuse the Distill architectural pattern for:

challenge registry
provider adapters
endpoint policy
canonical parsing
canonical hashing
transcript commitments
proof nullifiers
signed receipts
local plaintext retention
selective disclosure

The generic subsystem MAY be named:

ExternalExecutionEvidence

or equivalent.

30. Replay Prevention

Execution evidence SHALL contain a replay-resistant nullifier.

Conceptual derivation:

[ N_{execution} = H( VerifierID \parallel SessionID \parallel TranscriptCommitment \parallel AssignmentID ) ]

A previously consumed nullifier MUST NOT authorize a second settlement.

31. Result Binding

The marketplace SHALL distinguish:

provider response

from:

delivered artifact

The execution receipt MUST bind the delivered result to the authenticated execution.

For example:

response_commitment
    ↓ deterministic extraction
result_commitment
    ↓
patch / answer / artifact

32. ExecutionReceipt

Schema:

{
  "schema": "actum.compute.execution-receipt.v1",

  "id": "execution:...",

  "job_id": "job:...",
  "assignment_id": "assignment:...",

  "expert_id": "expert:...",

  "execution_class": "...",

  "input_commitment": "sha256:...",
  "result_commitment": "sha256:...",

  "evidence": [],

  "assurance": {},

  "cost": {},
  "latency_ms": 0,

  "started_at": "...",
  "completed_at": "...",

  "proof_nullifier": "sha256:...",

  "issuer": "...",

  "signature": "...",

  "actum_receipt": null
}

33. Actum ExecutionAct

A successful verified execution SHOULD generate an Actum ExecutionAct.

Conceptually:

ExecutionAct
├── JobIntent commitment
├── JobAssignment commitment
├── input-state commitment
├── result commitment
├── execution receipt commitment
├── evidence commitments
├── assurance vector
├── authority
└── finality

Actum finality proves that this execution claim entered finalized network history.

34. ZeroK Integration

ZeroK MAY prove private execution predicates without revealing witnesses.

Example proof:

ValidExecutionProof

may prove:

assignment exists
AND
TLSNotary evidence verifies
AND
required provider class satisfied
AND
required model class satisfied
AND
request commitment matches job
AND
result commitment matches execution
AND
price <= buyer maximum
AND
seller is authorized recipient
AND
nullifier unused

without exposing sensitive values.

35. Public and Private Inputs

A settlement ZK proof SHOULD minimize public inputs.

Potential public inputs:

job_nullifier
execution_commitment
settlement_commitment
proof_version
network/domain separator

Potential private witnesses:

buyer identity
seller identity
exact prompt
exact response
exact price
provider identity
model identity
evaluation data

depending on policy.

36. Confidential Market Modes

Recommended market privacy modes:

PUBLIC

Visible:

buyer
seller
provider
model
price
execution

PSEUDONYMOUS

Visible:

commitment identities
provider/model
price
execution class

PRIVATE

Visible:

required predicates satisfied
execution commitment
settlement commitment

Exact buyer, seller, provider/model, price, prompt, and response MAY remain private.

37. SettlementIntent

Schema:

{
  "schema": "actum.compute.settlement-intent.v1",

  "job_id": "job:...",

  "payer_commitment": "sha256:...",
  "payee_commitment": "sha256:...",

  "asset": "...",

  "amount_commitment": "sha256:...",

  "condition": {
    "execution_status": "VERIFIED",
    "required_assurance": {}
  },

  "expiry": "...",

  "nullifier_policy": "single_settlement"
}

38. Settlement Condition

Payment SHALL be conditionally authorized only if required predicates pass.

Typical predicate:

valid assignment
∧
valid execution
∧
required evidence
∧
required assurance
∧
result commitment delivered
∧
no prior settlement

39. SettlementAct

Schema:

{
  "schema": "actum.compute.settlement-act.v1",

  "id": "settlement:...",

  "job_id": "job:...",
  "execution_id": "execution:...",

  "asset": "...",

  "amount_commitment": "sha256:...",

  "payer_commitment": "sha256:...",
  "payee_commitment": "sha256:...",

  "settlement_nullifier": "sha256:...",

  "proof": {},

  "status": "finalized",

  "actum_receipt": "..."
}

40. Asset Neutrality

Actum Compute SHALL remain asset-neutral.

Settlement MAY use:

stablecoin
tokenized fiat
marketplace credit
bank-backed claim
native Actum asset
other supported asset

The cognitive protocol SHALL NOT depend on one monetary asset.

41. Escrow

For paid jobs, funds SHOULD be reserved before expensive remote execution begins.

Typical flow:

quote
 ↓
buyer accepts
 ↓
funds reserved
 ↓
assignment
 ↓
execution
 ↓
verification
 ↓
release

Failure MAY result in refund or partial payment according to agreed terms.

42. Partial Payment

Contracts MAY define:

zero payment on invalid proof
partial runtime reimbursement
evidence-provider fee
cancellation fee
milestone payments

Terms MUST be committed before execution.

43. Disputes

Actum Compute SHOULD distinguish cryptographic disputes from quality disputes.

Quality dispute

Examples:

answer technically valid but poor
buyer expected something different
subjective quality disagreement

These may require:

evaluation protocol;
arbitration;
additional experts;
human adjudication.

44. Evaluation Procurement

Kline MAY request evaluation through Actum Compute.

Example:

{
  "capability": "evaluate_kline",

  "subject": {
    "id": "kline:artifact:..."
  },

  "protocol": {
    "id": "evaluation:protocol:..."
  },

  "requirements": {
    "independent_evaluators": 3
  },

  "maximum_cost": {
    "amount": "20",
    "currency": "EUR"
  }
}

Actum Compute matches evaluators.

The resulting EvaluationClaims are recorded on Actum.

Kline decides whether they justify promotion.

45. Evaluator Independence

Evaluation contracts SHOULD support independence constraints.

Examples:

not artifact publisher
not expert operator
not same organization
different evaluator clusters
different model families
different jurisdictions

Independence itself MAY require evidence.

46. Evidence Market

Evidence production can be economically separate from execution.

Example:

Expert executes
      ↓
TLSNotary provider verifies
      ↓
ZeroK proof service
      ↓
Actum recorder

Each may receive compensation.

This creates a specialized evidence market.

47. Compilation Market

Kline's Cognitive Compiler MAY procure:

distillation
benchmarking
fine-tuning
quantization
compiler optimization
GPU training
human review
artifact evaluation

through Actum Compute.

Compilation remains cognitively directed by Kline.

The market supplies scarce resources.

48. Cognitive Capital Market

K-line artifacts MAY become independently tradeable or licensable cognitive assets.

Potential pricing:

one-time license
per-execution royalty
subscription
organization license
revenue share
free/open source

Lineage SHOULD preserve attribution from source episodes and contributing experts.

49. Expert Attribution

Actum MAY preserve causal contribution chains:

Expert
  ↓
Episode
  ↓
KLineTemplate
  ↓
Compilation
  ↓
Artifact
  ↓
downstream executions

Protocol 0.2 does not mandate downstream royalties but SHALL avoid destroying the metadata needed for them.

50. Reputation

Reputation SHALL be evidence-backed and contextual.

Avoid one universal number.

Possible dimensions:

capability-specific success
proof validity
completion rate
latency reliability
quality under protocol
dispute rate
evaluation independence
availability reliability

51. ReputationClaim

Schema:

{
  "schema": "actum.compute.reputation-claim.v1",

  "subject": "expert:...",

  "capability": "software_engineering",

  "metric": "verified_completion_rate",

  "value": 0.982,

  "population": 1204,

  "protocol": "...",

  "evidence": [],

  "evaluator": "...",

  "issued_at": "...",

  "expires_at": "..."
}

52. Private Reputation

ZeroK MAY allow an expert to prove:

completed_jobs >= 1000

verified_completion_rate >= 0.98

dispute_rate < 0.02

without revealing the underlying customers or jobs.

53. Pricing Models

Actum Compute MAY support:

fixed price
auction
reverse auction
spot pricing
reserved capacity
subscription
per-job
per-time
per-compute-unit
success fee
royalty
revenue share

54. Agent Compute Units

Normalized units MAY help compare heterogeneous execution costs.

An optional AgentComputeUnit MAY incorporate:

provider
model
input size
output size
agent duration
tool execution
context
local compute
energy

However ACU SHALL NOT replace explicit execution quality or model identity where those matter.

55. Quality Differentiation

The marketplace SHALL NOT assume two model outputs are fungible merely because they consume equal compute.

Price discovery MAY differentiate:

model family
model version
quality
provider
evidence
latency
privacy
historical performance
tool access
context

This is fundamental to the expert-market thesis.

56. Latest/Flagship Model Classes

Markets MAY define dynamic classes such as:

current_flagship_coding
current_frontier_reasoning
current_frontier_multimodal

A dynamic class SHALL have:

resolver authority
effective date
provider definition
supersession semantics

Historical executions MUST preserve the exact model label evidenced at execution time.

57. Provider Downgrade Protection

Where model quality is contracted, execution evidence SHOULD prove the disclosed provider/model identifier.

A supplier MUST NOT satisfy:

required: flagship model

with:

cheaper model
cached output
local dummy response

unless the buyer's contract explicitly permits substitution.

58. Supplier Autonomy

The buyer contracts for cognition, not remote interactive ownership of the supplier's account.

The supplier worker SHOULD retain control of:

provider session
sandbox
execution environment
credential storage
resource policy

Interactive execution MAY be supported through bounded protocol commands but SHOULD NOT expose unrestricted host control.

59. Buyer API Surface

The buyer-facing MCP façade SHOULD remain small.

Recommended tools:

compute.search
compute.quote
compute.submit
compute.status
compute.verify
compute.cancel

Optional:

compute.dispute
compute.fetch_result
compute.evaluate

60. Supplier API Surface

Recommended tools:

capacity.status
capacity.configure
capacity.offer
capacity.pause
capacity.jobs
capacity.earnings

Expert-specific extensions MAY be added.

61. Evaluator API Surface

Recommended tools:

evaluation.offer
evaluation.accept
evaluation.submit
evaluation.status

62. Artifact API Surface

Recommended tools:

artifact.search
artifact.quote
artifact.acquire
artifact.verify
artifact.execute

63. Agent Plugin Distribution

Actum Compute SHOULD be distributed through separate Agent Plugins for separate authority domains.

Recommended packages:

actum-compute-buyer

actum-compute-provider

actum-compute-evaluator

actum-compute-artifacts

A combined plugin MAY exist but MUST preserve explicit authority boundaries.

64. Installation Is Not Authorization

Installing a provider plugin SHALL NOT automatically publish capacity.

The provider MUST explicitly create or enable an offer.

Similarly:

installing buyer plugin
≠ permission to spend money

installing evaluator plugin
≠ authority to issue trusted evaluations

65. Agent Plugin Package

Conceptual layout:

actum-compute-provider/
├── plugin.json
├── skills/
│   ├── offer-capability/
│   │   └── SKILL.md
│   ├── configure-reserve/
│   │   └── SKILL.md
│   ├── inspect-jobs/
│   │   └── SKILL.md
│   └── inspect-earnings/
│       └── SKILL.md
└── mcp.json

Plugin manifests SHOULD expose the narrow façade, not internal Actum/TLSNotary/ZeroK complexity.

66. Agent Plugin Skills

Skills SHOULD teach agents semantic workflow.

Example buyer skill:

When external cognition is required:

1. Derive the minimum CapabilityRequirement.
2. Minimize unnecessary data disclosure.
3. Query Actum Compute.
4. Apply local trust/admissibility policy.
5. Request a quote if economic commitment is required.
6. Obtain required authorization.
7. Submit the job.
8. Verify evidence.
9. Validate result.
10. Commit relevant episode evidence to Kline.

67. Kline Integration

Kline SHALL call Actum Compute through capability requirements.

Canonical boundary:

Kline activation graph
        ↓
CapabilityRequirement
        ↓
Actum Compute
        ↓
candidate bindings
        ↓
Cognitive Kernel
        ↓
chosen ExpertBinding

Actum Compute SHALL NOT promote or demote K-lines.

68. Episode Integration

After remote execution, Kline SHOULD record:

ExpertBinding
ExecutionReceipt
Actum ExecutionAct
cost
latency
result commitment
evaluation

inside the corresponding KLineEpisode.

69. System-1 Use of Actum Compute

System 1 MAY invoke Actum Compute when a promoted K-line includes a remote capability requirement.

However local compiled artifacts SHOULD be preferred where they satisfy the same quality and policy constraints at lower total cost.

70. System-2 Use of Actum Compute

System 2 MAY use the market more broadly to:

discover novel experts
try alternative expert combinations
purchase independent critique
buy evaluation
buy evidence
acquire datasets
rent compute
commission artifact compilation

This is where the market primarily finances the cognitive frontier.

71. Higher-Order Market Composition

One ExpertOffer MAY itself resolve internally to several experts.

Example:

ExpertOffer:
    capability = complete_security_audit

Internally:

static analyzer
+
frontier reasoning expert
+
dependency scanner
+
human reviewer

The buyer contracts with the composite expert.

Its evidence SHOULD still expose the assurance required by contract.

72. Recursive Capability Resolution

Actum Compute implementations MAY resolve a requested capability recursively.

Example:

compile_mobile_kline
    ↓
requires:
    model trainer
    evaluator
    GPU compute

Recursive procurement MUST preserve budget and authority constraints.

73. Budget Propagation

Composite jobs SHALL propagate bounded budget.

If:

parent max = €10

subjobs MUST NOT cumulatively exceed the parent authorization unless new authority is obtained.

74. Authority Separation

Actum Compute does not grant application authority.

A purchased expert may produce:

recommendation
proposal
patch
plan

Actual world mutation MAY require separate authorization.

Example:

Expert suggests transfer €500
        ↓
Kline produces proposal
        ↓
authorization system
        ↓
Actum execution

75. Actum as Economic State Substrate

Actum SHOULD record critical market transitions.

Recommended acts:

OfferPublicationAct
JobIntentAct
AssignmentAct
ExecutionAct
EvaluationAct
ArtifactPublicationAct
SettlementAct
DisputeAct
SupersessionAct

Not every ephemeral market query needs to be anchored.

76. Minimal On-Actum Disclosure

Actum SHOULD record commitments rather than unnecessary plaintext.

Typical execution act may expose:

job commitment
assignment commitment
execution commitment
evidence commitment
settlement state

while private job content remains elsewhere.

77. Storage Architecture

Recommended separation:

ACTUM
durable commitments/finality

ZEROK
private proof witnesses

BUYER/SUPPLIER
private job material

OBJECT STORAGE
encrypted artifacts/proofs

KLINE/SURREALDB
local episodes and cognitive state

78. Evidence Retention

Evidence policies MAY specify:

full local transcript retained

portable proof retained

commitment only retained

proof expires

selective disclosure only

Market contracts SHOULD explicitly define evidence retention requirements.

79. Failure Semantics

Failures SHALL distinguish:

provider failure
supplier failure
market failure
evidence failure
quality failure
privacy failure
authorization failure
settlement failure

Each class MAY have different retry/refund semantics.

80. Reassignment

If an assignment fails before irreversible execution, the marketplace MAY reassign to another admissible expert.

The new assignment SHALL receive a fresh challenge.

Old assignment evidence MUST NOT authorize the new settlement.

81. Idempotency

Market mutations SHOULD support idempotency keys.

Operations such as:

create job
accept quote
publish offer
settle

MUST avoid duplicate economic side effects on retry.

82. Economic Nullifiers

At minimum distinguish:

execution_nullifier
settlement_nullifier
evaluation_nullifier

A single nullifier SHOULD NOT be overloaded across unrelated semantic purposes.

83. Market Integrity

Implementations SHOULD mitigate:

wash trading
Sybil suppliers
fake evaluations
collusion
self-dealing
capacity spoofing
benchmark manipulation
evidence replay
price manipulation
front-running

Mechanisms MAY include:

stake
reputation
proofs
delayed settlement
independent evaluation
identity assurance
statistical anomaly detection

84. Open Markets vs Curated Markets

Actum Compute MAY expose:

Open market

Anyone satisfying base protocol requirements may offer capability.

Curated market

Only suppliers satisfying defined trust/evaluation conditions appear.

Private market

Organization-specific suppliers and prices.

The Kline CapabilityRequirement MAY specify acceptable market classes.

85. Jurisdiction

Offers and jobs MAY include jurisdiction constraints.

Examples:

EU execution only
medical data cannot leave Sweden
human evaluator licensed in jurisdiction X
no processing in jurisdiction Y

Enforcement evidence MAY require external attestation.

86. Privacy-Preserving Matching

ZeroK MAY support private matching.

Example:

Buyer proves:

budget >= required price

Supplier proves:

quality >= threshold

without either revealing exact values before match.

This is optional for protocol 0.2.

87. Private Auctions

Future markets MAY support sealed-bid auctions using commitments and ZK proofs.

The base protocol SHALL leave room for this but does not mandate an auction construction.

88. Human Experts

Humans MAY participate as ExpertDescriptors.

Human evidence MAY include:

professional credential
signed work receipt
identity assurance
evaluation history

Human participation is economically equivalent to other scarce cognitive supply, though execution semantics differ.

89. Organization Experts

Organizations MAY publish composite experts representing:

teams
clinics
engineering groups
research organizations
certification bodies

The expert abstraction does not require one executing model or person.

90. Local Experts

A Mind MAY register local experts with Actum Compute or resolve them privately without market publication.

Examples:

on-device model
private RAG
company-internal model
local tool
personal K-line artifact

No marketplace transaction is required for local resolution.

91. Market Fallback

Kline MAY define fallback chains:

local artifact
   ↓ if inadequate
private org expert
   ↓
Actum Compute verified expert
   ↓
frontier provider-specific execution
   ↓
human escalation

Fallback policy belongs to the cognitive template/local Mind.

92. Model Independence Without Model Commoditization

Actum Compute SHALL preserve two apparently opposing properties:

K-line templates can remain vendor-independent.
Execution contracts can demand exact provider/model classes when quality requires it.

This is achieved through late binding plus explicit execution requirements.

93. Verified Model Identity

Where a model identifier appears in authenticated provider traffic, TLSNotary MAY prove the provider returned that label.

The market SHOULD describe this as:

authenticated provider/model-label evidence

rather than proof of hidden server internals.

94. Dynamic Quality Claims

Expert quality SHOULD be updated from evidence-backed evaluations and episodes.

Quality claims SHALL decay or expire where relevant.

A model's performance SHALL NOT be assumed timeless.

95. Market Discovery

Discovery MAY use:

capability taxonomy
semantic search
K-line semantic fingerprints
expert descriptors
evaluation history
price
availability
trust

Discovery results are not automatically admissible.

96. Capability Taxonomy

Actum Compute SHOULD support hierarchical capabilities.

Example:

software_engineering
├── debugging
├── code_review
├── architecture
├── test_generation
└── security_review

Semantic extensions MAY allow expert capabilities to evolve without one centrally controlled ontology.

97. Capability Equivalence

Two capability descriptions MAY be semantically similar without identical IDs.

Resolution MAY use semantic matching, but final binding MUST record the exact requirement and offer that were matched.

98. Evidence Classes

Recommended evidence class vocabulary:

self_attested
signed_runtime
provider_authenticated
tlsnotary
tee_attested
model_hash_attested
deterministic_replay
human_verified
zero_knowledge_verified
actum_finalized

Execution contracts MAY require combinations.

99. Assurance Profiles

Named assurance profiles MAY simplify procurement.

Example:

STANDARD
signed runtime receipt

VERIFIED_PROVIDER
provider-authenticated evidence

VERIFIED_BOUND
provider + request + result binding

CONFIDENTIAL_VERIFIED
verified bound execution + ZeroK settlement

Profiles MUST expand to explicit requirements.

100. Economic Thesis

Actum Compute is not fundamentally a token marketplace.

Its economic object is scarce cognitive capability.

The market finances:

novel reasoning
specialized expertise
evaluation
evidence
training
compilation
compute

As cognition becomes compiled into reusable K-line artifacts, repeated demand for expensive expert execution SHOULD decline.

Capital and expert attention can move toward unsolved frontier problems.

101. Cognitive Capital Flywheel

The canonical economic flywheel is:

UNSOLVED PROBLEM
       ↓
Kline System 2
       ↓
Actum Compute procures scarce experts
       ↓
verified successful Episode
       ↓
KLineTemplate
       ↓
evaluation market
       ↓
promotion
       ↓
Cognitive Compiler
       ↓
KLineArtifact
       ↓
artifact distributed through Actum Compute
       ↓
cheap repeated System-1 execution
       ↓
economic value accumulates around cognitive capital
       ↓
scarce expertise moves to next frontier

102. Why Actum Compute Is Strategically Distinct

Traditional compute markets sell:

CPU
GPU
storage
bandwidth

Traditional model markets sell:

tokens
API calls
models

Actum Compute sells:

verifiable access to problem-solving capability and reusable cognition.

This includes compute but extends above it.

103. Initial MVP Profile

The first interoperable implementation SHOULD remain narrower than the complete protocol.

Recommended Actum Compute 0.2 MVP:

one buyer plugin

one provider plugin

Codex coding expert

Git-based asynchronous jobs

subscription-backed local Codex worker

TLSNotary provider execution evidence

Distill-derived challenge/nullifier gateway

ZeroK settlement adapter

Actum JobIntent / ExecutionAct / SettlementAct

Kline CapabilityRequirement interface

104. MVP User Story — Buyer

The user says:

Continue this coding task using verified flagship coding capability. Spend no more than €3.

Kline creates:

CapabilityRequirement

Actum Compute:

searches
quotes
matches
funds
assigns

A supplier executes.

TLSNotary generates evidence.

Actum finalizes the execution.

Settlement releases.

Kline records the resulting Episode.

105. MVP User Story — Supplier

The supplier says:

Offer my unused verified coding capability while I'm idle. Keep 30% of my capacity for myself and don't accept jobs below €1.

The provider plugin creates:

ExpertOffer

The worker remains locally authenticated.

Jobs execute only while supplier policy permits.

106. MVP User Story — Kline

Kline sees an unfamiliar software task.

No promoted System-1 K-line satisfies it.

System 2 requests:

capability:
    software_engineering

quality:
    frontier

evidence:
    provider_authenticated

budget:
    €3

Actum Compute provides a candidate.

The execution becomes a new KLineEpisode.

Repeated successful episodes may later produce a reusable K-line.

107. Conformance Requirements

A conformant Actum Compute implementation MUST:

accept capability-based demand;
represent supplier offers independently from buyer jobs;
preserve buyer and supplier commitments;
support explicit execution/evidence requirements;
distinguish execution from settlement;
prevent evidence replay;
prevent duplicate settlement;
preserve provider credentials outside portable market objects;
record evidence-bound executions;
integrate with Actum for finalized economic acts;
support Kline CapabilityRequirement;
keep market resolution separate from cognitive activation;
support explicit supplier opt-in;
support lifecycle and expiry of offers and assignments;
preserve exact execution provenance.

108. Recommended Conformance

Mature implementations SHOULD:

support Agent Plugins;
support MCP;
support A2A;
support TLSNotary;
support ZeroK;
support evaluation markets;
support artifact markets;
support private reputation;
support supplier reserve policies;
support multiple economic assets;
support human experts;
support jurisdiction policy;
support composite experts.

109. Security Considerations

Threats include:

credential theft
malicious buyer jobs
supplier sandbox escape
provider impersonation
model downgrade
result substitution
proof replay
settlement replay
fake evaluations
Sybil experts
collusion
market manipulation
prompt injection
data exfiltration
artifact poisoning

Execution workers and evidence verifiers SHALL be treated as security-critical components.

110. Privacy Considerations

Sensitive information MAY exist at every boundary:

buyer → market
market → supplier
supplier → AI provider
execution → evidence service
settlement → Actum

The architecture SHOULD minimize disclosure independently at each boundary.

ZeroK SHOULD be used where public verifiability is required without public disclosure.

111. Relationship to Kline

Kline is the system that asks:

What cognition should become active?

Actum Compute answers:

What supply can satisfy that cognition requirement?

The two SHALL remain separately evolvable.

Actum Compute does not need to understand K-line promotion.

Kline does not need to understand market matching algorithms.

Their primary shared object is:

CapabilityRequirement

and their primary returned fact is:

ExpertBinding

112. Relationship to Actum

Actum Compute is built on Actum.

Actum provides:

verifiable actions
identity
commitments
evidence references
lineage
finality
settlement state
asset transfer

Actum Compute adds:

expert markets
capability resolution
pricing
matching
execution procurement
artifact distribution
evaluation procurement

113. Relationship to TLSNotary

TLSNotary provides one external evidence class.

It is especially valuable where:

provider identity matters
model identity matters
supplier could substitute a cheaper execution

The market treats TLSNotary evidence as an execution assurance asset.

114. Relationship to ZeroK

ZeroK allows Actum Compute to prove:

the market contract was satisfied

without disclosing all underlying commercial or cognitive information.

This permits a public verifiable market with private cognition.

115. Relationship to Agent Plugins

Agent Plugins package Actum Compute for installation into agents.

They provide:

skills
+
MCP façade

They do not replace the underlying protocol.

The same Actum Compute infrastructure MAY therefore be used by:

Codex
Claude
Gemini
other agent runtimes
personal Minds
enterprise agents

116. Architectural Definition

Actum Compute is:

A verifiable market and execution fabric for acquiring, supplying, evaluating, distributing, and settling scarce cognitive capabilities and compiled cognitive artifacts.

Its fundamental transaction is not:

buy tokens.

It is:

resolve and fulfill a capability requirement under explicit quality, evidence, privacy, trust, latency, and economic constraints.

117. Strategic Objective

The long-term objective of Actum Compute is to efficiently allocate scarce cognition at the frontier while allowing Kline to continuously convert successful frontier cognition into reusable System-1 capital.

The relationship is therefore:

ACTUM COMPUTE
allocates scarce intelligence

KLINE
learns from its successful organization

COGNITIVE COMPILER
turns learned cognition into abundance

ACTUM
preserves the verifiable economic and evidentiary history

The economic system should progressively move value creation from repeated token consumption toward the creation, verification, evaluation, and distribution of reusable cognition.

Volume IV should be “Actum Verifiable Cognition Profile 0.1.” That is where we define the actual Actum-side schemas and state transitions for ExecutionAct, EvaluationAct, KLineEpisodeAct, PromotionAct, CompilationAct, ArtifactPublicationAct, SettlementAct, lineage, VSTP mappings, evidence vectors, nullifiers, and how ZeroK/TLSNotary proofs become finalized claims rather than merely marketplace metadata.

Keyboard shortcuts

Distributed Cognitive Network

[ Score = w_q Q