01 Running
The mirror, with deletions.
One-way copy of approved libraries into the client's own account, several thousand documents, parsed, embedded and indexed there. Deletions propagate on a best-effort basis.
If the rest of this section is exact, this page is why. If it is not, this page is where you catch us.
The sentences we will not write about this product.
We keep a ledger of every claim about the gateway, sorted into safe, safe-with-a-hedge, and never. This is the third column, published. A product whose limits are written down is a product you can answer for in front of your own board.
A claim you cannot defend is a claim that costs you.
WHY THIS PAGE EXISTS
Every line of copy about this product is checked against a build, not against an ambition. Where a sentence would be true of the platform but not of the gateway, it does not get borrowed. Where something works but has only worked once, it says so. Where something does not exist, it is absent from the page rather than dressed as a direction of travel.
We do not publish a roadmap for this product. A dated promise on a marketing page is made by somebody who will not be in the room when it slips.
Proven in one real build
Real, and bounded
Not claimed at all
Keep the claim exact.The house rule, and the whole editorial policy
Fourteen sentences you will not find on this site.
NEVER SAID · AND WHY
Several of these are things a competitor might say about a product like this, and one or two are things we can truthfully say about our other product. Neither is a reason to say them here.
| What we do not say | Why not, and what is true instead |
|---|---|
| "Your prompts, context and output never leave your boundary" | False for this product. What a tool returns travels to your assistant's vendor on every call, under your agreement with them. Everything at rest stays in your account. Both clauses, always together. |
| "Inside your walls" | That phrase belongs to the platform, where no third-party assistant vendor is in the path. It does not transfer to a product whose whole design reaches an outside assistant. |
| Any data-residency claim at all | We make none for the gateway. Components can route across regions, and your assistant processes wherever its vendor does. The residency language elsewhere on this site reasons from the platform and does not extend here. |
| "Private networking", "not reachable from the internet" | The endpoint is public, protected by authentication and a small explicit firewall rule set. There is no private network path, so the control is the sign-in rather than the network. |
| "A full audit trail of what the AI accessed" | Writes are attributed with who and when. Reads and tool calls are not individually recorded today, and a source address identifies your assistant's vendor rather than the person. |
| "Hallucination-free", or any faithfulness or groundedness guarantee | The server never sees the answer. It returns source-linked evidence: cited passages, computed figures with their queries, scaffolds with flagged gaps. The prose is your assistant's. |
| "Source-linked answers" | One word apart from the truth. Evidence is source-linked. The answer is written by something we do not control. |
| "Works with any client that speaks the protocol" | Two major assistant vendors are evidenced. Conformance across implementations varies, so a third is a test in the assessment rather than an assumption. |
| "It mirrors your existing permissions" | It is an independent operational policy with its own allow-lists, not a reflection of your source system's access control. Enterprise search products often do carry native permission fidelity, and that is a real advantage of theirs. |
| "All your documents, searchable" | A maintained matrix of common business-document formats. In the one real build about 96% of the corpus became searchable; the remainder was almost entirely unsupported formats, which are listed rather than silently skipped. |
| Any freshness guarantee | Approved sources are checked on a short schedule. That is a cadence. End-to-end freshness has never been measured, so there is no figure to publish. |
| "Zero data retention", "no model provider sees your data", "no third-party software in the data path" | All three are false here, in the obvious way. The whole design brings your files to a third-party assistant on purpose. |
| "Turnkey", "fully auditable" | The first ignores the operations this needs from day one. The second is answered by the audit row above: writes are attributed, reads and tool calls are not. |
| Any business-outcome number | No baseline was taken in the one real build. There is no time-saved figure, no rework figure, no error-rate figure and no return-on-investment figure anywhere, so there is none on this site. |
This table is maintained from the same ledger the copy is written against. If you find a sentence elsewhere on this site that contradicts a row here, the row wins and we want to know.
What one build actually demonstrates.
PROVEN · ONE REAL BUILD
One real build, serving a document-heavy operations team of about ten people. One is not a pattern, so every statement about repeatability is a design intention rather than an observation. Here is what has actually run.
96%
Corpus · made searchable
2vendors
Assistants · evidenced
1day
Whole team · connected
0
Forbidden rows · under probe
02 Running
Corporate sign-in with roles at mint.
Federated to the client's own identity, roles written into the token from the verified email, an unrecognized person receiving nothing.
03 Running
Search and reading across common business formats.
Cited semantic search, plus whole-document reading over a maintained matrix of common business-document formats, with the file type detected from content rather than from the extension.
04 Running
Deterministic analysis, reconciled.
Canonical tables from one source export format, integrity checks first, answers in SQL over every row, reconciled exactly against the client's own workbook.
05 Running
Workbooks that refuse.
Both capability packs are in use, including a standard workbook that writes nothing at all when reconciliation fails, with no override available to anybody.
06 Running
A probe that came back empty.
An adversarial cross-scope probe returned zero forbidden rows. One test, on one deployment, and the section below says what that does and does not establish.
Three things that work, with the asterisk written out.
REAL, BUT BOUNDED
01 Bounded
Access control has not yet governed a restricted user.
Three-dimension policy is built and proved by probe, and every live user in the one build holds a full grant. The control has been tested on a range rather than in the field, which is a different kind of evidence and is described as one.
02 Bounded
The confirmed layer is thin in content.
The mechanism is complete: states, attribution, sign-off, enforcement of confirmed-only for outward-facing work. What it holds is still small, because filling it is your people's judgment and not ours to manufacture.
03 Bounded
No complete outward-facing document, end to end.
Scaffolds work and workbooks publish. A finished outward-facing deliverable has not yet been produced start to finish through the product, so we describe the scaffold and not the deliverable.
And what simply does not exist
No write-back of anything into your source library, by design rather than by configuration. No private network path: the endpoint is public and authenticated. No client-facing administration screen, so an access change is a request to us rather than a screen you drive. None of these are on a roadmap on this page, because we do not publish one. Several are contractable: if one of them is a condition of your sign-off, it is scoped as work in the assessment.
The point of the page
The limits are part of the specification.
Nobody is asked to trust us. They are asked to read the boundary, check it against their own obligations, and decide.
- 01It is a buying tool, not a confession. Every row above is a question your security owner would have asked in week three. Having them answered in week one is faster for everyone, including us.
- 02It shortens the security review. Most of what a reviewer will ask for is already written down here and on access and the data boundary, before the first call.
Where something else is the better answer.
CONCESSIONS · TO THE ALTERNATIVES
- 01Your assistant vendor's own document connector is simpler. For plain search over a library, it is a fair choice and a cheaper one. What it does not give you is a confirmed-fact layer, computed figures that reconcile, your written methods, or rules that are yours rather than the vendor's.
- 02An enterprise search product carries native permission fidelity. That is a genuine strength and we concede it plainly. It does not execute your calculations, apply your workflow gates, or expose deterministic tools to more than one assistant.
- 03On the data boundary, we lose. Against anything that keeps content away from a third-party assistant, this product cannot win that argument, and it does not try. We compete on action, on your own rules, and on numbers that reconcile.
- 04The ideas here are reproducible. The protocol endpoint will commoditize. What is hard to copy is the operating experience: policy patterns earned from real incidents, the leak probe, the format matrix, the adapters, and proof the thing can actually be run. We would rather say that than pretend to a moat.
If the boundary is the deciding question
Then the honest recommendation is the other product, and we will make it in the first meeting rather than the third. Platform or gateway sets out the decision, and where AI does not belong is the same discipline applied to the work itself.
Asked, and answered.
QUESTIONS · THE AWKWARD ONES
01Why publish this at all?
Because the alternative is that you find it out later, in a security review, with a signature already on a contract. A limits page costs us some deals early and saves both sides the expensive kind of surprise.
02How do these limits get fixed?
Through managed operations and, where a client needs something specific, as scoped work under forward-deployed engineering. What we will not do is put a date on this page for any of them.
03Does the platform have a page like this?
Yes, and it is a different list, because it is a different product with different claims available to it. Read what we do not claim for the platform, and the boundary for why the two must never be mixed.
- 01The platform's claim ledgerThe same discipline applied to orgOS, where the available claims are different.→
- 02Access and the data boundaryThe long version of the rows above about policy, travel and audit.→
- 03Shared responsibilityWhich obligations are ours, which are yours, and which are your vendors'.→
⎯⎯ Book the strategic assessment ⎯⎯
Your files, inside your control ·
Bring the row from this page that worries you most. If it is a blocker, the assessment is where we find that out, before either of us has spent anything.