AI Risk Auditor reference design

Auditable Modular RAG

Contract-driven agentic replacement with protected authorization, assurance, evidence, and release controls.

Reference profile v1.3.3 Architecture snapshot · 6 Sep 2026

Citable definition · for humans, search engines & generative AI

What Auditable Modular RAG is

Auditable Modular RAG is a reference architecture for Retrieval-Augmented Generation (RAG) and agentic AI systems in which components can be replaced when models, retrieval technology, requirements or the target architecture change — without losing authorization, assurance, evidence or rollback.

It applies Contract-Driven Agentic Development (CDAD): versioned module contracts and boundary contracts define what may be exchanged; a protected enforcement plane keeps authorization, policy and release rights outside the generating agent; agency and risk tiering set proportionate assurance; and evidence-backed release and retirement gates keep every replacement auditable. The agent is treated as an untrusted generator without production, gate, policy or self-approval rights.

This page is the interactive public reference (profile v1.3.3, snapshot September 2026) published by Siegfried-Thor Bolz, Enterprise AEMaaCS architect and AI Risk Auditor. Canonical URL: https://www.siegfried-bolz.de/rag-reference-architecture.html. Related portfolio: siegfried-bolz.de · AI Audit for Enterprise CMS · AI Governance Watch.

How to cite: Siegfried-Thor Bolz, Auditable Modular RAG — Contract-Driven Agentic Reference Architecture, reference profile v1.3.3 (2026), https://www.siegfried-bolz.de/rag-reference-architecture.html. Quote the definitions above with that URL and version. Commercial reuse requires prior written permission (see authorship footer).

Architecture motivation

Why I created this architecture

As an AI Risk Auditor, I want AI systems to evolve without turning every technology change into a rebuild—or every module boundary into unmanageable complexity.

Replace technology safely

RAG components should be replaceable when models, retrieval technology, requirements, or the target architecture change.

Bound autonomous agents

Agents may develop and integrate replacements only within versioned contracts, least-privilege permissions, and protected test and release gates.

Keep change auditable and secure

Every replacement must preserve authorization, provenance, cybersecurity, independent evaluation, evidence, and rollback.

Design principle: as few modules as possible; as many separate control and replacement boundaries as necessary.

How to read it Follow the risk thread—not just the boxes

Start with purpose, exposure, and decision rights, then follow the two RAG paths from left to right. At every hand-off, ask which contract defines the exchange, which guardrail states the permitted behaviour, which protected control enforces it, and which evidence proves that the remaining risk is acceptable. The page is designed to be read as an assurance case, not as a catalogue of fashionable components. Audit rules are control objectives; GR, CTR, and G0–G8 are their architecture and workflow projections, not additional controls to count cumulatively.

The recommended reading path

  1. Establish mandate, purpose, and pre-control exposure

    Begin at lifecycle gate G0, shown below: identify the intended purpose, prohibited uses, stakeholders, owners, risk appetite, the seven-dimension risk profile, and the agent’s autonomy, authority, tools, environment, and potential causal impact. Controls must not be used to disguise the baseline exposure.

  2. Follow the two operating paths from left to right

    Read the upper lane from Enterprise Sources to the versioned Search Index. Then read the query lane from the authenticated user through authorization, corpus eligibility, retrieval, generation, output assurance, and the grounded answer.

  3. Challenge every boundary before trusting a component

    Blue modules are replaceable units; purple CTR labels define exchanged artefacts and invariants; GR badges define required behaviour; red labels expose trust and enforcement crossings. Authorization and content eligibility must act before candidate materialization, fusion, or reranking.

  4. Open the contracts and guardrails

    Select any CTR or GR badge. Its popover is generated from the versioned German or English Markdown source and shows scope, producer and consumer, invariants, enforcement, failure behaviour, evidence, ownership, and versioning without duplicating the definition in this HTML file.

  5. Close the loop in the protected assurance layer

    Finish below the operating paths. Confirm independent evaluation, control effectiveness, KRIs, residual risk, signed release authority, monitoring, rollback, incident response, and trigger-based reassessment. A replacement is acceptable only when it is evidenced and reversible—not merely when it runs.

The red thread Purpose → pre-control risk → contract → guardrail → protected control → test and evidence → residual risk → release, rollback, or refusal.

Lifecycle decision gates · G0–G8

Scope → authorize work → assure the candidate → release → replace, monitor, or retire

  1. G0

    Scope and Risk

    May the use case proceed to further analysis?

  2. G1

    Contract Approval

    Is the target state, including risk treatment, complete and approved?

  3. G2

    Generation Admission

    May the agent work with the assigned sandbox, identity, tools, data, and budgets?

  4. G3

    Build and Static Assurance

    Is the generated artefact technically admissible?

  5. G4

    Contract and System Validation

    Does it satisfy interface, semantic, integration, and security requirements?

  6. G5

    Release Authorization

    Is residual risk within tolerance—or independently and temporarily accepted?

  7. G6

    Replacement

    May the existing component be replaced with proven equivalence and safe rollback?

  8. G7

    Runtime Assurance

    Does the system remain within its boundaries and current risk profile?

  9. G8

    Retirement

    Are permissions, data, dependencies, evidence, and closure obligations resolved?

Gate rule: required evidence is defined in advance, collected independently or automatically, and protected from the generating agent. A failed gate stops progression; every override must be authorized, time-limited, and traceable.

Why this is an evidence-led audit architecture

The named course materials are design inputs, not decorative references. Their ideas are traceable into risk tiers, contracts, guardrails, control ownership, lifecycle gates, evidence requests, and release decisions. I have combined this practice-informed professional education with an extensive AI and cybersecurity library and AI-assisted research; the architectural judgement and final editorial responsibility remain mine.

Ajit Jaokar · Guardrails, Controls & HITL

Intent must become enforceable and observable

Guardrails use seven mandatory fields: objective, risk, boundary, trigger, enforcement, escalation, and monitoring. Material risks require defence in depth rather than one brittle filter.

Visible here: GR definitions, layered controls, protected enforcement, bypass tests, and meaningful human-oversight boundaries.

Yemi Adeniran · Risk Management Overview

Governance begins before technical design

A formal mandate, AI Risk Policy, accountable roles, resources, lifecycle coordination, feedback, and periodic review are prerequisites—not paperwork added after deployment.

Visible here: the lifecycle gate map G0–G8 above, explicit owners, decision rights, resourcing expectations, and the continuous five-phase risk lifecycle.

Yemi Adeniran · Analysis, Monitoring & Reporting

Residual risk depends on proven control effectiveness

Qualitative, quantitative, or mixed analysis must disclose uncertainty, assumptions, exclusions, third-party exposure, and what cannot be measured. Monitoring must cover KRIs and relevant change events.

Visible here: independent EvaluationResult evidence, separate inherent and residual risk, control testing, third-party monitoring, and trigger-based reassessment.

Chris Fong · Risk Classification

Assurance must scale with what can actually go wrong

Seven use-case-independent dimensions classify consequences and system behaviour: harm, autonomy and reversibility, data, criticality, scale, cybersecurity, and human oversight.

Visible here: a transparent reference profile plus non-compensating risk floors, hard stops, and proportionate assurance tiers.

Vignesh Manikam + Agentic AI Profile

Agency and governance must be assessed at system level

Macro governance and micro implementation are joined through independent validation. Agentic risk scales across autonomy, authority, tool and resource access, environment, interaction, reversibility, and causal impact.

Visible here: enterprise, portfolio, and system governance; bounded agency tiers; least privilege; containment; independent go/no-go; rollback and decommissioning.

Professional showcase

Demonstrates how I translate AI risk frameworks and practitioner knowledge into concrete technical boundaries and auditable decisions.

Audit field guide

Structures scope, owner interviews, evidence requests, control testing, replacement reviews, and risk acceptance challenges during an AI audit.

Reusable method—not a copy-and-paste blueprint

Every identified module in every AI system must be assessed separately; its contracts and guardrails must reflect the real purpose, data, agency, harm, and operating context.

Focus
Layers

RAG component and control map

Select a component for audit detail; select a contract or guardrail label for its canonical Markdown definition.

Agent-replaceable unit Protected control Stable data/evidence anchor External actor or source

Offline indexing and knowledge representation

Replayable from immutable source evidence · new index versions are built, never mutated in place

External sources Enterprise Sources CMS/DAM (e.g. AEM), SharePoint, PIM/product catalog (Salesforce), file stores, APIs Source ACL Change events GR-01 GR-05 GR-11
Source Adapter Contract External trust boundary
RU-A1 · Replaceable Source Acquisition Connect, detect changes, validate file type Connector Malware scan Source manifest GR-03 GR-05 GR-11
SourceEnvelope Write-only ingestion boundary
Stable evidence anchor Raw Evidence Store Versioned original bytes, hashes, ACL references Object version Retention Replay GR-03 GR-10
RawDocumentManifest Read under scoped identity
RU-A2 · Replaceable Canonicalization Parse, OCR, normalize structure and metadata Docling OCR Trust labels GR-03 GR-05 GR-11
CanonicalDocument Content remains untrusted data
RU-A3 · Replaceable Representation Build Chunk, embed, build a new atomic index version Chunking Embeddings Sparse vectors Index writer GR-03 GR-04 GR-11 CTR-05 ChunkRecord CTR-06 EmbeddingRecord
IndexManifest Atomic version promotion
Versioned data product Search Index Dense + sparse vectors with security attributes Qdrant Tenant partition Read alias GR-02 GR-04 GR-11
IndexManifest binds RU-B to one approved index version and schema

Online retrieval and grounded generation

Authorization and corpus eligibility precede every retrieval branch · the generator never validates itself

External actor Authenticated User Query, tenant, role and session context Identity Intent
IdentityContext Authentication boundary
Protected control plane Authorization & Corpus Eligibility Two signed PDP decisions, one fail-closed retrieval predicate OPA Auth PDP Corpus PDP Trust epoch GR-01 GR-02 GR-11
RetrievalRequest RetrievalEligibilityPredicate Fail-closed eligibility boundary
RU-B · Replaceable Retrieval Authorized hybrid candidates and semantic ranking Query rewrite Dense/sparse Fusion Rerank GR-01 GR-02 GR-04 GR-11 CTR-11 CandidateSet
RankedContext Only authorized chunks cross
RU-C · Replaceable Generation Context assembly, prompt composition, LLM gateway Context builder LiteLLM Model policy GR-06 GR-07 CTR-13 GenerationRequest
GenerationResult Independent verifier boundary
Protected assurance Output Assurance Schema, citations, grounding, policy, redaction Grounding Policy check Fallback GR-02 GR-07 GR-08 GR-11
AssuredAnswer Consumer boundary
Consumer output Grounded Answer Validated response with citations and evidence IDs Citations Status Trace ID
Security invariant: unauthorized, quarantined, expired, or superseded content or metadata must never reach candidate fusion, the reranker, generation context, caches, or traces.

Protected cross-cutting assurance layer

Stable control objectives · independently governed implementations · never changed in the same autonomous replacement set

Protected workflow Thin Orchestration State, routing, retries, timeout, compensation GR-09
Protected acceptance Evaluation Harness Golden set, security tests, metrics, thresholds GR-08 GR-10 CTR-16
EvaluationResult
Protected evidence Observability & Evidence Trace correlation, redaction, immutable audit records GR-02 GR-03
Protected enforcement Build & Release Control Contract tests, security gates, signing, rollback GR-08 GR-10
One governed path, one evolving record The record progresses from release approval through deployment and monitoring to evidenced closure. G0 → G1 → G2 → G3 → G4 → G5 → G6 → G7 → G8
Lifecycle assurance artefact AAR-01 · Replacement Assurance & Acceptance Record The signed record links scope, risk tier, contracts, evidence, residual risk, release and rollback; retirement evidence becomes mandatory only when the record is closed. Open record definition →

Component details

Select a component on the map

Details are loaded from the verified reference bundle. If the bundle fails its integrity check, this panel stays empty by design.

Input contracts —
Output contracts —
Guardrails —
Audit evidence —
Replacement trigger —
Replacement constraint —

The architecture minimizes runtime boundaries while preserving independent contracts, security enforcement, evidence, and rollback.

FAQ · citable answers

Questions generative systems (and clients) ask

Short, self-contained answers intended for citation. Prefer these over paraphrasing interactive UI chrome.

What problem does Auditable Modular RAG solve?

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.

What is Contract-Driven Agentic Development?

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.

Is this a production-ready product?

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.

Who should use this reference?

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.

How often is this reference updated?

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.

Content cadence

Reference changelog

Dated public updates to this reference. Cite the profile version together with the URL when quoting.

  1. Findability & citation layer Added crawlable citable definitions, FAQ answers, citation guidance and this changelog. Portfolio integration on siegfried-bolz.de (nav, feature section, sitemap, JSON-LD).
  2. Reference profile v1.3.3 Clarified blocking gates for operator-controlled RAG / integration / deployment pipelines vs. third-party SaaS evidence.
  3. Profiles v1.3 → v1.3.2 Approval-signature binding, trust-key register, agency-tier floor, expiry of time-bounded approvals, and explicit source-system neutrality (not an AEM-only reference).
  4. Public interactive reference First public interactive system map for Auditable Modular RAG / Contract-Driven Agentic Development.