Laws before code
I'm rebuilding the system that runs my home. Before any feature I wrote an eight-article constitution and set up a six-seat review board for irreversible decisions, and its verdicts get written down.
Longview and the rebuild
Longview runs my home basically the way a facilities team runs a building. As of September 2026 it tracks 35 components and 39 warranties (32 of them with a source link), and it has a 30-year repair-and-replacement funding plan at 3% inflation. The assistant answers only from the household's records, maintenance only gets logged after I confirm it, and if data is missing the field stays blank. Those rules held up in daily use. The rebuild is early, and it's private.
The first thing I wrote for the rebuild was a constitution. It has eight articles and a version number, and "must" and "never" in it are binding. Among other things, the system can't invent a fact, anything consequential needs a human decision first, and each household's data is isolated by the structure itself. Specs, plans and code all have to comply with it. Changing it takes a documented rationale and a review, and the version goes up.
Why bother for one household
Agents write most of this system, and they don't remember what I told them in an earlier chat session. So the rules are in a versioned document, and a compliance script checks every change against it.
I found that out within a few hours of starting. I'd written the same law into three documents and they already disagreed with each other. Now each law is written once, in the constitution, and preferences go in a separate document. The compliance script checks the whole tree on every change, which right now is fourteen specifications mapped onto sixty-five tracked work items.
The review board
Anything I can't undo (an isolation model, a new data store, a vendor) goes to a review board with six specialist seats before I act on it. I write the proposal and five reviewers go through it in parallel. Then a contrarian chair merges what they found, checks their citations and writes the verdict with severities.
The feature I liked most was a shared knowledge base, so one household could use research that another household had already triggered. The board blocked it on three findings. The caching design broke my own rule about not inventing facts, private documents could leak into the shared store, and one poisoned web page could reach every household at once.
I ended up with a different design from the one I proposed. The record keeps the arguments that lost, and for each one it says what would get it reopened. My cost estimate is in there too, labeled as a hypothesis, with a measured range and a success criterion.
| Seat | Its question |
|---|---|
| Platform architect | does this design hold at ten thousand households |
| Security reviewer | how does this leak, and who can poison it |
| AI-pipeline engineer | can the model invent a fact and get away with it |
| Principles reviewer | one source of truth, tests first, no drift |
| Product and cost | is every number real, is the cost worth what it buys |
| Contrarian chair | breaks ties, audits citations, writes the verdict |
One database per household
Agents write most of the code, so I picked the isolation model with that in mind. With one shared database every query has to filter by household, and a generated query that leaves the filter out would return other households' data.
So each household gets a physically separate database, and a query without the filter can only see that one household.
I use the models to find things and pull them together. Anything that's a decision or a calculation goes to deterministic code. Money math, dates and anything that ends up in a funding plan are tested code behind a full coverage gate. A claim only gets marked verified after a separate judge fetches the cited source again and checks mechanically that the claim is actually in it.
Reopening the platform choice
Partway through the design I reopened the platform question, meaning whether the vendor I'd picked is right for this workload. After six review rounds the answer was yes. The verdict also records the strongest case against my choice, and eight measurable triggers that would reopen it, for example a cost threshold, an outage budget, specific service ceilings or a failed recovery drill.
The review also caught two places where I'd claimed confidence I had no evidence for. The plan for leaving the vendor was one sentence in a design record. And my backups lived in the same vendor account they were supposed to protect. Both are now funded work items, ahead of any pipeline code: backups replicated, encrypted, to a second provider with a credential that can write but can't delete, and a rehearsed restore into a different database engine.
The board had already refused once to count a cap that only existed in a document, and it did the same with the exit plan. It's marked unproven until the restore drill passes. I'd argued it was already covered, and the record shows I was overruled on that.
Free-tier limits
Every free-tier limit this build relies on got re-checked against the vendor's own published docs, in a dated pass, before it was allowed into a planning document. That audit corrected my tables in several places. On one service the real ceiling for my isolation model was a fraction of what I'd assumed, and on another one "free hours" meant ten minutes a day.
That left twenty-seven tracked limits. Each one has the plan it applies to and how it's measured, plus a named action at 80 percent. Where a vendor's pricing page contradicted itself the document says so, and that line reads "verify at signup".
What stays with me
Agents write the specifications and the code, and they run the reviews, audits and research. I've kept roughly a dozen powers for myself: accounts and payments, anything that touches a real household's data, production deploys and the final gate on anything a user will see.
The incident-repair agent in this build is designed to diagnose a failure, write the fix and prove it with a failing test. It can't merge, deploy or post anything public. Its specification requires a test in the build proving it can't reach those credentials, and that test has to pass before the agent runs even once.
On HurricaneWise the repair agent's scope is held by its instructions and by the shape of the incidents. No technical restriction limits which files it can edit.
I decide where that line goes separately for each system. HurricaneWise is a public weather tracker, and its orchestrator merges and deploys a repair once every check is green. Longview holds a household's financial records. There a production deploy is on my reserved list.
Where it stands
As of this writing the new code is about thirty lines of tested arithmetic. Everything else so far is paperwork (the constitution, five architecture decision records, the board's written verdicts, fourteen specifications, the limit table).
I don't have evidence yet that any of it makes the code easier to review or safer to run. The restore drill and the repair agent's credential test both still have to pass.