Footnote MCP server

Footnote

Claim-level provenance for AI over business data. Every number in an answer traces back to the rows that produced it — clickable at read time, exportable for an auditor, and tamper-evident.

An MCP server, a provenance store, and a demo UI showing what the combination looks like.

npm install
npm run demo      # http://localhost:4711
npm test          # 25 tests, including the invariants below

Node 22.5+ required (uses the built-in node:sqlite, so there is no database to install).

Postgres is opt-in. The same schema, seed and query set run against it, and the same suite has to pass on both:

npm run db:up     # Postgres 17 in Docker, seeded from migrations/001_init.sql
npm run test:pg   # the identical 25 tests, against Postgres
npm run demo:pg   # the demo, against Postgres

The problem

Language models produce plausible continuations, not true ones. Point one at a business database and it will confidently report a number that no query produced — and the fabricated figure is indistinguishable from the real one, because both come out of the same machinery.

The usual answers don't hold up here. Uncertainty signals catch the fuzzy cases, not the fluent ones. A verifier built from the same model can confirm a fabrication as easily as catch it. And in finance, inventory or procurement, "the model said so" is not an answer anyone can act on.

What does work is structural: never let the model produce the number.

The architecture

question
     │
     ▼
  model ──────────► picks an operation from a catalog and supplies typed args
     │                (it cannot write SQL, cannot invent an operation)
     ▼
  contract layer ─► validates params, resolves entities against the database,
     │                rejects anything that does not exist
     ▼
  deterministic ──► executes the query; SQL does all aggregation
  core                returns values + the evidence behind each one
     │
     ▼
  provenance ─────► appends a hash-chained record, server-side,
  store               where the model cannot influence it
     │
     ▼
  host UI ────────► fills slots from structured output and renders each
                      claim as a clickable citation

The model handles translation and phrasing — the two things it is reliable at. Numbers come from the system of record.

What it enforces

These are tests, not guidelines. npm test fails if any of them breaks.

No number is generated. Values are copied verbatim from an operation's structured output into template slots. A test asserts every monetary figure in an answer is covered by a claim with evidence behind it, and that the stated total equals the sum of the records it cites.

Entities are validated before any query runs. A fabricated customer produces a recoverable error listing real alternatives — not a silent empty result the model narrates around.

Aggregation happens in SQL. The model chooses which aggregation to run, never what it equals.

Empty results are handled in code. This is the single biggest fabrication trigger: hand a model an empty result set mid-sentence and it invents something to finish the sentence. Operations set an explicit emptyReason instead.

Unroutable questions are refused. "What will revenue be next quarter?" maps to no operation, so no answer is produced. Refusal is a first-class outcome, not a failure.

Provenance is written server-side. The model never reports its own provenance. Provenance that depends on the model choosing to cite is worthless.

The log is tamper-evident. Each record carries the hash of its predecessor. npm run verify walks the chain and reports the first record that was modified after it was written.

Interpretations, not just figures

Shortened. The full README is on GitHub.