World-State Consistency for Multi-Author Knowledge Bases

Once a knowledge base grows past a few dozen articles, its biggest enemy stops being writer's block and becomes old articles contradicting new facts: a selection guide still recommending a retired model, a comparison table quoting prices the pricing page has moved past, two tutorials using two generations of the same API's parameters. Multiple authors amplify the problem; AI collaboration pushes it to the extreme, because every writing session starts with no shared memory. GPTMap solves this with a pattern called world-state: one dated snapshot of shared facts, a fixed change-propagation workflow, and as much consistency verification as possible pushed into the build. This article breaks down the full implementation, using this site's 78 articles as the running example (verified 2026-09-03).

1. The Problem: Three Layers of Consistency Failure

• Surface layer: two articles give different numbers (prices, dates, versions). Readers may not remember which was right, but they will remember "this site contradicts itself".
• Middle layer: new articles quote old facts. Every industry event (price cut, shutdown, launch) turns every existing citation of the changed fact into a potential error -- exactly the kind search engines and AI summarizers love to surface.
• Deep layer: AI sessions write independently. Two sessions without shared context can both be "faithful to official sources" and still produce contradictory output, because each verified at a different moment.

All three layers share one root cause: facts have no single, dated, must-read home shared by every author and every AI session.

2. The Snapshot: Shared Facts Only, Always Dated

GPTMap's world-state is a single Markdown file with four kinds of content:

1. Core settings: the current model family, per-tier pricing (including promotional prices and their commitment windows), context and output limits, protocol versions;
2. Status lists: retired products (never recommend again in new writing), the product-side retirement vs API-side shutdown distinction, a competitor watch of the other vendors' current lineups;
3. Propagation rules: the fixed workflow for changing this world (section 3 below);
4. Command-driven lists: statistics that rot are not written as numbers -- the file embeds the generating command.

# world-state snapshot entry format (illustrative)
| Fact | Current value | Verified | Source |
| Sol pricing | $4 / $20 per MTok (promo) | 2026-09-01 | official changelog |

Two formatting disciplines run through the whole file:

• Every fact can answer "when was this verified": a last-verified date sits in the header, and significant changes (price cuts, deprecations) carry their dates inline. This is the same discipline as the "state claims carry verification dates" rule in our Source Verification and Review-Until-Clean: A Fact-Checking Workflow for AI Content, applied at the snapshot level.
• Estimates are labeled at the source: numbers without first-hand sources (some in-product quotas, for example) are marked as estimates inside the snapshot, and articles inherit the label when they cite them.

3. Change Propagation: Three Steps and One Judgment Rule

A fact change (industry event or snapshot correction) triggers a fixed three-step workflow:

1. Edit the snapshot -- change the fact's home before touching any article; reversing the order guarantees misses.
2. Grep and sync affected articles -- search the corpus for the changed item's literal surface (price digits, product names, parameter names) and update every hit. The judgment rule is recommendation context, not mere mention: a name in a news piece or deprecation list is correct (it reports the event); the same name in a selection table, migration advice, or fallback plan is residue. And scan tables by fact class, not row by row -- sibling rows usually share the same facts.

# After a fact change: find every old article citing the changed item
grep -rln '$4 / $20' apps/web/content/posts/
grep -rln 'gpt-5.6-sol' apps/web/content/posts/

3. Sync the living changelog -- this site keeps a continuously updated model-release-log article as the timeline view; if the snapshot changes and it does not, the timeline becomes fiction.

4. Engineering Guardrails: Push Consistency into the Build

Human review cannot hold at scale; anything a machine can verify should not be left to it:

• Two-way assertions: site navigation organizes channels under regions, and the build asserts regions must exactly cover all channels -- adding a channel without a region fails the build outright. This is deliberate: structural omissions must not pass silently and wait for a reader to hit a dead link.
• Frontmatter enum validation: category and content type are constrained enums; invalid values are caught in the write path (a wrong category would otherwise get silently dropped by the reader).
• Scripted link and title checks: internal-link slugs must exist, and link text must match the target file's title verbatim (checked separately for zh and en).

The generalizable principle: for every consistency rule a machine can check, build-time failure beats human review -- while the verification scripts' own outputs get cross-verified, so a script defect cannot masquerade as clean content.

5. AI Collaboration: The Entry Files Are the Worldview

An AI writing session has no cross-session memory, so its entire knowledge of the world comes from three entry materials:

1. The repo README: project positioning, hard constraints (static-only, never push to main directly), available commands;
2. The world-state snapshot: the current fact universe (this article's protagonist);
3. The workflow skill docs: how to write, verify, and review a piece, frozen into triggerable step documents.

The setup's effect is measurable: this site ran daily batches from 2026-08-29 through 09-03, produced by different sessions, with cross-article facts (prices, dates, competitor data) checked in every source-verification pass -- findings were fixed before publish. Consistency does not come from sessions remembering -- it comes from a snapshot they all must read. The competitor watch is a concrete case: launch-day competitor facts enter the snapshot, and later comparison pieces cite the snapshot as their single entry point instead of each remembering on its own.

6. Common Mistakes and Troubleshooting

• Turning the snapshot into an article index: recording what each article says -- it rots faster than anything and serves no reader. Shared facts only.
• Editing articles before the snapshot: the facts' provenance scatters into the articles, and the next change has nothing to sync from.
• "Fixing" every grep hit: legitimate news mentions of past events get "corrected" into errors. Apply the recommendation-context rule.
• Maintaining stale-prone lists by hand: article counts, dates, and aggregates hardcoded into the snapshot or articles. Carry as-of dates, or go command-driven.
• Siding with the snapshot over official sources: the official source wins -- fix the snapshot, then propagate. The snapshot is an index, not the authority.

7. Next Steps

• The full publishing checklist world-state feeds into: The GPTMap editorial checklist: 12 steps to a publishable OpenAI article.
• The verification process for snapshot facts: Source Verification and Review-Until-Clean: A Fact-Checking Workflow for AI Content.
• A snapshot change in action (the competitor watch's first run): OpenAI Ecosystem September 2 Briefing: Anthropic Launches Claude Fable 5.1 / Mythos 5.1, Benchmarks Include GPT-5.6 Sol.
• Maintaining articles after publication: GPTMap Article Maintenance Guide: Re-testing, Version Sync, and Sunset.