Laws before code

A constitution before the first feature

Longview manages my house the way a facilities team manages a building. Thirty-one tracked components, thirty-four warranties with every term traced back to its source document, and a thirty-year repair and replacement funding plan. It proved its operating rules in daily use for a while, and I am now rebuilding it properly.

Most side projects start with code. This one started with a constitution. Eight articles, versioned like software, written in the language of standards documents where "must" and "never" mean exactly what they say. It forbids the system from inventing a fact. It requires a human decision before anything consequential happens. It makes each household's data isolation a structural property rather than a promise. Every specification, plan and line of code has to comply, and amendments need documented rationale, a review, and a version bump.

Why bother, for a system with one household

Because the builders are agents, and agents drift. A rule that lives in my head evaporates the moment a conversation ends. A rule in a versioned document, enforced by a compliance script that fails when a specification loses its link to its work items, survives every session.

I learned this the embarrassing way. Within hours of starting the build I had stated the same law in three different documents, and they had already begun to disagree with each other. The fix became doctrine: laws live in exactly one place, preferences live in another, and a compliance script checks the whole tree on every change. Currently that is fourteen specifications mapped one-to-one onto sixty-five tracked work items.

Every irreversible decision gets attacked first

I do not let myself approve my own proposals. Anything irreversible, an isolation model, a new data store, a vendor, goes to a review board of six specialist seats that I convene on demand. The process is always the same. I write the strongest proposal I can. Five reviewers attack it in parallel from different angles. A chair whose entire job is disagreement deduplicates the findings, breaks the ties, checks the citations, and writes a verdict with severities.

It sounds like theatre until you watch it catch something. My favourite feature, a shared knowledge base that lets one household benefit from research another household already triggered, went in as a tidy proposal and came back with three blocking findings. Private documents could launder into the shared store. A poisoned web page could attack every household at once. And my caching design quietly violated my own rule against inventing facts.

The redesign that survived is meaningfully different from what I proposed, and the losing arguments are written down with named conditions for reviving them. The best finding was about me: my own cost estimate did not survive as a fact. It now sits in the record as a labelled hypothesis with a measured range and a success criterion that will validate or refute it.

Choose the architecture for whoever writes the code

The most consequential technical decision in this build is household isolation, and I made it from an honest reading of my workforce. Agents write most of this code. The classic approach, one shared database where every query remembers to filter by household, fails exactly where generated code fails: a single forgotten clause on the four hundredth commit.

So each household gets a physically separate database. A cross-household query is not risky, it is unwritable. The design records put it concretely: with a shared store, every query is one missing WHERE clause away from leaking another household's data, and that is the exact failure class of AI-generated code.

The same logic splits the work between model and code. Models identify and synthesize. Deterministic code decides and computes. Money maths, dates, and anything that ends up in a household's funding plan is tested code held to a full coverage gate. And no claim is labelled verified because a model said so. A separate judge re-fetches the cited source and mechanically checks that the claim is actually in it.

The platform choice, re-examined on purpose

Midway through the design I forced the biggest question back open: is the platform vendor I chose actually right for this workload? Six review rounds later the answer was yes, and the yes was not the useful output. The useful output was the strongest honest case against my own choice, written into the verdict, plus eight measurable triggers that reopen the question. A cost threshold, an outage budget, specific service ceilings, a failed recovery drill.

The review also found the two places where my confidence was asserted rather than earned. My documented escape hatch was a sentence in a design record. My backups lived inside the same vendor account they were meant to protect. Both became funded work items before any pipeline code exists: backups replicated encrypted to a second provider with a credential that can write but never delete, and a rehearsed restore into an entirely different database engine.

The board's ruling, quoted as written: "capped-on-paper is not capped." An escape hatch that exists only as a sentence in a document is in the same category, so until the restore drill passes, the exit is classified as unproven, and the claim that it was already covered is on record as overruled.

Trust numbers you fetched, not numbers you remember

Every free-tier limit and quota this build depends on was re-verified against the vendors' own published documentation on a dated pass before it was allowed into a planning document. The audit corrected my tables in several places, including one service where the real ceiling for my isolation model was a fraction of what I had assumed, and another where "free hours" turned out to mean ten minutes a day.

The result is twenty-seven tracked limits, each with the plan it applies to, how it gets measured, and a named action that fires at eighty percent, because a hard ceiling deserves a plan rather than an alert. Where a vendor's own pricing page contradicted itself, the document says so and the line reads "verify at signup" instead of carrying a guess.

Delegate everything except the decisions

The operating model is one person directing agents, so I wrote down what only the person does. Agents run the specifications, the code, the reviews, the audits and the research end to end. I keep about a dozen reserved powers: accounts and payments, anything touching a real household's data, production deploys, and the final gate on anything a user will see.

The incident-repair agent here is designed to diagnose a failure, write the fix, and prove it with a failing test, and it is structurally barred from merging, deploying, or speaking publicly. Its specification requires a test in the build proving it cannot reach those credentials, and that gate must pass before it ever runs.

That last clause is the pattern I care about most. A boundary the automation is asked to respect is a suggestion. A boundary it cannot physically cross is a control. Wherever I can, I buy the second kind.

Where exactly that line sits is a per-system judgment rather than a belief. In HurricaneWise, my public weather tracker, the repair agent may now merge and deploy its own gated fixes. This system holds a household's financial records, so its line stays exactly where it is.

The honest scoreboard

Here is the tension, stated plainly, because a report that hid it would violate its own rules. The governance is real: a constitution, five architecture decision records, four adversarial verdicts, fourteen specifications, a verified limit table. The new code, as of today, is about thirty lines of tested arithmetic.

Every mechanism above exists to make the next ten thousand lines cheap, safe and fast to write, and that claim is now the thing under test. The build phase will show whether laws-first was discipline or an elaborate form of procrastination. I think it is the former. I have written down enough to be proven wrong either way, which is rather the point.