01
A named owner for the content.
One person who can say what belongs in a library and what does not, and who can approve a library for mirroring. Not a committee, and not "IT will decide".
Every phase ends in a decision somebody is named for, and one of the available decisions is always to stop.
Nothing gets indexed until you have seen what it will cost to index it.
These are the phases, in the order they run, with the question each one has to answer before the next begins. The figures beside them come from one real build. They are what happened once, not a commitment about what will happen for you.
Six phases, and six chances to stop.
PHASES · EACH ONE A GATE
The first phase is the strategic assessment, which is bounded work you keep whether or not you proceed. Everything after it is scoped from what that phase found, rather than from a template written before we met you.
- 01Bounded
Discovery and control design
A source inventory: which libraries exist, who owns them, what is in them. A risk classification over that content. The workflows worth connecting first, chosen because they are frequent and document-bound rather than because they are impressive. A responsibility map, and the measures you will judge this by.
The output is a written control design: the roles, the three allow-lists each one gets, and the data-boundary statement you will be asked to sign.
GateIs any of this content safe to reach an external assistant at all? If no, stop and read the platform pages instead.Decides: your security owner - 02In your account
Deployment into an account you own
The server, the identity estate and the feeding layer are deployed into a cloud account you hold the root credentials for and are billed for directly. If you already run the platform, this lands beside it and shares only the sign-in estate.
GateIs the account yours, in your name, with your billing relationship? We do not proceed on an account of ours.Decides: your IT owner - 03Written first
Source connector and knowledge pipeline
A read-only grant against one named library, the mirror worker, the parser, the embeddings and the index. Before a single document is indexed, you get a written one-time indexing cost proposal: what the corpus is, what parsing and embedding it will cost once, and what it will cost to keep current.
Unsupported formats are reported as a list, so you know what did not make it and can decide whether it matters.
GateDo you accept the one-time indexing cost, in writing, before anything is indexed?Decides: your budget owner - 04Your sign-in
Identity and policy integration
Federation to your corporate sign-in, roles written into the token at mint, and the three allow-lists from phase one loaded as real policy. We then run the adversarial probe: a role that should not see a thing, trying to see it.
GateDoes a restricted role return zero forbidden rows under probe, on your data?Decides: org.tech, witnessed by your security owner - 05One day
The connect workshop
Roles are pre-assigned before anyone walks in. Each person adds the connector, signs in with the corporate account they already use, and asks their first real question against their own records. We teach two habits: ask in plain language, and treat a number with no citation as a bug worth reporting.
GateHas every named person connected and completed one real task, not a demonstration task?Decides: your operations lead - 06Scoped separately
Capability packs, as forward-deployed engineering
Everything so far is the generic kernel. A pack encodes your process on top of it: a readiness checklist, stage tracking with entry criteria, an ask list, a standard workbook, a roll-up. Each is scoped and billed as forward-deployed engineering, one at a time, against a workflow you can already see running.
GateIs this pack replacing a real piece of manual work, this quarter? If not, it waits.Decides: your operations lead
Four things that have to be true before we start.
PREREQUISITES · CHECKED, NOT ASSUMED
These are not paperwork. A project that begins without them stalls in the first fortnight, and the stall always looks like a technology problem when it is an ownership problem. The full table, with what goes wrong in each case, is on the gateway overview.
02
A folder taxonomy, or the will to build one.
The mirror preserves your tree exactly and classification leans partly on your folder conventions. If the tree is chaos, fixing it is the first deliverable rather than a thing we work around.
03
Roles, written down first.
Who reaches which tools, which records, which classes of data. There is no default role by design, so anyone not named simply gets nothing when they connect.
04
Rules explicit enough to test.
"We usually check the figures against last year" is not a rule. "Publication is blocked unless invoice totals reconcile exactly to the control total" is. Deterministic tools need the second kind.
What your people have to do, not just approve.
YOUR ADMINISTRATORS · THE REAL LIST
Workshop day at a glanceGATEWAY-WS
- BeforeRoles pre-assignedEvery attendee's policy already resolved
- Per personAbout two minutes to connectPaste an address, sign in, done
- InstalledNothingNo new application, no desktop agent
- First taskA real oneTheir own record, their own question
- Two habits taughtAsk in plain languageAnd report any number that arrives without a citation
- In the one buildThe whole team, one day
Administrator work · named up front
Six tasks, and none of them are ours to do for you.
We deploy, operate and extend. These are the things only somebody inside your organization can do, and they are on the plan from the first week rather than discovered in the fourth.
- 01Open the cloud account. In your name, with your billing relationship and your root credentials. We never hold production content on our own infrastructure.
- 02Grant the read-only source permission. One named library at a time, through the tightest grant your document platform offers, revocable by you in one action.
- 03Register the sign-in federation. A connection between your corporate identity and the directory in your account, so your existing multi-factor and conditional access rules apply unchanged.
- 04Point a name at it. The endpoint lives on your own domain, which is also what your people paste into their assistant.
- 05Approve the assistant. A commercial assistant your organization sanctions, on a plan that supports authenticated custom connectors.
- 06Own the policy decisions. Who is in which role, and which exceptions exist. We implement them; you decide them, and changing one is a request to us today rather than a screen you drive.
Who does what, phase by phase.
RESPONSIBILITY · SPLIT
| Phase | org.tech | Your administrators | Your people |
|---|---|---|---|
| Discovery and control design | Runs it, writes the control design and the boundary statement | Names owners, roles and the first workflows | Half an hour each, describing the work as it is |
| Deployment | Deploys every component from a pinned version | Opens the account, points a name at the endpoint | ✕Nothing |
| Connector and indexing | Quotes the one-time cost in writing, then indexes | Grants the read-only permission, approves the cost | ✕Nothing |
| Identity and policy | Implements the allow-lists, runs the probe | Registers the federation, witnesses the probe | ✕Nothing |
| Connect workshop | Runs the day, teaches the two habits | Confirms the attendee list and their roles | ✓Connect, then one real task each |
| After go-live | Managed operations, from day one | Raises access changes, owns the exceptions | ✓Use it, and report uncited numbers |
The rows marked as nothing are deliberate. If your people have to do work during deployment, the deployment is wrong.
At the end of it
The account, the corpus and the deliverables are yours.
Open formats, an open protocol, and the right to remove us. That is the ownership promise, and the second half of it is worth writing into the contract.
- 01What you hold. The cloud account and everything in it: the mirror, the index, the confirmed facts, the canonical tables, the generated artifacts. The deliverables, assigned on payment in full.
- 02What to put in writing. Export, revocation and deletion belong in the agreement rather than improvised on the day you need them. Ask for the clause and we will draft it with you, because a tested exit is part of an ownership promise and not a courtesy at the end of one.
"Runs in your account" never means "requires no operations".
OPERATIONS · FROM DAY ONE
This is the sentence most customer-owned deployments are sold without. The recurring work is real and it begins the day your people connect, not some months later when something breaks. Managed operations is on from day one and is not an optional extra.
01
A pinned version.
You run a known version, changed deliberately, not whatever was deployed last. Keeping it current, and deciding when to move, is work somebody has to own.
02
Mirror and index upkeep.
Runs that do not complete cleanly, formats that stopped parsing, a library somebody renamed. Somebody has to look, and it is us.
03
Access changes.
A new starter, a leaver, a role that needs narrowing. An operator task today, turned around directly rather than through a queue.
04
Connector maintenance.
Assistant vendors change their connector surfaces. Keeping up with that is ongoing work, and it is the main reason this is a service rather than a handover.
01How long does this take?
In the one build so far, a working authenticated connector existed a little over three weeks after signature, and the whole team was connected in a single workshop day. That is one deployment. We quote from your source inventory rather than from that anecdote, and we publish no time-to-deploy figure, because none has been measured.
02What does it cost?
The engagement is scoped in the strategic assessment. The running cost has been tens of dollars a month on the client's own cloud bill, with nothing per seat, plus the one-time indexing cost quoted in writing before anything is indexed. Cloud, document platform seats, domains and assistant subscriptions are paid by you directly to each vendor. See pricing for the published ladder.
03Can we start with one team?
Yes, and you should. One library, one set of roles, one workflow that is frequent and document-bound. The whole design is one library at a time, so a first team is the natural unit rather than a pilot carve-out we have to unpick later.
04Do we need the platform as well?
No. They are siblings, not a ladder, and neither is an on-ramp to the other. Where both run in the same account, they share exactly one thing: the sign-in estate, so one identity decides what a person sees in both. If you are weighing them, platform or gateway is the page to read.
05What happens if we stop paying you?
You keep the account, the data and the deliverables, and you lose us. Running it afterwards needs a competent cloud engineer, which is why runbooks and infrastructure-as-code are deliverables rather than internal documents. See ownership and exit, and put the export and deletion clause in the contract while you are still signing it.
⎯⎯ Book the strategic assessment ⎯⎯
Your files, inside your control ·
Phase one is the assessment: a source inventory, a risk classification, named roles and a control design you keep whether or not you proceed.