ONRAMP — The Autonomous Onramp: Ramp, Graduation, Boot, Takeover

Status: DRAFT v2.0 — command-center review pending

Descends from: SYSTEM.md §3 (progressive commitment, the commit boundary), corpus/COMMISSIONING.md, bounded by VALUES.md V4/V6. The prototype specified the steady state superbly and the build weakly: an imperative "build-mode override," human sign-offs at five points, thresholds denominated in days. A machine whose premise is "runs itself from the launch command" cannot have a hand-operated onramp. The onramp is the machine, at different settings. Nothing is built twice; nothing is switched off by hand; the system that emerges is the system that built itself.

1. The build is declarative, bottom-up, self-graduating

There is no build-mode override. The same gated workforce that runs the system builds it, under a ramp configuration that loosens gates early and tightens them per-gate as evidence accumulates — degrading gracefully into standard production with no cliff, no global switch, and no human in the loop. Every build-phase change flows through the normal propose→gate→execute→review loop at loosened settings, leaving the same audit trail as production. The commissioning orchestrator's residual role shrinks to infrastructure that cannot flow through gates: installing scripts, provisioning.

2. Provisioning — the only hard human dependency

The only thing the system cannot do for itself is hold ML's keys (V4: credentials are granted, never derived). Provisioning — keys, accounts, domain, hosting, API access — is the single hard human dependency, and it is verified mechanically: a prerequisite check at launch enumerates every required credential and access, tests each, and blocks launch on any failure with a specific, actionable list. No judgment, no interview, no sign-off — a checklist a script runs.

Everything after provisioning that the prototype required a human for — strategic direction sign-off, personality approval, master-document approval, "turn the system loose" — is replaced by measurable exit criteria and the build review (§7). The human's console (force-pass, hold, demote, steer) is always available and never necessary.

3. The boot interview — a fork-tested question bloom

The prototype opened with a fixed 11-question kickoff form (including the gut-feel persona question). Both the fixed form and its shrunken successor ("provisioning + optional steering") are wrong — the first over-asks mechanically, the second under-provides for intent. Intent questions are un-eliminable by the world: no amount of research can tell the system what ML actually wants from this deployment.

Boot is an interview, and the interview is a bloom:

1. The system generates candidate intent questions from the vertical seed and its own doctrine — monetization posture, risk tolerance, brand constraints, off-limits topics, takeover vs cold-start intent, success horizon.
2. Each candidate is fork-tested: does the answer change what the system would build? Questions whose answers don't fork downstream work are eliminated, not asked. ML's attention is priced; questions are kept few and large.
3. The bloom stops at saturation — when further questions no longer move the plan.

Heavy hour-zero intent escalation is CORRECT. At hour zero almost everything forks on intent, so the escalation rule fires constantly — that is the designed behavior, not a failure. The frequency decays by graduation: as answers accumulate into committed seed-intent artifacts and gates harden, fewer decisions fork on unknown intent, and human contact converges to the standing four-category floor (§8). The persona question never appears — the tournament answers it (seo/RESEARCH.md §3).

4. Ramp-as-config

"Build mode" is state, not prose. A machine-readable ramp configuration, consumed by every gate script, carries per-gate: phase, threshold, lookback, cadence, reviewer requirement, cooldown, and graduation criteria.

• Build thresholds are loose per progressive commitment. Young artifacts and young teams are cheap to revise, so early corroboration requirements are minimal — additive knowledge (playbooks, patterns, map nodes) commits at threshold 1; worker-create at 1 with mandatory review; the personality ethos gate loosest of all pre-lock-in. The consequence dial still governs: what forks heavily (architecture blueprint, URL taxonomy, persona lock-in) stays expensive even during build.
• Graduation is per-gate and evidence-based — NEVER calendar-based. Each gate carries its own criteria: N clean merges, population stabilized (additive-discovery rate below floor, majority of proposals refinements), baselines existing, first graded outcomes live, reviewer find-rates flooring. A gate graduates when its evidence says the loose setting is no longer safe-because-cheap, not when a date passes. Because gates graduate independently, the onramp dissolves gradually into production — no cliff, no global event.
• Graduation auto-applies with a notification; the console can hold or demote.
• Two-inventory discipline: seedable artifacts (the research pyramid, cold-start playbooks, directives) are prepopulated at blitz; accumulation-only artifacts (worker-earned playbooks, rejection baselines, graded outcomes) fill only through operation, each with a declared readiness criterion — and machinery that depends on them stays declared-dormant until its inputs exist, never silently wrong.
• Numeric graduation criteria are placeholders pending calibration from real deployments. [OPEN — flag for command center]

5. Cooldowns — damping as its own mechanism

Corroboration thresholds silently perform two jobs: filtering noise AND damping oscillation. Loosen a threshold to 1 and the damping vanishes — successive workers can thrash the system, executing a direction and its reversal in alternate runs.

Damping is therefore its own mechanism, decoupled from thresholds: a direction key that executes cannot re-fire, and its reversal cannot fire, for K epochs (default K=2) without escalation-path or console override. Enforced in the shared gate library, denominated in evidence epochs, not days. This is what makes threshold-1 building safe.

6. The model ramp

Early in a build, directives are unrefined and playbooks empty; a cheap model amplifies every ambiguity at exactly the moment errors shape foundations. So:

• All workers launch as capable as the worker ceiling permits (SYSTEM.md §7: GLM is the hard ceiling below the strategic layer; consequence above the ceiling climbs the escalation ladder, it never rents a bigger model). During build, immature directives make effective consequence-per-token maximal, so launching capable is the consequence-correct assignment, not an indulgence.
• Demotion is per-worker, on maturity criteria: directive stable for N runs, worker playbook past a depth floor, rejection rate under threshold, clean reviews. Each worker demotes to the cheaper class individually when its criteria hit; the demotion is an auditable ramp event, trialed against recorded outcomes (the cheaper class must match), and reversible on regression. Promotion back runs on metered evidence of under-power.
• The principle: **model strength compensates for directive immaturity; as institutional memory accumulates on disk, intelligence migrates from the model into the artifacts.**
• Workers whose consequence stays permanently high are pinned at the ceiling regardless of maturity.

7. Build review — permanent layers at build settings

The prototype's build had no immune system: nothing reviewed the build against the design principles, and the ramp itself was unwatched. v2's answer is not a transient corps. Build review is the system's permanent monitoring and self-knowledge layers, running at build settings from day one:

• Change review — fresh-eyes review of every gate-passed change against the design laws (scanner/fixer separation, externalized memory, no self-review, wiring completeness). At graduation this does not retire; it is the monitoring layer's standing review function at production settings.
• Directive review — every new or updated directive checked against the directive template, reference-file existence, and context-separation rules. Converts at graduation into the standing commissioning check: every directive, forever.
• Ramp audit — audits the ramp state itself: are graduation criteria met honestly or gamed; are cooldowns respected; is any gate stuck below graduation abnormally long. Its subject — the ramp — is genuinely transient.

Retirement discipline: reviewers retire on subject-completion only, never on silence. The ramp auditor stands down when the ramp ends — an observable event. Nothing retires because its defect-find rate went quiet: a silent-failure detector finding nothing is indistinguishable from its being needed. Any retirement criterion keyed to low find-rates must first be canary-verified — planted defects the reviewer must catch; a reviewer that misses its canary is broken, whatever else it reports.

Review criteria are staged, because what matters changes as the build matures:

• Early: maximum flexibility on execution detail, maximum scrutiny on direction — site architecture, beat structure, persona choice, concept-map shape. These are the ship-turning decisions that get exponentially more expensive to reverse as content accumulates on top of them. Polish and micro-voice are explicitly not priorities yet.
• Mid: consistency and coverage — is the flood even against the blueprint, are the accumulation inventories filling.
• Late / graduation: full steady-state criteria — polish, conformance, voice precision — as gates tighten and models demote.

Early review is throughput-enabling, not throughput-limiting: it keeps direction true while the valves are open.

8. Graduation — the definition

Graduation is not a ceremony and not a date. The system has graduated when, and only as long as:

• Human contact has converged to the four-category floor — intent/values changes, certified tiebreaks that survived the whole escalation ladder, key grants, final override. The measure is the escalation forward-count: how much reaches ML, in which categories, at what rate.
• The closure rate trends to 1 — the fraction of loops the organization closes without draining work to the human. An open loop anywhere drains its missing work to ML; graduation is the observable state of that drain approaching zero while the four-category floor holds.

Individual gates, workers, and reviewers graduate independently on their own criteria; system graduation is the aggregate those curves converge to. Nothing about it is irreversible — regression on the meters reopens ramp settings per-gate.

9. Takeover mode

Deployment onto an existing site changes the onramp's inputs, not its laws. The v1 framework is preserved:

1. PLAN — independent of the existing site. Run the full research blitz and build-out planning as if the site did not exist, producing the ideal state: expertise pyramid, concept map, beat structure, architecture blueprint, persona tournament. Plan-first is load-bearing: audit-first anchors on what exists and produces "improve what we have" instead of "build what should exist." The gap between ideal and actual IS the work plan.
2. AUDIT — against the plan. Inventory all existing content: crawl, categorize, quality-assess; pull rankings, traffic, backlinks per page; map every page to the plan's concept map.
3. DECIDE — keep / rewrite / merge / nuke / reclaim, data-informed per page:
     • KEEP — ranking well, good quality, on-strategy: preserve and integrate.
     • REWRITE — rankings or topic value with poor execution: through the pipeline.
     • MERGE — multiple pages on one target: consolidate, redirect the rest.
     • NUKE — no traffic, no rankings, low quality, or off-plan: delete, redirect to the nearest relevant node.
     • RECLAIM — ranking for an unintended keyword, or backlinks without traffic: re-optimize or redirect to preserve equity. The decision set is a gated commit at high consequence — it forks the site's SEO equity — with the decisions ledgered per page.
4. BUILD / OPERATE — the normal ramp (§1–8), with kept content entering the map as coverage, rewrites entering the pipeline as drafts, and redirect topology owned by the organizational-pipes surface (seo/FLOOD.md §6.3).

Takeover's SEO-equity risk (legacy cannibalization, authority dilution) is why the audit must be exhaustive and the decide step sits high on the consequence dial.

10. What changed from the prototype

11. Open items

• Numeric graduation criteria (clean-merge counts, stability windows, find-rate floors) — constants to be measured, not designed. [OPEN — flag for command center]
• Cooldown default K per direction class beyond the K=2 default. [OPEN — flag for command center]
• The boot bloom's candidate-question seed set per deployment mode (cold start vs takeover). [OPEN — flag for command center]