context-engine
Builds an object model of a product's business logic from its repository — then serves the smallest slice of it that answers a task. This is the machine behind GitMir Models.
A code index knows where. This knows what it means.
A code index knows that capture() is defined here and called there. This knows that a customer upgrading a subscription touches User → Subscription → Plan → Payment, that the upgrade is only legal from an active account, and which endpoint and screen carry it out. That is not in the syntax, so a parser cannot produce it — it has to be read.
Reading is paid for once, and every agent uses the result — instead of each agent re-deriving it from source at the start of every session.
Six stages, ascending cost, descending determinism.
| Stage | What it does | Cost |
|---|---|---|
| 0 · survey | Walk the repository, skip vendor and build output. | free |
| ½ · scan | Read what the code states outright — the database schema, the route tree, the enums. | free |
| 1 · orient | What is this product, what are its business areas — from the file listing, product briefs, and up to eight schema, route and entry-point files. | one call |
| 2 · extract | Per shard: entities and their fields, actions, endpoints, screens, events — each with the files it was read from. | most of the spend |
| 3 · connect | Journeys, lifecycles, reactions — from the catalogue of ids only, no source. | one call |
| 4 · verify | Every reference resolves or is dropped. | free |
Stage ½ is where a code index would stop — and it is worth doing first
A schema names every business object, its fields, their types and the relations between them — exactly, in text. A directory called app/api/v1/devices/[id] with an exported GET handler is GET /api/v1/devices/:id. On a real product that is 25 of 25 entities and 238 fields — every entity the hand-built model had — in 98 milliseconds, for nothing. Applied to the hand-built model itself, the scan corrected all 25 entities and raised its field count from 142 to 238.
On structure — fields, types, relations, methods, paths — the scan wins, because it read the declaration rather than an opinion about it. On meaning — what this is for, which area it belongs to, whether it holds money — the model wins, because a schema cannot say any of that. Getting this boundary wrong once produced 25 entities with exact fields and empty descriptions: a table, not a product model.
Stage 3 is the one that matters
A journey does not live in any single file: you get it by holding the whole catalogue at once. That is why a per-file indexer cannot produce one, and why this is a different layer rather than a nicer view of the same one.
Stage 4 is what makes it trustworthy
Everything a language model produced is checked by arithmetic before anything is built on it. A reference to an object that does not exist is dropped and counted, because a graph with edges to nothing is worse than a smaller graph — everything downstream trusts the edges.
Ten dimensions, linked by stable ids.
modules · entities (with fields) · serverUnits · serverFunctions · apiRoutes · frontendUnits · events · processes · statusFlows · reactions — plain JSON in .gitmir/model/ next to the code, with an index.json that records what it cost, which model built it, and how many invented references were thrown away.
It is the same shape the rest of GitMir already reads, so reach, risk and impact computations work over it unchanged.
The price is shown first
A dry run reports what will be read and roughly what it will cost — before a token is spent. This index has a price, unlike a parser's, and anyone about to point it at a two-million-token monorepo should see the number from us rather than from their invoice.