The Constraint-Based Development Methodology

FlowState Engineering

A constraint-based methodology that separates planning and execution the way TDD enforces tests and DevOps enforces builds.

Developed by Scott Michael Wilson

What FSE Is

Three Constraints That Define the Methodology

FSE is a set of constraints that keep human judgment and machine execution aligned on real codebases. Each pillar is a specific mechanism, not a slogan.

C

Constraint-Based

Planner and executor are strictly separated. One component writes the plan — files to change, conflicts to surface, architectural rationale. The other performs the edits and reports what actually happened. If the executor hits a decision not covered in the plan, it stops and escalates rather than improvising.

S

Self-Healing

Every change that can affect compilation triggers a full build. The loop continues only while the build shows zero errors and zero warnings. On the third failure for the same error class, the agent halts, states the conflict, and offers concrete alternatives instead of guessing again.

L

Living Documentation

FSE.md defines the protocol and standing orders. FSE_STATE.md tracks build status, known debt, and lessons from the last session. FSE_DISCOVERY.md captures architecture and key decisions. Read at session start, updated at session end, kept under 15 KB.

What FSE Is Not

FSE is not the common pattern of prompting an AI, accepting whatever output runs once, and moving on. Every session starts from verified state on disk, requires an explicit plan before any edits, produces only production-ready files, and ends only when the build is green with zero errors and zero warnings. The result is a codebase left in a known-good state for the next session.

What's Actually New

The Specific Novelty

FSE adapts established principles — TDD's correctness constraints, DevOps's state discipline, separation-of-concerns architecture — to a problem none of them were built for: keeping AI-assisted development from drifting under real-world pressure. The novelty is the axis, not the parts.

1

Thinking vs. Doing, Separated

Plans are produced before execution. Execution never happens outside an approved plan. This isn't a workflow preference — it's an enforced separation that prevents the most common AI failure mode: confidently shipping something that wasn't asked for.

2

Documentation as Runtime Context

The bedrock files are not artifacts written for humans to read later. They are operational state read at the start of every session. The codebase remembers its own architecture, decisions, and mistakes — so the next session starts where the last one ended.

3

Enforced Non-Drift

Standing orders are absolute. Every rule has a documented failure mode behind it. When a session ends, the build is green or the session is not finished — there is no "we'll fix it next time."

4

Conflict Escalation Over Guessing

Three failed self-healing attempts on the same error trigger a stop. The agent does not improvise a fourth try. It reports, asks, and waits. The same logic that produced three failures will not produce a fix on the fourth attempt.

5

Verified State Over Assumed State

Every session begins by reading what is actually on disk. No assumptions about file contents. No memory of what "should" be there. The methodology trusts measurements, not impressions — which is why FSE works the same way on session one and session one hundred.

Known Trade-offs

What This Costs

The four-phase session protocol and mandatory self-healing build loop add real friction, especially for trivial one-line changes. That cost is consistently outweighed by reduced drift, cleaner builds, and stable cross-session state. FSE was used to take all eight systems from initial generation through production-ready testing in healthcare compliance, legal practice management, financial trading, elder care, education, corporate operations, chiropractic, and geotechnical engineering.

Maintaining accurate living state files requires consistent discipline. When followed, every session starts from verifiable reality instead of accumulated assumptions. For one-off scripts or disposable experiments where the full ritual would be disproportionate, a lighter subset of the rules can be applied.

What FSE Is Building

The same constraints have been applied to eight systems taken from initial generation through production-ready testing in healthcare compliance, legal practice management, financial trading, elder care, education, corporate operations, chiropractic, and geotechnical engineering. One is now in true beta with real users.

Context is the code. — FlowState Engineering, Tenet 6

Explore the Methodology →