Your client produces documents in one language and needs them in several. Today that probably happens through an agency, a spreadsheet, a shared drive and a lot of email, and nobody can answer where a given document went, who touched it, or what it cost.
This is the system that runs that process: documents in, work tracked and assigned, language models used under rules somebody set, documents out, and a record of every one of those steps.
What follows is how it deploys, how it is operated, and what it does and does not do to your client's data. Including the parts we do not do, which for this conversation is the useful half.
Documents arrive three ways: somebody inside the organisation uploads one, the organisation's own customer drops one off through a web page of their own, or another system delivers one automatically. All three go through the same process and are recorded the same way.
The work is then done by a combination of language models and people. Which combination is configured — the organisation builds the route a document takes, and marks the points where a named person has to look at it before it moves on. Finished documents come back out in the format they arrived in.
The parts your client's own IT function will care about:
Not a shared service with a column separating one customer's data from another's. Your client gets their own database, their own object storage and their own installation — on our infrastructure, or on theirs.
For an integrator this is usually the deciding fact, and it cuts both ways honestly. It is a far better security story than a multi-tenant platform, and it means provisioning is a conversation rather than a signup page.
The full system runs on-premise or in your client's own cloud tenancy. Nothing has to reach us for it to work.
Nothing phones home. No telemetry, no usage reporting, no licence check-in. That is a published boundary rather than a gap, and the matching half of it is in §4.
The application and the three web interfaces release in lockstep at a single version. There is no compatibility matrix to work out and no combination to support.
The address of the application is runtime configuration, not a build-time constant. The web interfaces are told where the application is when the container starts, so the same images run in your client's estate as in anyone else's — no rebuild per customer, and nothing baked in that a deployment engineer has to discover.
Producing Word or OpenDocument deliverables needs a document renderer, and the image does not include it. Your client installs it and points one configuration value at it.
That is a licensing decision taken deliberately rather than an inconvenience we failed to remove, and the behaviour when it is absent is defined rather than accidental: a job that requires it is refused before it starts — not after the language model work has been paid for — and a job that does not require it delivers its output in a plain format and says so.
The same image that runs the service also runs the operational commands, selected before the service starts. Not a separate toolbox to install, not a set of scripts to keep in step with the version deployed — the thing you upgrade and the thing you diagnose are one artefact.
What they cover: preflight checks, database schema status, the impact of a pending upgrade, draining work before a maintenance window, opening and closing the system to new work, backup status, a diagnostic bundle, and exporting and replaying the erasure record.
Only the explicit migration command holds the rights to change the schema. A service that started up and quietly migrated a production database is a service that can do that during an incident, at three in the morning, while somebody is trying to work out what is happening.
And it refuses to run against a schema it does not match, in both directions. Older than expected is refused. Newer is refused too, which is the one people forget: a rolled-back service running against an already-migrated database is the failure mode that loses data rather than raising an error.
Every schema change declares its impact, and anything above a routine backfill will not run until somebody accepts it by name. A change that will lock a large table for several minutes is a thing your engineer finds out before the maintenance window rather than during it.
Upgrades are sequential from a minimum supported version, so an installation left alone for a long time upgrades through the intervening steps rather than jumping.
Capabilities can be closed centrally, and a capability closed on one node takes effect on every node within seconds — with no node-to-node traffic at all. The node that took the decision acts on it immediately; the others pick it up within a short, fixed window.
Two kinds are governed separately and default differently: capability gates default closed, so a new capability arrives switched off and somebody opens it deliberately; intake gates default open, so a system that comes up is working. Both are recorded as a ledger rather than as current state, so what was closed, when, and by whom is answerable afterwards.
Nothing in this software schedules a backup. Your client does it with the tools they already use, or we do it as part of running the system for them. We would rather say that plainly than have you assume a scheduler exists and discover otherwise during a handover.
What does exist is the recording: the backup record includes the backups that failed. A backup that did not happen is an entry saying so, rather than an absence somebody has to notice.
And restores are drilled rather than asserted — including reading the number of errors the restore tool ignored, because restore tooling routinely exits successfully having skipped things. The drill has been run repeatedly; it found six real defects before anybody needed it to work, and it never restores over the database that records the result.
An installation has a name, and a backup knows which installation it came from. Restoring one organisation's backup into another's system is detected rather than silently performed.
Where material may go is enforced, not documented. When the system decides whether a given language model provider may receive a given piece of your client's material, it checks four things about that provider and refuses on any of them: which trust category it is in, which region it is registered in, whether the agreement covering it is still current, and whether that agreement actually contemplates the provider seeing the material rather than information about it. A lapsed agreement stops permitting anything. Where the organisation's own rules and the deployment's baseline disagree, the stricter wins.
Confidential material is replaced before it is sent, not blanked out — substituted with stand-ins the AI model can work with, so the output comes back usable and the stand-ins are reversed afterwards.
The diagnostic bundle carries no configuration values, including a configuration value that was copied into a database row somewhere. It is built from a list of what may be included, never from a list of what to strip out — the difference being that a list of things to strip out is a list of the secrets somebody thought of.
Erasure survives a restore. This is the case that catches most systems: a person's data is erased in March and quietly reinstated by a restore in April. The erasure record is captured before the restore and replayed after it, and the system will not reopen to new work while that replay is outstanding.
One boundary worth having in advance: there is no user delete. The user identifier is referenced throughout the system, so removing the record would either break those references or silently rewrite history. Offboarding disables an account; erasure anonymises it and keeps the record. It is the right design and it is not what "delete my account" usually means.
Also: stored file names come from your client's own users, so the storage keys are treated as client data rather than as neutral identifiers.
What is already fixed, because it is a published boundary rather than a commercial choice: where your client runs the system themselves, we prescribe, provide and verify nothing about their backups, and nothing reaches us from their installation. No telemetry, no monitoring, no check-in. A support arrangement that implied we were watching would contradict a promise rather than merely surprise somebody.
That is a real constraint on what support can be, and it is deliberate. We would rather you priced it into your proposal than discovered it at handover.
Everything else about support is a conversation, and we are not going to put a number on this page that we have not decided.
Response times, hours, escalation, the boundary between our obligation and the operator's, and what changes when the system runs on our infrastructure rather than the client's.
Tell us about the estate — where it would run, who would operate it, and what the client's constraint actually is. We will tell you what deploying it involves, including when the answer is that it is not a fit.
If you want to look before you talk to us: Evidence lists every claim on this site with its status and what backs it, including what we have not built.
