Ask once. Own the answer.
Most of the decisions inside software are not inference problems. How many rows match? What is the total of that column? How many are missing a value? are arithmetic over data you already hold. Sending them to a model means paying per token, every time, for something that was checkable all along — and getting back an answer you cannot verify.
Describe the question once. A model composes a specification. The floor decides whether that specification is admissible. What you keep is a local tool that answers it offline, free, and forever — with its own derivation attached.
Python 3.9+ · standard library only · no network, no key, no model, no telemetry
How it works
1 · You describe the question
In English. "total value of approved invoices". The tool prints a prompt carrying your column names and a closed vocabulary of primitives.
2 · A model composes a spec
Not code — a pipeline. rows → filter(approved) → sum(amount). The model can only compose from the vocabulary; there is no escape hatch into Python.
3 · The floor admits it, or refuses
Seven checks. Deterministic? Do the columns exist? Does the verifier actually reject wrong answers? Does it abstain without evidence? Is it grounded in your data, or a constant the model memorised?
4 · You keep the tool
Signed, promoted, and served over MCP from your own machine. model_calls: 0, forever.
What an answer looks like
{"status": "DERIVED",
"value": 1290.49,
"model_calls": 0,
"derivation": "rows -> filter(approved) -> sum(amount)"}
The derivation is not a log line. It is the answer's justification, and it is the same string the floor admitted. A confidence score cannot be inspected this way; a pipeline can.
Three things it refuses to do
It will not guess. No evidence for your question returns NO_EVIDENCE — not a plausible number. A floor that always has an opinion is not a floor.
It will not run an unadmitted tool. Specifications carry a signature from the floor that admitted them. Edit one by hand and the runtime refuses it, names it, and serves the rest.
It will not invent a domain. A question the floor cannot check is reported unmappable. That question genuinely still needs a model, and saying so is the output — not a failure.
Download
The runtime is 303 lines of standard-library Python. Read all of it before you run it; that is the point of it being small.
Download runtime 1.0.0 (zip) ↓
shasum -a 256 -c SHA256SUMS python3 -m floor_runtime.serve --data invoices.json --tools ./floor --list
SHA256SUMS · README · free to use, including commercially
Why the gate is not in the download
The admission gate — the part that decides whether a specification may become a permanent tool — is not in this package, and this is a design decision rather than a licensing one.
If the gate shipped, a wrong specification could be hand-written, loaded, and would then answer confidently, offline, forever, with no model left in the loop to catch it. That is a worse failure than a model being wrong on each call, because nothing ever re-examines it.
So the gate stays where it can be maintained and audited, and what runs on your machine is an executor — complete for execution, and honest about being only that. The runtime contains no network code; you can confirm that by reading it.
Status, honestly
PROTOTYPE. The runtime, the signature check and the MCP server are real and tested. The primitive vocabulary is small — rows, filter, and seven reducers — and the data model is plain JSON rows. A question that needs anything outside that vocabulary is correctly reported unmappable.
The same architecture is measured elsewhere in this library: a learned floor on real Atari ROMs, where it is worth +32% on one game and −12% on another, and a symbolic cube solver that refuses an impossible cube by name.