Chris M.Reviewed
Putting It to Work: Routing, a Worked Example, Where to Start
This is part six, the final part, of the AI and Software Architecture Translation Guide, the six part series on how modern AI systems are actually assembled. The previous five parts covered the decisions and the components. This part brings them together: a routing matrix, one record followed end to end through the whole stack, and the order to actually build it in.
A construction decision matrix, deliberately written without model names
This table is the working output of the whole guide, and it is written without naming a single model so that it survives the next release cycle.
| Task type | Preferred approach | Construction example |
|---|---|---|
| Fixed rule or calculation | Deterministic code | Valuation arithmetic, date logic, mandatory fields, duplicate detection |
| High volume extraction | Volume model plus deterministic validation | Classify emails, extract delivery tickets, structure site diaries |
| General drafting and summarising | Balanced model plus source context | Meeting summaries, first draft reports, document comparison |
| Complex multi document reasoning | Frontier model plus retrieval plus human review | Tender analysis, commercial challenge, interface review, value engineering assessment |
| Autonomous action | Agent plus tightly scoped tools plus approvals | Create a workflow, update a register, prepare draft actions |
| Safety, contractual or regulatory consequence | Evidence led workflow plus a competent human decision | Fire compliance, payment position, formal notices, design acceptance |
Do not ask can AI do this. Ask what is the cheapest, safest and most reliable architecture that produces the required outcome and the evidence to stand behind it. That reframing is the entire point of the five parts before this one.
From site record to portfolio intelligence, followed end to end
Every idea in this series, applied once, in order, to a single site record.
| Stage | What happens |
|---|---|
| 1. Capture | A site manager sends a voice note, text and photographs through an interface they already use. No new app, no new behaviour |
| 2. Structure | The backend stores the originals unaltered and creates a controlled record: project, author, timestamp. The original is never overwritten |
| 3. AI extraction | A volume tier model proposes package, location, event type, people, dates and actions. It proposes. It does not decide |
| 4. Validation | Deterministic checks run against known project codes, valid ranges and mandatory fields. Low confidence values are flagged, not guessed |
| 5. Retrieval | Related drawings, RFIs, minutes, correspondence and earlier records are found by metadata and meaning, with permissions applied first |
| 6. Reasoning | A stronger model is invoked only if the task genuinely requires cross document interpretation. Most records never reach this step, by design |
| 7. Human review | The responsible project, commercial or technical person reviews any consequential conclusion or action, with the depth of that review set in advance by how much a wrong answer would cost |
| 8. Action | Approved information updates the register, creates a draft report, raises an action or feeds a dashboard |
| 9. Evidence | The output retains links to the original records and logs what happened, including anything a human overrode. This is what makes the record defensible |
Count the stages again. Only three of the nine involve a model at all: extraction, reasoning where it is genuinely needed, and nothing else. The other six are capture, validation, control and evidence. That ratio is not a limitation of the technology. It is what a defensible system actually looks like, and it is the difference between putting a chat tool on construction data and engineering a controlled, AI enabled business process.
Where to start building this
Ordered by what makes the next step possible, not by what is most impressive to demonstrate. This is a build order, not a policy order.
| Step | Do this | Because |
|---|---|---|
| 1 | Fix capture before intelligence | Retrieval over a partial record produces confident, partial answers. Nothing above this layer can fix it |
| 2 | Add deterministic validation | The cheapest quality improvement available, and it never needs re-verifying once it is written |
| 3 | Attach a risk level to every task type | A human decides, once per task type, how much a wrong answer would cost, and the system reads that decision to set the model tier, the evidence required and who has to sign off. Until it can read that classification, no control is actually enforceable |
| 4 | Add retrieval with permissions and citations | Turns the record into something answerable and traceable |
| 5 | Add routing across tiers | Cost control and reasoning quality, in one change |
| 6 | Add a second check on higher risk work | A separate model call, with its own sources, reviewing the draft rather than agreeing with itself. Run it only where the consequence justifies the extra cost |
| 7 | Log what the system saw and who decided | One record per output: the sources it used, what it did, what it was warned about, and who signed off. This cannot be added after the fact |
The most common sequencing error is starting at step five. Buying a frontier model and pointing it at an incomplete, unstructured, unpermissioned record produces an impressive demonstration and an unusable system. Steps one and two are unglamorous and they are where the result is actually decided. Deciding the specific risk bands, who approves what, and how AI use gets disclosed to a client is a separate, ongoing governance exercise for each organisation, not a one-off technical build, and it runs alongside this sequence rather than inside it.
What this guide is built on, and what to check before relying on it
This edition consolidates earlier internal drafts, corrects technical claims that did not hold up, updates the model references, and reframes the operational controls around a risk classification read by the system itself rather than left in a policy document.
Model references throughout this series were compiled from provider release materials and documentation for Anthropic, OpenAI and Google, together with independent reporting, as at August 2026. Product names, tiers, availability and prices change on a scale of weeks; re-verify before any external use, particularly anything drawn from part two.
The Model Context Protocol's specification revision dated 28 July 2026 introduced a stateless protocol core, an extensions framework and authorisation hardening, emphasising access control, user visibility and a human's ability to deny sensitive tool invocations.
RICS' Responsible use of artificial intelligence in surveying practice, first edition, took effect 9 March 2026 and is mandatory for members and regulated firms worldwide where AI use has a material impact on service delivery.
UK data protection requirements around meaningful human involvement in automated decision making apply to decisions about individuals based on personal data. This guide is not legal advice; take specific advice on scope for your own organisation.
Intelligence is one package. The system is the project. If this series is doing its job, it has replaced one question with another: not what can this technology do, but what is the cheapest, safest and most reliable architecture that produces the required outcome and the evidence to stand behind it. That is a question construction professionals are already extremely good at answering about any package on any project.
If you would rather build this against your own workload than start from a blank page, AI Metric works through this sequence with contractors and consultants directly. You can also read the full guide on one page, or start again from part one.
Sources
- 1.AI Metric Ltd, AI and Software Architecture Translation Guide, edition v3.1PrimaryAccessed
- 2.RICS, Responsible use of artificial intelligence in surveying practice, 1st editionAuthorityAccessed
- 3.Anthropic, Building effective agentsPrimaryAccessed
Published , last reviewed . This guide explains general principles and is not legal, contractual or safety advice. The position on any project depends on the contract signed and the facts of that project.