memorandum · custody

For papers that cannot leave the building.

Most AI products ask for your documents. Niska is built the other way around: the system goes to where your files live, reads them there, and never takes them out of your hands. This page states that posture as plainly as we can — as undertakings, refusals, and questions of record.

definitionsp. 02

“Your files”

Every document, email, workpaper, and record your firm places in scope — and everything the system derives from them.

“The deployment boundary”

The environment your firm chooses for the system to run in: your own hardware, a hybrid posture, or a dedicated single-tenant environment. Nothing in scope crosses it.

“The register”

What the system builds as it reads: an organized, searchable memory of your firm's documents, held inside the deployment boundary.

“The engine”

The reading system underneath, which is the same in every Niska deployment. Everything built on top of it is generated from your firm's own files and belongs to your deployment alone.

exhibit a · the undertakingsp. 03

What we undertake, in writing.

These are not marketing claims. They are how the system is built, stated as commitments your security team can hold us to — and they carry into the agreement that governs every engagement.

cl. 1.1
Your files remain in your custody. They live inside the deployment boundary your firm chooses, and they do not leave it.
cl. 1.2
We never see your files. The system is closed-loop by design; there is no Niska-side copy, cache, or mirror of your documents.
cl. 1.3
Every answer carries its source. Anything the system tells you links back to the page it came from, so your people can check the work.
cl. 1.4
Nothing pools between firms. Each deployment is its own system — single-tenant, isolated, and configured for one firm only. Nothing generic ships to a customer, and nothing learned inside your firm leaves it.
cl. 1.5
The posture is your call. On-prem, hybrid, or cloud — including fully air-gapped deployments with no network egress for work that cannot touch an outside wire.
cl. 1.6
When an engagement ends, there is nothing to hand back. Your files never left your environment; what was built from them stays with you.

schedule of refusalswhat the system will not do

Just as binding: what it will not do.

01
It will not answer without a source attached.
02
It will not move your files, or copy them to anywhere your firm has not approved.
03
It will not mix one firm's system with another's.
04
It will not act on your firm's behalf without a person in the loop.
05
It will not pass a guess off as an answer. Everything it tells you arrives with its source attached, so a wrong answer has nowhere to hide.

questions of recordp. 04

The questions a diligence team asks anyway, answered the way we answer them in the room.

q.1: Wherever your firm decides: on your own hardware, in your environment under a hybrid posture, or in a dedicated single-tenant environment. That location is the deployment boundary, and your files do not cross it.
q.2: No one. The system is closed-loop by design. In a hybrid posture, our compute reaches into your environment only with the access your security team approves, and every request is logged.
q.3: Yes. Air-gapped deployments are supported for work whose files cannot leave the building — including classified-adjacent and defense work.
q.4: You check it. Every answer cites the page it came from, which means your people can verify the work the way they would verify a junior colleague's — except the source is one click away.
q.5: No. The system learns your firm's patterns for your firm's deployment. What it learns inside your boundary stays inside your boundary.
q.6: Your files are already yours, in your environment. There is no extraction, no migration, and no copy of your documents on our side to delete.

the long-form version — architecture, controls, and the posture schedule for your vertical — is available on request. write to tucker@niska.com, leo@niska.com. this page last revised june 2026.