Governance as Scaffolding
Why the system's goal is to make itself unnecessary
Halfway through building Togetherly, I killed a feature before the constraint file flagged it.
The spec called for an observation dashboard — a panel where the primary caregiver could monitor activity across all family members. It would have been the natural next screen. In a previous version of my practice, I would have built it, shown it around, and discovered three sessions later that it undermined the entire product’s trust model. A caregiving app where someone is watching creates a power dynamic the product was designed to avoid.
I didn’t need the constraint file to tell me this. I’d internalized it from four prior projects where governance artifacts had caught exactly this kind of mistake — the feature that makes sense locally but violates something architectural. The constraint file was still there. I didn’t consult it.
Every governance artifact I’ve built assumes it will stay. Constraint files, decision logs, adversarial review pipelines, concept registries — I treated them as permanent infrastructure. The governance layer has caught real mistakes, prevented real drift, and produced artifacts I use daily.
And the goal may be for all of it to become unnecessary.
Two critiques of this kind of practice have been sitting with me.
The first is the irony argument: any practice that treats structured earnestness as a virtue is performing a kind of devotion. The constraint files, the coined vocabulary, the meticulous logs — they’re rituals. And rituals have a way of becoming the point. You start governing because the governance produces better outcomes. You continue governing because governance is what practitioners like you do. The rigor of the process replaces the quality of the output as the test.
I’ve felt this. The cooling-off gate I installed last week — requiring new skills to sit for seven days before building — exists specifically because I noticed I was building governance faster than I could evaluate whether the governance was working.
The second is the composability argument: real architectural skill means knowing where to draw boundaries, and you can’t draw the right lines before you understand the joints. A practitioner who writes the constraint file before writing the code risks locking in boundaries that fail in practice. And the governance layer would enforce those wrong boundaries with the same diligence it enforces the right ones.
I know this because it happened. Early in the system, I wrote a constraint prohibiting cross-workspace file references — each workspace had to be fully self-contained. Three projects later, I’d routed around it so many times the constraint was generating more overhead than the coupling it was supposed to prevent. The governance layer dutifully enforced a boundary I’d drawn before I understood the joints.
Both critiques assume the governance stays.
Scaffolding goes up so the building can go up. Then the scaffolding stops being load-bearing.
The metaphor isn’t perfect — scaffolding is passive, and governance actively shapes what gets built. But the temporal logic holds. The constraint file is load-bearing at one phase and overhead at the next. Both states are correct.
You write “no features that create surveillance dynamics” and build three products under that constraint, and you discover which features actually create surveillance dynamics and which ones just looked like they might. The constraint teaches you to see the pattern. Once you see it, the constraint is overhead.
Not because I removed the constraint file. It’s still there. But I didn’t need it for that call. Four projects’ worth of governance had compressed into a reflex.
Decisions that required constraint-file consultation in month one — trust model violations, scope boundary checks, voice register slips — now happen without it. The shift is categorical, not situational. The file catches nothing new in those categories. It still catches mistakes in categories I haven’t internalized yet. And it doesn’t replace the judgment required to write the right constraints in the first place — the cross-workspace failure proved that. Governance externalizes pattern recognition until repetition makes it internal. It doesn’t generate the patterns.
The irony critique worries about practitioners who never leave the explicit phase. Who treat governance as devotion rather than development. That’s the real risk. If the constraint file becomes an identity rather than a tool, you’re maintaining scaffolding on a finished building because you’ve confused the scaffolding with the architecture.
The Honest Part
If the system’s goal is to become unnecessary, what am I building?
The answer I’ve landed on: nobody skips scaffolding. The practitioners who work without visible governance aren’t ungoverned — they’ve internalized the constraints through years of building things wrong. What the explicit system does is compress that timeline. Months of building under constraints that make mistakes visible earlier, instead of years of trial and error.
But I can’t yet prove the compression claim fully. I can point to one category shift — trust-model decisions that moved from explicit to implicit in four months. I can’t yet point to a whole workspace where I’ve taken the governance layer down and the work held up. That experiment hasn’t run yet.
And there’s a harder question the irony critique raises that I haven’t answered: what does failure look like? If governance becomes devotion instead of development, the failure mode isn’t dramatic. It’s invisible — the practitioner who maintains every artifact, consults every checklist, and never notices that the artifacts stopped teaching them anything new. The system looks rigorous. The judgment underneath stopped growing. I’d know it was happening if the constraint file kept catching the same categories of mistakes month after month. If the error profile doesn’t change, the governance isn’t building anything — it’s just preventing.
The signal to start taking scaffolding down is when maintaining it costs more than what it prevents.
The constraint file is most valuable the week before you stop needing it. After that, it’s archaeology.
Robert Ford builds products, writes stories and essays, and publishes The Intelligence Engine — a Substack about building AI practices that compound. His other writing lives at Brittle Views.
The scaffolding argument in this piece owes a debt to Gordon Brander's "Folding Context" (https://newsletter.squishy.computer). He frames context management through Ashby's requisite variety — the solution has to be as complex as the problem.
What I'm calling scaffolding maps to his compression step: explicit governance reduces variety so the practitioner can internalize the categories. Once internalized, the constraint file becomes archaeology. Brander describes folding as a manual process — extract, compress, persist. What I'm finding is that a persistence layer changes who does the folding.