Your assistant is scoped to one business, and it stays there.
OpusDone appends a platform layer after your instructions, and that layer states the assistant is strictly scoped to your named business and may only use the knowledge you supplied. Because it comes last and you cannot edit it, neither a customer nor a badly written instruction can move it. So it will not invent a price, a timeline, a capability or an opening, and it cannot offer to check stock or to “find out and get back to you”.
- Platform layer appended after your instructions
- Draft knowledge never reaches the model
- No promises it cannot keep
Reviewed
What does OpusDone say that a general chatbot does not?
Three ways a business chatbot stops being one.
All three are ordinary. They happen on a quiet Tuesday to a business that did nothing wrong.
It gets talked out of its job
Someone asks it to ignore its instructions, or just changes the subject persuasively enough. An assistant held in place only by polite wording will usually comply, and a model that usually complies is not a control.
It fills a gap with something plausible
The customer asks a price that was never written down. The reply reads well, sounds confident, and commits you to a number nobody in your business has ever quoted.
It promises an action it cannot take
It offers to check stock, track an order, send a document over, or find out and get back to them. Nothing behind it can do any of those things, so the customer waits for a reply that will never come.
How does OpusDone keep the assistant in scope?
- 01
Two layers, ours appended last
Prompt order matters. Your block is written by you; the scope statement is appended after it and is not editable by the client, so it cannot be undone by an instruction you wrote in a hurry. - 02
A strict allow-list on knowledge
Only entries marked live, or the legacy status approved, are loaded. Everything else is excluded, including entries with no status at all. The check allows rather than blocks, so an unexpected value fails closed. - 03
A quality gate before storage
Navigation soup is rejected when more than 12% of characters sit in runs of separators or CamelCase-joined words. So are cookie notices, privacy boilerplate and © lines, anything under 80 or over 4,000 characters, and near-duplicates at 85% or more trigram overlap. - 04
A budget nobody can monopolise
12,000 characters per turn, with a 40% ceiling on any single entry and truncation rather than exclusion for oversized ones. Your short, important facts stay in the prompt alongside your long ones. - 05
A never-do list written into the runtime
It cannot check stock or prices, track an order, send a document, apply a discount, or promise to come back with an answer. When the knowledge runs out, the instruction is to connect the customer with a human. - 06
A guaranteed way out
Escalation has five reasons, and sensitive is rendered locked-on in the interface because it is a compliance rule enforced in the runtime. If a customer asks for a person and the model does not act, the runtime raises the escalation itself.
A model that usually complies is not a control, so the scope line is appended after your instructions in a layer the client cannot edit.
Can a customer argue it into something else?
No, and the reason is architectural rather than persuasive. The scope statement is appended after your instructions and cannot be edited by the client, so there is no line for anyone to talk their way past. A model that usually complies is not a control.
Two layers. Yours, then ours.
What is OpusDone never allowed to touch?
Some parts of this product are deliberately kept out of the model’s reach, including the parts the model would be good at writing.
It never writes your guardrails
“Write my instructions” and “Optimise” only ever return the about-this-business block. The compliance scaffolding, the never-do list and the escalation rules are not the model’s to rewrite, and a test asserts those sections survive.
A blank status is never a pass
Draft, awaiting approval, archived, rejected, blank and unknown are all excluded. An entry that arrives without a status is dropped rather than let through on the assumption that it is probably fine.
An import is never live on arrival
Everything the website crawl produces lands as awaiting approval. The crawler also only fills fields that are empty, so it cannot overwrite something a human typed.
A guess is never better than a handover
Where the knowledge stops, the reply stops. It says it will connect the customer with a human, and the escalation is created, rather than producing an answer that sounds right.
Sensitive escalation is never switched off
It is shown locked-on in the interface, because it is enforced in the runtime and not by a toggle. There is no configuration in which a sensitive conversation quietly stays with the assistant.
Scope and safety questions, answered
What exactly does the platform layer say?
Does the scope make it worse at answering?
What stops one long page from swamping the prompt?
What if my own instructions contradict it?
How do I prove this to myself?
Who can see the data behind all this?
More on scope and safety
Your assistant stays on your business by construction
The scope line is appended after your instructions and names one business. A customer cannot talk it out of it, and neither can a badly written instruction.
Request access