Mechanism

The Concrete Operational Filter That Every Decision Passes Through

How locking what I was building — not just why — gave every decision a filter and turned 596,903 lines of code into ten shipped systems with zero scope drift.

596,903
Lines of code across 10 shipped systems — each with identifiable Target-governed build phases
2,561
Commits showing thematic coherence within build phases — not random scatter

The Problem

I never lacked vision. I lacked specificity. I could describe the future state I was building toward — the ecosystem, the market position, the product suite — but when I sat down to execute, the question was always the same: what am I building right now? Not next quarter. Not eventually. Right now, in this session.

Without an answer to that question, every decision required fresh deliberation. Should I build the user management system or the reporting module? Should I integrate this API or that one? Each of those questions has a clear answer when I know what I am building this week. "Build the MVP lead routing engine by Friday" makes the reporting module a left swing and the routing API a right swing. Without that specificity, each question demands first-principles thinking — consuming cognitive resources that should be directed toward execution.

In AI-native execution, the problem compounds. AI can build anything I can describe. The constraint is not capability — it is description quality. When I hold only abstract vision, I produce abstract instructions. Abstract instructions produce scattered output. The specificity of what I tell AI to build is directly proportional to the quality of what comes back. Target is the mechanism that converts "build the dashboard" into "build a lead routing engine that ingests webhooks from three providers and routes to five buyers with real-time status." That conversion changes everything downstream.

What Target Actually Is

Target is the current build — what I am making right now. It is concrete, measurable, and has a defined end state. I know what "done" looks like before I start. Everything in scope is clear. Everything out of scope is clear. Target sits Above the System alongside Vision and the 80% Premise.

What it provides:

  • An operational filter — every decision evaluates against the locked Target. Does this advance the current build? Right swing. Does it not? Left swing. No deliberation required.
  • A translation layer — Target converts Vision's abstract direction into concrete, actionable specificity that drives daily execution and gives AI precise instructions.

What it does not provide:

  • Strategic direction — that is Vision's job. Target without Vision produces action without direction. Target answers what, not why.
  • Permanent commitment — Target changes when the current build completes and the next one begins. It locks during execution but unlocks at completion, intentional pivot, or Governor intervention.

Target has five properties: concrete (I can describe the finished build), measurable (completion criteria are defined before execution begins), bounded (in-scope and out-of-scope are explicit), time-bound (temporal constraint shapes achievable scope), and connected to Vision (every Target advances the future state Vision describes).

Locking, Unlocking, and the Pendulum Criterion

The critical operational distinction is Target state: locked or unlocked. A locked Target provides the filter for all decisions. An unlocked Target means no filter exists — the Pendulum has nothing to swing against, and the system stalls.

Locking is deliberate. I commit to a specific build with defined completion criteria. I articulate what I am building, what done looks like, and what is excluded. The act of locking is itself a forcing function for specificity — if I cannot describe the end state concretely, the Target is not ready to lock.

Unlocking happens three ways. Completion: the Target is achieved and I select the next one. Intentional pivot: I determine during execution that the Target is wrong and deliberately switch. Unintentional drift: the Target degrades through accumulated scope changes until it no longer provides a meaningful filter. That third path is the failure mode — the Governor should catch it before it compounds.

The Pendulum's binary question is: does this advance the Target? That question is only answerable when Target is locked. Without it, the question becomes "does this advance... what?" — and I am back to first-principles deliberation on every decision. With a locked Target, the Pendulum operates automatically. I see a decision, evaluate it against the Target, and swing. The cognitive cost approaches zero because the criterion is pre-established. That automaticity is what enabled the Pendulum to process an estimated 15,000+ decisions without accumulating cognitive debt.

Target can also be found, not just built. When something that already exists reaches 80% of what I need, the Target can be to Bridge it into the ecosystem rather than build it from scratch. "Integrate this open-source engine" is as valid a Target as "build this engine."

What the Data Shows

Target was validated across ten production systems totaling 596,903 lines of code between October 2025 and February 2026. As a directional element, Target's function is observable through project boundary clarity, commit pattern coherence, and defined build phases.

Each of the ten systems has identifiable start points, build phases, and completion states — consistent with locked Targets governing execution:

Project LOC Days to MVP Target Clarity Evidence
PRJ-05 16,993 4 Clear scaffold deployment; defined product scope
PRJ-08 39,288 43 Extended build reflecting learning-phase Target
PRJ-01 194,954 — Clear phase transitions; Target refined across phases
PRJ-03 Guide 5,862 4 Rapid MVP; tightly scoped Target
PRJ-04 29,193 5 Narrow Target; 100% primary execution

The variation in MVP timelines reflects Target scope, not execution quality. PRJ-08 at 43 days was the first system in its vertical — no Foundation to draw from. PRJ-03 Guide at 4 days drew from mature Foundation. Different Target definitions against different Foundation states.

PRJ-01's commit history shows the clearest evidence of Target-driven phase transitions. Foundation phase averaged 4.6 commits/day. Iterative feature development hit 6.4. Post-pause acceleration reached 24.1. Peak sprint — completing the integration layer — hit 61.5 commits/day. Sustained expansion held at 24.1. Each phase corresponds to a distinct locked Target, and each transition marks where I reassessed and locked a new Target against growing Foundation.

The portfolio's zero backlog across 596,903 lines of code is indirect but strong evidence. The Pendulum requires Target to operate. The Pendulum eliminates backlog. Zero backlog therefore confirms Target was locked and functioning throughout.

How to Apply It

1. Lock Before Executing The most common execution failure is starting without a locked Target. Excitement drives immediate action — but action without Target is motion without direction. Before touching code, articulate what you are building, what done looks like, and what is excluded. If you cannot describe the end state concretely, refine until you can.

2. Define Done Before Starting Completion criteria must exist before execution begins. "Improve the dashboard" is not a Target. "Build a lead routing engine that ingests webhooks from three providers and routes to five buyers with real-time status" is a Target. If you cannot recognize completion when it arrives, the Target is not specific enough.

3. Scope the Exclusion List Explicitly Name what is out of scope and write it down. When scope pressure arrives — and in AI-native execution, every AI interaction suggests adjacent features — reference the exclusion list. The Target boundary answers the question without deliberation: is this in scope? If not, left swing, regardless of how compelling it appears.

4. Transition Quickly Between Targets When a Target completes, lock the next one promptly. Extended time without a locked Target degrades execution because no filter exists. The Pendulum stalls. Decisions accumulate. The stash from left-swing decisions during the previous Target may contain candidates for the next one — review it, select, lock, and move.

References

  1. Keating, M.G. (2026). "Vision." Stealth Labz CEM Papers. Read paper
  2. Keating, M.G. (2026). "Foundation." Stealth Labz CEM Papers. Read paper
  3. Keating, M.G. (2026). "Pendulum." Stealth Labz CEM Papers. Read paper
  4. Keating, M.G. (2026). "Nested Cycles." Stealth Labz CEM Papers. Read paper
  5. Keating, M.G. (2026). "Governor." Stealth Labz CEM Papers. Read paper
  6. Keating, M.G. (2026). "80% Premise." Stealth Labz CEM Papers. Read paper
  7. Keating, M.G. (2026). "Bridge." Stealth Labz CEM Papers. Read paper