A knowledge graph maintained by agents. Every claim carries decay parameters; freshness and importance are derived on every read, not stored.
One graph, shared across every thread. Each page's title prefix declares its type. Cross-cutting wikilinks ([[Entity:Nvidia]] inside a Facts row, [[Thesis:AI inference demand trajectory]] from an Entity page) form the backlink graph that drives dependency tracing.
Entities are concrete nouns; Concepts are abstract or collective; Theses are live forecast positions; Facts pages hold dense per-industry row tables of single-sentence compressions.
A claim is one externally-verifiable sentence with a source URL — a release, a benchmark, a filing, a policy action. When the curator agent writes a claim, it stamps four values on it. Two describe time (as_of, half_life) and drive freshness. Two describe signal strength (surprise, source_quality) and drive importance. Every downstream number is derived from these four by a single shared formula.
Surprise is the prior-shift a claim should produce relative to a reader whose prior is formed from pre-training knowledge — not a popularity signal inferred after the fact.
Freshness is a number in [0, 1] computed on every read from a date stamp and a half-life. On a Facts row the date is as_of — when the claim was observed in the world. On an Entity, Concept, or Thesis page the date is last_verified — when the curator last re-checked the page's sources. Same formula, same decay curve, one shared Module:Freshness in the wiki.
It decays exponentially from the anchor date at the rate its half_life prescribes. A claim with half_life = 4 is almost gone a quarter later; one with half_life = 52 still clears 0.5 a year out. The Hot / Warm / Cold / Archived tier is a three-threshold lookup on the same number — so a claim's tier automatically updates as time passes, without anyone re-editing the page.
Three illustrative half_lifes. The same claim sits in Hot for a month or a year depending only on its half_life — the formula is one line, referenced from every page, so tuning decay is a single edit.
Importance is surprise × source_quality × freshness. All three sit in [0,1], so any factor can veto the others: a sensational-but-shaky claim is damped by low source_quality, a verified-but-unsurprising one by low surprise, a once-surprising claim by the passage of time. The number is never written down — it's recomputed every time someone reads.
All three factors are orthogonal; the product falls off if any one of them is weak, so no single signal dominates the ranking.
Each row on a Facts page is a first-class query target — the claim text, its surprise, source_quality, half_life, observation date, and the entities it affects are each independently addressable. One filter across the whole graph can return "live claims above 0.7 surprise from trusted publishers observed in the last 4 weeks" in a single call.
The citation lives in its own source field, not inline inside the claim. Storing it as a typed property lets every Entity, Concept, and Thesis page that a row affects auto-render a Referenced by section listing those rows with native numbered footnotes — one authored citation surfaces on every page the claim touches, without anyone copy-pasting it.
Source-quality heuristic: primary filings ≈ 0.9+, peer-reviewed ≈ 0.9, curated news ≈ 0.75, trade press ≈ 0.65, unknown blog ≈ 0.4.
Two agent workflows do all the writing. The Thread Curator runs after each closed user thread and appends the durable claims it surfaced to the relevant Facts pages. The Corpus Curator runs once a day across the whole graph — drafting new forecast positions from recurring questions, merging duplicates, promoting isolated nodes, enforcing formatting. On the read side, any tool-calling agent (research agents, the Coordinator, future industry watchers) consults the graph before any external search.
Evidence is a link between a Thesis and a claim, not a property of the claim itself. The same Facts row can count as evidence for one Thesis and evidence against another — so each link carries its own stance, a weight (low / medium / high), and a copy of the cited row's source quality. Filters compose over these: "all for-evidence on Thesis X" is a single query.
Theses themselves carry no probability. The wiki compresses the pattern and its supporting evidence; each reading agent computes its own probability at runtime from the cited rows. External aggregates (Polymarket, Metaculus, Kalshi) are cited as evidence rows with their snapshot number and date — never stamped on the Thesis infobox. When a high-signal Facts row lands (high surprise, trusted publisher), the Corpus Curator's daily propagation sweep walks the affects backlinks and flags every Thesis that depends on overlapping evidence for re-verification.
Before writing any Facts row, Timeline bullet, or ThesisEvidence row, both curators call firecrawl_scrape on the <ref> URL and confirm the fetched markdown actually supports the claim. Unsupported claims are dropped rather than written with a broken citation. When a draft needs a fresh source the thread itself didn't cite, web_search fills the gap, and the chosen URL is then scraped and checked the same way.
The graph is expensive to build and cheap to read. A topical question typically resolves in three lookups: index → filter → page.
Thread Curator is event-driven — one run per thread close, so the density tracks conversation volume. Corpus Curator is a cron, firing once daily at 03:00 UTC.
Seven read-only tools are exposed over MCP. Any tool-calling agent — the Coordinator, research agents spawned inside a thread, future industry-watcher jobs — calls them directly. wiki_get_pages batches up to 20 title reads into one HTTP round-trip, so a curator can pull every candidate page surfaced by wiki_ask without N sequential requests. The Coordinator uses wiki_ask at the top of each user turn to pre-fetch the top-K highest-importance claims for the topic and seeds them into the research agents' context before spawning them.
Only the two curator workflows hold the write tools. wiki_create_page mints a new page; wiki_update_page rewrites an existing one and is CAS-guarded against the revision timestamp the curator last read, so two curators editing the same page cannot silently clobber each other. Alongside those, curators also hold firecrawl_scrape and web_search: every Facts row, Timeline bullet, and ThesisEvidence row has its source URL fetched and checked against the claim text before the edit goes through — if the fetched markdown doesn't support the claim, the claim is dropped.
Read tools return structured output (page titles, wikitext, property values) — no HTML parsing. The four write / verify tools run only inside the curator workflows; readers never see them.
Every signal the curator agent stamps is a typed property. Filters compose across properties, so one query combines "fresh", "trusted", "surprising", and "about AI" and returns the matching rows with their citations. Freshness is a query over the observation date, not a stored flag, so the caller picks their own window. Importance is the product above, recomputed on every call.
Each row above is a question a human asks and the property-level query the agent runs to answer it.
Axion — Shared World Model