How the analysis works

We map your software from its code, and every finding points to the exact line it came from. This page explains how we read it, how a rebuild is kept safe, and what is in place today.

Reading the code

We use parsers that read each language the way its own compiler does. They list the functions, routes and database tables they can resolve, and the calls between them, each tied to the line it came from. What they cannot read is recorded as a limit, with what it would take to resolve it. Where a call could lead to more than one place, the tool records how certain it is. Nothing is guessed at this stage. The result is a set of facts you can check line by line.

Evidence you can take elsewhere

Each finding is tied to the file and line it rests on, with a permanent fingerprint of that file. Results come out in published industry formats, checked with the official validators. Another firm can read them without us.

Where AI comes in

Parsers cannot tell you what code does for your business, or why an odd rule exists. Our method uses a language model to propose that, under three rules:

• The model proposes. A deterministic check accepts or rejects.
• Every statement cites a specific line of code.
• A model from a different family checks that the line supports the statement.

Languages

We read Delphi, VB6 and TypeScript, including Drizzle database schemas. A reader for SQL Server stored procedures is written and is being connected to the assessment. We add a language when an engagement needs it, and we test its parser before we take the work. We decline Classic ASP, because no available parser reads it.

Keeping a rebuild safe

A rebuild moves in stages, and each stage can be reversed. Your current system keeps running until the new one is proven against your own real business records. The main proof is historical reconciliation: we run your historical inputs through the new system and compare what it returns and writes against the results already in your database. Cutover is then staged: the old system keeps running until the new one is proven, and stays available as a fallback until each stage is proven. Where you need it, we also compare critical outputs side by side on live work before a stage is finished: invoicing, payroll, month-end, whichever ones you cannot be wrong about. Every difference is sorted into noise we handle, intended changes you sign off, and defects that block the stage. Reconciliation runs on copies of your data, on a network with no route out, so a test cannot reach a customer or a supplier. We need no change inside your existing system; if one would help, it is optional and only with your written consent. One named person is accountable for every change.

What is in place

The code-reading stage and the evidence formats are running today. The interpretation stage and the rebuild testing method are designed, not yet built. When we scope your assessment, we tell you exactly which parts it will use.

We don't quote an accuracy figure yet. When we have one, we'll publish how it was measured.

Start