How to Publish 60+ Pages in Parallel Without Contradictions

Publishing 60+ pages in parallel without contradictions is a coordination problem, not a writing problem — and the solution is making every decision once, upstream, in artifacts that bind every writer: a content contract, a closed source list, canonical stances, and a tranche brief, enforced by 2 automated gates. This page is the method; the git-dated narrative of what the method produced — and broke — is the 100-pages-in-a-week field report.

Why do parallel writers contradict each other?

Because each writer produces a locally coherent page against the same unresolved questions, and locally coherent answers diverge globally. Before canonical stances existed on our auto-finance rebuild, the fleet answered one contested question 3 different ways across 4 pages — every individual page read fine, and the corpus disagreed with itself [our data].

Exemplars create the second failure mode: staleness. Writers told to match existing pages match them faithfully — which is how a retired claim leaked back into 6 new pages on the same build, resurrected from exemplar pages that predated the retirement [our data]. Both failures are structural. Neither is fixed by hiring better writers, because neither is a writing error.

What must exist before the first writer starts?

Four artifacts, in dependency order. The content contract fixes everything global: frontmatter shape, voice, vocabulary, compliance rails, schema defaults per cluster. The closed source list enumerates the only external URLs a claim may cite — the single strongest defense against invented statistics entering a corpus at fleet speed. The canonical stances document records the site's one position on every question the wild answers inconsistently. And the tranche brief assigns the work: per page, its slug, primary question, angle, key sources, schema type, and internal links.

The brief is binding in both directions. A writer who finds the brief wrong flags the operator instead of improvising — because an improvised fix ships silently, N pages wide, in parallel.

Exemplars need active management too. Writers imitate whatever example they are handed — including its retired conventions, which is exactly how a dead claim came back on 6 pages [our data]. Point every tranche at a current, contract-clean exemplar, and when a claim or convention is retired, add its build-failing regex the same day so stale imitation fails loudly instead of shipping.

What do the two gates check?

The source gate reads markdown; the output gate reads what readers and crawlers actually receive. Both exist because each catches a class the other cannot see [our data]:

The output gate exists because of that right-hand column: source-level checks passed while the rendered pages carried visible artifacts. Render every page in CI and fail on what the reader would see.

How does a tranche actually run?

In the order the steps above give: contract and source list stand permanently; stances and the brief are written per tranche; writers run in parallel against their rows; the source gate screens every file; the build runs and the output gate screens every rendered page; an adversarial review audits the result; and every error class the review finds becomes a new gate rule before the next tranche launches.

One timing rule matters more than it looks: pages within a tranche may link each other only because the whole tranche ships as one commit — the link gate fails any target that does not exist at build time, so cross-links to unshipped future pages are never legal from live pages.

The record says the machinery, not heroics, is the throughput: 67 reviewed pages in the first 2 days of the auto-finance rebuild and 298 content files by day 14, with the same system completing a 167-page five-cluster map in 2 days on our greenfield build [our data]. What each page costs under this system — and where the money actually goes — is priced in content-ops cost per page.

What does this method not solve?

Three things, stated plainly. First, gates encode past errors only — every adversarial review across our 3 builds found real defects the gates missed, which is why the review is a fixed phase and not a formality [our data]. Second, parallelism amplifies brief-level mistakes: one wrong canonical stance ships onto every page that touches the question, so the upstream artifacts deserve the most skeptical review in the pipeline. Third, the link graph is its own failure surface with its own discipline — internal linking for a content library covers the orphan collapse that page-level checks can never see.

And against our own interest, since fleet production is what we operate: a site publishing a handful of pages a month does not need this machinery. A checklist, one reviewer, and Google's people-first bar (Google, helpful-content guidance) cover low volume fine. The system pays for itself only when the page count is high enough that consistency can no longer live in one person's head — the scale at which a library becomes an authority surface worth engineering. The full production system is documented as the authority engine.