The Fan-Out Architecture: Compiling Truth for Budgeted Agents

Standard web architecture was designed for eyeballs (rendering). Agents need something else: facts they can lift without guessing.

A retrieval pipeline doesn’t “read” your site the way a person does. It fetches, parses, keeps a few passages, and drops the rest. If a fact sits in one sentence and its conditions sit three paragraphs away, the passage that survives may carry only half of it.

The common advice is still the same: publish a hub, publish spokes, and “the model will assemble the answer.”

Runtime reality is uglier. Even long-context, tool-capable systems answer under budgets: tokens, latency, retrieval limits, and the cost of assembling evidence. When a condition doesn’t make it into the context, the system can only leave it out or fill the gap.

Here’s the whole thesis, with no mystery:

You keep writing pages. You compile the facts inside them into small, machine-readable records, so search engines and AI systems have less to guess.

The target isn’t “Search” alone. It’s ingestion: what a system can extract, keep, and attribute to you.

Under a fixed budget, density matters. That is the design pressure this architecture answers.

What This Looks Like on a Normal Business Website

If you already have a website, most of the source material exists.

This does not replace your website.

There is no AI runtime system. No special “LLM mode.” No parallel “machine site.”

This is a build-time compilation layer:

• You keep your normal pages: services, pricing, case studies, docs, FAQs.
• You add one source file that pins your identity, scope, and offers.
• During the build, the same facts render into page copy and into machine-readable outputs.
• You embed matching structured data on the canonical pages. That is the path Google documents (Google Search Central: intro to structured data, accessed 2026-10-18)², not a guaranteed one: Google says structured data makes a feature possible without guaranteeing it (structured data policies, accessed 2026-10-18)¹, and that AI Overviews and AI Mode need no special schema, machine-readable files, or AI text files (AI features and your website, accessed 2026-10-18)³.
• Optionally, you export the records as JSON for integrators and agent systems that want contracts and versioning.
• Discoverability isn’t magical: link the export from your developer docs or the page <head>.

Nothing “thinks” at runtime. Nothing assembles a graph live. It’s compilation, export, and stable IDs.

What this site runs today

Own-site work, checked on 2026-10-18 against this site’s repository and the live pages:

• src/data/entity.ts is the source of truth. pnpm sync:entity writes public/entity.json from it, and pnpm check fails when the two drift apart.
• Pages and articles read facts through getEntityValue() and <EntityValue>, and declare them with <AAOMarker>.
• The build stops when an answer object lacks an ID, a value, or a source URL.
• The site publishes one export, /entity.json, plus an audit packet at /audit/argbe_tech.json. It does not publish per-page exports such as /contact.json. The per-page examples below show the pattern, not this site’s current output.
• The build does not yet check that each value is visible on its source page. The walkthrough adds that gate and shows it failing on this site.

Prerequisites

• A build step you control (Astro, Next.js, Hugo, or similar) and a CI job that can fail a deploy.
• One owner for the facts that must not drift: pricing model, scope, regions, response commitments.
• A current Node.js LTS release to run the gate script below as written. It uses the built-in fetch and has no dependencies.
• Facts that are true. The compiler copies what you give it; it doesn’t make a claim true.

Walkthrough: One Page, Two Claims, Two Outputs, One Gate

Take a normal page like /contact. This matters: every record should point to a real, canonical page URL.

1. Write two visible claims on the page and give them stable IDs:
   • pricing.model → “Fixed weekly rate”
   • availability.regions → “DACH + United States”
2. The build emits machine surfaces from those same claims:
   • JSON‑LD on the canonical HTML for crawlers that read structured data
   • An optional export (/contact.json) for integrators and agent systems
3. CI enforces: no visible source → no emit → no ship.

This is the record this site actually publishes for the pricing claim, copied from /entity.json on 2026-10-18:

{
	"id": "pricing.model",
	"value": "Fixed weekly rate",
	"source_urls": ["https://argbe.tech/", "https://argbe.tech/contact"]
}

A record earns its keep when it carries its conditions. This one is hypothetical, but its field names match this site’s AAO type:

{
	"id": "pricing.nonprofit_rate",
	"value": 50,
	"currency": "USD",
	"period": "month",
	"constraints": ["Registered non-profit organizations only", "Billed annually"],
	"source_url": "https://example.com/pricing#nonprofit-rate"
}

Example JSON‑LD for the canonical page. This is an illustrative pattern: PropertyValue is valid schema.org vocabulary, but Google documents no search feature that reads it this way, and this site doesn’t emit it on /contact today. For Google, describe the page with the documented types that match it (Organization, Service, Offer, Article) and keep custom fact records in the export.

{
	"@context": "https://schema.org",
	"@type": "WebPage",
	"@id": "https://example.com/contact",
	"url": "https://example.com/contact",
	"mainEntity": [
		{
			"@type": "PropertyValue",
			"propertyID": "pricing.model",
			"value": "Fixed weekly rate",
			"url": "https://example.com/contact#pricing.model"
		},
		{
			"@type": "PropertyValue",
			"propertyID": "availability.regions",
			"value": ["DACH", "United States"],
			"url": "https://example.com/contact#availability.regions"
		}
	]
}

Example per-page export (/contact.json), again the pattern rather than this site’s output:

{
	"canonical_url": "https://example.com/contact",
	"aaos": [
		{
			"id": "pricing.model",
			"value": "Fixed weekly rate",
			"source_url": "https://example.com/contact#pricing.model"
		},
		{
			"id": "availability.regions",
			"value": ["DACH", "United States"],
			"source_url": "https://example.com/contact#availability.regions"
		}
	]
}

One discoverability line is enough:

<link rel="alternate" type="application/json" href="https://example.com/contact.json" />

This is a hint, not a standard. The documented path is JSON‑LD on the canonical HTML plus an export your developer docs describe.

The gate: check every record against its visible source

This site’s build checks the shape of each record. It doesn’t check that the value appears on the page the record cites. This script closes that gap: it fetches entity.json, fetches each source page, strips scripts, styles, and tags, and fails when a text value is missing from what’s left.

// check-aao-visibility.mjs — Node 18+ (built-in fetch), no dependencies.
// Usage: node check-aao-visibility.mjs <entity.json URL> [aao.id ...]
// Fails (exit 1) when an AAO's text value is missing from the visible text of its source page.
const [entityUrl, ...onlyIds] = process.argv.slice(2)
if (!entityUrl) {
	console.error('Usage: node check-aao-visibility.mjs <entity.json URL> [aao.id ...]')
	process.exit(2)
}

const pageText = new Map()
async function visibleText(url) {
	const pageUrl = url.split('#')[0]
	if (!pageText.has(pageUrl)) {
		const html = await (await fetch(pageUrl)).text()
		const text = html
			.replace(/<(script|style|template)\b[\s\S]*?<\/\1>/gi, ' ')
			.replace(/<[^>]+>/g, ' ')
			.replace(/&amp;/g, '&')
			.replace(/\s+/g, ' ')
			.toLowerCase()
		pageText.set(pageUrl, text)
	}
	return pageText.get(pageUrl)
}

const entity = await (await fetch(entityUrl)).json()
let failures = 0
for (const aao of entity.aaos ?? []) {
	if (onlyIds.length && !onlyIds.includes(aao.id)) continue
	const sources = aao.source_urls ?? (aao.source_url ? [aao.source_url] : [])
	const values = (Array.isArray(aao.value) ? aao.value : [aao.value]).filter(
		(v) => typeof v === 'string'
	)
	if (values.length === 0) {
		console.log(`SKIP ${aao.id}: non-text value ${JSON.stringify(aao.value)}`)
		continue
	}
	for (const source of sources) {
		const text = await visibleText(source)
		const missing = values.filter((v) => !text.includes(v.toLowerCase()))
		if (missing.length) {
			failures++
			console.log(`FAIL ${aao.id}: ${JSON.stringify(missing)} not visible on ${source}`)
		} else {
			console.log(`PASS ${aao.id}: visible on ${source}`)
		}
	}
}
console.log(failures ? `${failures} failure(s): do not ship` : 'All text AAOs visible')
process.exitCode = failures ? 1 : 0

Run against this site on 2026-10-18:

$ node check-aao-visibility.mjs https://argbe.tech/entity.json pricing.model availability.regions audit.schema_version
FAIL availability.regions: ["United States"] not visible on https://argbe.tech/
FAIL availability.regions: ["United States"] not visible on https://argbe.tech/contact
PASS pricing.model: visible on https://argbe.tech/
PASS pricing.model: visible on https://argbe.tech/contact
FAIL audit.schema_version: ["argbe.audit_packet.v1"] not visible on https://argbe.tech/audit
3 failure(s): do not ship

That is a real failure, and the useful kind. The golden record says “United States”; the home and contact pages say “US.” A model reading the export and a person reading the page see different strings for the same fact. Either the copy changes or the record does, and until one of them does, the gate blocks the deploy. The audit.schema_version failure is the same drift somewhere else: the record cites a page that never shows the value.

Know the gate’s limits. It is a substring match, so it catches drift but can’t judge meaning: “US” and “United States” are the same fact to a reader and a mismatch to the script, which is why one canonical spelling belongs in the record. It skips non-text values such as booleans and numeric ranges; those need a rendering rule of their own. It reads server HTML, so text that only client JavaScript renders counts as missing. Point it at a preview deploy in CI if you want it to block a release rather than report on production.

What “Entity-Driven” Looks Like in MDX (getEntityValue)

If your article needs to reference stable facts (brand name, markets, pricing model), don’t hardcode them. Derive them from the golden record so they can’t drift.

Entity Path	Example Render
identity.brand_name	Argbe.tech
markets.regions	DACH, United States
pricing.model	Fixed weekly rate

In plain MDX, you can also call the helper directly:

{brandName} serves {regions.join(' + ')}.

What “AAO-Backed” Looks Like on a Page (AAOMarker)

The compiler needs a stable, machine-readable declaration of the claim on the canonical page. That’s what <AAOMarker> is for. It renders a visually hidden <data> element carrying the ID, value, and source URL, placed next to the visible sentence that states the same fact.

This article embeds two real markers, so parsers can lift the IDs and values without guessing:

• Pricing model: Fixed weekly rate Fixed weekly rate
• Regions: DACH + United States ["DACH","United States"]

Example (on /contact or any canonical page section):

Our pricing model is a fixed weekly rate.

<AAOMarker id="pricing.model" />

We serve DACH + United States.

<AAOMarker id="availability.regions" />

The Three Layers of Truth

This only works if you hold a hard line:

• Entity = source of truth
• Packets = compiled facts, not new content
• API = export layer, not the primary discovery surface

Entity: the single source of truth

Start with one record. Treat it like package.json for your company:

• identity (name, brand, legal)
• scope (what you do / don’t do)
• offers (what you sell, constraints, pricing policy)
• locales (regions, languages, availability)

It’s internal. It’s boring. That’s the point: it stabilizes everything else.

Example sketch (YAML for readability; this site keeps the record in a TypeScript module and generates entity.json from it):

version: 1
last_updated: '2026-10-18'
identity:
  brand_name: 'Example Co.'
  canonical_url: 'https://example.com'
  languages: ['English', 'German']
markets:
  regions: ['DACH', 'United States']
pricing:
  model: 'Fixed weekly rate'

Pages: human canonical truth

Your pages stay primary:

• SEO and conversions live here
• navigation and persuasion live here
• context and nuance live here

Pages still own the truth. Packets do not invent facts. Packets don’t “improve” copy. Packets are compiled artifacts of what the page already says.

Packets and exports: machine truth

Packets are:

• extracted (from pages, plus entity constraints that already govern those pages)
• normalized (same structure every time)
• bounded (small enough to survive budget pressure)

The export layer produces alternate representations of the same truth:

• JSON‑LD embeds on canonical pages (machine-liftable facts with URLs)
• API exports (contract + versioning + bounded payloads)

Same truth, different packaging.

And to be explicit: packets do not replace pages. They make your pages easier to cite under a budget.

Packets, in Plain Terms

A packet is not new content. A packet is a compiled fact already stated on your site.

Concrete example. On your contact (or pricing) page, you write:

“Our pricing model is a fixed weekly rate.”

At build time, that sentence becomes a bounded object with a stable ID:

• pricing.model
• value normalized ("Fixed weekly rate")
• scope attached (if needed: eligibility, exclusions, effective dates)
• canonical source URL attached (the canonical page fragment)

That object is then emitted as:

• a JSON export for integrations (for example, /api/packets/pricing.model.json)
• a JSON‑LD embed for search, injected into the canonical page HTML

Only after you see the example do we name it: this bounded object is an Atomic Answer Object (AAO). AAOs are the units a budgeted system can afford to retrieve and cite.

The Kill Box: Why “Chunks” Fail

Many retrieval pipelines slice text into fixed-size chunks. Chroma’s evaluation found the then-default OpenAI Assistants settings (800-token chunks with 400-token overlap) among the least precise configurations it tested (Smith and Troynikov, Evaluating Chunking Strategies for Retrieval, Chroma, accessed 2026-10-18)⁹.

A sentence sliced away from its header loses its constraints. Price is $50 is a lie if the chunk lost the header For Non-Profits Only.

The Atomic Answer Object (AAO) is the smallest unit of truth that carries its own constraints (scope, eligibility, exceptions, effective dates) wherever it travels.

Retrieval Unit	What It Is	Failure Mode	What Survives Under Budget
Raw text chunk	A slice of prose	Constraints get orphaned; meaning mutates	Words, not truth
AAO	A bounded claim + constraints + source URL	Harder to write; easier to validate	A citeable fact

The API Is an Export Layer (Not Discovery)

APIs don’t “replace pages.” They don’t exist to be the primary thing crawled.

APIs provide:

• contracts (a predictable shape)
• versioning (explicit changes)
• bounded exports (small enough to pull under budget)

Required rules:

• Pages remain canonical.
• API routes mirror packet IDs.
• Every export points back to a canonical page URL.
• No new truth lives in the API.

If a packet only exists in an API and not on a page, it’s a ghost.

The Mirrored Output Pattern (Dual‑Head)

Stop treating “content” as text and start treating it as Data with a Skin. One source → two outputs, so an important URL becomes a Dual‑Head Node:

• The Human Head (HTML): https://example.com/contact, optimized for reading, design, and persuasion.
• The Machine Head (JSON): https://example.com/contact.json, the AAOs with their constraints and source URLs.

You do not write two websites. You add a compilation step. Agents shouldn’t have to parse your DOM to find your price. Give them the JSON. It makes you cheaper to check.

Why it helps

• Token economy: the pricing record on this site is a tiny fraction of the contact page that states the same fact (measured below). A system that can fetch the record doesn’t have to parse the page to find the price.
• Context preservation: the constraints field travels with the value. Disclaimers stop being “optional” because they’re structurally bound to the claim.
• Less drift: where page copy and export read from the same record, they can’t disagree. Where page copy is hand-written, they can, and the gate is what catches it.

$ curl -s https://argbe.tech/entity.json | jq -c '.aaos[] | select(.id=="pricing.model")' | wc -c
     118
$ curl -s https://argbe.tech/contact | wc -c
   73528

Measured on 2026-10-18. Byte counts, not tokens; the ratio is the point.

Compliance & SEO Guardrails

Fan‑Out only works long-term if it stays inside search and structured-data rules:

• Structured data must reflect visible page content. Google’s policy: “Don’t mark up content that is not visible to readers of the page” (structured data policies, accessed 2026-10-18). The visibility gate above is how you enforce that before Google has to.
• Treat JSON‑LD on canonical HTML as the default. It’s the format Google documents, and it stays attached to the page people actually read (intro to structured data, accessed 2026-10-18).
• Decide whether exports should be indexed. If you publish JSON exports and don’t want them in search results, send X-Robots-Tag: noindex on those responses (Google: robots meta tag and X-Robots-Tag, accessed 2026-10-18)⁴.
• No duplicate-content panic. Google has long said duplicate content isn’t a penalty by itself (Demystifying the “duplicate content penalty”)⁵; canonicalization and indexing directives are the guardrails (Google: canonicalization, both accessed 2026-10-18)⁶.

How Things Are Interlinked

Canonical flow:

entity.json → pages (HTML) → packets (AAOs + manifests) → JSON‑LD embeds → API exports

Rules:

• Everything points back to canonical page URLs.
• Packet IDs are stable across pages, JSON‑LD, and API exports.
• No circular dependency: pages don’t depend on the API to be “true.”
• No runtime graph assembly: edges are compiled; consumers read exports.

How This Fits into a Normal Development Workflow

This is a build step. Not runtime. Not fragile, if you treat it like a compiler.

Minimal flow:

1. Author or update content on pages.
2. Validate the entity record (identity, offers, locales, constraints).
3. Compile packets (extract → normalize → bound → assign stable IDs).
4. Generate:
   • JSON‑LD embeds for canonical pages
   • API exports that mirror packet IDs
   • schema docs / manifests for integrators
5. Enforce the gate: no visible source = no ship.

Honest difficulty table:

Team	Difficulty	Why
Solo founder	Easy to start, hard to keep up	You’re doing content, structure, and QA alone; drift creeps in quietly.
Small dev team	Medium	You can add a compiler step and validation without stalling shipping.
Serious SaaS	Easy	You already live on contracts, schemas, versioning, and CI gates.

The Physics of Failure: Three Failure Modes

Failure Physics (Budgeted Systems)	What Breaks	What You See
Failure Mode A: Context dilution	Retrieve more → accuracy declines	The “ultimate guide” buries the one fact needed
Failure Mode B: Graph noise	Structure explodes context size	GraphRAG pulls the whole map, not the street
Failure Mode C: Chunking trap	Claim separates from scope/constraints	True words + wrong meaning

These are lab results on specific pipelines. None of them measures Google, ChatGPT, or Perplexity answers. They show the mechanisms this architecture designs against, not how much any search product suffers from them.

Failure Mode A — Context Dilution

The naive strategy is “retrieve more.”

In a controlled study of five models on math, question-answering, and coding tasks, performance fell by 13.9% to 85% as input length grew, even when the models could retrieve all the relevant information and even when the extra tokens were whitespace (Du et al., “Context Length Alone Hurts LLM Performance Despite Perfect Retrieval,” arXiv:2510.05381, accessed 2026-10-18)⁷.

Implication: a long “ultimate guide” is a poor retrieval surface for a fact with conditions, especially when it is your only one.

Failure Mode B — Graph Noise (Structure Can Explode)

“Add structure” is good advice until your structure balloons the context.

In a page-level question-answering comparison on one undergraduate math textbook (477 question-answer pairs), GraphRAG retrieved about 47K tokens of context against about 3.7K for standard retrieval, and answer quality dropped (Chen et al., arXiv:2509.16780, accessed 2026-10-18)⁸. One textbook isn’t the web, but the direction matches the warning: if you don’t budget graphs, you don’t get “more intelligence.” You get a token flood.

Implication: structure must be constrained, or it becomes expensive noise.

Failure Mode C — Chunking Trap (Truth Becomes a Widow)

Chunking often separates a claim from its constraints (an orphaned constraint): scope, date, plan, exceptions, and definitions.

Chunking strategy changes retrieval quality: in Chroma’s evaluation, recall differed by up to about nine percentage points between strategies on the same data, on a small synthetic dataset its authors describe as a demonstration of their method rather than a benchmark (Chroma technical report, accessed 2026-10-18). The failure this architecture designs against is simpler: a model retrieves valid words with invalid meaning because the constraint chunk wasn’t co‑located.

Implication: if constraints aren’t attached to claims, your truth is unstable under retrieval.

Diagrams (Where the System Breaks, Where It Works)

Diagram A — The Failure Mode (The Chunking Trap):

In words: the pricing page states a price and its condition together. Chunking splits them, retrieval returns only the chunk with the price, and the answer drops the condition.

Diagram B — The Fan‑Out Solution:

In words: one source compiles into a record that keeps the value, its constraints, and its source URL together; the JSON‑LD and the optional export are both generated from that record, and the visibility gate checks it against the page.

Precedents: Where Packet Discipline Already Works

Fan-Out is a proposal by analogy. Some domains already publish bounded facts with contracts instead of narrative, because errors there are expensive:

• APIs
• infrastructure documentation
• legal texts
• clinical guidelines

Fan-Out applies the same discipline to the facts a business publishes about itself. Whether that changes how any AI search product treats a marketing site is untested. What it does reliably is make your own facts consistent and checkable.

Contracts beat narratives under budget

APIs work well for machines because they are bounded, versioned, and constraint-coupled by default.

That’s the lesson. Not “APIs crawl better.” Not “APIs replace pages.”

Budgeted systems handle units well when:

• the claim and its constraints live together (constraint coupling)
• the object has a stable identifier
• exports are predictable and testable (a contract)

Fan-Out extracts that discipline and applies it to business truth claims.

Who already publishes packets (even if they don’t call them that)

Stripe (payments)

Stripe’s API reference publishes endpoints such as POST /v1/payment_intents, parameter tables, and explicit constraints such as capture_method (Stripe API: create a PaymentIntent, accessed 2026-10-18)¹¹.

A question like “How do I place a hold on a card and capture later?” resolves to one endpoint and one parameter, documented on its own page (Stripe: place a hold on a payment method, accessed 2026-10-18), not to a narrative guide.

Fan-Out equivalence:

• endpoint = AAO-like bounded fact unit
• API categories = facet manifest
• OpenAPI spec = export surface

AWS (cloud infrastructure)

Nobody reads AWS documentation end to end, yet it is easy to retrieve against, because it decomposes truth into capability tables, region availability, quotas, and policy statements (Amazon S3 Object Lock documentation, accessed 2026-10-18)¹².

A question like “Is S3 Object Lock available in eu-central-1?” resolves to one service fact, one region constraint, and one eligibility rule.

Fan-Out lesson:

• typed edges already exist (for example, APPLIES_WHEN region == eu-central-1)
• narrative is optional; bounded facts are mandatory

EUR-Lex (law and regulation)

EU law is indexed by article, paragraph, point, and version. Lawyers don’t cite “GDPR explained.” They cite Article 6(1)(f) (Regulation (EU) 2016/679 on EUR-Lex, accessed 2026-10-18)¹³.

Fan-Out lesson:

• legal clauses are packets
• amendments are typed edges (SUPERSEDES)
• citations demand exactness

Implementation Checklist: The Dual‑Head Build Protocol

This is not a content calendar. This is a deployment pipeline.

Model the claim

Isolate the “function call.” Stop asking “What keywords do we target?” Ask: “If this page were an API endpoint, what would it be named?”

Examples: getPricingDetails(), checkAvailability(), getServiceScope().

Define the AAO schema. Draft the minimal JSON shape required to answer that function call without ambiguity.

Rule: every AAO includes the raw value, the constraints, and the source URL (evidence), plus any promises that change expectations (SLA, lead time, eligibility).

Example (a generic “Contact” becomes a contract):

{
	"id": "contact.primary_method",
	"canonical_url": "https://example.com/contact",
	"claim": {
		"promise": { "business_hours": "mon-fri" }
	},
	"source_url": "https://example.com/contact"
}

Author the facet manifest. List the questions you want budgeted systems to route to, and keep the list short enough that someone will maintain it.

Compile

Implement the extractor. Write a build step (Astro/Next/Hugo) that compiles both outputs from the same source of truth.

Rule: do not hand-write the JSON. The .json head must be compiled from the same inputs as the HTML head, or drift becomes inevitable.

Assign stable IDs and bounded payloads. Set a size budget per record and enforce it; this site’s validateAAOBudget() flags oversized records with a rough character-count estimate. Normalize types and co-locate constraints with claims.

Map typed edges (routing, not “internal linking”). Use explicit relations like DEPENDS_ON, APPLIES_WHEN, CONTRASTS_WITH, SUPERSEDES so consumers don’t have to infer how two facts relate.

Compile the three surfaces. From the same AAOs, generate:

• canonical page (HTML)
• JSON‑LD embed (crawler lift)
• API export (versioned contract)

Deploy and gate

Run the visibility gate in CI against a preview deploy, and fail the release on any FAIL line.

Deploy the dual‑head if you publish exports:

• GET /contact → HTML (human UX)
• GET /contact.json → JSON (agent evidence)

Smoke-test with a model. curl the export and ask a model: “Based only on this JSON, what is the price / scope / eligibility?” Pass: the answer is precise, scoped, and names the constraint fields. Fail: the model guesses. Run it several times; models run with settings meant to be deterministic still varied between runs in a five-model study (Atil et al., “Non-Determinism of ‘Deterministic’ LLM Settings,” arXiv:2408.04667, accessed 2026-10-18)¹⁰, so one good answer proves little. This test checks the clarity of your export. It says nothing about whether a search engine will use it.

When Not to Do This

• You have few facts that change. One well-structured page and accurate Organization markup may be enough.
• You can’t keep the record current. A stale export spreads a wrong fact further than a stale page does.
• You expect a ranking or citation boost. Google says its AI features need no special files or schema (AI features and your website, accessed 2026-10-18), and no engine we know of documents JSON exports as a citation signal. The payoff is consistency and checkability, for you and for integrators.
• Your key facts only render client-side. Fix rendering first; the gate will fail anyway.

Next Steps: Execute the Dual‑Head Build

Don’t overthink this. You don’t need a new CMS. You need a build script and a gate.

1. Pick your money page. Identify the one page that answers: “How do I hire you?” or “What does this cost?”
2. Define the AAO. Write the JSON shape that answers that question without ambiguity (value, scope, constraints, and canonical URL).
3. Run the gate. Prove the value is visible on the page the record cites. Fix whichever side is wrong.
4. Deploy the mirror if integrators need it: make the export available at a documented URL.
5. Test with a model, more than once. If its answers vary, your record is ambiguous somewhere.

That is Fan‑Out: you are still publishing pages, plus contracts for truth that a budgeted system can afford to ingest, and a gate that keeps the two saying the same thing.

How This Was Checked

The site facts, the gate output, and the size measurement come from running the commands shown against argbe.tech and this site’s repository on 2026-10-18. The research results are quoted from the cited papers; none was reproduced here. The precedents are analogies, not tests of this architecture.

Evidence Locker