I have an app with an absurd number of features. A 3D mall. A neuroscience simulator. An inventor's workshop that finds real parts. Arcade games my kids play. And if you asked me what the most unique structure in that codebase is, the answer surprises people:
It's the database schemas. Specifically, what's written inside them.
In my app, the file that defines each data type carries a contract. The kind of memory-lab result that stores your reaction time describes itself as "a self-recorded result the user chose to save — not a clinical or EEG measurement." The public photo tool's usage log says, in its own schema: "numbers only. No photos, no filenames, no accounts, no IPs." The payment-request tool declares "the app does NOT move, hold, or process money and takes no fee" — right where the money record is defined.
Why does that matter? Because the disclaimer travels with the data.
Most software handles honesty in the UI layer — a gray paragraph at the bottom of the page, added after the lawyers or the conscience show up. It can be deleted. It can be forgotten when the next screen gets built. Mine lives one layer down, in the definition of the record itself. You can't build a screen that overclaims without first editing a contract that says what the thing IS — and when you read that contract, you have to decide, consciously, to break it.
Here's a concrete example from today. I audited my inventor tool and found that some supplier links opened a search page while looking like a product page. Classic honest mistake: the suppliers' product URLs need a slug the part number alone can't produce. The lazy fix is to shrug — "close enough." The quiet fix is to hide it. The fix my architecture pushed me toward was to make honesty a typed field: every link now comes back from the backend as either "product" or "search," and the UI labels a search link "Find this part" instead of "View part." Same with part photos: if the app couldn't actually fetch and re-host the image, it shows an honest category icon instead of a broken hotlink. The truth became data. Data gets checked. Marketing copy doesn't.
There's one more piece: I keep a written list of my own dead ends — every approach I tried that failed (the framework that wouldn't build, the screenshot service that returned black rectangles, the browser text-to-speech that scared my kids). Failed experiments live in the project memory as first-class facts, so the same mistake doesn't get retried, and the next feature starts from what's actually true.
Why am I telling you this? Because we're all wiring AI into products right now, and AI is a confident fabricator by default. Most teams fight that at the prompt level — add a line to the system prompt, cross fingers. I moved the fight down into the data model, the layer that outlives any single page and that every future feature has to read.
If you build things, try this one move: when a claim about your system really matters — what's measured, what's stored, what's NOT happening — make it a field. Write it into the schema. You'll find that structure keeps you honest in a way that willpower doesn't.