Features, rules, customer paths and how they connect. It decides what your product does, it is not written down anywhere in one piece, and every task — human or agent — starts by putting it back together.
Take one rule from a product anyone can open: Supabase Studio, published in full on this site.
Rule · Billing & Subscription
An unpaid invoice restricts the organization
Warning → grace period → restricted
Reaches Organization · Project
Nothing in that sentence is a file name. It is the product: what holds, what changes, and who meets it. A change to the invoice code reaches the organization and its projects — through the rule, not through an import.
The code holds calls, imports and types. That a rule restricts an organization, and which customer path meets it, is nowhere in a call graph — it is spread across the files that implement it.
A specification describes what was intended on the day it was written. The product keeps changing after that, and nothing ties the document back to the code that now decides the behaviour.
Search and retrieval return what looks like the question. A part that shares no word with the task — an organization restricted because an invoice stayed open — is not similar to it, and is not returned.
When AI writes a large share of the code, the connections stop passing through the person who would have known them. Each task starts by rebuilding what somebody already understood.
This is why no single tool your team already owns can hand it to you: each of them holds one of the pieces.
Measured across the projects GitMir has run — the same workflows timed with the business logic established and without it.
16 h → 0.3 h
45 min → 8 min
6.5 h → 2.4 h a week
21 days → 4 days
90 min → 20 min
69% → 5%
Same team, same hours: +38% changes accepted per quarter.
Ask what a change reaches, what a rule holds and which customer path passes through a screen — and see the answer with the part of the product it came from.
One MCP server: the agent gets the rules, customer paths and features a task touches before it changes code, and every commit is checked against them before it lands.
Accepted work carried out from the same business logic and committed to the repository, at a fixed price per project rather than per token.
Benchmark 001
92% of answers correct against 78% for the strongest alternative, on 8.4K tokens of context a question against 27.4K. Same repository, same fifty questions, same AI model.
The rules a product enforces, the states its records move through, the customer paths people walk, and the features those belong to — together with the connections between them. It is what the product does, as opposed to how the code is written.
Implemented across the code, described partly in documents that drift, and understood in pieces by the people who wrote it. Nowhere in one place, which is why every task, every agent and every new hire starts by rebuilding it.
An agent can read files and infer parts of it per prompt, and pays for that on every run. In Benchmark 001 — one repository, fifty questions, the same AI model for every system — answering from an established model of the business logic was correct 92% of the time against 78% for the strongest alternative, on 8.4K tokens of context a question against 27.4K.
A code graph connects symbols and answers where something is used. Business logic connects rules, statuses, customer paths and features, and answers what a change alters for the customer and what else it reaches.
It is built from the repositories themselves and updated as commits land, so the answer a person or an agent gets is the product as it is now, not as it was when somebody last wrote it down.