# 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
- **Audience:** both
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/knowledge/owner-authority/

## 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](/docs/knowledge/knowledge-owner-tenant/).

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](/docs/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](/research/authority-separation/), which is worth reading before deciding either setting for a live workspace.

## Changing authority is an event, not an edit

1. 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.
2. 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.
3. 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.

> **Note** This is why authority cannot be raised quietly in a hurry. A source that has been sitting harmlessly as `reference` may well contain something that contradicts approved material — that is precisely what `reference` was protecting you from.

## 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'.

## Related

- [Knowledge and Fact are different things](https://connectbyjbrh.com/docs/knowledge/knowledge-vs-fact/)
- [When two sources disagree](https://connectbyjbrh.com/docs/knowledge/source-conflict/)
- [What Connect may do](https://connectbyjbrh.com/docs/autonomy/)
- [Separating the agent's authority from the person's](https://connectbyjbrh.com/research/authority-separation/)
- [Knowledge for the Owner and for a customer](https://connectbyjbrh.com/docs/knowledge/knowledge-owner-tenant/)
- [Auditing what an answer was based on](https://connectbyjbrh.com/docs/workflows/knowledge-audit/)

## What this page is based on

- `backend/app/knowledge_bank.py` — authority, reassessment, risk review and activation rules
- `backend/app/safe_sales.py` — the deterministic gates the model cannot override
- `docs-source/sources/GENERAL.md` §5 — autonomy, approvals and Needs You
- Connect capability registry (docs-source/facts.py)