Skip to content
How much to read

Knowledge base

projects / clarity / decisions

The front desk is refused money twice, at the gate and in the app

Clarity 2 refuses the attendant the money addresses with a 403 from the gate before any app bytes are served, and again inside the app.

decision · current · updated 2026-09-21 · Clarity case study

Context

The attendant books Clarity 2's phone schedule and must never see money. Both users reach the same address through the login gate, and the app's screens are ordinary client-side routes that a person could type or reach by a link. The requirement is that no amount, fee, balance or money word is reachable by the bar, by a link, by client-side navigation, or by typing an address.

Decision

The wall has two layers. The gate answers 403 to a request for /insights, /expenses or /settings that carries a front-desk cookie, matching those three addresses exactly, with a styled page in the palette and a way back to her Today. It does this before any of the app's bytes are served, so the desk's screens never arrive in her browser. The app refuses the same addresses itself. The dentist is refused nothing: the clinic makes him the admin of everything, so the wall is deliberately not symmetric.

Alternatives rejected

  • A redirect instead of a 403. A status code is what a fresh checker can execute unambiguously, so the refusal is a code rather than a bounce.
  • One layer only. The gate's refusal is the one provable with a status code; the app's is what stops a client-side hop once the shell is loaded. Neither covers both cases alone.

Why

Two different ways of reaching a screen need two different refusals. A direct request never touches the app, and an in-app hop never touches the gate, so the same rule is written on both sides.

Consequences

The gate now knows three addresses that belong to the app, written in as strings. A later work order that adds a desk-only screen has to add it there too, or the wall will have a gap; this is recorded as a gap rather than solved. The checker also confirmed the wall is drawn on addresses rather than on the app's own downloaded files, which the attendant's browser can still fetch directly; that gap is recorded as well. See known gaps and the login gate.

Status

Built on 2026-09-20. The checker asked for each money address with a front-desk cookie and read a 403, and with the dentist's cookie and was served normally. See work order 2, the login gate and the product overview.

This page was written by a model from my own repositories and checked by a second one against the same sources. I did not write it, and no version of it was approved by me before it went up. How that works, and where it can still be wrong.