PIPELINE — The Content Pipeline as Operating Stages

Status: DRAFT v2.0 — command-center reviewed 2026-07-20 · ML review pending

Descends from: SYSTEM.md §3–4 (the core operation, the operating layer), bounded by VALUES.md V1/V2/V5. Mechanical contracts in specs/GATES.md and specs/LEDGER.md. The prototype's 13-stage pipeline survives here re-expressed as the operating layer's stage sequence: every stage is a generate→orient pair or a dumb gate; nothing survives a stage because it "looked good" — only because it could not be ruled out.

1. What the pipeline is

The pipeline is the operating layer of the content organization: the sequence a page travels from framing to the live site and beyond it into outcome observation. It is not a conveyor belt of prose steps — it is a chain of matched generation and elimination, ending at a mechanical gate no clever argument can talk its way past, and a release boundary that pulls, never pushes.

Two properties govern everything below:

1. Every generation step is immediately followed by an elimination step. A draft is a candidate, not a deliverable. Surviving a scan is "could not be ruled out."
2. Flood velocity is licensed by pipeline integrity. The strategic flood (seo/FLOOD.md) is defensible only because every page crosses this full chain of gates. A page that skips a stage is an ungated act on the world and violates V5.

2. The stage sequence

BRIEF/FRAMING → EVIDENCE → DRAFT PRODUCTION → ELIMINATION STAGES
  (fact-check · Voice 3D scan/fix pairs · injection scan/fix)
→ COMPRESSION/ASSEMBLY → MECHANICAL GATEKEEPER → DRIP PUBLISHER
→ POST-PUBLICATION OUTCOME OBSERVATION

Stage 1 — Brief / framing

A committed strategy directive (itself gated upstream — strategy consensus is not this document's subject) is translated into briefs: target concept, angle, beat assignment, audience question being answered. The brief is a mini mission frame.

• Cannibalization check: every brief is checked against the map of published and in-flight pages before it enters production. Two pages targeting the same query cannibalize each other's ranking and split the audience's answer across two half-pages — a defect against both pillars of the mission (SYSTEM.md §0). The check is an independent orienter, not self-administered by the brief's author: the framer generates candidate briefs, a separate dumb check kills collisions against the content registry.
• A brief that survives declares what the page must contain to be acceptable — the acceptance standard is authored before the draft exists, so the downstream eliminations judge against a declared bar, not a retrofitted one.

Stage 2 — Evidence

The draft is grounded before it is written. Inputs:

• The expertise map (seo/RESEARCH.md): the deployment's committed domain knowledge — facts with per-field source and confidence, prospect questions, consensus positions, misconceptions, pulse.
• Live SERP inputs: what currently ranks for the target query, what the search intent actually is, what formats win. Admissible as evidence and prioritization — what is worth covering, what the audience is being underserved on — never as the acceptance standard (V1 enforcement point 2).
• Keyword data: volume, difficulty, adjacent queries. Same admissibility rule.

All external evidence enters through the ingestion quarantine with provenance attached (seo/SECURITY.md). A claim without a traceable source does not enter the evidence pool, and therefore cannot survive fact-check.

Stage 3 — Draft production

Beat writers produce drafts from brief + beat directive + voice references. Production is deliberately elastic — many writers, one per beat/job, each a durable unit with its own directive and earned reference (corpus/COMMISSIONING.md).

• Multi-writer collaboration: pages that span beats (a buying guide drawing on reviews, pricing, and setup knowledge) are produced by multiple contributing writers whose raw materials are composed by a lead writer at the compression stage. Writers coordinate through the file system and verdicts, never shared memory — each contribution is an artifact with an owner, findable and auditable.
• Meta work informed by live SERPs: titles and descriptions are written against the live SERP for the target query — what the searcher sees, what competing titles claim, what gap ours fills. This is the one production step whose evidence is gathered at production time; its SERP pull runs through the same quarantine as any sensor.

Stage 4 — Elimination stages

The teardown block. Staffed separately from production (teardown ≠ reconstruction); none of these workers composes new content except as rework against a specific flag.

4a. Fact-check against the evidence pool. Every claim in the draft is checked against the expertise map's facts view — the verified, provenance-tracked evidence pool. Unsupported claims are flagged and returned; the fact-checker flags, it never rewrites. A claim that cannot be traced to committed evidence does not ship (V2, V5: never publish uncommitted claims). The evidence pool itself is grounded upstream — facts enter it only through gated, provenance-checked proposals — so fact-check is a check against ground truth, not against another LLM's opinion.

4b. Voice 3D scan/fix pairs. Three dimensions, fixed in order — Personality (ethos, conviction, energy), Positioning (structural framing, objection handling), Voice (word-level execution, AI tells) — because fixing words without fixing framing is polishing a defect into permanence.

Each dimension is an orienter/generator rework pair:

• The scanner is the orienter: deliberately dumb, reading detection criteria only from the pattern library — triggers, signatures, flag thresholds. It judges against a declared standard and emits flags. It carries no expert knowledge and cannot be argued into accepting a sophisticated miss.
• The fixer is the generator: reading expert knowledge only — fix guidance, rewrite patterns, the persona's dial settings. It reworks exactly the flagged sections and nothing else.
• **Context separation is preserved absolutely: detection criteria and expert knowledge never cross.** A scanner that reads fix guidance learns to rationalize; a fixer that reads detection criteria learns to write to the test rather than to the standard. The pattern library is physically structured to enforce this — detection and fix sections are separate artifacts with separate readers.
• The pattern libraries grow through the normal gated loop: researcher proposes → gate counts distinct-provenance corroboration → library grows → scanners detect more.

4c. Injection scan/fix pair. A security elimination stage before assembly: detects instruction-shaped artifacts, laundered directives, and policy-violating output that survived ingestion (seo/SECURITY.md §5). Same scanner/fixer separation.

Rework loops within stage 4 are bounded: a page that keeps dying on the same flag class is evidence about the brief or the writer, not raw material for infinite polishing — repeated same-reason deaths route the page back to framing and file a defect record.

Stage 5 — Compression / assembly

The lead writer composes surviving materials into the final page: on-page work (keyword placement, internal links within silo rules, semantic coverage), rich-media integration, schema. Compression is generation and gets its own elimination: assembly output passes a fidelity check — did any contributor's surviving, fact-checked point get dropped or mutated in composition? Compression may lose resolution, never survivorship.

Rich media (redesign note). The prototype's Rich Media Taste Gate — a single smart LLM making a "judgment call, not consensus" — is abolished. A clever judge is exactly what the core operation forbids: it can be argued into a sophisticated mistake. Its replacement is a dumb checklist plus consequence-scaled corroboration: mechanical criteria (dimensions, relevance-to-section match, budget arithmetic, source/licensing fields present) checked by script, and for rich media whose consequence is high (site-wide reuse, claim-bearing infographics), corroboration from distinct proposals at the threshold the consequence dial sets. Taste lives in the pattern libraries and the persona dials — upstream, where it is generated against — never inside a gate.

Stage 6 — The mechanical gatekeeper

The last gate before release, and deliberately the dumbest thing in the pipeline: mechanical checks only. Frontmatter and schema validity, link integrity, required fields, staging completeness — everything recomputable by anyone, arguable by no one.

• The gatekeeper never judges quality. Quality was judged by the elimination stages; the gatekeeper verifies the page carries proof it survived them — stage stamps, fact-check clearance, scan/fix completion records.
• Every listed criterion blocks. The prototype demoted voice violations to warnings — a gate that cannot kill on a declared criterion is not a gate. If a criterion should not block, it does not belong on the gatekeeper's list; move it upstream.
• No single worker's output reaches the live site without passing here (V5). The gatekeeper is inside every publish path with no exceptions and no smart fallback.

Stage 7 — The drip publisher (pull-only release gate)

The single actor with publish access (seo/SECURITY.md §6 blast-radius doctrine).

• Pull-only: the publisher pulls from the gatekeeper-cleared queue on its drip schedule. Nothing upstream can push a page to release; an upstream worker's only power is to place a candidate where the publisher may pull it. The release boundary therefore stays intact even if everything upstream of it is compromised.
• Drip discipline: releases are scheduled and paced (the prototype ran a 6am–10pm, one-per-30-minutes drip; the operating cap is a valve — see seo/FLOOD.md §4).
• Currency re-check at release: before publishing, the publisher confirms the page's clearance records are present and its facts have not been superseded in the evidence pool between gate-pass and release. Stale clearance returns the page to fact-check.

Stage 8 — Post-publication outcome observation

Publication is not the end of the loop; it is where ground truth starts.

• Typed outcome records: every observation enters the ledger as page id + observable event + timestamp + source — an indexation, a first impression, a ranking position, a citation, a click, an engagement signal, a decay event. Typed and attested: an opinion ("this page seems to be doing well") is not an outcome record and is rejected at the ledger boundary.
• These records are the substrate for everything meta: quality series per writer class, drift alarms, the canary metrics that govern flood valves, champion/challenger trials on directive changes, and the resonance evidence that locks the persona (seo/RESEARCH.md §4).
• Published pages carry decay conditions — pricing claims, version references, seasonal validity — and the observation layer watches for exactly those, feeding the refresh/prune lifecycle.

3. VALUEMAXX enforcement points (mission machinery, structural)

The pipeline enforces the mission; the values floor (VALUES.md) is separate and lighter — law, honest transactions, no scam-shaped output. Quality is enforced HERE:

1. **SEO data is admissible as evidence and prioritization input — inadmissible as an acceptance standard.** SERP and keyword data shape briefs (stage 1) and inform meta work (stage 3). No gate anywhere in stages 4–6 passes an artifact because it targets a keyword well, and no elimination stage reads ranking data at all.
2. **"Publishes thin, derivative, or valueless content" sits at the top of the consequence dial** — graded there because it forks both pillars at once. The block comes from the pipeline's acceptance standards and the gatekeeper's stage-stamp requirements — mission machinery, not the values gate (quality is not a refusal; it is the standard of the work).
3. Velocity is defensible only through quality-adherence at volume. The pipeline is what makes the flood non-slop; if quality canaries degrade, the valves close on the publisher and admission queues, never on the elimination stages.
4. A ranking-motivated action that degrades audience value fails its acceptance standard — at every stage. The audience's needs are the acceptance standard.

4. What changed from the prototype

5. Open items

• Whether the earliest build phase may run any elimination stage at loosened acceptance criteria versus bypass-with-scheduled-revisit: the standing lean is **always-on with loosened criteria** — the pipeline is what makes flooding defensible, and revisit-debt has a way of never being paid — but the bypass pattern deserves a designed experiment. [OPEN — flag for command center]
• Numeric rework-loop bounds per elimination stage (how many same-flag deaths before a page routes back to framing). [OPEN — flag for command center]
• The exact dumb-checklist line items for the rich-media gate per media type. [OPEN — flag for command center]