Security & compliance · SOC 2 Type II
We are working toward a SOC 2 Type II report. Until an auditor issues one, this page claims nothing, it shows where the engagement stands and which controls you can already assess. A standing request brings you the report the day it exists.
A Type I describes controls at a point in time; a Type II has an auditor examine evidence across a live observation window of months. The window cannot be compressed — so here is the engagement, station by station, exactly where it stands. No promised dates: the current state is shareable at any time from your account.
Done. The mechanisms the criteria expect — isolation, filtered answers, the audit chain, the release gate — are in the product, not on a slide.
In progress. Evidence collection wired into the pipelines that already run: signed releases, heartbeats, audit exports, access records.
Next. The months a Type II is made of: the auditor watches controls operate, not a snapshot of them.
Then. The report lands with everyone whose request is standing, under NDA, as SOC 2 reports are.
Controls designed and shipped; readiness and evidence in progress; the observation window and the report still ahead. No report is claimed until an auditor issues one — and when it is, this page will say exactly what it covers, no more. A standing request means the report reaches you the day it exists.
File a standing request ›
Security is the required baseline: single-tenant isolation, permission filters inside every query, signed webhooks, throttled sign-ins. Confidentiality rides write-only secrets and zero-retention AI terms. Availability rides signed heartbeats and self-rollback. Processing integrity rides cite-or-abstain answers and the hash-chained audit log. Every row is expanded in the trust library, reviewable before any auditor confirms it.
Read the trust library ›
The same controls the audit will examine are reviewable now: the architecture overview, the trust library, the audit chain design, the release gate, and your own questionnaire answered from the architecture, never a script. Organisations that must answer for their data assess the mechanisms directly and contract the DPA; the report, when issued, confirms what you already reviewed.
Request documents ›
The engagement’s papers, readable right here — the SOC 2 status, the architecture record, the data-flow note and the DPA structure. The Type II report joins them the day an auditor issues it.
The trust criteria, security, availability, confidentiality, privacy, run as engineered product mechanisms; the SOC 2 page carries the current status.
The system operates to the trust services criteria as engineered mechanisms, evidenced on its own audit chain; the report itself is what we are waiting on. Criterion by criterion:
Its own page carries the current status. File a standing request from your account, and security questionnaires are answered directly from the architecture in the meantime.
An account action, the request files under your Naxis account, and the answer arrives on its thread.
One client, one deployment, one boundary, what that means concretely: containers, database, credentials, the AI boundary and the audit chain.
Each client runs their own complete instance: application, worker, database and document store in isolated containers on a machine that serves no other client. There is no shared platform, no pooled database, no cross-tenant anything, isolation is the deployment model, not a configuration option.
Indexing (reading and preparing documents for search) runs entirely inside the deployment. Generation follows the deployment's configuration: the fullest posture is a self-hosted deployment that answers entirely on its own hardware, where nothing leaves the boundary at all. Deployments using the Naxis AI service send the question and the permission-filtered excerpts (zero-retention terms, see sub-processors); the model never sees documents the asking person cannot see, because permission filtering happens before the request leaves.
In every configuration: your data is not used to train models, and nothing is retained after the answer returns.
Access is group-based and settled before a question is even considered, everywhere the assistant answers, never in any one surface. Accounts activate by invitation link; administrators never see or set a password. Channel guests receive nothing until groups are explicitly opened to them.
Every consequential event, questions, answers with their citations, administrative actions, syncs, erasures, lands on an append-only, hash-chained log. Verification recomputes the whole chain on demand from the console; a broken link is impossible to hide. Rows cannot be edited or deleted; retention prunes whole aged spans and records that it did.
Releases are versioned images; deployments install them in a quiet window after a safety backup and roll back on their own if the health check fails. What changed in each release is shown in the console in plain language.
An account action, the request files under your Naxis account, and the answer arrives on its thread.
What leaves the deployment, what never does, and where things physically live.
An account action, the request files under your Naxis account, and the answer arrives on its thread.
The DPA every deployment is contracted under, subject matter, duration, sub-processor notice procedure, audit rights, deletion on termination.
The signed DPA is executed per client. Its structure, so your legal team knows what to expect:
Request the full template, or a signed copy for review under NDA, through the contact page; it is provided as a matter of course.
An account action, the request files under your Naxis account, and the answer arrives on its thread.
File a standing request from your account and the report reaches you the day it exists, under NDA, as SOC 2 reports are; security questionnaires are answered from the architecture, not a script.
Not yet, and we say so plainly: the SOC 2 Type II engagement is in preparation and no report is claimed until one is issued. A standing request from your account means the report reaches you the day it exists.
Because that is what makes it worth reading. A Type I describes controls at a point in time; a Type II has an auditor examine evidence across a live observation window of months. The window cannot be compressed, evidence has to accrue.
The same controls the audit will examine: the security & architecture overview, the trust library, the hash-chained audit log design, the release gate, and your own questionnaire answered from the architecture. All requestable from your account today.
Security as the required baseline, with Availability, Confidentiality and Processing integrity mapped below, the final scope is stated with the engagement, and this page will say exactly what the report covers, no more.
Yes, organisations that must answer for their data do it by assessing the mechanisms directly and contracting the DPA. The report, when issued, confirms what you already reviewed; a standing request keeps you first in line.
Every paste into a consumer chatbot is a question your own systems could not answer fast enough. Security vendors sell detection, which reads the app and never the question. What the 2026 breach data actually shows, how far Microsoft's new Shadow AI controls really reach, and why the only fix that scales is making the company answerable.
Glean is Google for your company: it finds where things are stored. Naxis is the private knowledge engine that knows what is actually true right now. Different machines, different questions, different prices. An honest way to choose, and the Glean alternative for companies of 5 to 200 people.
Lidl wrote off €500 million trying. Birmingham City Council is £144 million in and reinstalling from scratch. Consolidation megaprojects fail for a structural reason: real work is too fluid to hold one shape. The part you actually wanted, one place to ask, never needed the migration.
