From Shloka to State Machine

The Akriti Dialogue ended with a shloka and a punchline: two things that don't exist bring forth a form that's useful but cannot truly be. Good. Now what?

The problem with philosophical frameworks is they stay philosophical. You get a beautiful observation — the form is exputed, not designed — and then what? You still have a screen to build, a developer who doesn't know where the loading state goes, and a PR review that degenerates into "I don't know, it feels off."

The question that matters is: can you turn "expute" into instructions?

The constraint hypothesis

The thesis from the dialogue was that form emerges from the meeting of constraints — not from aesthetic judgment, not from design talent, not from having the right Figma file. If that's true, then building good UI reduces to: enumerate the constraints, tighten them until only one form fits, ship that.

This is how databases work. NOT NULL, UNIQUE, CHECK, FOREIGN KEY — you don't design your way to data integrity. You constrain your way there. The absence of equivalent mechanisms for frontend is why "intuitive UI" feels subjective when it shouldn't be.

So the experiment: what if you treated UI development as progressive disambiguation? Start with everything possible, eliminate options layer by layer, until the form that's left is the one that works.

Six layers of elimination

Every UI feature has six questions to answer. Each question narrows the space:

L5 — Domain Facts. What is true about the world? A tract belongs to exactly one client. Acreage may disagree with FSA records. These aren't requirements — they're physics. Remove any fact and the UI does something wrong in the real world.

L4 — User Paths. Who arrives, from where, wanting what? A client uploading their own data needs maximum guidance. An internal operator needs minimum. Same screen, different constraints. If you don't enumerate the paths, you build for one and break the others.

L3 — State Enumeration. What are all the states this view can be in? Not the three you thought of. The 8-15 that actually exist: idle, loading, validating, invalid, parsed, partial, clean, conflicts, empty, stale, unauthorized, offline. Most screens handle 3 of these. Users encounter 12.

L2 — Screen Composition. What regions exist, how do they relate? A tract table and a geometry map are synchronized — select one, the other highlights. This is structural, not aesthetic.

L1 — Component Contracts. Typed interfaces. Props in, events out. Renderable with mock data. Domain-agnostic.

L0 — Visual Primitives. Design tokens. Not invented values — system values.

The top half (L5-L3) pushes down from domain truth. The bottom half (L2-L0) pushes up from the existing toolkit. They meet in the middle. The form that survives is the one consistent with both directions.

From levels to commands

Levels are a framework. Developers don't use frameworks — they use tools at specific moments. So the levels became four commands, each locked to its slice of the stack:

/discover handles L5 and L4. It's a curious consultant: asks about domain, people, context. Redirects any talk of components or layout back to "but what's actually true about this domain?" It's the command that says stay in the problem space.

/spec handles L3. It's a precise engineer: takes discovery output, walks through every step, applies the 18-state vocabulary, challenges you on completeness. "You listed 4 states. Real workflows have 8-15. What happens when data is stale? When the user loses auth mid-flow? When three of five imports succeed and two fail?"

/compose handles L2. Before defining anything, it checks: does the framework already do this? Does the component gallery have this pattern? Does the codebase already have a version? Only when all three come back empty does it define new structure. That single reflexive check — does this already exist? — would have caught most of the DRC violations I've seen in real codebases.

/build handles L1 and L0. It implements exactly what the spec says. Every L3 state gets a render. Every acceptance criterion gets a check. It doesn't question the design — it verifies against it.

The chain enforces phase boundaries. You can't jump from discovery to build. You can't talk about components during spec. The constraints constrain the process of constraining.

Nielsen as loss function

The levels tell you what to check. They don't tell you how to choose between two valid approaches. For that you need a scoring function.

Nielsen's 10 usability heuristics are that function. Each heuristic maps to a constraint level: visibility of system status is an L3 concern (is the loading state rendered?), consistency is a DRC concern (does this concept work the same way everywhere?), error prevention is L3/L5 (does the UI prevent domain-illegal actions?).

Score two competing approaches against the same 10 checks. The tradeoffs become explicit. "Approach A scores higher on H1 (visibility) because it renders partial-success distinctly. Approach B collapses partial-success into success, which violates H9 (error recovery) because the user can't tell what failed."

That's not aesthetic judgment. That's a specific claim about a specific heuristic at a specific constraint level. You can agree or disagree with it, but you can't wave your hands at it.

What actually happened

The Akriti Dialogue produced a concept: form is exputed from the meeting of constraints. The concept produced a question: what are the constraints? The question produced six levels. The levels produced four commands. The commands needed a scoring function. Nielsen provided it.

Each step was a concretization. Philosophy → framework → tools → objective function. At no point did anyone sit down and "design" the system. It was exputed — brought forth from the reckoning of what you'd actually need if you took the thesis seriously.

Which is, of course, the thesis demonstrating itself. Two illusions met, applied constraints progressively, and a form emerged that neither would have built alone. The shloka said: in the midst of Maya, the fruit of action. The fruit of action is a state machine with 18 canonical states and a four-phase command chain.