April 30, 2026
In the early morning, my primary coding agent (Lead Developer) filed a design memo for the next phase of a multi-week ethics-activation arc.
The piece of the arc still pending was the flag-flip. The ethics floor we'd been building since the start of the month — the upstream detector, the contract my Chief Architect (Arch) and Experience (CXO) agents had co-authored, the six-day build that had shipped on Monday — was all in the codebase. The flag in the local docker-compose file was set to false. Flipping the flag to true turned ethics enforcement on for the running system.
The design memo proposed a careful path to flip. The flip would happen in a log-only mode first. Both the new ethics layer and the existing pre-classifier would run, we'd record which inputs each one caught, we'd compare the records against each other for a calibration period, and once we had enough samples we'd flip to enforcement mode. The argument was that we should know how the ethics layer behaves under real traffic before we let it block responses.
Reasonable plan. Three open questions surfaced for Architect's review. The memo went out to the relevant inboxes around 7:35 AM.
I read it. Thought for a while, then I asked a question.
Where would the real-traffic data come from?
We're in alpha. We have no real users yet. The "wait for real-traffic calibration" plan was waiting for data that the project's current state could not produce. The careful path was unreachable from where the project actually sat.
I've been on the other side of this question often enough to recognize what was happening. Engineering plans usually optimize for accuracy under future-state conditions. Alpha plans need to optimize for learning under current-state conditions. The careful-calibration framing assumed we had production traffic to calibrate against. The actual constraint was that the only traffic the system was going to see for the next several weeks was either mine, in development, or scripted, in a test harness.
Within minutes, Lead Dev had filed a new memo. The flag would flip now. Calibration would be reframed three-phase: Phase A — simulation harness — synthetic input population generated by a smaller model, scored against the ethics layer first in log-only mode and then in enforcement mode. Phase B — beta-traffic refinement once we have actual users post-onboarding. Phase C — stable. Phase A could ship alongside the flip. The thing we'd been waiting for, the thing that wasn't coming, no longer had to be waited for.
What this unlocked
The flip-now memo went out at 7:55. By 8:23, Architect had filed a response concurring with all three of Lead Dev's open design questions: defer the proposed repo restructure, keep the session factory inside the log call (the transaction-boundary semantic was important to preserve), remove the inactive adaptive-boundary code outright rather than retarget it.
ADR-061 v1.0 — the architectural decision record that had been waiting for these resolutions — was committed in the same window with all six of Lead Dev's earlier review findings folded in.
By 1:30 PM the flag-flip was merged to main. ENABLE_ETHICS_ENFORCEMENT=true was live. The multi-week arc that had started in early April closed on Thursday afternoon, six hours after a single question reshaped its remaining work.
What had been blocking the close wasn't engineering effort. Engineering effort was the slot the plan had reserved for the calibration step. What had been blocking the close was a category error in the plan — treating calibration as a step that could be scheduled, when calibration as defined required inputs the project couldn't produce. The question surfaced the error. The reframe — simulation can stand in for the inputs we don't yet have — let the rest of the work happen in parallel with the flip instead of being gated behind it.
What's portable
Alpha plans drift toward production-shaped sequencing. The form is familiar — "build the thing, then verify, then ship" — and the form is right for a system that already has the inputs verification needs. For a system that doesn't yet have those inputs, the same form is a trap. Verification gets reserved as a future step against a future input set that may not arrive in the timeframe the plan assumes.
The question to ask of any plan's "verify" or "calibrate" step is the small one I asked here: where would the data come from? If the answer is "real traffic" and the project doesn't yet have real traffic, the step is unreachable until something else changes. Either the project has to wait for those changes — which means the step is gating on something the plan didn't name as a dependency — or the step needs to be reframed to use inputs the project can actually produce.
Six hours from a question to a multi-week arc closing isn't fast because everyone worked harder than usual. It's fast because the question stopped the plan from waiting on something that wasn't going to arrive.
Next on Building Piper Morgan: a record day, and the question of whether momentum that fast is real or just adrenaline. "The Pace Verified," Thursday.
Where in your work has a verification or calibration step been reserving a slot against inputs the project couldn't yet produce? What would the simulation-first version look like?