Trust should beopen to inspection.
Effective date September 30, 2026 · Document version 2026-09-30
Where processing happens. What an answer relies on. Who authorizes a change. Devexana makes these boundaries part of the platform.
This is a product architecture overview, not a certification or a statement that your deployment meets a specific regulatory framework. Deployment requirements and evidence are reviewed with your organization.
Primary intelligence runs locally.
Devexana collects records from configured sources and uses local models to retrieve and interpret that information on the appliance. The local answer path does not require sending your organization’s records to a cloud model.
Hardware, source access, and enabled capabilities are selected for the deployment. Network boundaries and permitted external destinations should be reviewed as part of that configuration.
Local processing is a defined data path. An optional external path has its own authorization and audit requirements.
Devexana on your applianceRetrieve records · Interpret locallyYour organization’s records stay in the local answer path.
Evidence belongs with the answer.
Corpus-backed claims carry citations to the records used to produce them. An operator can inspect the source behind a claim and distinguish a captured observation from a live verification.
When the available records cannot support an answer, the answer path is designed to abstain. A previous resolution may inform a diagnosis; it does not prove that a new incident has the same cause.
“Where does this uplink go?”
The answer points to the neighboring switch and the port it connects to.
Retrieval follows the user’s access.
The retrieval path filters information using the asking actor’s permissions. Conversation context helps resolve references; it must not expand the user’s access to records.
Source credentials, user roles, and allowed collections need to be configured for the deployment. Evaluate access boundaries with representative users and records before rollout.
A follow-up question keeps the same access boundary.
A path you open, or none at all.
Devexana holds no access to your systems. The appliance answers on your own network, behind your firewall, and accepts no inbound connection from us. We can reach it only where you open a path: a remote session you start and watch, or a virtual private network you establish, authorize in writing, and can close.
We operate no tunnel, no agent, no relay, and no standing credential of our own. Section 6.1.2 of the Terms says the same thing in contract language. The Devexana Cloud dashboard is not a path in: it carries no route into an appliance.
A path you open is a designation you can revoke on written notice, and the appliance is reached again only on your terms.
The Devexana Cloud dashboard carries no route into an appliance.
Infrastructure changes require a person.
Read-only connectors collect information. Infrastructure changes use a separate, gated path that is disabled by default and restricted to supported intents and devices.
A model may prepare a proposal. It cannot grant itself permission to apply it. Each supported infrastructure change requires human acceptance, with the relevant scope, checks, and transitions recorded.
Review before execution
- Confirm the target device and the exact requested change.
- Review the available checks and expected operational effect.
- Capture the pre-change state where supported.
- Authorize the individual change and verify the result.
Rollback depends on device capabilities and operational conditions. It is not a guarantee that every change can be reversed.
- PrepareA supported change is drafted.
- ReviewA person checks the target and effect.
- AcceptThat person authorizes this change.
- VerifyThe result and transitions are recorded.
Change capabilities are disabled by default.
Privileged activity leaves a record.
The platform uses an append-only, hash-chained audit trail. Database triggers enforce restrictions on editing or deleting audit rows, and privileged transitions write audit events.
The hash chain supports detection of changes to recorded history. Audit evidence must still be evaluated alongside deployment configuration, administrative access, retention, and operating procedures.
References to AU-9 describe the audit-control design. They do not constitute an independent certification or an authorization to operate.
Each record links to the history before it. Editing that history changes the chain.
External assistance is an explicit choice.
Cloud AI sends nothing until a cloud AI key or sign-in is stored on the appliance. What each capability sends, and when a person confirms it, is set out in Privacy Policy Section 2 and Terms Section 8. Every call is written to the egress log before it is made.
- KeyA cloud AI key or sign-in is stored on the appliance.
- RulesPrivacy Policy Section 2 and Terms Section 8 set out what is sent and when a person confirms it.
- RecordWrite the egress event before sending.
Cloud AI sends nothing until a key is stored.
Review the controls in your context.
Your organization’s requirements determine the scope of an evaluation. A product description is only the starting point; the configured deployment and its observed behavior are what your team needs to assess.
- Source systems, credential scope, and permission boundaries.
- Local hardware and permitted data flows.
- Enabled change capabilities and acceptance requirements.
- Audit evidence, operating procedures, and support scope.