Scenario 2. Design a new in-house service
This section examines how agencies can design and build a new AI-enabled capability from the ground up. A common example is a governance-grade AI assistant, where agencies assess how to create a capability that supports traceable, reviewable and reproducible analysis of authoritative information. Such a capability may be reusable across agencies where teams analyse overlapping authoritative records.
Key challenges
- Key challenges for practitioners: This is a greenfield design problem. Unlike enabling AI within an existing platform, agencies have significant architectural freedom and must determine how traceability, reproducibility, validity, security, privacy and human oversight should be engineered into the solution from the outset. Governance-grade AI assistants address different challenges from productivity tools such as Copilot. Efficiency gains matter, but they are not enough on their own in this context. Outputs need to withstand review in consequential contexts such as briefing, policy or governance decisions
- Key challenges for agencies: Agencies need confidence that users can review the outputs without redoing the entire task, and that the system supports accountability over time. This requires traceability that supports both auditability and reproducibility, with AI inputs, outputs and use recorded in a durable and reviewable manner. Where identical outputs may not be feasible, agencies will need to define an acceptance criterion based on whether analysts reach substantively consistent conclusions grounded in traceable evidence. Agencies also need confidence that outputs are valid and reliable for their intended use. This requires generative AI testing capability and evaluation datasets that are representative of the use case.
How AIRA supports this scenario
AIRA helps by turning governance-grade AI assistants into a structured design problem rather than a single technology choice. It articulates the solution across layers and domains so agencies can compare buy, build or blend options to identify from the outset where traceability, reproducibility, security, privacy and human oversight may need to be designed.
In summary, AIRA supports this scenario as follows:
- Use AIRA to articulate the design space and surface trade-offs: Use AIRA to structure and compare architecture decisions across experience, orchestration, model sourcing, data pipelines, communication patterns and operating infrastructures. Decisions in one layer may impact or constrain other parts of the architecture.
- Clarify what the architecture should prioritise: In this scenario, traceability and validity/reliability are likely critical to resolve first because they determine whether outputs can be governed, tested and relied on at all. Where the corpus holds personal or classified material, privacy and security are equally foundational. The architecture should prioritise these before adding orchestration sophistication or scaling deployment.
- Develop evaluation datasets, test cases and thresholds to validate the architecture: Validity and reliability are a central challenge without an established benchmark for AI-assisted analysis of authoritative records. Agencies may need to develop evaluation datasets to assess reliability and validity consistently.
- Clarify how reproducibility will be measured: Reproducibility could mean analysts reaching substantively consistent conclusions grounded in traceable evidence, rather than requiring identical outputs.
- Design for human agency, oversight and control at the outset: Consider making oversight interactive, rather than a ‘box-ticking exercise’ and more interrogative and evidence gathering. Other controls include circuit breakers, uncertainty signals, approval gates, escalation gates and recordkeeping bundles.
- Define the simplest governable solution: This typically involves starting with the least complex option capable of meeting the objective, such as grounding through retrieval-augmented generation (RAG) before introducing more complex approaches such as fine-tuning or agentic orchestration. Establish the evaluation framework needed to test the solution and only increase capability, automation or complexity where evidence supports doing so.
Figure 2: Architecture incorporating context engineering, curated authoritative records and an off-the-shelf foundation model
Illustrates an example of the simplest architecture that may satisfy the requirements of this scenario. It combines a bespoke experience layer, context engineering, a curated and well-governed corpus of authoritative records, and an off-the-shelf foundation model on top of Platform as a service.
Legend:
- (G) govern
- (C) configure and govern
- (D) design, configure and govern
Detailed scenario analysis
While parliamentary transcripts are used as an example here, the same architectural challenge applies to legislation, regulations, budget measures, formal policies and other authoritative records.
Functional stack
This section demonstrates the range of architectural options agencies may consider when building this capability. Agencies can also use the functional stack decomposition to identify a component-based buy, build or blend strategy for this solution.
| AIRA Layers | Capability groups (indicative) | Design considerations and pattern options | Example off-the-shelf components |
|---|---|---|---|
| Experience | Analyst workbench | Chat interface, structured query interface, or notebook-style interface for analysts | bespoke |
| Reporting and review views | Structured brief templates, citation-annotated summary views and export to records-management workflows | bespoke | |
| Application and orchestration | Orchestration framework | Coordinate retrieval and generation, multi-step workflows or agentic patterns | LangChain, LlamaIndex, Google ADK, Haystack, CrewAI, Autogen, Mastra |
| Caching and state management | Approaches for response caching, workflow state and repeatable execution where needed | Redis, SQLite, GPTCache, Memcached | |
| Service gateway and control layer | Central control points for routing, rate limits, model access and policy enforcement | LiteLLM, OpenRouter, Portkey | |
| Prompt and retrieval management | Versioning and governance for prompts, retrieval settings and analytical workflows | PromptLayer, Langfuse, Helicone, Jinja | |
| Intelligence and analytics | Model sourcing | Closed models, open-source models or hybrid arrangements | OpenAI GPT, Claude Opus, Gemini, Grok, Llama, Mistral, Qwen, DeepSeek |
| Embedding and retrieval models | Model choices for indexing, retrieval quality and domain-specific search relevance | OpenAI, Cohere, Hugging Face | |
| Entity extraction and resolution | Capabilities for person-linked attribution, speaker resolution and linking records over time where analytically necessary | AWS Comprehend, Quantexa Entity Resolution, Azure AI Language, custom fine-tuned NER models, Langextract | |
| Data and metadata | Ingestion and retrieval pipelines | Batch or event-driven ingestion, preparation, indexing and retrieval over authoritative records | Databricks, Apache Airflow, Kubeflow |
| Data preparation and parsing | OCR, structured extraction, segmentation, metadata capture and quality checks | IBM DataPrepKit, LlamaParse, Unstructured.io | |
| Search and index storage | Vector stores, search indexes, relational stores or hybrid approaches, depending on retrieval needs | Pinecone, Milvus, Weaviate, ChromaDB, pgvector | |
| Platform and infrastructure | Metadata and governance controls | Purpose metadata, role and office metadata, person-linked metadata, access controls, retention and provenance | Bespoke schema |
| Training and adaptation environment | Infrastructure for fine-tuning, adaptation or controlled experimentation | Axolotl, LLaMA-Factory, Hugging Face Trainer, PEFT and LoRA frameworks | |
| Evaluation and monitoring infrastructure | Execution environments for benchmark runs, monitoring and regression testing; evaluation datasets for this use case may need to be built from scratch by domain experts | RAGAS, DeepEval, TruLens, Promptfoo, Langfuse | |
| Inference environment (if self-hosted) | Serves models on agency-controlled infrastructure; required where data classification or sovereignty constraints preclude cloud inference for the relevant corpus | vLLM, TGI, SGLang, Triton, Modal | |
| Operational monitoring | Telemetry, logging and operational dashboards for monitoring T&A | TraceAI, Langfuse, Braintrust |
This table is illustrative only and do not represent preferred, endorsed, or comprehensive technology choices. Note that decisions made in one layer can affect the feasible options in other layers due to dependencies. Decisions made in each layer may also be analysed for impacts on communication, T&A and HAOC.
Given the breadth of considerations in building a bespoke GenAI assistant, architecture can help agencies start with the simplest solution before adding complexity. Architecture can also help agencies compare alternatives, define evaluation criteria and design experiments to test which option appears to be the simplest, safest and most cost-effective way to meet the objective.
Communication
Communication defines how evidence, queries, retrieval results, model outputs and workflow events move securely and traceably across the stack. Agencies need patterns for ingesting authoritative records from source systems, exposing retrieval and analysis services through governed APIs and moving outputs into briefing, review and records-management workflows without losing provenance or introducing uncontrolled copies. Communication patterns should also help agencies identify which open standards can be used for these interactions and understand the capabilities and limitations of those standards before relying on them for interoperability, traceability or long-term portability. Communication patterns should consider how person-linked information moves across ingestion, retrieval, review and downstream briefing workflows, particularly where information crosses trust boundaries or is surfaced to different user roles.
Trustworthiness and assurance
In this scenario, T&A analysis provides key architecture drivers and implications. Agencies need not develop every T&A domain to the same depth from the outset. In this scenario, traceability and evaluating validity and reliability are critical to resolve first – sufficient and proportionate to the intended use – because they determine whether outputs can be governed, tested and relied on at all; privacy and security are equally foundational where the corpus holds personal or classified material. If these cannot be established for consequential use, agencies may constrain use to exploratory analysis or to build that capability first, rather than to add orchestration sophistication or scale deployment.
| AIRA Group | Key architectural drivers | Indicative architectural implications |
|---|---|---|
| Observability | Agencies need enough visibility into system behaviour to detect degraded retrieval, unstable outputs, drift or other signs that the capability is moving outside approved bounds. | The architecture may need to support telemetry, monitoring and review signals across retrieval, generation, workflow execution and downstream use so that emerging issues can be detected and acted on before outputs are relied on in consequential work. |
| Traceability | Outputs may inform briefing, policy or governance decisions and need to be reviewable later. | The architecture may need to preserve links between sources, retrieved evidence, analyst queries, system outputs and downstream use in records or briefing workflows. It may also need to define when deterministic retrieval is required and when generative synthesis is acceptable. Because authoritative records such as legislation are amended over time, it may also need to version source records and bind outputs to the version relied on. |
| Explainability and interpretability | Analysts need to inspect how conclusions were formed and challenge them where needed. | The architecture may need to support evidence presentation, source linkage, workflow transparency and clear signalling of uncertainty and limits. |
| Validity and reliability | Agencies need confidence that conclusions are fit for purpose and stable enough for consequential use. | The architecture may need to support evaluation approaches, domain-specific test cases and comparison of outputs under controlled variation. |
| Safety | Weakly grounded or unsupported outputs may create a governance risk if they are used without sufficient caution. | The architecture may need deterministic bounded use, abstention or warning behaviours, escalation pathways and safeguards against unsupported claims entering consequential workflows. |
| Fairness | Retrieval and analysis may privilege certain speakers, sources, time periods or records if not designed carefully. | The architecture may need to consider corpus coverage, retrieval design and fairness testing in evaluation. |
| Sustainability | Agencies need maintainable architectures rather than brittle or over-engineered solutions. | The architecture may need to favour simplicity, replaceability and manageable evolution of prompts, retrieval logic, models and corpora over time. |
| Security and resilience | Authoritative records may be sensitive and subject to classification, trust-boundary or sovereignty constraints. | The architecture may need clear deployment boundaries, controlled integrations and handling approaches suited to sensitive corpora and trust-boundary constraints. |
| Privacy | Some corpora may contain publicly available personal or person-linked information or may be combined with such information for sensitive analysis. | The architecture may need to support minimisation, purpose limitation, role-based access, accurate attribution, and careful handling of person-linked information |
Human agency, oversight and control
For this scenario, architecture can help agencies design the solution so that the AI assistant performs retrieval, synthesis and draft generation, while humans (the analysts in this scenario) retain evaluative control over whether outputs are fit to use in briefing, policy or other consequential contexts. The goal is not for humans to redo the task from scratch, but for the architecture to provide reviewable evidence, clear intervention points and practical ways to approve, reject, escalate or constrain outputs.
Architecture provides patterns for agencies in defining what can be built in versus what remains when the system is operating. This is illustrated in Table 6.
| Indicative capabilities | Design-time controls | Run-time human control |
|---|---|---|
| Evidence and provenance pack | Define citation, provenance and query-context fields for outputs used in briefing or advice where this level of traceability is needed. | Users can inspect source material, verify claim–evidence links and determine whether outputs are sufficiently supported. |
| Decision support | Define how rationale, confidence and uncertainty are represented in outputs, including conditions for warnings, abstention or constrained responses. | Users interpret rationale and uncertainty signals to support review, further analysis, escalation or non-use of outputs. |
| Recordkeeping and appeal bundle | Define what constitutes a record, applicable retention rules, export formats and how AI artefacts are linked to briefing and advice workflows. | Outputs and associated artefacts are captured and can be retrieved for audit, review or compliance purposes. |
| Supervisory monitoring and oversight | Define what system behaviour, usage patterns and output characteristics must be observable to support oversight. | System behaviour is monitored over time, enabling detection of drift, anomalies or changes in output patterns that may require intervention. |
| Feedback and controlled system improvement | Define structured feedback mechanisms linking user interaction and analytical outcomes to model evaluation and update processes. | Feedback from use informs controlled updates to prompts, retrieval strategies, models and workflows. |
| Operational control and safe stop mechanisms | Define conditions under which system behaviour may be constrained, paused or rolled back, including thresholds for drift, degradation or anomalous outputs. | System operation can be constrained, paused or adjusted in response to emerging risks, degraded performance or governance concerns |