Home/Rulers Before Models/Rulers Before Models

Chapter 19 · ORCHESTRATION FOUNDATIONS

Six ways to launder a midpoint without breaking a single API contract

Product pane: midpoint widget refuse. The backend honours the dual-mark schema perfectly. The screen puts the forbidden number in the largest font on the page anyway. Rights design does not stop at the API.

Ch 19 · Product 7.5σ SURFACE_LAUNDERED_MIDPOINT

Product thinking, redefined

Product thinking for gated financial AI is rights design: what the user, or the agent, is allowed to do under which cards. The job to be done is not "predict next return." It is "decide under uncertainty with an audit." Compliance is not a PDF appendix stapled after a demo ships. It is tool behaviour, audit trails, as-of honesty, refusal surfaces, dual-frame visibility, and the deliberate absence of any silent midpoint peace.

How far apart the frames actually are

Before the screens, fix the arithmetic so severity is not a matter of taste. Read each band as a four-standard-deviation interval, which is how the frame card declares them: the spread cloud has standard deviation 0.16/4 = 0.0400, the curve cloud 0.21/4 = 0.0525. The denied midpoint 1.80 sits 7.50 standard deviations above the spread frame's centre and 5.71 standard deviations below the curve frame's centre. Under the spread frame, the probability of a mark that high is about 3.2×10-14. Under the curve frame, the probability of a mark that low is about 5.5×10-9. The two frames do not merely disagree about the value. They disagree by roughly five orders of magnitude about how likely 1.80 even is, and their average sits at exactly the coin-flip point: formally zero information, dressed as a number.

Six screens, one fully compliant API underneath each

Every rendering below can be built on top of a backend that honours the dual-mark schema, stores both frames in the audit bundle, and never once returns a blended field. This is the table that gets built by people who read the constitution carefully and then designed a screen, which is exactly why it matters.

RenderingWhy it passes reviewWhat it actually did
1.80 (range 1.50-2.10)Both frames are shownPuts a 7.5σ event in the largest font, demotes both honest models to an error bar
A gauge with a needle at 1.80, shaded band around it"It's a visualisation, not a mark"A needle is a point estimate; the shading is decoration around it
Two rows plus a bolded "Blended" rowNothing was hiddenThe bolded row is where the eye goes; copy-paste takes one row
A sparkline of both frames with one averaged lineHistorical context is usefulManufactures a time series of a number no card can produce
Sort order that places the crowd mean first"It's just the default sort"A default is read as a recommendation
A CSV export with a single mark column populated by the meanThe screen itself was compliantThe export is the surface most downstream systems actually consume

The last row is the one that reaches production. Screens get design review; exports get a ticket that says "analysts need this in Excel." An export schema is a product surface with the same obligations as a screen: it must carry two columns with frame identifiers, never a single mark column, and it must carry the as-of hash in a header row so a spreadsheet emailed twice can still be traced back.

Two rules that discharge the whole table

First: no rendering may occupy a visual position that implies summary unless a card can actually produce the number in it. Largest font, first row, needle position, bolded row, leftmost column of an export — all of them are summary positions, and summary positions require a card-authorised number. Second: a control that requires the operator to choose must not have a default, because a default is a recommendation, and there is no card authorising a recommendation between frames. The violation code is SURFACE_LAUNDERED_MIDPOINT, owned by the frame card, and its fixture is unusual for this book: the assertion runs over rendered output, not over a schema, because that is the only place this particular failure actually lives.

Designing for the refusal, not around it

Every gate this book builds can be defeated by a user interface. A refuse that renders as a dismissible yellow toast is not a refuse; the operator learns to click through it. An inconclusive verdict sharing a button with allow is not a third value; it is allow with an asterisk nobody reads. A compliant product surfaces the two clouds honestly, escalates instead of averaging, and makes inconclusive as visually distinct as refuse. The discipline is the same one this book applies to models and agents everywhere else, only now applied to a screen: nothing downstream of a correct backend earns the right to quietly repaint the answer into something friendlier.

Book: Chapter 19 in Rulers Before Models.

ch19Open on YouTube ↗

Next. Open ch20: Control plane: Clearance. Previous: ch18 (Pipeline design for AI-powered research systems). Rulers Before Models index.