Prepare, never publish

Start with the honest part, because everything else rests on it: the AI can be wrong. Large language models hallucinate. Anyone selling you one that simply cannot is selling you something. So the question worth answering is not how we stop it being wrong, because you cannot, but what happens when it is. Doris's answer is a design in which a wrong output has nowhere to land.

The whole of it fits in three words: prepare, never publish. The assistant is allowed to do all the preparation: read your data, generate the paperwork, suggest what matches what. It is not allowed to commit anything that cannot be taken back. That line is drawn in code, not in a policy document, and it is held by three separate walls.

The first wall: Doris prepares, but it cannot commit

Doris's connector mostly hands over reports: your bookings, your room utilisation, your statements. It can also prepare two specific things: it can generate a month's statements, and, when your accounts show a payment has arrived, it can suggest which invoice that payment settles.

What it cannot do is make the change that matters. Marking an invoice paid is a guarded action that only a human triggers, by confirming a suggestion inside Doris. The tool that proposes a match has no ability to change an invoice's status at all; that capability is not wired to it. The suggestion lands in a review strip on your invoicing screen; you confirm it or dismiss it. Confirmation is the only route to paid, and confirmation is a person's.

Two details make this sturdier than it first sounds. Generating statements is idempotent: run it against a month that has already been invoiced and it does nothing, so the assistant cannot double-bill by being asked twice. And the write tools are a separate permission, the drafting pair is its own deliberate opt-in. Left alone, the connection is read-only.

The second wall: everything consequential waits in draft

Across the other tools on the switchboard, your email, your accounting package, the actions that cannot be undone are left as drafts for a person to approve. The reminder sits in your drafts; the assistant does not send it. The invoice waits; the assistant does not raise it.

An honest note for anyone reading closely: that safety spans tools Doris does not build or control, so it is a discipline the pattern gives you, not something Doris can guarantee end to end. What Doris guarantees is its own edge: prepare, never publish. The draft habit covers the rest, and it is worth keeping as a house rule.

The third wall: it only ever sees your organisation

The assistant has no privileged access of its own. It sees your data through exactly the same organisation-scoped keyhole a signed-in member of your team looks through, and every query it makes is bounded to your organisation at the data layer.

That is worth stating precisely, because the tempting phrasing, that it is impossible for it to reach another organisation's data, is the kind of absolute security people have learned to distrust. The truer, stronger claim is about the mechanism: reaching another organisation's data is not a door the assistant is trusted not to open. It is a door that was never cut into the wall. The isolation is not a promise of good behaviour; it is the absence of a path.

So what actually happens when it is wrong?

This is the test the whole thing has to pass. Say the assistant misreads a bank reference and matches a payment to the wrong invoice. The result is a single wrong suggestion sitting in your review strip, waiting for someone to glance at it and dismiss it. That is the blast radius of a hallucinated reconciliation: one dismissible row. Not a wrongly-closed account, not a payment marked settled that never arrived, not an email already gone to the wrong member.

That is the point of the design. It is not a promise that the assistant is never wrong. It is an arrangement where being wrong costs you nothing, because the only things it can do on its own are the things that do not count, and the things that count wait for you.

And if someone technical asks how you know the isolation holds, the honest answer is scoping discipline and testing, not mathematics, which is why the claim stays at bounded by design, at the data layer, and the proof is the test coverage behind it rather than a superlative in the copy.