How we work
From your architecture question
to a result someone owns.
AI-assisted investigation, senior architecture judgment and a defined engagement result. We connect the evidence to your business and operating context. You get a recommendation and a handoff you can act on, and each finding says how we know it.
Talent × Software × Methodology
Depth of investigation.
Clarity of judgment.
A useful result connects how a system really works, or how a proposed design would work, with the decision your business needs to make. A named senior architect directs the investigation and checks what it means.
Agree the result and the decision
We agree the architecture question, the business change and the decision it serves, with decision rights made explicit. We also agree the system boundary, the evidence needed and the deliverables.
Investigate the relevant evidence
Designs and assumptions; code, configuration, tests and operating evidence; or decision records and milestone criteria, whatever the decision needs. AI-assisted workflows support the investigation where useful.
Validate and integrate
We check the findings that matter against their sources, the people who know the system and the business context, and bring in specialists where needed. Every finding says how we know it: verified (we saw it in the code, configuration or running system), inferred (it follows from what we saw), reported by your team (not yet checked) or still open. The report also lists what we didn't examine.
Make the direction usable
We explain recommendations, design choices, significant deviations or readiness conditions in terms you can act on. We state trade-offs, priorities and open questions explicitly.
Deliver the agreed result
The agreed artefacts and a walkthrough with your team, with actions, dependencies and responsibilities clear. For ongoing governance, we review significant technical choices on an agreed schedule, within the hours set in the contract.
The Architecture Fabric
A shared method.
A deeper evidence base.
Our Architecture Fabric is the method and tools we developed independently to investigate a system. It combines AI-assisted investigation, structured methods, links from each finding to its source, and quality checks. It is built to let a senior architect connect system behaviour, dependencies and failure paths to your architecture question, and see much deeper into the actual system than a manual review allows.
We use third-party technology where useful. A senior architect checks the findings that matter, brings in specialist input and stands behind the recommendation.
AI-assisted investigation
Analysis tools and AI workflows help inspect and correlate relevant documents, code, configuration, tests and operating evidence. The scope determines the sources and depth.
Traceable system understanding
Connect business functions, components, data and dependencies to their supporting evidence. Each finding is labelled: verified, inferred, reported by your team or still open; what we didn't examine is listed separately.
Accountable architecture judgment
A named senior architect tests what the findings mean against your business and operating context, brings in specialists where needed, and turns them into the agreed result.
Two roles for AI
AI in our investigation.
AI in your solution.
AI supports our investigation. We also assess and design AI-enabled solutions: their data and model interactions, workflows, integration, evaluation requirements and operating controls. The same architecture services apply to conventional software and legacy estates.
What usable outputs can look like
Different contributions.
Different decision artefacts.
Worked examples of what each kind of work produces, following one customer portal from discovery to handover. Each kind of work can stand alone.
Assess: The portal reads the order system's database directly
- Evidence
- Verified: the portal's code queries the order system's customer and order tables, using a database account that can read every customer record. Reported by your team: those tables change in most order-system releases.
- Finding
- Inferred: an order-system release can break the portal without warning. Because the portal's account can read every customer record, one faulty query could also show a customer someone else's orders.
- Action / check
- Fix now, before launch: put an API between the portal and the order system, and remove the portal's database account. Engineering then checks that every portal page works with that account switched off.
- Owner / limit
- We own the finding; the portal supplier and your order-system team make the change. Not examined: the nightly reports, which may read the same tables. Still open: whether the API can be ready before launch.
Architect: An API between the portal and the order system
- Options
- Three ways to connect the portal: a nightly copy of the order data, the integration platform you already use, or an API on the order system itself.
- Chosen design
- An API on the order system with four calls: customer details, order status, order history and new orders. Each call returns only the signed-in customer's data.
- Reasons / conditions
- A nightly copy would show yesterday's order status; the integration platform adds licence cost and another team for four calls. Condition: your order-system team owns and versions the API, so changes are announced before they reach the portal.
- Handoff / limit
- We hand over the API contract, the access rules and the sequence for moving each portal page to the API. Engineering estimates, builds and tests. The nightly reports stay outside this design until they are examined.
Govern: A request to bypass the API for one release
- Request / risk
- The order-history call will not be ready for launch, so the supplier asks to read order history straight from the database for one release. Risk: the portal depends on those tables again, and a temporary workaround can become permanent.
- Recommendation
- Allow it for one release only: a read-only database account that sees order history and nothing else, with its removal planned in the next release.
- Decision / action
- Your product owner accepts or rejects the exception; the supplier implements it. A named senior architect advises, records the exception and escalates under the agreed governance terms if a condition slips.
- Conditions / limit
- Reviewed again when the next release is planned, and closed only when the temporary account is removed. We cannot block a release unless your contract gives us that right.
Assure: The portal integration at handover, with conditions
- Supported
- Criterion: the portal reaches order data only through the API. Verified: customer details, order status and new orders use the API, and each call returns only the signed-in customer's data.
- Exception / gap
- Order history still uses the temporary database account agreed for launch; it is recorded as an exception. Still open: performance at launch volume, because the load-test results were not available.
- Conclusion
- The evidence supports accepting the integration on two conditions: the temporary account is removed in the next release, and, before launch, the supplier provides load-test results that pass at launch volume.
- Owner / reliance
- We own the scoped conclusion; you decide whether to accept. The report goes to you and the supplier, and only you may rely on it. It states any earlier work we did on this integration.
Clear accountabilities
One engagement.
Explicit responsibilities.
Each engagement sets its own scope and decision rights, so our work fits with the teams already responsible for the system.
Sparkling
A named senior architect leads the contracted work, checks what our tools find, integrates specialist input and stands behind the recommendation.
Client leadership
You make the business, investment and acceptance decisions. You give us access, context and time with the people who know the system.
Delivery teams
Your teams and partners build, test and run the system. Through Architecture Governance, we can review significant technical choices within the decision rights and hours we agree.
Independence & information handling
Make the arrangement explicit.
Before work starts, we agree who engages us, what we can access, which tools we use, and who may rely on the report and for what. If we designed or governed the same work earlier, we say so. If you need a check that is independent of that work, we agree who does it: a different reviewer or an outside specialist.
Know what you're building on.
Tell us about the system, the decision and what is changing. 25 minutes on Teams, no preparation needed. We will tell you which engagement fits, or if none does.