A coding agent reads a handful of files and infers the rest. That works for a feature. In a modernization it is how the rule buried in a stored procedure gets missed, how an integration nobody mentioned breaks in production, and why you get a different answer every session.
ARC works the other way round. It indexes the whole estate before any model interprets it: every file in every repository across 78+ languages, plus the database. Code is parsed into abstract syntax trees, the same structure a compiler builds, so ARC follows real call chains, type hierarchies and data paths across millions of lines instead of guessing from text. A two-tier embedding index sits on top: a 161-million-parameter code model fused with a natural-language model, so an architect's question and a developer's identifier find the same code. Each of the six stages below reads from what the last one proved.
- 01Code ingestionEvery file, read once, read-only
Repositories, schemas and stored procedures across 78+ languages, indexed before any model draws a conclusion.
- Abstract syntax trees: real call graphs, types and data paths, not text matching
- Two-tier embeddings: a 161M-parameter code model fused with a language model
- Credentials used read-only, then deleted
- 02Audit and analysisMeasured, then interpreted
Around fourteen analysers compute the system: dependencies, integrations, data contracts, screens, journeys, security and code quality.
- Business rules as Given / When / Then, cited to files and lines
- Security findings mapped to the controls auditors ask about
- Change coupling and hot spots from git history
- 03RearchitectEnterprise architecture in a box
A structured architecture intake: 96 questions across 15 areas, from your SDLC and hard constraints to hosting, data, security and team.
- Constraints first: compliance, frozen schemas, approved stacks
- Every answer becomes a pinned decision with a decision record
- Signed off by your architects, section by section
- 04PlanIntent becomes specification
The approved future state is written as a spec pack: one specification per capability, in build order.
- Each spec owns the legacy rules it must preserve
- Acceptance criteria and API contracts per capability
- Open questions routed to the people who can answer them
- 05Code generationA harness, not a prompt
Coding agents build each spec as stories, and every story passes the same gates before it counts.
- Tests written and run per story; 100% pass acceptance first time
- Security audit and dependency scan on every build
- Spec-to-code traceability, documentation and ADRs
- 06DeliveryProven before it ships
Our QA team tests the new system against the rules discovery extracted, and a Field CTO owns the cut-over.
- Acceptance walk against legacy behaviour, rule by rule
- Handover checklist, defect register and runbooks
- Compliance evidence packaged for your auditors
One index, one decision record.Every stage reads from the same index and appends to the same record of decisions, so the plan your architects approved is the plan the agents build.
Complete and measuredThe whole estate is analysed and its structure computed before any conclusion is drawn. Nothing is missed because it wasn't in the prompt.
Every claim verifiableEach rule, capability and decision links to the files and lines behind it. Your architects check evidence, not a model's confidence.
The same answer twiceA fixed pipeline over one index means the plan doesn't drift between sessions, agents or teams.
Want the engineering detail? Read the architecture and security docs →