GRADEUM
← Dev Log
April 12, 2026 · 5 min read · Gradeum Technologies

Documents Never Leave: What That Actually Means

"Documents never leave your network" is the kind of sentence every SaaS vendor wants to be able to say and almost none of them can. It is worth pinning down what we mean by it, because the architecture is the whole answer.

This is not a CISO briefing. It is an explanation for a PE who has been asked by their client — or their insurer, or their board — "where exactly does our data go when you use this thing?"

The three-layer picture

Gradeum has three pieces. The distinction between them is the entire security story.

  1. Nexus is a service that runs on hardware you control. A workstation, a server, a VM inside your network. It reads your document library, chunks it, embeds the chunks into a local vector index, and stores the result on disk alongside the documents themselves. Nexus holds the only complete copy of your corpus that Gradeum ever sees, and it does not leave your network.
  1. Engine is the cloud service Gradeum operates. It handles the AI compute — the language models that generate answers, summaries, and structured outputs — along with identity, billing, and the shared infrastructure that is not sensitive to you. Engine does not store your documents. It does not store your retrieved chunks. It processes a request and moves on.
  1. Veil is the sanitization layer that sits between Nexus and Engine. When a question needs cloud compute, Veil strips or tokenizes the parts that should not leave — client names, project identifiers, site addresses, specific individuals — before the query crosses the boundary. The AI does its work on a sanitized representation. The response comes back and is rehydrated locally, inside Nexus, using context the cloud never saw.

That is the entire architecture. Everything below is details.

What actually crosses the boundary

When an engineer at your firm asks Nexus a question, four things happen in roughly this order:

  1. Nexus retrieves the relevant chunks from your local index. These live on your disk. They do not go anywhere yet.
  2. Veil builds a query payload — the user's question plus the retrieved context — and applies sanitization. Identifiers are masked. Sensitive passages can be tagged to stay local.
  3. The sanitized payload is sent to Engine over mutual TLS. Engine's AI returns a draft response.
  4. Nexus receives the response, rehydrates any placeholders, writes the exchange to the audit log, and shows the answer to the engineer with citations pointing back to the local source documents.

At no point is a PDF, a drawing, a contract, or a calculation transmitted to Gradeum in its raw form. The cloud sees a question and a sanitized excerpt. That is the surface.

Why mTLS matters

Mutual TLS means both sides of the connection prove who they are. Your Nexus has a certificate. Gradeum's Engine has a certificate. Neither accepts unauthenticated traffic. In practice, this means:

  • An attacker who breaches the public internet cannot inject traffic into the Engine and pretend to be your firm.
  • An attacker who compromises your network perimeter cannot redirect your queries somewhere else without invalidating the certificate chain.
  • Rotations and revocations are centralized. If a Nexus installation is ever suspected to be compromised, we revoke its cert and it is out of the fleet immediately.

This is not exotic. It is how machine-to-machine authentication should work. We mention it because the alternative — long-lived API keys in a .env file on a shared server — is depressingly common and we refused to ship it.

The immutable audit log

Every query. Every response. Every PE approval. Every access to the corpus. Timestamped, append-only, cryptographically chained so that any tampering is detectable after the fact. You can export the log. Your regulator can review the log. Your client can audit the log. Your internal QA can spot-check the log.

This was not added to satisfy a checkbox. It was added because the alternative — a system where "the AI said something" is an unauditable event — does not belong in a professional engineering practice. If a decision can be attributed to a record, the record must be real.

What this looks like for a PE audience

The practical version of all of this: when you sign off on a deliverable that used Gradeum, you can defend it. You can show the question you asked, the chunks retrieved from your own corpus, the response, the citations, and your approval. The audit trail is a record of engineering judgment, not a black box.

If a client asks whether their documents are training a foundation model somewhere, the answer is no. If a client asks whether the documents are stored in Gradeum's cloud, the answer is no. If a client asks for a list of exactly what crossed the boundary on a given project, the answer is a file you can hand them.

The boundary we will not cross

Security architectures fail when the commercial pressure to loosen them gets ahead of the discipline to hold the line. We have designed Gradeum so that loosening the boundary is not a configuration flag. Documents do not leave the Nexus. There is no "premium tier" where they do. The entire product falls apart without that constraint, which is precisely why we want it there.

Start with your own corpus

We launch on May 4, 2026. The most instructive conversation we can have with a firm is always the same one: install Nexus against a live document library, run a few real questions, and look at what actually crosses the wire. The architecture is easier to trust when you have watched it work.

Request a demo to see a live query round-trip, or read more about Praxis if you are evaluating for a design firm.

— Gradeum Technologies

Want to see Gradeum in action?

Request a personalized demo for your firm.

Request a Demo