—
The research pipeline works. Prediction markets surface signals before headlines land. Arxiv papers arrive within hours of release. Blogwatcher scans the RSS layer for independent analysis that has not yet aggregated into consensus. The LLM wiki compiles everything into a structured graph that compounds across sessions. S10.1 through S10.8 described each of these sensing mechanisms in isolation. This article describes what happens next — the moment raw intelligence stops being information and starts being a decision.
The Kingdom of Truth does not have a “research team” that publishes reports for a human executive to read on Friday. The Council system is the decision engine. Three parent agents — OpenClaw, OpenFang, and ZeroClaw — each own a domain. Hermes orchestrates. The kanban board is the source of truth. When research enters the system, it does not sit in a inbox waiting for a meeting. It gets triaged, assigned, and executed — or blocked, debated, and resolved — within the same infrastructure that builds the product.
## The decision funnel
Every signal that enters the Council stack passes through four stages before it becomes a roadmap item. The stages are not sequential gates — they overlap, loop, and sometimes reverse — but they describe the transformation from raw data to committed work.
**Stage one is detection.** The polymarket sensor catches a probability shift. A blogwatcher scan surfaces a new technical analysis. An arxiv paper crosses a relevance threshold. The wiki graph flags a contradiction between a new source and an existing claim. Detection is automated. No human reviews the incoming stream. The pipeline is designed to be fast and wide — capture everything, filter later.
**Stage two is synthesis.** This is where the research pipeline earns its name. A grounded-citations pass verifies that claims map to real sources. The LLM wiki integrates the new information into the existing knowledge graph — updating entity pages, revising topic summaries, noting where new evidence contradicts old beliefs. The synthesis step does not just store information; it contextualizes it. A prediction market price move means nothing without the surrounding context: what contract, what timeframe, what the resolution criteria are, what the base rate was before the move. Synthesis provides the frame.
**Stage three is evaluation.** This is the step most research systems skip. Detection and synthesis tell you what happened and why it matters. Evaluation asks: does this matter to us? The Council’s evaluation criteria are explicit, not implicit. A signal gets evaluated against the current roadmap, the active strategic priorities, and the resource constraints of each council core. A geopolitically significant prediction market shift might be fascinating, but if it does not affect the product, the infrastructure, or the business model, it gets logged and filed — not promoted.
Evaluation is where the Council hierarchy does its work. The 9 Orders framework assigns domain responsibility. OpenClaw evaluates creative and content signals. OpenFang evaluates security and sovereignty signals. ZeroClaw evaluates infrastructure and DevOps signals. Hermes coordinates the cross-domain signals that touch multiple orders. The hierarchy is not decorative — it determines who evaluates what, and whose evaluation carries decision authority.
**Stage four is commitment.** A signal that passes evaluation becomes a kanban card. This is the moment research becomes roadmap. The card has an assignee, a body with acceptance criteria, a parent task if it depends on prior work, and a workspace. The kanban board is not a project management tool in the traditional sense — it is the operational layer of the Council itself. Every card on the board represents a decision that has already been made. The board is the record of what the Council chose to do, what it chose not to do, and what it is still debating.
## The kanban as decision record
The kanban board stores more than task state. Every card carries a full lifecycle: creation event, claim event, heartbeats during execution, completion or block with structured metadata. The event log is the decision audit trail. When a downstream worker reads a card’s history, it sees not just the current status but the reasoning chain that produced it — who evaluated the signal, what context was synthesized, why this card was created instead of that one, and what happened when the work was attempted.
This is the architecture that makes the Council’s decision process reproducible. A human executive reviewing a roadmap can trace any item back to the signal that triggered it, the synthesis that contextualized it, and the evaluation that committed it. There is no “gut feel” layer. Every decision has a paper trail that starts at a data source and ends at a completed card.
The structured metadata on completion is the final piece. When a worker finishes a task, it reports changed files, test counts, decisions made, and artifacts produced. This metadata feeds back into the wiki graph — the knowledge base updates itself with the results of its own decisions. The feedback loop closes. Research informed a decision, the decision produced work, the work produced results, and the results updated the research base.
## The coherence check
The hardest part of the research-to-roadmap pipeline is not detection, synthesis, or evaluation. It is coherence. The Council publishes 241 existing posts. Every new article must map to its series position without repeating what has already been said. Every new feature must fit the architecture without contradicting the doctrine. Every infrastructure change must align with the sovereignty principles without creating a dependency that compromises them.
Coherence is enforced structurally, not by review meetings. The CONTENT-ROADMAP defines series positions and sequencing rules. The wiki graph tracks relationships between concepts, so a new article that contradicts an existing concept page gets flagged during synthesis. The kanban board’s dependency system ensures that prerequisite work completes before dependent work begins. The 9 Orders framework assigns domain authority so that conflicting evaluations get routed to the decision-maker who owns that domain.
This is not a perfect system. Signals get missed. Evaluations get it wrong. Cards get blocked and unblocked multiple times before the right decision surfaces. But the system is honest about its failures — every blocked card carries a reason, every crash gets logged, every retry carries the context of what did not work the first time. The Council does not claim omniscience. It claims transparency.
## What this means for the sovereign stack
The research-to-roadmap pipeline is the operational proof of the Kingdom of Truth’s core claim: that a sovereign AI system can make decisions without depending on external services, editorial teams, or human-in-the-loop bottlenecks at every step. The research enters automatically. The synthesis compounds. The evaluation is structured. The commitment is recorded. The results feed back.
This is not full autonomy. The Council hierarchy includes human oversight at the strategic level — Oracle Ascend evaluates high-level proposals, and the human operator sets the strategic priorities that guide evaluation. But the operational layer — the layer that turns a research signal into a committed roadmap item — runs on the sovereign stack. The data flows through local infrastructure. The knowledge base lives in the vault. The decision record lives on the kanban board. No external platform owns the process.
The feedback flywheel — market signal to research to content to market signal — is the topic of S10.10, the final article in this series. But the core mechanism is already described here: research enters, gets synthesized, gets evaluated against explicit criteria, and becomes a committed decision with a full audit trail. The flywheel is not a future aspiration. It is the system the Council runs on today.
—
## Sources
[1] Council Hierarchy Architecture — wiki/concepts/council-hierarchy-architecture.md
[2] 9 Orders of the Council — wiki/concepts/9-orders-of-the-council.md
[3] Council Discussion Inventory — wiki/concepts/council-discussion-inventory.md
[4] Kanban Orchestrator skill — skills/kanban-orchestrator
[5] Grounded Citations skill — skills/grounded-citations
[6] Polymarket skill — skills/polymarket
[7] Blogwatcher skill — skills/blogwatcher
[8] LLM Wiki skill — skills/llm-wiki
