Trust should beopen to inspection.

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.

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.

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.

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.

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.

External assistance is an explicit choice.

Optional external assistance is disabled by default. When a permitted external path is enabled, an operator reviews a redacted preview and authorizes the request. The destination must be permitted by the deployment’s egress controls.

The egress record is written before the external call. Provider arrangements, data retention terms, destinations, and edition restrictions are reviewed for the specific deployment.

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.