What we hold,and what we cannot.

1. Who this policy applies to

This policy applies to our customers, prospective customers, resellers, partners, and website visitors, and to information collected through our websites, our applications, and the software and appliances we supply (together, “Devexana Resources”).

It does not describe what a customer’s own appliance holds about that customer’s staff and systems. That data belongs to the customer and is governed by the customer’s own policies and by its records-retention obligations. Section 2 explains why.

2. The architecture this policy describes

Devexana is a local-first product. It runs on an appliance inside the customer’s building, inside the customer’s network boundary, under the customer’s physical control.

The software transmits no customer operational data to Devexana. It sends us no usage data, no crash reports, no analytics, and no operational, network, inventory, or monitoring data about a customer or a customer’s systems, unless an administrator turns on the optional appliance telemetry described in Section 5B, which is off in every appliance we ship and carries a closed list of readings and nothing else. We operate no mirror of a customer’s records. Devexana Cloud, described in Section 2B, holds account and appliance records; it holds no customer records.

We hold no readable customer data, and we cannot produce readable customer data in response to a subpoena or other legal process directed at us. The customer-related material that can sit in our custody is the encrypted backup ciphertext described in the next subsection, which we cannot decrypt, and the account and appliance records described in Section 2B.

Records read from a customer’s connected systems, and everything derived from them (records, embeddings, summaries, chat history) are stored only on that appliance, in an encrypted local database. A process-wide egress guard blocks unexpected outbound connections, and every outbound call the appliance does make is written to an append-only egress log the customer can read, except web lookups, which are recorded in the audit log as Section 8.6 of the Terms describes.

Once a key or sign-in for a cloud AI provider is stored on the appliance, these optional capabilities can send the content of a question off it: the cloud consult; and the appliance’s built-in cloud assistance, which the network assistant uses and which, where enabled, also plans chat investigations and writes chat answers. Built-in cloud assistance can send the question together with records, device configuration, and command output the appliance read. No edition blocks any of them. The Government/Education edition and the Business edition behave the same way; on a Government/Education-edition appliance, the settings review reports cloud escalation as a finding while it is on. Depending on how the appliance is configured, these capabilities send to OpenAI (the testing partner), OpenRouter, Anthropic, and Amazon Bedrock. Every call is written to the egress log before it is made.

The cloud consult is off by default. An administrator turns it on; where the customer has turned on dual approval, a second administrator must agree. The consult sends the question; on the Anthropic route it also sends the title and problem text of up to five records the appliance retrieved for the question. Before anything is sent it is redacted: a suspected secret, or an identifier-shaped span that cannot be classified, blocks the send; other identifiers are replaced with placeholders, except on the OpenRouter route and in cloud deployment mode, where by default they are sent as written. On the OpenAI, OpenRouter, and Amazon Bedrock routes, a named user consents to each question on a preview of the redacted copy. On the Anthropic route, a user may also consent once for a whole conversation, and by default a question the appliance could not answer, and classifies as safe to consult on, is sent without a confirmation step; a question about the customer’s own network state, identities, or incidents is never sent that way. On request, Devexana configures the appliance to require a confirmation for every send. Where the appliance is set up in cloud deployment mode, a question the appliance cannot answer on its own is sent to the consult without a confirmation step. Turning the consult off stops the consult’s calls.

Built-in cloud assistance uses the same key as the consult’s OpenRouter route, which requests zero data retention on every call. Once that key is stored, the part of built-in cloud assistance that uses it is on unless an administrator turns it off, whether or not the consult is on. The chat investigations and the network assistant’s agent engine run only where Devexana has enabled them, and Devexana turns them off on request. Where Devexana has configured it, built-in cloud assistance can instead use an Anthropic account. It does not ask for a confirmation before each call, and what it sends is not redacted the way a consult is.

What happens to content after it is sent depends on the provider. Content sent to OpenAI, the testing partner, may be retained by OpenAI under its own terms. Content sent to Anthropic or to Amazon Bedrock is retained according to the terms of the account it is sent under. The OpenRouter route requests zero data retention from the provider on every call. Devexana has not signed its own retention agreement with any provider, and does not represent that any cloud AI path is FedRAMP authorized. Our Compliance Disclosure states which agreements are signed and which are not.

We do not train models on customer data, not our models, and not a provider’s through our product. We do not sell or share personal information for advertising or profiling.

2A. Off-site backup storage

Devexana offers an optional off-site backup service. It is off by default and takes effect only where a customer asks for it. Where it is enabled, the appliance uploads its encrypted snapshots to Amazon Web Services storage in United States regions.

What is stored is ciphertext, and only ciphertext. A snapshot is encrypted on the appliance, before it is uploaded, with the appliance’s own database key. That key is held by the customer and the appliance, in the appliance’s operating-system keychain or equivalent local custody, under the customer’s key-escrow arrangements. It is never uploaded, and neither we nor the storage provider holds a copy of it.

Two keys bear on a stored snapshot, and it is worth being exact about both. The appliance’s database key, above, is the one that opens the contents; we do not have it. The storage service separately wraps each stored object with a key we administer, and that is what lets us retrieve an object and remove the wrapping. What that recovers is the appliance’s ciphertext. We cannot decrypt or read it.

The consequence is that Devexana cannot decrypt or read the contents of a backup. Restoring a backup takes two things from two separate custody chains: the stored ciphertext, and the appliance key that the customer holds. Anyone who obtained the whole storage account would obtain bytes they could not open.

Each appliance’s uploads go to its own storage location, and the appliance’s own credential can write there and nothing else: it cannot list, read back, or delete. A customer whose contract requires that its backups never sit in a vendor-controlled account can instead have them written to the customer’s own storage account, in which case Devexana holds nothing at all.

This also means that losing the appliance key loses the backups. Off-site storage does not soften that; it is why the key-escrow step is part of onboarding and is not optional.

2B. Devexana Cloud accounts and identity

Devexana Cloud is an optional web dashboard we operate, at which a customer’s staff sign in to see the appliances that customer has registered, to manage who holds an account in the dashboard, and to retrieve encrypted backup snapshots. It holds no customer records. It opens no path into an appliance and it never authenticates a person to an appliance: an appliance verifies a sign-in itself.

About a person who holds an account there we hold: their name, their business email address, the issuer and subject identifier their identity provider gives us, the Microsoft Entra tenant identifier where they sign in with Entra, and which organizations they belong to and in what role. Where a person signs in with an email address and a password, we hold a password verifier (a value derived from the password) and never the password itself.

About a registered appliance we hold: its identifier, the name the customer gives it, its edition, its software version, its public key, and backup metadata, meaning the time, the size, and the storage location of each snapshot.

Signing in with Google or with Microsoft tells that provider that the person signed in to Devexana, and when. What we receive from the provider is the identifiers listed above. The provider’s own privacy terms govern what it records.

Devexana Cloud runs on Amazon Web Services in United States regions, and its sign-in is operated with Amazon Cognito. Section 5C lists the providers.

We keep an account record while the person holds a role in an organization, and remove it within 30 days of the last role ending. An administrator can remove a person immediately.

3. What we collect

Personal information means information that identifies a person directly or indirectly. What we collect is the information a person gives us in the course of buying, evaluating, or being supported on our product:

name, job title, employer or agency, business email address, business postal address, and business telephone number;

purchase and billing details, including purchase order numbers, remittance information, and tax-exemption certificates;

the content of support requests, sales correspondence, and any log bundle, screenshot, or export a customer chooses to send us with a support request;

registration details for an appliance, so we know which unit a support request concerns; and

for website visitors, the technical information described in Section 4.

We do not collect payment card numbers ourselves; where a customer pays by card, the card is handled by our payment processor and we receive only the confirmation and the last digits.

4. How we collect it

Directly from the person, when they fill in a form, request a quote, download material, open a support request, or write to us.

From the organization that employs them, when it names staff on an order, a support authorization list, or an appliance registration.

From our website, which records the technical details of a visit: the requesting IP address, the pages requested, the date and time, the referring page, and the browser and operating system reported by the browser.

Not from the software. The appliance sends us nothing. See Section 2.

5. Cookies

Our website uses the cookies it needs to serve pages and to remember a preference a visitor sets. A cookie is an identifier stored by the browser; it cannot execute code or carry a virus. A visitor can refuse or delete cookies in the browser, and the site will still serve its pages, though a remembered preference will be lost.

We use no third-party advertising, analytics, or cross-site tracking cookies.

5A. This website

This section describes devexana.com itself, the site you are reading. It is a set of static pages with an embedded Google Calendar booking form. The Log in link opens the separate Devexana Cloud application.

We run no analytics service on this site, no advertising cookies, and no tracking pixels. The site is hosted on Vercel, and the host keeps ordinary server logs of the requests it serves, including the requesting IP address. Those logs are retained by the host under its own terms. Our domains’ DNS is served by Cloudflare, and Cloudflare’s network sits in front of our operator console; where it does, Cloudflare receives a request and its IP address before we do.

The site remembers your calendar and motion choices in local storage under devexana.site.preferences.v1. Google Calendar loads only when allowed in cookie settings. Google then receives your browser’s request; information you enter in the scheduler is handled by Google and shared with us to arrange the meeting. You can disable the embed in Cookie settings. Mail sent to support@devexana.com arrives in Google Workspace.

Product films and illustrations load from this site. They do not connect to customer appliances. All network records shown are fictional.

The Devexana Cloud dashboard is a separate application at its own address. Section 2B describes what it holds.

5B. Optional appliance telemetry

An appliance can send Devexana Cloud a periodic reading of how it is loaded, so that the dashboard can show it. It is off in every appliance we ship. Only an administrator on the appliance can turn it on, and turning it off stops the reports immediately.

A report carries these readings and no others:

• the appliance identifier;
• the Devexana software version and edition;
• processor utilization as a percentage;
• memory in use as a percentage;
• disk in use as a percentage, for the appliance’s data volume;
• the one-minute load average;
• how long the appliance has been up;
• graphics-processor utilization as a percentage, where there is one;
• the names of the AI models loaded on the appliance, which are Devexana’s own model names, never a document or a record;
• how many connected data sources are reading and how many are configured, as two counts;
• the time of the reading.

That is the whole list. Every field is a number, a version string, or one of Devexana’s own model names; the appliance rebuilds the report from this list on every send, and a value that is not on it cannot leave. A report carries no customer records, no record content, no file name, no host name, no network address, no account name, no person’s name, and no text of a question put to the appliance or of an answer it gave.

Around those readings the report carries four marks and nothing more: a fixed label naming it a Devexana appliance report, the version number of the report format itself, the appliance’s signature over the readings, and the public key that checks that signature. None of them says anything about the customer.

Every report is written to the appliance’s own egress log before it is sent, with its purpose, its destination, and the time, so an administrator can read exactly what left and when.

We delete the readings we hold within 90 days of the switch being turned off.

5C. The providers we use

These are the service providers that act for us. Each acts under its own terms and is bound to use what it receives only for the purpose we give it to them for. None of them receives customer records from an appliance.

• Amazon Web Services. Hosts Devexana Cloud and stores the encrypted snapshots described in Section 2A. United States regions (us-east-1, us-east-2).
• Cloudflare. Serves DNS for our domains, and sits in front of our operator console. Its global network.
• Vercel. Hosts devexana.com and its product media. United States region.
• Google. Workspace mail, the booking calendar and Google sign-in for Devexana Cloud. United States.
• Microsoft. Microsoft Entra sign-in for Devexana Cloud. The region of the customer’s own Entra tenant.

6. Why we collect it

Website visitors. To serve the site, to answer enquiries, to understand which pages are read, and to diagnose problems with the site.

Customers and prospective customers. To quote, to process an order, to ship and register an appliance, to deliver and support the software, to bill and collect, to give notice of updates and of the end of a subscription term, and to meet our own legal and accounting obligations.

Payment information. To take payment. Where a customer pays by purchase order, check, or wire, we hold the remittance details for the period our accounting obligations require.

7. How we use it

We use personal information to perform our contract with a customer; to pursue our legitimate interest in running and supporting the business; to respond to a support request; to tell customers about changes to the product, to these documents, or to a subscription term; to detect and prevent fraud; and to comply with a legal obligation.

We send marketing email only to a person who has asked for it, and every such message carries an unsubscribe link. Unsubscribing does not stop the operational notices a customer needs: an update notice, a renewal notice, or a security advisory.

We do not use personal information to train or tune any model.

8. When and how we disclose it

We disclose personal information to our own personnel who need it, and to service providers who act for us: hosting, email delivery, payment processing, accounting, shipping and logistics, and professional advisers. Those providers are bound to use it only for the purpose we give it to them for.

We disclose personal information where we are required to by law, to a regulator or a court, or to law enforcement acting on lawful process; and in connection with a merger, an acquisition, or a sale of all or substantially all of our assets, subject to this policy continuing to apply.

We cannot disclose what we cannot read. A legal demand served on Devexana for a customer’s operational records, network data, ticket data, or chat history cannot be answered, because that data stays on the customer’s appliance. Where a customer uses the off-site backup service in Section 2A, what we can produce is ciphertext we are unable to decrypt. Such a demand must be directed at the customer, who holds both the data and the key. A demand could reach the account and appliance records described in Section 2B: who holds an account, which organization they belong to, which appliances are registered, and when a backup was taken. It could not reach a customer’s records: those stay on the customer’s appliance, and what we store of them is ciphertext we cannot read.

We do not sell personal information, and we do not share it for cross-context behavioural advertising.

9. Where we store it

We are based in New Jersey and we store and process personal information in the United States. Devexana Cloud runs in United States regions of Amazon Web Services, and the encrypted snapshots described in Section 2A are stored in United States regions. We do not, on our own account, transfer personal information outside the United States.

Where a person signs in with Google or with Microsoft Entra, that sign-in is handled by the provider on the provider’s own infrastructure, which may sit outside the United States; for a Microsoft Entra sign-in, in the region of the customer’s own tenant. What reaches us from that sign-in is the identifiers listed in Section 2B.

10. How we keep it secure

Personal information we hold sits on systems we or our service providers manage, protected by account authentication, multi-factor authentication where available, access limited to the personnel who need it, and encryption in transit and at rest where appropriate. Paper records, where they exist, are held in a locked location in the United States.

On a customer’s appliance, security is the customer’s to inspect: the local database is encrypted, connector and device credentials are held in the operating system keychain rather than in files or the database, secrets are scrubbed from logs and search indexes, and every privileged action is written to an append-only, hash-chained audit log that an administrator cannot silently edit or truncate.

We do not sell personal information to anyone.

11. Marketing choices

A person who has asked to hear from us can stop at any time using the unsubscribe link in any marketing message, or by writing to the address in Section 19. Cookies are controlled in the browser, as Section 5 describes.

12. Web analytics

Our website records the technical details of a visit listed in Section 4 in its own server logs, and we read those logs in aggregate to understand which pages are used and to diagnose faults. These logs are kept on systems we control.

We use no third-party analytics service. Our website is not instrumented with Google Analytics or any comparable service, and we do not share visit data with an analytics provider.

13. Children

Devexana Resources are intended for use by adults acting for a government, education or business organization. We do not knowingly collect personal information from anyone under 18; if we learn that we have, we will delete it.

14. Information made public

Where a person publishes information themselves, in a public forum, on social media, or by sending it to another party, we cannot control how it is used. Anyone considering sharing information publicly should read the receiving party’s own privacy policy first.

15. How long we keep it

We keep personal information for as long as we need it to provide and support the product and to meet our legal, accounting, and tax obligations, and then we dispose of it. A person may ask us to correct or erase the information we hold about them, and to close an account, using the contacts in Section 19.

After an erasure request we may keep the minimum record we need to enforce an agreement, resolve a dispute, prevent fraud, or comply with the law, for example the invoice history our accounting obligations require. We will say what we have kept and why.

Data on a customer appliance is a separate matter: it is retained under the municipality’s own records-retention schedule, which its administrators configure and apply. Removing a source stops new reads immediately; stored records are disposed of per that schedule. Decommissioning the appliance removes the data with it. The one copy that can exist elsewhere is the encrypted backup ciphertext described in Section 2A; where a customer used that service, decommissioning should be paired with a request to delete the stored snapshots.

16. Governing law

This policy is governed by and construed in accordance with the laws of the State of New Jersey, where Devexana is based. Where the customer is a New York governmental entity, the laws of the State of New York govern. Where a signed agreement between Devexana and a customer states a governing law, that agreement controls.

17. Things outside our control

No system is beyond reach. Where information is exposed by an event outside our control (a compromise of a third party, an intrusion, or a fault in software we did not write), we will act on it and give the notice the law requires, but we do not warrant against events we cannot control.

18. When this policy changes

We update this policy when the law or our practices change. Where notice is required, we will give it. The current version is always the one published at the address in Section 19 and the one presented in the product, and it carries an effective date and a document version.

Where the product presents this policy, a materially updated version is presented for acceptance before use continues, and the acceptance (account, document version, and timestamp) is recorded in the appliance’s audit log.

19. How to contact us

Privacy questions, and requests to see, correct, or erase what we hold, go to legal@devexana.com, or by post to DEVEXANA INC., PO Box 1, Demarest, New Jersey 07627, marked for the attention of the privacy contact.

A customer’s own staff and residents should direct requests about data on the appliance to the customer’s system administrator or records officer, who can act on that data directly. Devexana cannot reach that data and holds no readable copy of it.

Security vulnerability reports go to security@devexana.com. We acknowledge reports promptly and do not pursue good-faith researchers.

20. State privacy rights

Where a United States state privacy law gives a resident rights over personal information we hold about them (to know what we hold, to have it corrected, to have it deleted, or to opt out of sale or sharing), we honour those rights. We do not sell personal information and we do not share it for cross-context behavioural advertising, so there is nothing to opt out of on those grounds. Requests go to the contacts in Section 19.

Devexana holds business-contact and billing information about New York residents, and, where a customer enables the service in Section 2A, encrypted backup ciphertext derived from a New York municipality’s systems.

Our municipal customers are subject to the New York Freedom of Information Law. Records held on a customer’s appliance are governed by that customer’s own records obligations, and Devexana holds no copy that could be responsive to a request directed at Devexana. Where such a request reaches material Devexana treats as confidential under its licence terms, Section 16.2 of the Terms of Use governs.

21. How to access your information

To see, update, or ask about the personal information we hold, write to the contacts in Section 19. We will respond within a reasonable time, and in any event within the time the applicable law requires. We will confirm identity before acting on a request.

Where we must keep information to comply with the law, to resolve a dispute, or to enforce an agreement, we will say so and say why rather than deleting silently. Where a request concerns data held on a customer’s appliance rather than data we hold, we will say so and point to the customer’s administrator, who can act on it.