Reference architecture
Eight competencies and an eight-phase method explain what we do. This page explains how the system is built, layer by layer — for readers who need to evaluate it technically before signing off, not just read the outcome.
Not a single architecture applied to every client: a set of patterns we recombine based on the process, the risk level and the infrastructure constraints of each organization — the same logic already stated for how we choose technologies, one level deeper here.
RAG & evaluation
Retrieving sources and verifying accuracy
Answers are grounded only in authorized sources retrieved at request time, never in the model's unverifiable internal knowledge. Before release, accuracy is measured on the client's real cases, not prepared examples, with explicit thresholds below which the system flags instead of answering.
Identity & permissions
Who can do what, on which data
The system inherits roles and permissions that already exist in the organization instead of creating new ones: a user sees and queries only what their permissions already allow elsewhere, with clean segregation between environments and between clients.
Application guardrails
Explicit limits on what the system can do
Every piece of content retrieved from documents, emails or external pages is treated as untrusted input: system-prompt isolation, sanitization, and an explicit perimeter of actions agents can execute, verified with targeted red teaming before release.
Logging & audit trail
Every source, action and decision traced
Technical and application logs link every answer to the source that generated it and every action taken to whoever initiated it, retained according to agreed policies and usable for internal audits, external reviews and incident analysis.
Versioning
Models, prompts and document bases under version control
Models, prompts and document bases change over time — vendor updates, new documents, threshold tuning. Every change is versioned and tested before release: if it degrades measured accuracy, we roll back to the previous version instead of accepting the regression in production.
Human review
High-impact actions stay human, by design
Confidence thresholds determine when the system acts on its own and when it flags for review; high-impact actions remain subject to explicit human confirmation in every case, as a design choice — not because the model isn't accurate enough.
These six layers aren't a software product sold as-is: they're the criteria we use to design every system, recombined based on the process, the risk level and the organization's infrastructure constraints — cloud, on-premise or hybrid. The policy, certification and AI Act detail behind each layer lives on the Security and governance page.
Want to see how this applies to your case?
An AI Assessment starts from a real process, not a theoretical architecture: it checks which of these layers actually matter for your context, before any development commitment.
Request an AI Assessment