For engineering leads and enterprise architects, handing an architecture review to an AI system can sound efficient — and a little uncomfortable. When you click submit, what is actually happening? Is the system comparing your design against a general-purpose model that might produce a plausible but ungrounded answer, or is it running a structured, traceable check against rules your own architecture team has written and approved?
That distinction is the whole point. Architecture governance should not run inside a black box. Engineering teams should never have to guess why a design choice was flagged — if a system surfaces a risk, it should be able to point to the exact rule responsible, why it applies, and what to do about it.
This post walks through what actually happens, step by step, when cajeX reviews a project — and why that review needs to happen earlier and more often than the traditional model allows.
The Cost of Knowledge Walking Out the Door
Before getting into the mechanics, it is worth understanding why this matters as much as it does. When a senior architect leaves an organisation, a meaningful share of what made their reviews valuable leaves with them — and in technology, that happens more often than most teams plan for.
Engineering tenure in tech is short. The US Bureau of Labor Statistics puts median employee tenure at 3.9 years across the workforce as a whole — but Ravio's 2026 Compensation Trends Report, tracking the European tech industry specifically, found average tenure closer to two years. Replacing that person is not free: Gallup estimates that replacing a departing employee costs between 50% and 200% of their annual salary, with technical and specialist roles consistently landing at the higher end of that range because of how much role-specific knowledge has to be rebuilt.
Layered on top of that turnover, research from Panopto's Workplace Knowledge and Productivity Report found that 42% of institutional knowledge is unique to the individual employee — and that knowledge workers lose an average of 5.3 hours a week recreating information that already exists somewhere in the organisation, just because it was never written down anywhere they could find it.
Put those findings together and the picture is clear: in an industry where the average architect or engineer may not be with the company for much more than two to three years, where replacing them costs a meaningful share of their salary, and where nearly half of what they know exists only in their own head, governance built around any one person's institutional memory is governance with a built-in expiry date.
~2 years
average tech industry tenure in Europe
Ravio 2026 Compensation Trends Report
50–200%
of salary to replace an employee
Gallup / SHRM
42%
of institutional knowledge lives in one person
Panopto Workplace Knowledge Report
Figure 1 — The cost of institutional knowledge concentrated in individuals.
The fix is not to make individual architects redundant — it is to make their knowledge structurally durable. When standards live as approved architecture directives rather than in any one person's head, that knowledge survives staff changes, scales beyond whoever happens to be available, and becomes something the whole organisation owns rather than something a handful of people carry.
An Agile Approach to Architecture Governance
Most of what follows describes a review pipeline, and it is easy to read that as being about code — catching a bad pull request before it merges. That is one use case, but it is not the main one. The bigger shift cajeX enables is making architecture governance self-service across the full range of decisions an organisation makes, not just software delivery.
That includes investment business cases, vendor and SaaS procurement decisions, infrastructure changes, and classic IT implementation projects — anywhere a team is choosing a technology, a vendor, or an approach that needs to hold up against the organisation's standards. The traditional model gates all of these behind a scheduled review, late in the process, with a senior architect's calendar as the bottleneck.
cajeX inverts that. Teams can run a self-service review during the idea and analysis phase — before a business case is finalised, before a vendor contract is signed, before a sprint is planned — and clear straightforward findings on their own. Architects step in where they add the most value: reviewing and mitigating the findings that carry real weight, the ones with material impact on technical debt or that signal a deviation from strategy. The routine gets handled at the speed of the team raising the question. The judgment calls still go to the people qualified to make them.
Figure 2 — Self-service governance: routine findings cleared by the team, critical findings escalated to architects.
This is what an agile approach to architecture governance looks like in practice: review available at the moment a decision is being shaped, not weeks after it has already been made.
The Five-Step Review Pipeline
Instead of a loose, conversational exchange, cajeX processes a submission through a deterministic, repeatable pipeline — whether that submission is a code change, a solution design, or a procurement business case.
Submitted
Design or RFCMatched
Against directivesFindings
With severityMapped
To directive nameAudit log
CreatedFigure 3 — The five-step cajeX architecture review pipeline.
Step 1: Submission and ingestion
The workflow begins when a project design, RFC, infrastructure schematic, business case, or vendor proposal is submitted. The cajeX AI co-worker parses the submission and normalises unstructured text, diagrams, and parameters into a clean structure ready for evaluation.
Step 2: Directive matching and evaluation
This is where your institutional knowledge does the work. Rather than comparing your submission against general best practice on the open internet, the cajeX AI co-worker reads it specifically against your organisation's active, approved architecture directives — the live guardrails your own architecture team has established, covering security parameters, framework choices, data residency requirements, vendor constraints, and technology standards.
For a closer look at how these directives are written and approved before they ever reach a review, see What Are Architecture Directives.
Step 3: Finding generation with severity and categorisation
As the AI co-worker evaluates the submission against active directives, it surfaces discrepancies, mismatches, and omissions. Each finding carries a severity level — Critical, High, Medium, or Low — based on risk and impact, and is classified by category:
Nonconformity
A direct violation of an approved standard or guardrail
Observation
A design choice that merits closer human review
Opportunity
A more current pattern or approach could apply
Risk
A potential source of technical debt or exposure
Figure 4 — The four finding categories cajeX applies to every result.
A service attempting to write directly to a production database without an approved abstraction layer, for example, generates a Nonconformity finding with an AI confidence score, classified under its structural category. A procurement proposal naming a vendor outside the approved cloud provider list would generate a similar finding — same pipeline, same traceability, different domain.
Step 4: Mapping to directive name
This is what eliminates the black-box problem common in general-purpose AI systems. Every finding the AI co-worker produces is explicitly mapped back to a specific directive from your organisation's approved catalogue. If a design omits a required encryption standard, the output references the exact directive by name — not a generic security observation. No guessing, no unexplained flags.
Order service writes directly to the production database without an approved abstraction layer.
Figure 5 — A real finding, mapped to the directive it violates.
Step 5: Immutable audit log creation
Every check performed — what failed and what passed — is bundled into a comprehensive, exportable audit log. This log is the verifiable source of truth feeding into architecture sessions and dashboards, and it is what regulated organisations need when an auditor asks how a review was conducted.
Why the Pipeline Approach Is Faster, Not Just More Accurate
The immediate benefit of a dedicated AI architecture review tool is not only accuracy — it is velocity. Traditional architecture reviews rely on finding open calendar slots, trading email threads, and scheduling multi-stakeholder follow-ups to walk through static documents.
DORA's software delivery research consistently identifies Change Lead Time — the time it takes a change to move from committed code to production — as one of the clearest indicators of where delivery bottlenecks live, and slow review cycles are a well-documented contributor to that lag.
cajeX collapses that timeline:
| Traditional review | cajeX AI-assisted review | |
|---|---|---|
| Process | Calendar coordination, email threads, manual document review, multi-stakeholder meetings | Submission evaluated against live directives immediately, severity flagged automatically |
| Output | Meeting notes, inconsistent findings | Structured findings mapped to directives, with full audit trail |
Figure 6 — Traditional review versus cajeX AI-assisted review, timeline and outcome.
By bringing architecture review automation into the workflow, teams catch compliance issues during the idea and analysis phase, before a business case is approved, a vendor is contracted, or code is written — turning the review from a bureaucratic checkpoint into a normal step early in any decision.
Why This Matters as Delivery Accelerates
As AI coding assistants increase the volume of code teams produce, the pressure on manual governance increases with it — but the same pressure exists on the non-code side too, as procurement and vendor decisions move faster and self-service tooling lets teams commit to a direction without an architect ever being consulted.
Gartner's research on technical debt management projects that architectural technical debt will account for 80% of all technical debt by 2027 — a structural shift toward exactly the kind of decisions architecture governance exists to catch, regardless of whether those decisions show up as code, a solution design, or a signed contract.
That shift carries a real cost. Deloitte's 2026 Global Technology Leadership research found that technical debt already consumes between 21% and 40% of the average organisation's IT spending.
Architects cannot be in every pull request, every design conversation, or every procurement meeting. Standardising review through directive matching — and reserving architect time for the findings that actually carry strategic weight — is what keeps governance functioning as both delivery speed and decision volume increase, without dragging down momentum anywhere in the organisation.
See the Pipeline in Action
If you are setting up your first directive library, Getting Started with cajeX covers the basics, and What Are Architecture Directives explains how directives are built and approved before they ever reach this pipeline.