Specification v0.1.0-draft

Transport Bindings

How Akashik Protocol messages are carried over different communication layers.

Overview

The Akashik Protocol is transport-agnostic. Operations MAY be carried over any communication layer as long as the message envelope and operation contracts are respected. This specification defines bindings for three common transports.

Native SDK

Direct API calls in the host language. Lowest latency, full feature support, no serialization overhead.

const field = new Field();

// Register
const agent = await field.register({
  id: 'researcher-01',
  role: 'market_researcher',
  interests: ['market size', 'competitors']
});

// Record a finding
const unit = await agent.record({
  mode: 'committed',
  type: 'finding',
  content: 'European HR SaaS market growing at 23% CAGR.',
  intent: {
    purpose: 'Validate market size for go-to-market strategy'
  },
  confidence: {
    score: 0.82,
    reasoning: 'Based on three independent analyst reports.'
  }
});

// Attune
const context = await agent.attune({
  scope: { role: 'market_researcher', max_units: 10 },
  contextHint: 'Drafting competitive analysis section'
});

Characteristics:

Full feature parity with the specification
Supports push-based SUBSCRIBE (WebSocket/SSE)
Supports REPLAY and COMPACT
Recommended for production deployments

MCP Server Binding

Exposes Akashik operations as Model Context Protocol tools, enabling any MCP-compatible agent to use the protocol without a custom SDK.

Tool Mapping

MCP Tool	Maps To	Conformance
`akashik_register`	REGISTER	0+
`akashik_record`	RECORD	0+
`akashik_attune`	ATTUNE	0+
`akashik_detect`	DETECT	1+
`akashik_merge`	MERGE	2+
`akashik_replay`	REPLAY	2+
`akashik_compact`	COMPACT	2+

MCP Limitation: MCP's request-response model cannot support real-time SUBSCRIBE push notifications. MCP-connected agents MUST use polling via ATTUNE with since_epoch.

HTTP REST Binding

A stateless HTTP API for interoperability with any language or platform.

Endpoints

POST /v1/register         → REGISTER
POST /v1/deregister       → DEREGISTER
POST /v1/record           → RECORD
POST /v1/attune           → ATTUNE
POST /v1/detect           → DETECT
POST /v1/merge            → MERGE
POST /v1/replay           → REPLAY
POST /v1/compact          → COMPACT
POST /v1/subscribe        → SUBSCRIBE (returns WebSocket URL for push)

GET  /v1/field/status     → Field overview and capabilities
GET  /v1/agents           → List of registered agents
GET  /v1/conflicts        → Active (unresolved) conflicts

Requirements

All request and response bodies MUST use Content-Type: application/json and conform to the JSON Schema definitions.

HTTP status codes:

HTTP Status	Meaning
`200 OK`	Operation succeeded
`400 Bad Request`	Validation error (e.g., `MISSING_INTENT`)
`401 Unauthorized`	Agent not authenticated (Level 2+)
`403 Forbidden`	Insufficient authority for this operation
`404 Not Found`	Referenced entity does not exist
`409 Conflict`	State machine violation (`INVALID_TRANSITION`)
`500 Internal Server Error`	`INTERNAL_ERROR`
`507 Insufficient Storage`	`STORAGE_FULL`

When an agent calls POST /v1/subscribe, the response includes a WebSocket URL:

{
  "status": "ok",
  "subscription_id": "sub-xyz",
  "websocket_url": "wss://field.example.com/v1/ws/sub-xyz"
}

The agent connects to this URL and receives push notification JSON objects as they are emitted by the Field.

Conformance Levels

Complete requirements for Level 0 through Level 3.

Security

Authentication, authority hierarchy, and memory unit visibility rules.