Five Portals, One Read-Only AI Layer
A state government ran five portals on different technology, each with its own idea of how to store the same facts. Officials could see their own screens. Nobody could ask a question across the records.
What Was Actually Wrong
None of these portals were broken. Each did its job. The problem was that the meaning of the data lived outside the software, in the heads of the officers who had worked with it for years. They knew which status code really meant an application was stuck, which date field was reliable, and which table you had to join to get a number a minister could be shown.
So every non-routine question became a request to a person. That person exported a spreadsheet, cleaned it by hand, and produced a figure nobody else could reproduce.
A question goes to the officer who knows. They export a spreadsheet, clean it by hand, and produce a figure nobody else can reproduce.
A question goes to the layer. It answers from that portal’s own rows, and every figure opens the records it was built from.
The Layer Sits on Top and Reads Down
An officer asks how many applications in a district are waiting on one document, and gets an answer with the rows behind it.
A written record of what each measure means and every way it can legitimately be broken down: by district, by scheme, by month, by status. The layer answers from that record, not from a guess.
Untouched. Same screens, same tables, same logins, same release process.
The arrows only point up. The layer holds read permission and nothing else, so it cannot alter a record even if it is asked to. For a government system, that permission boundary is why the work could be approved at all.
Written Down Before Any Software
For each portal we built a catalogue of two things: the measures the portal actually tracks, and the dimensions each measure can be cut by. That sounds administrative. It is the whole job. Until it exists, a question like "show me pending applications by district" has no single correct answer, because two officers will disagree about what "pending" means.
Every table, column and relationship in the portal's own database.
What each measure is, in the words the department already uses, and who owns the decision it feeds.
Complaints and remarks typed by hundreds of hands, sorted into a fixed set of categories so they can be counted.
Every figure carries the rows it came from, so a number can be defended rather than trusted.
Step 3 carries the volume. On one portal the classifiers made 115,652 separate decisions about what a piece of text meant. No team reads a quarter of a million free-text entries by hand, which is why that intelligence had never existed before.
What the Catalogue Looks Like
The catalogue is a grid. Down one side are the things a department counts. Across the top are the ways each of those can legitimately be cut. A filled cell means that combination is defined and answerable; an empty one means it is not, and the system says so rather than inventing a number.
| By district | By scheme | By month | By status | By officer | |
|---|---|---|---|---|---|
| Applications received | • | • | • | • | |
| Pending beyond limit | • | • | • | • | • |
| Amount disbursed | • | • | • | ||
| Complaints raised | • | • | • |
Scroll the table sideways →
A filled cell is a promise. The layer will answer that question from the portal's own rows. The empty cells matter just as much, because they are where the department's data genuinely cannot support a breakdown, and saying so is more useful than producing a figure nobody can defend. This grid is small here for the example; on the largest portal it runs to more than fifty measures.
What Happens When Somebody Asks
"How many applications in this district are waiting on one document?"
The question maps to a defined measure and two defined cuts. If it maps to nothing, the layer says the question cannot be answered rather than guessing.
A read-only query against the department's own database. No copy, no separate warehouse, no stale figure.
The number, and the rows it was computed from, so the officer can open the underlying files.
The second step is the one that makes this safe. A layer that maps every question onto something will always produce an answer, including for questions its data cannot support. Refusing is a feature that has to be designed in.
Why It Repeats
We built this layer five times. Each portal was written in a different framework, sat on a different database engine, and modelled its domain differently. One was an old application that had to be rebuilt on a modern platform before anything could be added to it.
Across all five, the sequence above did not change. What changed was the content of the catalogue, because that is the part that is specific to a department.
| Changed every time | Did not change once |
|---|---|
| The database schema | Reading the schema before writing anything |
| The framework and language | Writing down measures and their dimensions |
| The measures a department cares about | Classifying free text into a fixed set |
| The vocabulary staff use | Tracing every figure back to its rows |
| What counts as a decision | Read-only by construction |
What It Found That Nobody Asked For
Once the free text was structured, patterns appeared that no report had been built to look for. On one portal the classification surfaced a duplicate-registration signal precise enough to act on. On another, a public form had been quietly absorbing automated attack attempts for a long time; turning the logs into a structured map of who was probing what also revealed a missing rate limit.
Neither was the brief. Both are what happens when data that used to be unreadable becomes countable.