05EXPERIENCE
Projects · Agents · DraftsIdentity context · Human reviewDiana Architecture
Company context in.Cited work out.
A sovereign Work AI stack designed to connect approved sources, preserve access, run company-context processing inside the selected boundary, and return work reviewers can trace.
SYSTEM MAP / 015 LAYERS
04ORCHESTRATION
Skills · Policy · ApprovalsApproval gates · Scoped actions03INTELLIGENCE
Retrieval · Models · CitationsNo public-AI egress · Evidence binding02COMPANY CONTEXT
Sources · Permissions · IndexSource 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 where the work goes.Know what controls it.
Follow a single request from a person with a role, through approved company context, to a cited output and a reconstructable activity record.
Compare the renewal clauses and draft a cited risk memo.
01
Identity
ROLE RESOLVEDResolve the person and project.
Diana begins with the user, role, 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 relevant company context.
The system finds material from approved sources without flattening access boundaries.
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 ATTACHEDBind material claims to evidence.
The result carries links back to the source file and page, with clause or cell detail where supported.
06
Approve
REVIEW REQUIREDHold consequential work for review.
Human approval can gate agent 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 data path moves work.The control path governs it.
Diana separates the flow that produces an answer 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 work.
A person or governed agent starts work.
→Permitted source material is assembled.
→Models operate inside the selected boundary.
→Cited work is prepared for review.
02
Control plane
The checks and evidence that surround every step.
User, role, project, and source scope.
→Retrieval and action permissions.
→Human gates for consequential work.
→Source lineage and activity records.
Company context
Connect systems.Keep their boundaries.
Diana connects categories of systems already used by the company. 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 environment.
Bring your identity, network, source, retention, key-custody, and deployment requirements. We will review the architecture against them.