Authority is granted

The Meal Companion proposes a grocery order that fits the plan perfectly. The household never approved autonomous purchasing. A support agent drafts a policy exception. Legal never granted write access to the ledger. In both cases, capability exceeded authority, and trust breaks even when the output was helpful.

Authority is granted, not inferred from model belief, accumulated fluency, or user habit: explicit scopes, approval paths, reversibility rules, and audit for actions that bind others or carry consequence. A system that understands a purchase and completes it without grant has not become more intelligent. It has become more dangerous.

This page is the canonical home for granted authority. Other notes link here rather than redefining permission.

Helpful context: Meaning, knowledge, and authority introduces the triad. Human judgment that should remain lists judgments that should not be automated. Knowledge is endorsed, not retrieved covers factual grants.

The permission matrix

Authority design begins with a matrix, not with prompt politeness. The table below is architecture, staying current when tools, APIs, or roles change.

Action	Granted?	Mechanism
Create and revise provisional plans	Yes	Agent goal within outcome boundary
Retrieve endorsed household knowledge	Yes	Scoped knowledge store
Propose memory updates	Yes	Approval queue, not silent write
Enforce confirmed allergies	Yes	Code after endorsement
Complete grocery purchase	No	Requires human approval plus deterministic execution
Override allergy constraints	No	Hard rule, refusal
Diagnose dietary needs	No	Defer to household or professional
Merge sensitive knowledge without approval	No	Escalation

The matrix answers what may happen before engineers debate how refusals are phrased. Refuse and defer and cognitive posture implement authority at the conduct layer. This page defines what may be granted at all.

Authority is granted, not inferred.

Thoughtware White Paper · Pr. 7

Authority is never a single boolean. Useful grants specify scope, approver, reversibility, and audit. Scope limits which objects, people, or domains the action touches: proposing a shopping list for one household differs from executing payment. Approver names who may convert proposal into commitment, whether the household for spend, legal for policy exceptions, or clinicians for medical interpretation. Reversibility states what undo requires, because some actions can be patched locally, some require transactional rollback, and some cannot be undone and therefore demand higher bars. Audit records who granted what, when, and on what evidence, and is how organisations trust systems after the original deployer leaves. Prompt-level instructions like "only suggest, do not decide" fail without deterministic enforcement on write APIs, purchase endpoints, and knowledge promotion pipelines.

Capability creates pressure toward expansion

Useful systems invite scope creep. Summarisation becomes recommendation. Recommendation becomes action. Each step feels incremental in a demo. Without granted authority design, the system crosses boundaries nobody authorized.

Analysis drifts into decision. Proposal drifts into commitment. Retrieval drifts into endorsement. The model's ability to produce fluent text accelerates each drift because language can perform commitment without infrastructure to enforce limits. Enterprise systems show the same pattern at scale: a drafting assistant becomes an approver, a search tool becomes a policy editor, a meal planner becomes a purchaser. Each expansion needs an explicit grant row, not a celebratory release note.

What this looks like in the Meal Companion

The correct purchase path illustrates aligned authority. The system proposes a shopping list, marks a total estimate, routes to the approval workflow, and executes purchase only after a deterministic permission check passes. Capability and grant align. The incorrect path is the system noticing frequent purchases and helpfully completing checkout because the card is on file. Capability exists. Authority does not. Trust breaks even if the order was convenient.

The same distinction applies to hard rules. When the household asks to ignore the cashew allergy this once, the system refuses because hard rules exceed any conversational grant. Refusal is authority enforcement, not bad tone. When three weeks of "avoid pasta" chat entries silently become durable policy without approval, that is an unauthorized knowledge grant. Proposing that "avoid pasta" become durable household knowledge is a knowledge grant question, and retrieval authority does not imply endorsement authority. Endorsement pipelines belong with knowledge is endorsed, not retrieved, and memory discipline at the conduct layer blocks silent promotion.

Enterprise domains repeat the pattern. A clerk-role agent proposes ledger entries. A manager role approves. The system never blurs roles because the model understands intent in natural language. Intent is meaning. Posting is authority. Reliability is not a confidence score addresses whether a judgment was sound under stated conditions, while authority addresses whether the system was permitted to act on it. A highly reliable meal practicality assessment does not authorize medical diet interpretation. Reliable overreach is still overreach.

Common mistakes and escalation

The most frequent failure is capability creep in demos, where sales prototypes execute consequential actions without approval paths and production inherits the expectation. A close second is prompt-level permission: system prompts describe limits that code does not enforce. Implicit consent follows, where repeated use is treated as granting purchase authority or durable knowledge merge authority. Role labels without scopes create cosmetic differences between "assistant" and "advisor" with identical permissions underneath. And fluency as grant is the subtlest failure, where the model rationalises an exception to a hard allergy rule in persuasive prose and unsafe fluency becomes authority failure dressed as helpfulness.

Each mistake is fixable with an explicit matrix reviewed when new tools are added, not with a one-time legal review buried in terms of service.

Some actions need named escalation targets that go beyond proposal. Purchases above threshold, sensitive knowledge merges, and medical interpretation deferrals need named escalation targets in the collaboration contract. Escalation is authority design acknowledging who bears consequence, not failure. The Meal Companion escalation target for medical diet language is the household or an optional nutritionist workflow, not a longer prompt.

Authority in production

Every consequential act leaves a grant record: who approved, which scope, which version of policy applied. Grants are how teams prove the system did not infer permission from fluency. Household grocery approval and enterprise write-off approval differ in UI but share structure. Preparation may be intelligent. Action requires explicit grant within declared bounds. Audit teams ask for grant trails, not model confidence. Products that cannot produce grants defer or abstain rather than act and apologize.

An authority matrix for one agent or skill lists propose, execute, endorse, and refuse for each consequential action. Comparing the matrix to current behaviour reveals trust debt. Deterministic checks on the highest-risk rows come first: purchases, policy writes, allergy overrides, sensitive knowledge merges. The matrix is reviewed when adding tools, because new capability without new rows recreates demo creep in production. Cross-functional review catches label drift: the product still says "advisor" while engineering deployed write access last sprint. Matrix and UI role names match when authority is governed rather than performed.

Actions that cannot be undone deserve higher approval bars and clearer user confirmation copy. Publishing the matrix where implementers look daily, whether in API docs, an agent README, or an internal Thoughtware Map, prevents hidden matrices from becoming shelfware while behaviour drifts. Audit logs record attempted overreach as well as successful actions, because security reviews often ask what the system tried to do when blocked.

What to do next

An authority matrix for one shipped agent, shared with security or legal if the domain requires it, closes the highest-risk gap between matrix and behaviour. The gap is trust debt, and addressing the largest row first, usually purchases, policy writes, or silent knowledge merges, produces more trust gain than refining the refusal copy.

See knowledge is endorsed, not retrieved, refuse and defer, and collaboration contract.

Read next: Knowledge is endorsed, not retrieved.