Tiersel

Tiersel · Teaching note

Let the model choose a card, not its numbers

An AI interface can show the right-looking chart with the wrong answer. A useful boundary is to calculate the facts first, construct the available cards from those facts, and let the model choose only among those cards.

This small JavaScript example isolates that boundary. It uses four invented service requests, no model, no network and no packages. The accepted selection uses only card IDs; any numeric field in the simulated model response is ignored. Run it with Node.js:

node inspectable-cards.mjs
Download the example

The program checks five failure or consistency cases and prints two cards for the three synthetic open requests: a count of 3, and a breakdown of 2 pothole requests plus 1 missed-pickup request. The attached file is the complete example.

The boundary

  1. Validate a narrow request scope. An unsupported status fails instead of silently becoming “all.”
  2. Calculate a count and a grouped breakdown over the same selected records.
  3. Build an immutable catalog of cards from those calculated facts. Each card retains the fixture record IDs behind it.
  4. Accept a display suggestion only if it contains a nonempty, unique list of known card IDs. An invalid suggestion uses a deterministic fallback.

A fake value: 999 in a suggestion has no effect: the output is assembled from the catalog, not from the suggestion. An unknown card ID triggers fallback. This is more useful than asking the model to double-check its arithmetic after it has written an answer.

What this does not prove

Deterministic calculations can still answer the wrong question. A planner might misunderstand “open,” choose the wrong date window, or apply the wrong neighborhood. Test the intended scope separately from the calculation, and make the applied filters visible.

The fixture IDs here are an inspectability aid, not a production access-control design. Real systems need authorization before returning source records, limits on returned data, and a stable snapshot for comparisons. Request counts are not counts of unique people, and repeated reports are not necessarily separate incidents. If a population denominator is missing, a per-capita rate should stay unavailable.

Where this pattern comes from

I build Tiersel. Its Houston interface separates structured query planning, database calculations and display composition. The layout model selects from prepared display candidates; the calculation path also supports a deterministic display fallback. This example illustrates one boundary rather than reproducing that application or benchmarking it.

The recorded Houston walkthrough shows the product context. Houston's real service-request source is the City's 311 data page; none of that real data is included in this example.

Prepared with AI assistance. The accompanying checks validate this synthetic example only; they do not establish production accuracy, customer results or live provider availability.