STOKE: the protocol behind the receipt.

Overview

STOKE is the protocol R1 uses to record agent runs. The unit of record is the event; the unit of publication is the graph. Events are content-addressed (their id is a hash of their canonicalised body), and the graph is canonically ordered before signing. Two implementations that follow the spec produce byte-equal receipts for byte-equal runs.

Event types

• THOUGHT. a model's intermediate reasoning step, captured before it becomes a tool call.
• TOOL_CALL. a single tool invocation; carries the canonicalised arguments and a hash of the result.
• MEMORY_READ. an access to one of the four memory tiers; identifies the tier, the key, and the read fingerprint.
• MEMORY_WRITE. a write into a memory tier; carries the tier, the key, the write fingerprint, and the diff hash.
• PHASE_TRANSITION. a gate-checked move between PLAN, EXECUTE, VERIFY, COMMIT.
• GATE_DECISION. a gate's verdict (allow, block, escalate) on a transition.
• ARTIFACT. the materialised output of a phase, with a content hash linking back to its origin events.
• SKILL_AUTHORING_DECISION. one operator decision during a skill wizard session; carries the question id, the answer, the structured interpretation, and the confidence score.
• BEACON_LEDGER_EVENT. one of the beacon-protocol ledger events (registered, claimed, session_opened, command, token_issued, advisory_signed, and similar); carries operator, device, beacon identifiers and the cryptographic provenance chain.

Memory tiers

The harness UI labels these L0..L3; the storage tier names in the codebase are working / episodic / semantic / procedural (see internal/memory/tiers.go). Both vocabularies refer to the same four-tier system.

• L0 identity — storage tier working. The agent's stable identity facts; loaded at session start, immutable within a run.
• L1 critical — storage tier episodic. Task-level decisions and constraints; persists across the four phases of a single task.
• L2 topical — storage tier semantic. The working set for the current phase; high churn, high access locality.
• L3 semantic — storage tier procedural. The long-running content-addressed cache; survives across tasks, deduplicates by hash.

Gate machine

Each phase has an entry gate and an exit gate. Built-in gates ship for syntax, tests, lint, secret detection, policy, and cross-family review. Gates produce a GATE_DECISION event; the harness refuses to record a PHASE_TRANSITION event unless every gate at that transition returned allow or an explicit operator override is present and recorded.

Receipt format

The receipt is the canonicalised event graph plus an Ed25519 signature over its hash. Canonicalisation orders events first by causal predecessor closure, then by content hash. The signing key is configurable: per-agent, per-team, or per-tenant. Verification is a single CLI call: r1 receipt verify path/to/receipt.json.

{
  "spec_version": "1.0",
  "events": [ /* canonicalised event list */ ],
  "signing_key_id": "kid:abc...",
  "signature": "ed25519:..."
}

What is and isn't in scope

The spec covers the event format, the canonicalisation rules, the signing format, and the gate-decision contract. The spec does not cover model selection, tool implementation, prompt content, or budget enforcement. Those are R1 implementation concerns; other implementations are free to differ.

Source

The full spec lives at github.com/RelayOne/r1-agent (the spec moved alongside the agent under the rename). Issues and discussion happen there.

The Beacon Protocol is a sibling protocol that handles secure remote control, cryptographic identity, capability tokens with full RBAC, and Hub-side signed advisories. It composes with STOKE: Beacon-mediated actions are recorded as STOKE events, so a beacon-driven session produces the same content-addressed receipt format as a local session. The Beacon Protocol overview lives at /beacon-protocol/ and the spec repository lives at github.com/RelayOne/beacon-protocol.