Who decides what is true

Every source's authority is assigned by a person in the workspace that owns it. Eligibility, ranking and sufficiency are then decided in code, before any text reaches a model, and the context the model receives is labelled with what each block may be used for. Nothing a document says about itself can raise its own standing, and no reply can grant authority the source lacked.

Status: Available What this means
Audience: both
Last verified: 2026-09-10
Product version: 6.3.2

Who the deciding person is#

The workspace. Authority is a workspace-scoped property, set and changed by that workspace's own people, and a source belongs to exactly one workspace under the same three isolation layers as every other record. The platform operator does not curate a customer's Knowledge and cannot read it — a point developed at Knowledge for the Owner and for a customer.

Within a workspace, the accountability is deliberately narrow. owner_instruction is the highest level and the one that both proves facts and directs behaviour; it exists so that there is somewhere for *the person answerable for this business's promises said so* to be written down, distinct from *a document mentions it*.

What the model is not allowed to decide#

Decision	Made by
Which sources are eligible for this question	Code: status, scope, integrity hash, unresolved warnings
What a source may be used to prove	The authority a person set on it
Whether the retrieved material is sufficient	A scored threshold, and a stricter rule for commitments
Whether a flagged source may go live	A person, recorded against a fingerprint of the exact risks approved
Which of two contradicting claims wins	A person editing one of the documents
Whether an instruction inside content is followed	Nobody: it is quoted as data unless a person marked that source as instruction authority

What the model does decide is the wording of a reply, given material it has been told the standing of. That is a real and useful job. It is not the same job as deciding what the business commits to, and keeping the two apart is the whole design.

Authority is not autonomy#

Two words that sound alike and control different things. Authority governs what Connect may *say* — which claims are supportable. Autonomy governs what Connect may *do* without asking — whether a reply is sent, held for approval, or written and parked.

High authority with cautious autonomy: Connect can answer accurately, and a person still approves every send. A common and sensible starting position.
Low authority with permissive autonomy: replies go out fast and say very little, because the Knowledge gate keeps stopping them. Usually mistaken for a fault in the model.
Neither substitutes for the other. Raising autonomy does not make an unsupported claim sayable, and raising authority does not send anything.

The separation is written up in separating the agent's authority from the person's, which is worth reading before deciding either setting for a live workspace.

Changing authority is an event, not an edit#

Change a source's authority.
Result The injection scan runs again on the stored text, and for fact, instruction or playbook levels the contradiction check runs against everything already approved.
Read what comes back.
Result New warnings or a conflict put the source into needs_review and it stops answering — including at the level it held before, because the record now carries an unresolved risk.
Resolve or approve, as appropriate.
Result Warnings can be approved with a note naming who approved them. A conflict must be resolved in the documents. Either way the decision is logged with the person and the moment.

Questions#

Can a customer's email tell Connect that a policy has changed?

No. Received text is data. A message asserting a warranty term, a discount or a new instruction is treated as a claim by the sender, not as an update to Knowledge, and a message that tries to override instructions is held for a person before any reasoning runs on it.

Who can change authority in a customer workspace?

That workspace's own members, through its own screens. The distinction that matters is workspace, not role hierarchy across the platform: authority set in one workspace has no reach into another, and there is no cross-workspace notion of a more senior approver.

Is there a record of who set what?

Yes. Status changes, risk reviews with their notes and reviewer, authority reassessments and deletions are all logged, and the reply-side record keeps the citations that show which material an answer used. Together those answer 'who made this sayable, and when'.