An experiment we're running at Liito Labs.
Two confessions to start.
First: every spec we have ever maintained eventually lied. Not through anyone's negligence. The document described the product at the moment someone wrote it, the product kept moving, and within a few months the spec was a museum exhibit. Everyone on the team knew which parts to ignore, which is another way of saying the document had quietly stopped being a spec.
Second, and more recent: AI makes it wonderfully cheap to generate design mockups, and we have the graveyard to prove it. Screens by the dozen, beautiful, disposable. When the iteration ended, nothing survived except some images and whatever we remembered about why we liked them. The thinking evaporated; only the pixels remained.
We are trying an approach that attacks the second problem with a cure for the first. We call it Vedos, the Finnish word for a printer's proof: the draft you review and mark up before committing to the real run. We believe this is real and that it will work. It still needs proving, and we intend to prove it, but unproven is not the same as uncertain, so we will describe it plainly, including what remains to be shown.
We wrote before about the layer that can't lie: the formal spec that governs behavior while the interface above it moves at the speed of taste. The gap we kept feeling: the spec knew everything about what the system must do and nothing about why any screen exists. Vedos puts those reasons into the layer that can't lie, and leaves how the screens look where it belongs, with taste.
The observation underneath it
Here is the thing we kept circling: intents change more slowly than implementations.
Screens get rebuilt. Components get replaced. Layouts get retasted every time someone has a strong opinion on a Tuesday. But "a mechanic lands on this page in the middle of dealing with a maintenance issue, and needs to log it" stays true across every one of those rebuilds. The reasons users show up somewhere are the most stable facts in the whole system, and they are usually the facts nobody writes down.
So we started writing them down. For every screen, a set of small entries, each answering three questions:
- Why is the user here? What happened in the world that brought them, this time.
- What are they trying to learn or do?
- How does the program help them do it? Concretely, in terms of what is actually on the screen.
A page gets several of these, because the same person visits the same page for different reasons on different days. If that sounds like user stories, it mostly is. The only novelty is the third question, because it is checkable: every element on a screen should serve at least one entry, and every entry should be fully served. An element that serves no recorded reason is clutter you can now find by query. A recorded reason with no path to accomplish it is a gap. A page carrying too many conflicting reasons is quietly asking to become two pages.
None of these ideas are individually new. There was an entire research field called design rationale in the eighties and nineties: issue-based information systems, structured arguments recording why every choice was made, real tools built to capture all of it. The field understood the value clearly and died anyway, of a cost asymmetry its own researchers diagnosed: the person doing the recording paid the cost, while the benefit landed on someone else, months later, if ever. Living documentation and task analysis kept rediscovering the same wall. What is different now is that the recorder is a machine. The AI does the capture and the upkeep, and that tedious half was the entire reason these practices died.
That is the bet, stated plainly: Vedos is design rationale, revived, with AI carrying the half that killed it.
How a session actually runs
The AI proposes; the human decides. That division is not a courtesy, it is the architecture.
A working session looks like a walk. The AI presents a screen, but before we argue about the screen, it presents the entries: here is who it thinks arrives here, carrying what, trying to do what. We correct those first. "Nobody arrives here for that." "You are missing the third reason." Getting the story right before judging the screen matters, because a screen reviewed against the wrong story generates confident nonsense.
Then we look at the screen itself, and there are two separate verdicts. Does it serve the recorded reasons? And is it good: clear, intuitive, something you would want to look at? These are different judgments and neither substitutes for the other. A screen can trace every element to a documented purpose and still be a spreadsheet. Taste stays a human responsibility on purpose. The system attempts good design, and it checks its own coverage mechanically, but it does not get to tell us something ugly is fine because the boxes are ticked.
The part we find most valuable is what happens with changes, after things ship. A proposed change gets checked against the recorded reasons at proposal time. The response we are designing for sounds like this: "Here is a change to this page. Ok, but the page can no longer serve this purpose, and the user can no longer get from here to where the flow says they should." Caught in the moment when catching it is cheap, and answered in terms of user intent rather than someone's memory of a meeting.
Always on, and honest about what it knows
Vedos is not a design phase that ends. The entry procedure is the same regardless of state: catalog what is true right now, then decide what to do about it. On a brand-new product the catalog comes back empty and the work is generative. On a shipped product it comes back full, and re-running it later acts as a validation: if nothing has drifted, it finds nothing. Anything it does find is a real discrepancy with a small set of causes: the code moved without the design record, the design moved without the code, or reality moved and one of our recorded reasons is no longer true.
One rule keeps this from becoming self-deception: cataloging never implies blessing. We are pointing this at our own product first, and our own product has plenty of problems. Recording what exists does not declare it correct. Everything the AI derives is labeled as an unreviewed hypothesis until a human reviews it, and the gap between "what is built" and "what we have actually approved" is kept visible instead of papered over. That gap is our defect list, and we would rather look at it than not.
Where this stands
The concept is settled, the intent-entry schema is in our spec system, and the first audit is already running against our own product. We think this will work, and the reasoning is not complicated: every earlier attempt at living design rationale died of maintenance burden, and the maintenance is precisely the part AI is good at. The idea stands on its own; the proof is a matter of running it, and the system conveniently defines its own pass condition: re-run the catalog, and a clean run means the record still matches reality.
There are honest open questions. Review time is finite, so approving the record has to stay cheap. Entries have to stay well written or they become noise. The prototyping rig (real React screens against faked data shaped like our real API, so a prototype is a head start rather than a drawing) is young. We will publish what the first full walks teach us.
If this works the way we expect, the deliverable is not a tool. It is a product whose design reasoning is current, queryable, and still true a year after shipping, which is something we have never had.