Not a report. A working model of your estate.
Assessments usually end in a document that is out of date the week it arrives. This one does not. What you receive can be queried, it stays accurate as your code changes, and it works without us.
Two ways to run it
You get the same model either way. The only question is whose environment it is built in, and that is usually decided by your regulator rather than by us.
In our environment
You send us the source for the systems in scope and we do the work in our own hosted environment. Nothing for you to provision, nothing to install, and the shortest route to an answer.
This is how most engagements run. It suits you if your code is not subject to a residency or handling restriction, and if standing up infrastructure would slow you down more than the work itself.
In yours
Where source code cannot leave your building, and in banking, insurance and government it usually cannot, we deploy a project-based license onto a server inside your own environment and work over VPN.
Nothing crosses the line, including the AI. The models run inside your boundary too. This is a routine arrangement for us rather than a concession we make reluctantly.
Everything else on this page is identical in both cases. The model, the exact answers, the plain-language search and the provenance behave the same way. What changes is only where the work happens and where the result lives.
If you are not sure which applies to you, that is a normal place to start. It is usually the first thing we work out together, and it is worth settling before scope rather than after.
Four things land
One model of your estate, and three ways of getting the truth out of it.
A model of your estate
A complete, structured description of your systems: programs, batch jobs, transactions, data structures, the flows between them, and the business rules buried inside them.
It is built on ISO/IEC 19506, an international standard published by the Object Management Group, so it is readable without our software. If you replaced us tomorrow it would still be yours, and still be useful.
Exact answers
Ask for the layout of a record and you get every field with its real precision and scale. Ask what writes to a variable and you get every place, across every program. Ask what a job depends on and you get the whole chain.
These are lookups against a resolved model, not searches. There is one right answer and you get it.
Search that understands intent
You do not always know the program name. Ask where late payment penalties are calculated and you are pointed at the rules, paragraphs and fields that do it, even when nothing is named helpfully.
This finds things. The model then tells you the facts about them.
Provenance on every answer
Every element carries the file and line range it came from. Anything the system tells you can be followed back to the code that produced it.
Your engineers can check it. So can your auditors, without involving us.
How your people and systems reach it
Three ways in, over the same model.
- Your engineers use a web interface and ask questions in plain language.
- Your tools and pipelines call an API and get structured results back.
- AI agents connect over MCP, the emerging standard for giving models access to tools, so a migration pipeline can request exactly the facts it needs and nothing else.
One rule governs all three. Plain-language search locates, the model states the fact, and the ledger cites the line. An approximate match never becomes an answer.
That distinction matters more than it sounds. It is the difference between a system that sounds confident and one that is correct, and it is why we will not simply point a language model at your source and read you the result.
As your code changes
Your estate is not static. Re-running extraction over what changed brings the model back up to date, and because every element is tied to a line of source we can tell you what else that change touches.
That gives you something a one-off assessment cannot: two points in time, and an exact account of what moved between them.
What you need to run it
If it runs in our environment, nothing. That is rather the point of the first option.
If it runs in yours, the AI has to run there too, which means somewhere to serve models: accelerated compute, or a well-provisioned VM for a smaller estate.
We will tell you what your estate actually needs before you commit to anything. If the answer is that it is not worth it, we will tell you that too.
Nothing here is an opinion
Every answer this system gives names the program and the line it came from. That is not a feature bolted on afterwards. It is a property of how the model is built, and it is the reason the output survives an audit.
The whole picture
One boundary, and everything happens inside it. Whether that boundary is your environment or ours is the choice above.
See what this would look like for your estate
Tell us roughly what is in scope and we can describe what you would get back, and what it would take to produce it.