The part of your product
your AI keeps rebuilding
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.
A rule, a status, a customer path
— and what they reach
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.
Everywhere in pieces
Nowhere in one place
Not in any one file
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.
Not in the documents
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.
Not in a search index
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.
Not in people’s heads any more
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.
Rebuilding it is most
of the work
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.
Builds it once from your code
Keeps it current with every push
For people
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.
For your coding agent
One MCP server: the agent gets the rules, customer paths and features a task touches before it changes code, and each change is checked against them before it is committed.
For the work itself
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
8% of the answer score lost to errors and omissions against 22% for the strongest alternative, on 8.4K tokens of context a question against 27.4K. Same repository, same fifty questions, same AI model.
Asked about business logic
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 lost 8% of the answer score to errors and omissions against 22% 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.
In a layered application, the business logic layer — also called the domain or service layer — is the part that holds the rules, between the screens that show data and the storage that keeps it. In real products the rules do not stay in one layer: a check sits in a handler, a limit in a database constraint, a status change in a background job. GitMir reads them from wherever they are implemented into one model.
Business logic is what the product promises: the rules, statuses and customer paths that would exist even if the code were rewritten. Application logic is how the software delivers it: routing, caching, retries, rendering. A change to application logic should not alter what customers get; a change to business logic always does — which is why it is the part to check before a change lands.
Flaws in the rules rather than in the syntax: an action anyone can take because nothing records who may take it, a status that can be skipped, a limit enforced on one path and not on another. Scanners that look for code patterns rarely see them. GitMir flags some of them from the model without being asked — actions with no recorded rule about who may take them, routes whose code shows no access check, and statuses nothing leads out of.
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.
Ask before the work starts, or let the check run on the commit: GitMir answers which rules, statuses, customer paths and features the change reaches, and which of them belong to other parts of the product. The risk people describe is not the bug visible in the diff — it is the contract that changed silently and looked clean.
The model says which commit it is pinned to and how current it is. A reading that is behind the code says STALE, a model that was read only in part says how many parts were read, and work that is not in the repository yet — uncommitted local changes — is outside its view and is named as such, instead of being answered as if it were the whole picture.
Yes. A project holds several repositories, and GitMir joins their models into one: a rule enforced in the backend and the customer path that meets it in the mobile app are the same thing in the model, so a change in one is answered with what it reaches in the others.