Architecture Review Gate: Calibrate and Organize Stages

FlowRidge

This article walks what the AITE-SAT architect contributes to Calibrate and Organise reviews, the artefacts that depend on architectural input, and the practical discipline of expressing architectural judgement in the stage-gate vocabulary.

Calibrate — the architect’s inputs

Calibrate is the stage where a candidate AI use case is assessed for business value, strategic fit, regulatory posture, and technical feasibility. The outputs are a decision to advance, a decision to reshape, or a decision to decline. The architect’s job at the Calibrate gate is to answer four questions.

1. Is this use case architecturally sensible

The first filter is crude but important. Does the use case match a known architectural shape (prompt-only, RAG, fine-tuned, agentic), or does it require a novel configuration. Known shapes advance faster because the team has experience estimating their costs, risks, and time-to-value. Novel configurations need additional discovery work before they can be sized honestly.

A use case that sounds like a frontier problem — “the assistant will plan a complex multi-week project autonomously” — is a red flag at Calibrate. The architect’s service is to classify it correctly (agentic, high-autonomy) and signal the implications rather than let the programme assume it is a minor extension of the team’s current work.

2. What is the data readiness posture

The AITE-SAT architect works with the data-readiness assessment from the AITM-DR or AITB-TRA specialist. At Calibrate the architect’s read is whether the data plausibly supports the use case. For RAG systems: does a usable corpus exist; if not, can one be built in the available window. For fine-tuning: is there a labelled dataset or a realistic plan to produce one. For evaluation: is there a path to an eval set that reflects production traffic.

A use case with no plausible data path does not advance from Calibrate regardless of business appeal. The architect’s note in the readout makes the risk explicit.

3. What is the regulatory posture

The architect has read Article 22 (EU AI Act Articles 9–15) and the regulatory specialist (AITB-RCM) has done the formal classification. At Calibrate the architect translates the regulatory posture into architectural implications: if the use case is high-risk, the conformity-assessment evidence path adds 15–25% to the programme budget, extends timelines, and constrains certain technical choices (residency, logging, human oversight). The programme needs this in its mental model before the gate closes.

4. What is the platform fit

Does the existing platform (Article 24) support this use case, or does it demand new platform capability. A use case that requires a new vector-store capability and a new guardrail policy is not unaffordable but it is no longer a thin product build. The architect names the platform additions explicitly so the programme’s sizing is honest.

Calibrate deliverables from architecture

The architect contributes a small set of documents to the Calibrate readout:

Architectural classification of the use case (prompt-only, RAG, fine-tuned, agentic, multimodal). One paragraph with the reasoning.
Reference architecture sketch. A rough cut of the reference architecture from Article 1, placeholders allowed. The purpose is to orient the reviewers, not to pre-commit.
Platform-fit note. Which existing platform services the use case consumes; which new ones it requires.
Risk notes. Top three to five architectural risks with a preliminary mitigation direction each. Risks are not rejections; they are signals for the Organise stage to address.
Sizing note. A high-level estimate of engineering effort, platform additions if any, and the critical path. Ranges are acceptable and expected.

These artefacts live in the platform and are revisited at subsequent gates. They are not throwaway; they form the first draft of the system card (Articles 11, 21) and the ADR corpus (Article 23).

Organise — the architect’s inputs

Organise is the stage where a use case that passed Calibrate gets shaped into a deliverable programme: team composition, timeline, acceptance criteria, data preparation, initial architecture, initial risk register. The architect’s Organise work is heavier than at Calibrate because the rough sketch becomes a committed reference architecture.

Reference architecture commitment

The architect produces a full reference architecture drawing on Article 1’s five-plane model: client, orchestration, model, knowledge, observability. The diagram is now detailed enough for the team to estimate and build. The architect names the provisional model family, the retrieval approach, the orchestration pattern, and the observability hookup.

Each choice is an ADR candidate. The architect does not have to close every ADR at Organise but does have to name the decisions the team will take in Model stage and flag the ones that cannot be deferred.

Data architecture

The data pipeline (Article 15) is drafted — ingest, transform, chunk, embed, index, retrieve. Provenance and consent paths are specified. Residency requirements are mapped. The data architect or the AITE-SAT holder takes this on depending on organisation.

Evaluation plan outline

The architect works with the eval owner (often the AI engineer or the ML scientist) to outline the offline eval suite, the online eval plan, and the human-review cadence. The eval plan does not have to be complete at Organise, but its shape and the resource demand are visible.

Initial security and privacy architecture

The architect maps the system against the STRIDE threat categories plus OWASP LLM Top 10 (covered in Article 14) and identifies the high-severity concerns that need addressed design answers before Model stage.

Platform additions scoped

Any new platform capability identified at Calibrate is now scoped. The platform team has a change request on its backlog. The programme knows how the new capability will be delivered in parallel with the product work.

Organise deliverables from architecture

A richer deliverable set than Calibrate:

Detailed reference architecture diagram with all five planes specified.
ADR list — the decisions the team will take through Model stage, each with target review date.
Data architecture document — pipeline, provenance, residency, consent.
Evaluation plan outline — offline and online eval shape, resource demand, timeline.
Threat model v1 — OWASP LLM Top 10 mapping plus STRIDE analysis.
Platform change request — scoped additions the platform team will deliver.
Cost model v1 — rough per-query economics and monthly run-rate forecast (Article 33).

The Organise readout presents these artefacts. The architect answers questions from the business, the regulatory owner, the platform lead, and the executive sponsor. Questions that surface at Organise have cheap answers; questions that surface at Model stage have expensive ones.

The architect’s posture in the review room

The AITE-SAT architect is in the review room as a credible, constructive gatekeeper. A few practical notes on posture.

Advocate for architectural honesty. Sponsors sometimes want to advance a use case that the architect knows is under-scoped. The architect’s job is not obstruction but realism: name what would make the programme successful, and name what would make it fail.

Resist vendor optimism. Vendor account teams are often in the room, especially at large enterprises. Their interest is aligned with the programme advancing; the architect’s interest is with it succeeding. The architect reads vendor promises critically without discarding the vendor’s input.

Distinguish Calibrate questions from Organise ones. Not every architectural question has to be answered at Calibrate. The architect moves questions to the right stage rather than forcing premature commitment.

Link to evidence. Every claim the architect makes should link back to a document or an article — the reference architecture, the threat model, the eval plan. Verbal claims in the review room have lower half-life than linked artefacts.

Worked example — a field-service assistant at Calibrate

A programme at an industrial-services company proposes a field-service assistant that helps technicians diagnose equipment faults from photos, audio, and text notes. The architect’s Calibrate contribution:

Classification: multimodal RAG with light agentic behaviour (the assistant might look up parts manuals and check inventory).
Reference architecture sketch: vision input -> caption; audio input -> transcript; text query combined with modality captions; retrieve from manuals and service history corpus; LLM reasons; output includes citation to the source manual page.
Platform fit: requires the platform to offer a vision captioning service and a speech-to-text service — both new. Corpus ingestion of manuals needs a new source type. Existing orchestration and retrieval suffice.
Risk notes: (1) safety implications if the assistant recommends a service action that damages equipment; (2) multimodal eval-set curation cost; (3) residency of service-history data; (4) field connectivity — offline fallback may be required.
Sizing note: medium-complexity product work (roughly 6 to 9 months to first production), plus platform additions (vision and speech services — roughly 3 to 4 months to platform general availability).

The sponsor wanted a three-month timeline. The architect’s Calibrate readout reshaped the conversation to a phased delivery with platform work and product work running in parallel.

Worked example — a high-risk EU use case at Organise

A programme inside an EU-based bank proposes an AI-assisted credit-decisioning support tool. Annex III of the EU AI Act classifies this as high-risk.¹ The architect’s Organise contribution:

Reference architecture: RAG over internal policy corpus plus structured data about the applicant; LLM provides reasoning but does not make the decision; human credit officer always in the loop.
ADRs scoped: model-family (managed API in EU residency or self-hosted open-weight); evaluation contract (must meet internal accuracy targets plus fairness tests); fallback (if AI unavailable, officer proceeds without assist).
Data architecture: residency in EU; provenance tracking per Article 10; PII redaction in all logs.
Threat model: adversarial prompt construction via loan application free-text; retrieval poisoning via customer-uploaded documents; model regression on protected classes.
Eval plan outline: baseline accuracy against historical officer decisions; fairness tests per protected class; citation accuracy on policy retrieval; monthly eval cycle.
Platform change request: EU-residency deployment of the guardrails service; integration with the Article 12 logging retention policy.
Cost model v1: per-decision cost with envelope for the additional audit-logging storage.

The Organise readout surfaces the regulatory-driven 20% effort uplift explicitly. The sponsor signs off knowing what they are committing to.

The gate decision

At each review the gate decision is advance, advance-with-conditions, loop-back, or pause. The architect’s recommendation is one input among several. When the architect’s concerns are not addressed, the architect writes them into the record; if the gate advances anyway, the architect has a documented position for the eventual post-mortem. This is not defensive posturing — it is how stage-gate processes maintain learning.

Anti-patterns

The architect as rubber stamp. An architect who advances every use case is providing no filter and the business gets no value from the role. Calibrate is the cheapest place to pause a misconceived programme.
The architect who blocks everything. The opposite failure. An architect who pushes back on every use case is not calibrating; they are obstructing. Reviewers stop consulting them.
No architectural artefact at the readout. A verbal architect position without linked documents leaves the programme without a useful memory. Every readout should leave behind a document the successor architect can read.
Premature lock-in at Calibrate. Committing to a specific model or vendor at Calibrate is usually wrong. The Calibrate decision is whether to advance; the specific vendor choice belongs later.
Under-scoping platform additions. A use case that requires a new platform capability is not the same as one that fits the current platform. Treating them as interchangeable produces the overruns that inevitably follow.

Summary

At Calibrate, the AITE-SAT architect classifies the use case, sketches the reference architecture, notes platform fit, flags risks, and sizes the effort. At Organise, the architect commits a detailed reference architecture, scopes the ADRs, and produces the data architecture, evaluation plan outline, threat model, and cost model v1. The architect’s posture is advocate for architectural honesty and resister of vendor optimism. Every Calibrate and Organise artefact becomes input for the Model and Produce gates in Article 29.

Key terms

Stage-gate review
Calibrate stage (COMPEL)
Organise stage (COMPEL)
Reference architecture sketch
Platform-fit note

Learning outcomes

After this article the learner can: explain Calibrate and Organise gate artefacts that depend on architect input; classify four architecture inputs by artefact; evaluate a stage-gate submission for architectural completeness; design the architect’s section of a Calibrate readout.