Auditable Modular RAG

It keeps RAG and agentic systems evolvable: components can be replaced when technology or requirements change, while authorization, evaluation, evidence and rollback stay under protected controls. The goal is safe change without a full rebuild and without opaque agent autonomy.

An architecture pattern in which AI agents may propose and integrate replacements only inside versioned module and boundary contracts. The agent is an untrusted generator; enforcement, tests and acceptance thresholds remain outside its control.

No. It is a verified public reference design (test keys, reference schemas and an interactive map). Real deployments still need organization-controlled trust roots, publisher signatures, environment-specific policies and live evidence stores.

AI risk auditors, enterprise architects, RAG/GenAI engineers and compliance owners who need a shared language for replaceable, assurance-backed agentic RAG systems — especially under the EU AI Act, NIST AI RMF and OWASP Agentic guidance.

The page carries an explicit reference-profile version and a public changelog (see right). Material architecture changes bump the version; editorial and findability updates are logged with dates so citations can name the profile they used.

Guardrails define the boundaries of permitted behaviour. Module and boundary contracts specify the obligations a component or hand-off must satisfy, including data structure, meaning, security and evidence. Controls enforce these requirements through code, configuration, platform services or accountable human decisions. A contract describes the obligation; it does not enforce itself.

Conditions that can be reliably checked by software are enforced automatically, for example access rights, schemas, versions and resource limits. Business judgements and designated approvals remain with authorized people. Where human approval is required, the workflow must block progression until a valid decision is recorded for the exact scope and version under review.

No. Routine requests can run automatically within approved boundaries. Human oversight is selected for the risk and decision involved, such as resolving a source conflict or authorizing a material change. A four-eyes review is required where the applicable decision policy calls for independence; it is not an extra approval step for every box or every answer.

No. The map shows logical responsibilities, including sources, stores, processing modules, protected controls and consumers. Several modules may share one application or deployment. Separate services or permission boundaries are introduced where security, operations or independent replacement justify them; modularity does not require a microservice for every box.

A coding agent may propose changes only within its authorized implementation scope and versioned contracts. It may not independently weaken protected policies, acceptance thresholds, release tests, evidence or approval rights. Protected acceptance holdouts are inaccessible to the generating agent. Independent checks and authorized release decisions determine whether its candidate may replace the existing component.

A knowledge update changes the admitted source content and search representation, such as a newly released manual. Replacing a module changes how the system processes information, for example through a new parser, retrieval strategy or model. The two paths have different validation and release requirements. An ordinary product update does not automatically trigger the full software-replacement lifecycle.

Controls and assurance depth follow concrete risks, exposure and the effect of a change. Existing platform controls and evidence can be inherited within their verified scope instead of being duplicated for every module. Additional tests, forms or approvals must have a decision-relevant purpose. Non-applicable requirements are justified, conditional requirements remain trigger-aware, and routine processing stays automated within approved limits.

The optional fictional example applies this reference to PIM publication, RAG knowledge preparation and a checked internal-support answer. Its surrounding landscape includes Azure, Contentful and a product website. Product-sheet JSON generation and publication in Contentful are context, not a separate guided walkthrough. No live customer services are called, and no actual software or model replacement is performed. The example remains separate from the technology-neutral reference.