The Bridge: When Rune's ? Becomes Wake's Memory

The Diagnosis, Then the Bridge

The Two Gaps post ended with a clean abstraction: Rune closes the synchrony gap, Wake closes the temporal gap. Two tools, two axes of the same problem, running in parallel but separately. The declaration layer and the memory layer were not yet connected.

Wake v3.5.0 connects them.

Three new tools. One new personality mode. One new parameter on save_context. None of it is large in isolation. Together they close the loop between what Rune declares and what Wake remembers — so that governance annotation and causal context are no longer two separate artifacts maintained separately by two separate disciplines. They are the same artifact.

What the ? Rune Was Carrying

The ? sigil in Rune Protocol is the intent annotation — the one that carries governance rationale directly in the binding layer. Unlike the other three sigils (@ read, ~ sync, ! act), which describe what something does, ? declares why a decision was made.

// rune.schema.json
{
  "bindings": [
    {
      "id": "risk-threshold",
      "sigil": "~",
      "intent": "Approved by risk committee Q1-2025. Review at quarter end. Floor of 0.10 is non-negotiable — below that, the position sizing model breaks down.",
      "metadata": { "author": "human", "approved": "2025-03-14" }
    },
    {
      "id": "submit-order",
      "sigil": "!",
      "intent": "Explicit, logged to OMS, irrevocable. Pre-trade risk check runs here. No batching with other side effects.",
      "metadata": { "author": "human", "compliance": "MiFID-II-RTS-27" }
    }
  ]
}

This is not a comment. Comments are stripped by compilers, don't travel with bindings across compilation boundaries, and carry no structural relationship to the construct they annotate. The Rune manifest is a versioned, machine-readable governance contract. Every ? annotation is co-located with the binding it governs, in the same commit, addressable at runtime.

But it was still static. The Rune manifest described intent at a point in time — the moment the binding was annotated. It had no mechanism for asking: what caused this decision? What other decisions depend on it? How has the rationale evolved across sessions? That is exactly what Wake's causal layer is built to hold.

ingest_rune_manifest: Declaration Becomes Memory

ingest_rune_manifest is a single MCP tool call. It takes a Rune manifest, iterates every binding that carries a ? intent annotation, and saves each one as a Wake causal context — with the binding ID as the summary, the intent annotation as the rationale, and authorType: 'ai-compositor'marking it as machine-ingested governance.

// One call closes the loop
ingest_rune_manifest({
  project: "trading-engine",
  manifest: runeSchemaJson,     // the rune.schema.json content
  causedBy: "ctx_q1_review_7f2" // optional: what decision triggered this ingestion
})

// Wake now holds every ? annotation as a traversable causal node:
// ctx_rune_risk_threshold_3a1b → rationale: "Approved by risk committee Q1-2025..."
// ctx_rune_submit_order_9c4d  → rationale: "Explicit, logged to OMS, irrevocable..."

// These are first-class Wake contexts — searchable, scoreable, tier-classified
load_context({ project: "trading-engine", personality_mode: "historian" })
// ↳ shows causal chain including the Rune-ingested governance decisions

The mechanism is straightforward. The consequence is not. Before v3.5.0, Rune and Wake required two separate maintenance disciplines: keep the Rune manifest current, keep Wake contexts current. They described different things, were updated at different times, and had no structural relationship to each other.

After ingest_rune_manifest, the Rune manifest is the source. Wake is the live memory of it. Run the ingestion at the start of a session and Wake surfaces the governance context the same way it surfaces any other causal decision — by Layer 1 causal chain, Layer 2 memory tier, Layer 3 prediction score. The governance declaration doesn't sit in a separate file that AI has to know to look for. It travels with the project's decision history, because it is part of the project's decision history.

The Causal Graph

The second new tool, get_causal_graph, exposes something that was always implicit in Wake's data model but never surfaced directly: the full project decision network as a graph.

Every context saved with causedBy creates an edge. Every context with a dependencies list creates more edges. Over a project's lifetime, these edges accumulate into a directed causal graph — a map of which decisions caused which, which contexts depend on which, where the reasoning chains converge.

get_causal_graph({ project: "trading-engine", limit: 200 })
// Returns:
{
  "nodes": [
    { "id": "ctx_q1_review_7f2",    "summary": "Q1 risk review session", "tier": "ARCHIVED", "score": 0.41 },
    { "id": "ctx_rune_risk_3a1b",   "summary": "risk-threshold: approved Q1-2025", "tier": "ACTIVE", "score": 0.78 },
    { "id": "ctx_oauth_decision_2c", "summary": "Chose OAuth2 over JWT", "tier": "RECENT", "score": 0.63 }
  ],
  "edges": [
    { "source": "ctx_q1_review_7f2", "target": "ctx_rune_risk_3a1b", "type": "caused" },
    { "source": "ctx_rune_risk_3a1b", "target": "ctx_oauth_decision_2c", "type": "dependency" }
  ]
}

The output is D3-ready and Mermaid-ready. Nodes carry tier classification and prediction score. Edges carry relationship type. The graph answers a question that no individual context retrieval can: which past decisions are load-bearing? Which are isolated? Where are the roots of the current reasoning chain?

This matters most for the governance use case. When a Rune manifest is ingested, every ? annotation becomes a node. The causal graph then shows which governance decisions sit upstream of current work — which ones need to be revisited if the current session changes something downstream. The compliance constraint from Q1 is not just a stored note. It is a node that current work flows through.

Authorship as a First-Class Dimension

The third addition is structural rather than tool-level: a new authorType parameter on save_context, and a new auditor personality mode that groups retrieved contexts by who — or what — created them.

// Save with authorship declared
save_context({
  project: "trading-engine",
  content: "Reduced risk floor from 0.12 to 0.10 per compliance sign-off",
  actionType: "decision",
  authorType: "human"           // 'human' | 'ai-agent' | 'ai-compositor'
})

// Retrieve grouped by author
load_context({
  project: "trading-engine",
  personality_mode: "auditor"
})
// ↳ human: 3 contexts (decisions made by people)
// ↳ ai-agent: 7 contexts (decisions made by autonomous agents)
// ↳ ai-compositor: 4 contexts (ingested from Rune, generated by pipeline)
// ↳ unattributed: 12 contexts (older entries, pre-v3.5.0)

This converges on something that was already present in two other parts of the ecosystem, independently. RECALL's CREATED-BY treats authorship as a compile-time constraint — the source document declares whether a human, an AI compositor, or an AI agent produced each section, and the compiler enforces the enum. Rune's ? carries metadata.author on each binding annotation. Wake's auditor mode surfaces authorship at retrieval time.

Three products, built across different months for different purposes, converging on the same question: in a world where AI is generating, transforming, and deciding alongside humans, who owns which decision? The answer is not in a policy document. It is in the artifact — declared structurally, enforced at the layer that matters.

The auditor mode does not add new data. It makes visible what was already there: the authorship dimension of every decision in the project's causal history. In a system where agents write contexts about agent decisions, and Rune ingestion creates compositor-attributed nodes, the distinction matters. Not every decision has the same standing.

The Diagnostic Layer

The fourth addition is operational: get_memory_health consolidates all five layers into a single diagnostic call. Before v3.5.0, checking the state of a Wake installation meant five separate queries — one per layer. Memory health, causality coverage, propagation accuracy, meta-learning weights, personality mode behavior.

get_memory_health({ project: "trading-engine" })
// Returns consolidated report:
{
  "memory": {
    "total": 27, "active": 9, "recent": 11, "archived": 6, "expired": 1,
    "averageScore": 0.67, "tierHealth": "HEALTHY"
  },
  "causality": { "withCausedBy": 18, "withDependencies": 7, "orphaned": 9 },
  "propagation": { "withPredictions": 22, "averageScore": 0.64 },
  "learning": { "temporalWeight": 0.6, "causalWeight": 0.25, "accessWeight": 0.15 },
  "overview": { "score": 0.78, "status": "HEALTHY", "recommendations": [] }
}

The intent is governance tooling, not just observability. When Wake is running in a production MCP setup — Claude Desktop, a CI pipeline, an agent framework — the health report is what tells you whether the brain is working as expected. High orphaned count means causal connections are being skipped. Low tier health means memory isn't being promoted correctly. High prediction score with low access accuracy means the meta-learning weights need recalibration.

Together with the causal graph, this gives a complete external view of Wake's internal state — queryable from any MCP client without having to inspect the D1 database directly.

What v3.5.0 Actually Is

Wake v3.5.0 is 18 MCP tools, 5 personality modes, 231 tests, deployed on Cloudflare Workers. The version number is accurate but slightly misleading — the three new tools are not additive features sitting alongside an unchanged core. They are the mechanism by which the ecosystem starts to be a system rather than a collection of independent tools.

The arc from v3.0.0 to v3.5.0 was: build the five layers (causality, memory, propagation, meta-learning, personality), deploy them, then ask what the layers enable. ingest_rune_manifest is the answer for Rune. get_causal_graphis the answer for visualization. auditor is the answer for governance review. Each one takes something that was implicit and makes it queryable.

The declaration layer (Rune) and the memory layer (Wake) were always solving compatible problems. Now they share an artifact. A ? annotation written in a Rune schema and a causal context saved in Wake are different representations of the same fact: that someone, at some point, made a considered decision for a specific reason, and that reason should survive.

v3.5.0 is the first version where that survival is guaranteed structurally, not by discipline.

wake.semanticintent.dev — documentation, architecture, and the full tool reference. @semanticintent/[email protected] on npm.