What a screen costs: depth

An Interface costs one function of the definition, and a machine checks it. A screen costs a product of counts, and a person judges every cell of it.

An Interface is a sumCopy Anchor Link

Each Interface is one pure function from Nouns and Verbs to calls. The API route, SDK method, CLI command and MCP program for Lease.renew all come from one record. A check compares each output with the definition.

leaseclock.com declares Property and Lease. They hold 12 operations: 5 standard Verbs each, plus Lease.renew and Lease.terminate.

The forms grow, but the work does not. A new Verb reaches every Interface with nothing new to review.

A screen is a productCopy Anchor Link

A screen has no single function to check. Its axes are mostly independent, so the cells multiply, and a function cannot say whether a cell reads well. API only or with an App counts 96 cells for clinicshift.app's Swap; Lease runs higher.

A second Theme doubles the cells to 288. A fourth Persona adds 48.

Each cell needs taste, not only correctness. A terms value in dark mode, seven date columns at phone width, an owner's empty list: each is a judgment.

Gaps in the definition show only on a screen. A Verb with no declared inputs still has a call form on every Interface, but a form for it has nothing to draw. So each screen pushes a fact back into the definition, as Verb inputs: what a form needs explains.

What each row costsCopy Anchor Link

The Admin turns the product back toward a sum. It serves one Persona, the team, with one Theme, and 19 rules stand in for judgment. A rule decides once for every Noun, so a new Noun costs nothing to review.

The price is loss. Rules guess where the definition holds no type: a record's name, 7 list columns, no input for json. Admin: derivation rules and edge cases lists every rule and its edge cases.

3 of 7 rows print. The other 4 wait for code that serves them.

PlanThe rows past the Admin

In the design, the Portal costs the platform a fixed, steep amount and the Startup almost nothing. It grows with data states, not Nouns.

An App per Persona multiplies Personas, Nouns, data states and Offer gates. Your own screens are built by hand, one at a time, because the definition says nothing about layout or intent.

Why policy holds behind the APICopy Anchor Link

A rule that lives in a screen holds only in that screen. The CLI, the MCP server and every Agent reach the Verb without it, so the rule belongs to the Verb, as Software sets out.

Policy kept in screens also doubles the product. Each Persona and Verb pair then needs a check and an omission, and the two must agree in all 144 cells.

In the Admin, the Verb refuses in the browser: its rules run there, against the data layer. So no promise about the API enforcing Permissions prints. App guarantees holds 1 printed guarantee and 4 that wait.

PlanPolicy behind the API

In the design, the API enforces every Permission, and a screen holds no rule the API lacks. A screen omits a button only to match what the API already refuses.

What a Startup does with the countsCopy Anchor Link

Start with the sum: define the Nouns and Verbs, and ship API only. Add the Admin when the team needs to edit records, because its rules cost nothing per Noun.

Add screens for Customers only where people sign in and the cells pay for themselves. API only or with an App makes that choice by who signs in.