FLOOD — Strategic Flood Doctrine, Valve Theory, Architecture Ownership

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

Descends from: SYSTEM.md §3 (spartan design, not token thrift; the commit boundary), bounded by VALUES.md V1 enforcement point 4: publishing velocity is defensible only through quality-adherence at volume. Volume never earns exemption from V1. This document is the build-out doctrine the prototype lacked: it started producing keyword-targeted content from priority scores on day one, with no concept of an initial build-out plan, no sequencing doctrine, and no theory of its own speed.

1. The strategic flood

The build phase is a deliberate, sophisticated flooding of the system to develop the core bones of the website. The system is built to crush compute; during build, that capacity is aimed at standing up the site's core as fast as quality-adherence permits.

The design assumption: ~50 pages/day is acceptable for a new site, provided every page is thoughtful, diverse, and genuinely valuable — unique, distinct, directly adherent to Google's AI-content policies, categorically not slop. A properly working system meets that bar at that rate; the system is designed against that assumption rather than treating velocity itself as the risk.

This supersedes the earlier earned-headroom doctrine (~5/day with slow ramps). The resolution of that tension is recorded: headroom is earned by quality-adherence at volume, not by volume restraint. Flood velocity is licensed by pipeline integrity — every one of those 50 pages crosses the full elimination chain and the mechanical gatekeeper (seo/PIPELINE.md); a flood of ungated pages is not a flood, it is a values violation.

The 50/day figure is a monitored hypothesis, not a constant of nature. Each deployment treats it as a commit with a falsifiable predicted effect:

• Canary metrics watch the trust signals that would falsify it: indexation rate and latency, crawl-rate response, impression growth, manual-action or quality-signal indicators, engagement on fresh pages.
• If trust signals degrade, valves close. Canary degradation mechanically reduces publish caps and queue admission (§4) — no judgment call, no argument, no exemption for being mid-plan.
• Canaries are observed on the market clock (§5) — corroboration of degradation counts only across market state changes, so a one-day wobble neither closes valves nor licenses reopening them.

2. Core first, keywords second

The initial content is the core — the pages that make the site worth existing for the researched audience. There is no sense targeting keywords when the site doesn't yet add value. Keyword-targeted content is produced early but explicitly subordinate to core construction.

The pivot from core-building to keyword-driven strategy is a named transition with criteria, not a drift:

1. Core coverage complete per the architecture blueprint (§3) — the build-out plan's core sections report coverage at their declared thresholds.
2. Help/trust surfaces live — about, editorial policy, contact, the pages that make the site accountable to its audience.
3. Site experience coherent — navigation, hubs, and cross-links pass the experienced-surface review (§6); a visitor landing anywhere can orient.

After the pivot, the concept map's priority engine takes over as the primary production driver. The pivot is a saturation event on the core-building work-front — pivot when core-coverage discovery saturates, not when a calendar says so. Concrete thresholds for the trigger list remain to be calibrated from deployment data. [OPEN — flag for command center]

3. Even flooding against an explicit build-out plan

The flood is planned, not opportunistic. Before mass production starts, the Layer 0–5 knowledge bank (seo/RESEARCH.md) is converted into an explicit initial build-out plan: what the core is, in what order it is built, and how the flood stays even.

• Every page maps to the architecture blueprint. A page proposal that maps to no blueprint node is rejected at brief admission — not because it is bad, but because an unmapped page is architectural drift at flood speed.
• Evenness is a reviewed property. No lane races ahead while another lags: the build review (seo/ONRAMP.md §7) checks flood evenness against the plan in its mid-build posture — is every architecture section filling at its planned proportion, are the accumulation inventories filling alongside the content.
• The build-out plan is authored and reviewed by the architecture owners (§6) as a first-class gated artifact — it is the site's skeleton, and skeleton decisions get exponentially more expensive to reverse as content accumulates on top of them.

4. Valve theory — the valve map

Speed is not one dial. It is an art of opening and closing valves distributed through the whole system. The prototype prescribed one set of frequencies as if cadence were a property of the design rather than a setting; v2 ships valve mastery as delivered knowledge — the deployment receives the valve map at launch and does not rediscover couplings by breakage.

The valve map enumerates every throughput control:

For each valve the map records: what it modulates, its interaction effects, its safe operating range, and what breaks first when pushed — evidence epochs collapsing into noise, API rate limits, host compute, gatekeeper throughput, search-engine tolerance. An operator (human or agent) scales content velocity deliberately, the way a plant operator runs a refinery.

Valve rules:

• Valves close faster than they open. Canary degradation closes valves mechanically; reopening requires corroborated recovery across market state changes.
• Closing order is pre-declared: publish caps first (stop contact with the world), then queue admission (stop accumulating in-flight work), then worker schedules (stop spending). Elimination stages are never the valve that closes — quality machinery runs at full strictness at every velocity.
• The map's safe ranges are measured limits, not guesses. How far cycle speed can actually push — 10× steady-state is a hunch — and what breaks first per loop needs instrumented experiments; the valve map records measurements as deployments fill them in. [OPEN — flag for command center]

5. Two clocks and the evidence-epoch rule

Two clocks run through the system, and conflating them was one of the prototype's deepest errors (thresholds denominated in days assumed daily cadence everywhere).

• The internal clock — pipeline health, directive drift, playbook growth, map population — changes state in hours during build. Internal loops audit at the state-change rate: 2–3×/day minimum during build, faster where the valve map's measured limits permit.
• The market clock — rankings, citations, analytics, trust signals — changes daily at best. Market loops audit at the evidence rate; auditing faster is harmful, not neutral: it manufactures observations of an unchanged world.

The evidence-epoch rule: never audit faster than the audited domain changes state. An observation adds evidence only if the system changed state since the last one. Re-observing an unchanged domain manufactures consensus from noise — corroboration counts only across state changes. The memory layer guards the rule: delta-briefs tell auditors what changed since their last pass; "nothing changed" obliges "no new evidence," never invention.

Consequences:

• Lookbacks are denominated in qualifying observations across epochs, with day-figures surviving only as staleness ceilings.
• Flood-phase acceleration is legitimate precisely because the internal domain really does change state that fast during build; the market loops do not accelerate with it.
• Canary verdicts (§1) and pivot criteria (§2) are market-clock judgments: they require corroboration across market state changes by construction.

6. Architecture ownership — three owned surfaces

The prototype produced thousands of pages and had optimizers for technical details, but no function owned the architecture of the site as an artifact. v2 assigns three distinct-but-interlocking surfaces to dedicated owners — instrumental at build (they author and review the build-out plan), maintainers at steady state (drift-auditing and surfacing decisions as the site grows 10×). Distinct workers per surface, cross-reading each other's artifacts; when in doubt, split by job.

6.1 The crawl surface — what machines see

How the site presents itself as crawlable and citable: XML sitemaps, section indexes, feeds, llms.txt and machine-readable surfaces, canonical structure. Owned as a reviewed artifact — the crawl surface is a claim about what the site is, made to every crawler and answer engine, and it must stay true as the flood fills the blueprint.

6.2 The experienced surface — what humans see

Doctrine: restraint. An SEO site holds thousands of pages at maturity but surfaces few — what is easily accessible is what the researched target prospect actually wants, organized the way they think: stacked menus, categories in their vocabulary, not the taxonomy's. Design extends two clicks deep: not just which pages sit in the menu, but which pages those link out to — is everything that should be reachable actually reachable via deliberate cross-links (within silo rules), and is what's reachable right. How much surface area at which site size needs worked examples per niche archetype. [OPEN — flag for command center]

6.3 The organizational pipes — how it's plumbed

The information architecture under the whole system: URL structure, collection and taxonomy design, hub-and-spoke wiring, redirect topology, and the mapping between the concept map and the site's physical structure. The pipes are the contract between the knowledge plane and the published site; pipe changes (URL migrations, taxonomy restructures) fork everything built on top of them and sit at the top of the consequence dial.

7. What changed from the prototype

8. Open items

• Measured valve limits and what-breaks-first per loop (§4). [OPEN — flag for command center]
• Concrete core→keyword pivot thresholds (§2). [OPEN — flag for command center]
• Menu/architecture restraint heuristics per site size and niche archetype (§6.2). [OPEN — flag for command center]
• The 50/day hypothesis's per-deployment canary thresholds and valve-closure rules (§1) — structure is doctrine, numbers join the constants-to-be-measured ledger. [OPEN — flag for command center]