05EXPERIENCE
Search · Assistant · CreationIdentity context · Human reviewDiana Architecture
Company context in.Personal AI help out.
A sovereign Work AI stack designed to map approved sources, people, relationships, and access—then give each person AI help that fits their role inside the selected boundary.
SYSTEM MAP / 015 LAYERS
04ORCHESTRATION
Assistance · Policy · ApprovalsApproval gates · Scoped actions03INTELLIGENCE
Retrieval · Models · ContextNo public-AI egress · Evidence binding02COMPANY CONTEXT
Sources · People · PermissionsSource ACLs · Scoped connectors01DEPLOYMENT BOUNDARY
EU cloud · On-premise · Air-gappedCustomer keys · Audit StreamREQUEST ↓CONTROL AT EVERY LAYER↑ CITED WORK
One request · end to end
Know what Diana understands.Know what controls it.
Follow a request from a person with a role, through the approved company context they can access, to useful AI help and a reconstructable activity record.
Compare the renewal clauses and draft a cited risk memo.
01
Identity
ROLE RESOLVEDUnderstand the person and their context.
Diana begins with the user, role, team, project, and connected-source scope attached to the request.
02
Permission
ACL VERIFIEDCheck access before retrieval.
Source permissions determine which records can enter the working context.
03
Retrieve
CONTEXT SCOPEDSelect context that fits the person.
The system finds material from approved sources without flattening access boundaries or treating every person the same.
04
Process
ZERO EGRESSRun intelligence inside the perimeter.
Company context is processed in the selected Diana deployment without external LLM API calls.
05
Cite
EVIDENCE ATTACHEDMake important answers inspectable.
Where the work requires it, the result can carry links back to the source file and page, with clause or cell detail where supported.
06
Approve
REVIEW REQUIREDKeep important actions under review.
Human approval can gate AI actions, exports, and handoffs before work moves forward.
07
Record
AUDIT WRITTENWrite the activity to the Audit Stream.
Reads, edits, approvals, exports, and automated activity create a record teams can inspect.
Two planes · one system
The context path helps people.The control path governs it.
Diana separates the flow that gives people useful AI help from the controls that decide what may enter, what may happen, and what must be recorded.
01
Data plane
The path company context takes to become useful AI help for each person.
A person starts with their role, team, and request.
→Permitted company information is assembled for them.
→Models operate inside the selected boundary.
→Useful answers, creation, and actions are prepared.
02
Control plane
The checks and visibility that surround every step.
User, role, team, project, and source scope.
→Retrieval and action permissions.
→Human gates for consequential work.
→Source lineage and activity records.
Company context
Map your company.Keep its boundaries.
Diana connects the systems, people, permissions, and relationships that make your company unique. Connector scope, authentication, sync behavior, and deletion handling are confirmed for each deployment.
THE RETRIEVAL RULE
If a person cannot access a source outside Diana, they cannot retrieve it through Diana.
Documents and file systems
Contracts · Policies · Reports · Shared drives
File and folder access remains part of retrieval scope.Email and messaging
Mailboxes · Channels · Threads · Attachments
Connected spaces are limited to approved organizational scope.Business systems
CRM · Case tools · Internal databases
Records are retrieved according to role and connector configuration.Proprietary systems
Internal applications · Domain repositories
Integration depth is defined during architecture review.Deployment topology
One control model.Three possible perimeters.
The architecture remains recognizable across deployment modes. What changes is where the boundary sits, how updates arrive, and who operates the surrounding infrastructure.
Default topology
A controlled European Diana environment.
For regulated teams that need a dedicated processing perimeter without operating the entire stack themselves.
- Perimeter
- Dedicated European environment
- Network
- Controlled service paths
- Operations
- Deployment-specific operating model
Architecture ledger
Separate the invariantfrom the configurable.
A credible architecture review distinguishes core design intent from controls selected by the customer and behavior that depends on deployment.
01
Core architecture
No external LLM API calls
Diana is designed to keep company-context processing inside the selected deployment.
Permission-aware retrieval
Connected-source access is intended to constrain what each person can retrieve.
Citations and Audit Stream
Material claims and activity are designed to produce inspectable evidence.
02
Configurable
Retention and export policy
Retention windows, export controls, and review gates are selected for the deployment.
Key custody
Customer-managed encryption keys are available depending on deployment requirements.
Connector scope
Systems, data domains, authentication, and synchronization are agreed during implementation.
03
Deployment dependent
Operations and updates
Staff access, maintenance, and software updates follow the chosen topology and runbook.
Network paths
Allowed ingress, egress, and connector paths change between EU cloud, on-premise, and air-gapped modes.
Availability design
Resilience, backup, recovery objectives, and monitoring are confirmed for the deployed environment.
Architecture review
Questions to resolvebefore deployment.
The exact topology should be reviewed against identity, network, retention, key custody, and operational requirements.
No. Diana is designed to run without external LLM API calls so company context remains inside the selected deployment boundary.
Private architecture review
Map Diana to your company.
Bring your identity, teams, sources, network, retention, key-custody, and deployment requirements. We will review the architecture against them.