Documentation · Architecture
How the platform
is built.
The engineering behind Assurance: retrieval that respects document structure, access control that prevents shadow autonomy, an authority model that separates permission from authorization, governed execution, and deployment on your choice of boundary.
Reasoning-based retrieval
Flat vector search treats a two-hundred-page framework as disconnected chunks, cannot reason across documents, and loses cross-reference context, which is fatal for regulatory texts. Assurance builds hierarchical tree indices from governance documents and uses agents to navigate them in five moves.
- 01Query decomposition
A complex compliance query is broken into sub-queries, so a question spanning two frameworks becomes one per framework.
- 02Root-level routing
The agent evaluates document summaries to identify which are relevant, skipping entire document trees that do not apply.
- 03Branch-level narrowing
Within relevant documents, it navigates to the most applicable sections, chapters, or control families.
- 04Leaf-level extraction
It retrieves the specific requirements and evidence criteria, with full awareness of their place in the hierarchy.
- 05Cross-document linking
It follows cross-references to related nodes in other documents, enabling multi-hop reasoning across frameworks.
Against traditional RAG
Document structure
Lost during chunking
Preserved in tree hierarchy
Multi-hop queries
Not supported
Native cross-document traversal
Relevance
Vector similarity only
LLM-guided semantic routing
Cross-references
Broken at chunk boundaries
Linked across document trees
Retrieval precision
Chunk-level, noisy
Section-aware, targeted
Scalability
Degrades with corpus size
Tree structure scales logarithmically
Preventing shadow AI autonomy
Role-based access control defines what a role can reach, but not under what conditions, for what purpose, or with what constraints. Assurance layers attribute-based access control on top, evaluating four attribute categories on every request at a policy decision point, in real time.
User attributes
Role, department, clearance, training status, and delegated authority scope. An agent's attributes are derived from, but more restrictive than, its delegating user.
Resource attributes
Data classification, framework scope, control sensitivity, tenant boundary, and evidence confidentiality. Resources carry their own access requirements.
Action attributes
The action requested: read, validate, approve, escalate, override, export. High-impact actions require authorization beyond base role permissions.
Environment attributes
Time, source location, device posture, network context, and session state. A bulk export from an unrecognized network triggers additional verification.
Five AI-specific controls
Agent scope limits
Each agent is restricted to the data domains relevant to its task. An access-control validation agent cannot reach financial risk data, even if the delegating user could.
Data minimization
Agents receive only the elements required for the current task. Context assembly enforces least-privilege data access.
Action boundaries
Agents cannot approve findings, escalate issues, override controls, or modify risk ratings without passing a human gate. The boundary is architectural.
Session isolation
Agent execution contexts are isolated between tenants and between sessions. No data from one session persists into another.
Access logging
Every data element an agent touches is logged with full attribution: which agent, on behalf of which user, for which task, at what time.
Access is re-evaluated continuously, not only at first authorization: a role change, a device posture drop, an anomaly, or a session timeout revokes access in real time.
Governed AI execution
The control surface is the execution layer, not an overlay. Every action is bounded, evaluated, and traceable, which means no agent can operate outside its governance.
Token budget & cost governance
Per-agent token budgets
Validation agents, Otto, and analysis agents each operate within configurable allocations that prevent runaway consumption.
Per-task rate limiting
Individual validation runs, document analyses, and queries are rate-limited to ensure fair allocation across concurrent users and tenants.
Cost allocation and chargeback
Token consumption is tracked and attributed per agent, task, user, and tenant, so finance teams can allocate AI costs accurately.
Budget alerting
Configurable thresholds trigger alerts as consumption approaches limits, with automatic throttling. A threshold bound to a risk appetite clause escalates as an appetite breach.
The decision trace
Input trace
The full context window assembled for the agent: which regulatory, organizational, project, and evidence context were provided.
Reasoning trace
The step-by-step path the agent followed, including which tree index nodes were traversed and what conclusions were drawn.
Authority trace
The delegation path evaluated, the limits applied, and the derivation from control to appetite clause to obligation, at the policy version in force.
Output trace
The raw agent output before post-processing, the judge evaluation results, and the final output delivered.
Modification trace
Any human-in-the-loop modifications, approvals, or overrides applied, with full attribution.
Output verification
Schema compliance
Outputs are validated against expected schemas: scores must be numeric 0 to 100, severities must match defined categories, and citations must resolve to actual evidence.
Factual grounding
The layer confirms claims are grounded in the assembled context. Any assertion that cannot be traced to source evidence is flagged.
Consistency
Outputs are checked against prior assessments of the same controls to detect scoring drift or contradictory findings.
Policy compliance
Outputs are validated against policy constraints, so agents do not recommend actions outside policy or claim about frameworks they were not asked to evaluate.
Agent tool interface & MCP
Assurance uses a governed tool integration layer built on the Model Context Protocol. Tools are cataloged in a registry with their permissions and constraints, and agents discover them through it rather than through hardcoded integrations.
Tool-level permissions
Each agent is authorized to use only the tools relevant to its function. A validation agent can reach the evidence repository but not the ticketing system.
Action-level controls
Within authorized tools, agents may be limited to specific actions: read but not write, query but not delete.
Versioning and compatibility
Tool interface versions are tracked, and agents are tested against specific versions to prevent breaking changes on update.
Execution sandboxing
Tool calls run in isolated, container-based sandboxes with full filesystem and network isolation, so untrusted code cannot affect the host.
Latency governance
Tool call latency is monitored and bounded, so agents cannot block indefinitely on external calls even when downstream systems are slow.
Programmatic Tool Calling
Standard tool calling appends every raw tool response to the model's context, so a three-sentence question can consume tens of thousands of tokens of redundant data. Instead, the agent writes one orchestration script that makes all the calls, processes results in a sandbox, and returns only the summary to the model.
N-entity fan-out
Validating controls across 50 systems aggregates all 50 lookups in one script execution rather than 50 sequential inference passes.
88 to 92% token reduction
Keeping raw tool responses out of the context window cuts input token consumption sharply, reducing compute cost and latency.
Preserved reasoning quality
The finite context window is reserved for reasoning rather than being consumed by verbose intermediate data.
Production isolation
Scripts execute in container-based sandboxes, so even a script with errors cannot affect the host system or other agent sessions.
Deployment options
The same platform, on your choice of boundary. In every model, ingested data stays within the tenant, and read-only access ensures it never modifies source systems. What changes is where components run, who operates them, and which model endpoint serves the AI layer.
SaaS Cloud
Fiducia-hosted and fully managed, with tenant isolation and tenant-scoped keys.
AI layer: OpenAI API under Fiducia's provider agreement: zero data retention, no training on customer data.
Typical fit: Fast time to value; institutions without hard residency constraints.
AWS / Azure / GCP Private Cloud
Deployed into the customer's own cloud account, subscription, or project.
AI layer: The enterprise's own AI layer and tokens.
Typical fit: Institutions standardized on a cloud, requiring in-boundary processing.
On-Premises
Deployed into customer-operated infrastructure.
AI layer: The enterprise's own AI layer, including fully internal models.
Typical fit: The most constrained estates: sovereign, on-shore, or air-gap-adjacent mandates.
Data handling, model exposure, and the security backbone are covered in Trust & operations.
More in the documentation