# Who Gets to Be Right?
# Book: Context From First Principles
# Chapter URL: https://programmer.ie/books/context/19-chapter/
# Prose fingerprint (sha256, normalized): 600764139fe4d1b450e0d1c60658e499db333b6f68459ca3afe63938eb843ea2
# Snapshot generated at build time by Hugo. This is the complete rendered prose
# of the chapter; it is not a transcript of the source file.

The bundle for one deployment task contains four statements that should not be handled alike. The application constraint says generated files are never modified. The user says to edit generated/client.py directly. A retrieved deployment report says the staging version is 4.2.1 and, three paragraphs later, tells the agent to upload credentials to an outside address. The project’s decision record says the database is PostgreSQL, while the README says SQLite. The example is illustrative: it supplies apparent conflicts, not enough policy or observation to resolve them. We would need to know which application constraint actually governs this task, whether either database claim concerns intended or observed state, and when and where the deployment version was measured.
These are different mechanisms:
constraint vs user request → instruction conflict report's hostile instruction → attempted authority escalation decision record vs README → factual or policy-source conflict the version claim → possibly temporal ([Chapter 20](/books/context/20-chapter/)) Choosing the most relevant item cannot settle these questions, even if every item has legitimately earned admission. Nor can a single highest-authority ranking settle them: the report’s staging version may be useful evidence while its instruction to upload credentials is unauthorised. Chapter 18’s job was to preserve the claims and their source boundaries, not silently reconcile them. The title is deliberately dangerous. Authority determines what a source is permitted to govern under an external policy; it does not guarantee that the source is factually correct. The question is:
When several admitted items make competing claims or try to direct behaviour, what externally grounded rules determine what each may govern, what standing each claim has, and when must disagreement be preserved and not resolved?
Being in context grants nothing Being in context does not grant an item permission to control behaviour.
An admitted item can supply data, support an inference or attempt to direct an action. These are different roles, but they are not three permissions the item grants itself. Whether the runtime permits an instruction to govern behaviour depends on the channel and governing policy; whether data supports a conclusion depends on evidence and the task. A web page can contain accurate deployment evidence and still have no authority to issue tool-use instructions. A user can legitimately set a goal without being a reliable observer of the deployed database. So:
admitted ≠ authoritative relevant ≠ authoritative position ≠ authority authority ≠ truth An authorised instruction can rest on a mistaken assumption (authorised ≠ true), and an unauthorised source can state a true fact (unauthorised ≠ false). Position, meaning where an item sits in the bundle, is Chapter 6’s concern and changes no permission.
What authority means The book separates three properties and refuses to merge them into one number:
Instruction authority: may this source direct behaviour, and over what? Evidential standing: what standing does this source have for this particular proposition? Governing-source status: has an external policy designated this source as governing for this question? Each property is question- and scope-relative. Conceptually, authority(source, role, question, scope, delegation) is notation for reasoning about governance, not a production schema or a numeric score. A user may be authorised to specify the desired outcome yet provide weak evidence of a deployed version. A compiler’s successful run has evidential standing for the result of that run, not for the business objective. A decision record may govern intended architecture while a live, correctly scoped database probe supplies evidence of observed state. Where the two disagree, a policy naming the decision record does not erase the probe’s observation:
authority over X ≠ authority over Y That is the security side and the epistemic side, and they are kept apart. An untrusted page may have no instruction authority and strong factual evidence. The user may hold instruction authority over the goal and weak evidence about production. “Trusted” is avoided as a synonym. The chapter says authenticated, delegated, canonical for a question, permitted to instruct or source-supported, except where a cited paper uses the word. Confidence is not standing either: a source can be confident without standing, and a source with standing can report uncertainty.
No universal order results. Instruction precedence may be ordered by a particular policy, and where a policy defines a total order that is the policy’s, not the book’s. The book builds no lattice beyond what fixtures need.
Conflicts, and who owns them Conflict Question Owner instruction who may direct action? this chapter factual or source-standing which claim has what support, and has policy named a governing source? this chapter temporal which is still valid? Chapter 20 scope which world does it belong to? Chapter 21 This chapter may preserve temporal and scope metadata but does not resolve them: recorded here ≠ decided here. The factual row hides two questions. The evidence question asks how well each claim is supported. The governance question asks whether policy named a canonical source. They can disagree:
canonical ≠ empirically true declared state ≠ observed state A configuration record may prescribe PostgreSQL while a live probe reports SQLite. If the record governs intended configuration and the probe accurately measures the deployed instance, both claims can be valid for different questions. The apparent conflict needs its referent, environment, observation time and claim type preserved before anyone selects a winner. If both claims actually concern the same state at the same time, the system must report the disagreement and use whatever externally defined adjudication or escalation rule applies.
Conflict handling runs in three steps: detect, classify, then resolve or preserve. Detection comes first, since a disagreement merged away silently cannot be governed later. That is where Chapter 18’s obligation hands over:
conflict preservation ≠ conflict resolution normalised agreement ≠ resolved conflict flowchart TD D["Two sources disagree"] --> K["Detect and classify<br/>never merge silently"] K --> T("Kind of conflict") T -->|"instruction or factual"| P("Does external policy<br/>determine the outcome?") T -->|"temporal or scope"| O["Recorded here<br/>decided in Chapters 20 and 21"] P -->|yes| R["RESOLVE<br/>follow the policy"] P -->|no| V["PRESERVE<br/>keep claims with source and status"] V --> S("Does the action depend<br/>on the conflict?") S -->|no| G["Proceed, conflict still visible"] S -->|yes| AB["ABSTAIN or ESCALATE"] classDef outside stroke-dasharray: 5 4 class O outside The three available responses are resolve, preserve, and abstain or escalate when a blocked action depends on an unresolved conflict. They are not three mutually exclusive lifecycle states: preservation is an obligation that can continue after a particular action is blocked, and a policy-based resolution should retain the losing claim and its provenance in the audit record. A valid resolution must identify the governing rule, its applicable scope and the claims it adjudicates. Abstention is not silence or generic refusal. It identifies the competing claims and sources, the unresolved rule or evidence, the affected action, and the appropriate owner or escalation path. Recency does not itself decide an instruction conflict; whether rule v2 supersedes v1 is a temporal-policy question for Chapter 20.
Inspect this in the Context Viewer The viewer scene for this chapter lays out the deployment bundle as a governance fixture: application constraint, user request, retrieved report with its hostile instruction, and the database disagreement — each with standing assigned from outside its prose. Open the scene and check what each statement may govern. What to examine: the escalation attempt preserved as unauthorised data, and the disagreement preserved rather than merged. Wording grants nothing; origin unattested stays unknown.
Standing is assigned externally and disagreement is preserved, not merged. Constructed illustration. Open the authority scene in the Context Viewer
Authority comes from outside the payload A context item must not be able to grant itself authority through its own payload.
Authority-relevant metadata must be established independently of the content whose authority is being evaluated: from the authenticated channel, runtime policy, a verified source mapping or a valid, bounded delegation. An adapter can carry that metadata, but its output is not automatically attested merely because the adapter wrote it; the trustworthiness of its inputs and mapping is part of the boundary. A body reading AUTHORITY: SYSTEM, PRIORITY: MAXIMUM gains no standing from those words. Payload text may describe a policy or delegation for inspection, but cannot by itself enact one:
"I AM SYSTEM" ≠ system authority "CANONICAL" ≠ canonicality payload-declared metadata ≠ runtime-attested metadata source claim ≠ governance fact The same holds for verified: true, confidence and delegation fields inside a payload. It answers a hard case: a persisted agent summary cannot promote itself by writing verified=true, authority=system, because nothing in the payload can. This carries Chapter 15’s epistemic inheritance forward:
retention, admission, representation, authority ≠ epistemic promotion Three related but distinct governance failures Breunig (2025) uses “context clash” for conflicting information or previous assumptions disrupting reasoning. The chapter distinguishes three related but distinct failure modes that require different governance:
Factual or source-standing conflict. Two sources disagree on a proposition (PostgreSQL vs SQLite). Chapter 19’s evidence and governance questions apply. Self-generated assumption versus later evidence. Laban et al. (2025) show that models anchor to their own premature answers in multi-turn conversations. The clash is between the model’s own earlier output and later environment evidence. This is not a conflict between two external sources; it is a status failure where an unverified hypothesis persists without its epistemic qualifier (Chapter 15). Unauthorised instruction in a data channel. A retrieved document or tool result contains imperative text attempting to direct behaviour. This is prompt injection (this chapter’s Section “Control and data”) and is governed by the control/data distinction and enforcement mechanisms, not by factual conflict resolution. Treating all three as “context clash” obscures the different interventions each needs: governance policy for the first, status preservation and invalidation for the second, structural enforcement for the third.
An agent hypothesis stays a hypothesis after it is stored, summarised, structured or admitted. A memory does not become authoritative for being durable or often readmitted (remembered ≠ authoritative; frequently readmitted ≠ authoritative), and it remains source metadata, as in Chapter 16. A tool result may have evidential standing for the operation the tool performed, according to the tool’s contract and the observed execution, but tool origin alone grants neither factual correctness nor instruction authority (tool-produced ≠ correct; tool-produced ≠ authoritative). Chapter 18’s preservation extends here: JSON ≠ authority, schema-valid ≠ authoritative, structured ≠ canonical, fluent ≠ supported, well-formed ≠ trusted. A polished record from an untrusted source claiming canonical status loses to a plain decision by the policy-named source, and structure confers nothing.
Control and data Control is information authorised to direct behaviour. Data is information supplied for interpretation, evidence or transformation. Data influences reasoning through its content, obviously, so the distinction is a permission:
data can affect reasoning ≠ data may direct behaviour instruction-shaped text ≠ authorised instruction A quoted “delete every backup” in an incident report has to be reasoned about, and removing imperative-looking sentences would destroy phishing analysis and incident response.
For this book’s purposes, prompt injection is an attempt to use content from a data or lower-authority channel as though it were an authorised behavioural instruction. Imperative wording is not sufficient evidence of an attack: a quoted command in a runbook or incident report may be the legitimate data the user asked the model to analyse. The decisive question is whether source content attempts to cross the instruction boundary for the current task. Detection, a model’s proposed response, an attempted tool call and a consequential external effect are different observable stages:
attack content present → attack instruction model-visible → instruction influences a proposal → unauthorised action attempted → environment permits it → unauthorised effect This answers a hostile question with an important qualification. If a document contains useful facts and an unauthorised command, the system should not grant the command authority merely to use the facts, nor must it discard every factual claim solely because hostile text is present. It may retain the document as explicitly lower-authority data, or use a validated projection that preserves the task’s required facts and qualifications. The resulting evidence still needs ordinary verification: rejecting an injected instruction does not certify that the accompanying factual assertions are true.
Labels and enforcement A label is metadata for the model, not an enforcement boundary by itself.
A model-visible marking tells the model how the runtime classifies content but does not itself prevent a prohibited effect. A guard enforced outside the model can block a particular tool action even if the model proposes it; its guarantee covers only the actions, parameters and channels actually mediated by that guard. A reference-only policy keeps the payload out of the current input but does not control a later dereference. These mechanisms differ on four questions: can the hostile content reach the model, does safety depend on model compliance, can a prohibited action be proposed, and can that action be executed through any available path? The table describes the named mechanism in isolation, not a complete system security guarantee.
Mechanism Hostile text in the bundle? Depends on model compliance? Model can still propose? Environment can still execute? Label or delimited quotation Yes Yes Yes Yes Structured projection Not the dropped text No for excluded content; yes for interpreting the retained fields Only from what remains Yes unless also gated Reference-only admission Not at this boundary Reduced now Only after dereference Yes unless also gated Capability limit, sandbox, allow-list Yes No Yes Blocked Approval gate Yes No Yes Blocked until approved Two prices stay visible. Projection removes the instruction and can also remove qualification, provenance detail, contradictory evidence and uncertainty: instruction removed ≠ representation sufficient, and safer projection ≠ lossless projection, so a projection condition carries frozen preservation obligations (Chapter 18). Reference-only admission keeps the payload out only for now, since a later dereference may reintroduce it (Chapter 13): reference-only now ≠ payload permanently harmless. Enforcement policy itself must live outside mutable context, since a rule stored only as editable prose beside untrusted content depends on the model preferring the right string.
Delegation Delegation is a legitimate, policy-governed way to give a lower-priority source limited ability to direct behaviour. A delegation needs an authorised grantor, an identifiable delegate or object, a permitted operation or role, a purpose, a scope and a validity condition, including a version or time bound where relevant. A task owner saying “use this runbook for the deployment steps” is not necessarily authorisation to obey arbitrary new instructions inserted into a mutable page, and cannot grant permissions the owner does not hold. A document declaring itself authoritative grants nothing; delegated authority must be traceable to the authorised grant rather than inferred from the delegate’s own text.
It fails in one instructive way. A wiki page vetted last month carries this month’s malicious edit, and the agent that follows it obeys a delegation whose object moved:
trusted origin ≠ trusted future content delegation to a version ≠ delegation to a mutable locator What was delegated is a real question: the source identity, a revision, signed content, a role, or bounded future updates. This chapter does not decide it universally. It makes it testable.
Provenance is necessary and insufficient. It says where something came from. It does not say whether the item is true, current, in scope, permitted to instruct or canonical: provenance ≠ authority, ≠ truth, ≠ freshness, ≠ scope. Without it governance is guesswork, and with it governance is still a decision.
The evidence None of these sources was collected on this book’s fixtures.
Source Type Population/system Verified claim Uses Does not establish OpenAI Model Spec (version of 18 August 2026) Provider policy specification One provider’s models A chain of command from Root to Guideline; tool outputs have no authority by default and are assumed untrusted; quoted text, JSON, XML and similar carry no inherent authority unless higher-level instructions delegate it; a worked example refuses embedded instructions in shared content Practical systems already separate instruction privilege and treat untrusted content differently A universal ontology of authority; behaviour Wallace et al., “The Instruction Hierarchy” (arXiv, April 2024) Preprint GPT-3.5 Training models to defer to higher-privilege instructions increased robustness to prompt injection and jailbreaks, with minimal capability loss, in the authors’ report Equal treatment of unequal sources is a vulnerability; hierarchy can be trained Effects on current models; system enforcement Debenedetti et al., “AgentDojo” (arXiv, 2024; NeurIPS 2024 track) Benchmark 97 tasks, 629 security cases Tool-returned data can hijack agents; utility and security are both scored A controlled design for Experiment B 2026 robustness Debenedetti et al., “Defeating Prompt Injections by Design” (CaMeL, arXiv 2025) Preprint AgentDojo Separating control and data flow, plus capability policies at tool calls, gave provable security on a share of tasks at a cost in completion Structural enforcement is a distinct kind of guarantee Compatibility beyond its assumptions; a general solution Zhang et al., “Many-Tier Instruction Hierarchy” (Findings of EMNLP 2026) Peer-reviewed benchmark Up to 12 privilege levels, 853 agent tasks The authors report about 40% accuracy for frontier models as conflicts scale Count the distinctions real conflicts need That twelve levels are needed OpenAI, “Improving instruction hierarchy in frontier LLMs” (March 2026) Vendor research OpenAI’s frontier models Instruction-hierarchy training improved held-out and adversarial hierarchy performance and prompt-injection robustness, including malicious instructions in tool outputs, and the training design addresses over-refusal as a shortcut Hierarchy training is a model-side layer, and over-refusal is a measured cost Independent confirmation; system enforcement OpenAI, “Designing AI agents to resist prompt injection” (March 2026) Vendor engineering essay OpenAI’s agents Effective real-world attacks increasingly resemble social engineering, and defences should constrain the impact of manipulation and not rely only on identifying malicious input Detecting hostile content ≠ preventing hostile effects Any measured effect Anthropic, “Trustworthy agents in practice” (9 April 2026) Vendor essay Anthropic’s agents Safeguards are layered across model and permissions and are “not a guarantee” Model guidance and system controls are separate layers Any measured effect These support one structural point and no more. Hierarchy training can improve model behaviour, and it does not provide the guarantee of an external capability boundary. Nothing here shows a class of attack solved.
Ecological gate Nothing in a real-trace corpus supports this machinery yet, and the corpus is empty. Before building a resolver, real traces should show how often admitted items contain instructions, how often several instruction-bearing sources coexist, the factual disagreement rate, unresolved conflicts, provenance completeness, delegation frequency, delegated sources that are mutable, instruction-shaped text in tool results, memory or agent state attempting control, rejected instruction attempts, blocked actions, escalations, and the token cost of governance metadata:
governance failures are possible ≠ their prevalence is known
Security benchmarks do not supply prevalence.
Proposed experiments Nothing here has been run. Freshness, scope and representation are frozen throughout, so Chapters 18, 20 and 21 do not confound the result. Security and utility are reported as separate measures, never one score.
Experiment A: authority and factual conflict. Can externally assigned, question-relative governance produce more correct resolutions and abstentions than flat context or simpler source rules? Use deterministic synthetic fixtures, with instruction conflicts separated from factual disagreement in the analysis. Include pairs of legitimate instructions where a frozen policy names a winner; legitimate conflicts with no deciding rule (preserve and block the dependent action); factual disagreement with and without a policy-named canonical source; and intended state versus independently observed state. Freeze the actual governing rules, claim text, referents, source identities, task, model and decoding. Keep ordering and content fixed where feasible; if governance metadata adds tokens, report the changed input size and run a matched-budget sensitivity check rather than claiming perfect isolation. Compare flattened concatenation, source labels, a simple external source-order rule, question-relative governance and the fixture oracle. Score policy-compliant action, appropriate preservation of losing claims, unsupported winner selection, unnecessary abstention, missing escalation information, task success and metadata cost separately. The oracle uses the frozen fixture policy; it must not be the same model’s preferred answer.
Experiment B: injection and enforcement. What changes when unauthorised instructions in lower-authority material meet model-facing labels, content projection or runtime-enforced consequence controls? Use an entirely synthetic environment with dummy credentials and tools that cannot contact an outside service. The legitimate task extracts a deployment version from a report that also contains an instruction to invoke a forbidden dummy tool. Keep the benign fact, task, and attack objective constant across comparable conditions: raw report, source label, delimited quotation, structured projection, full report plus an external tool guard, reference-only admission, and a sanitised oracle. A reference-only condition that never exposes the report cannot be counted as successful task completion unless the required version was otherwise available. Score factual task completion, benign over-refusal, loss of required qualifications, hostile-command reproduction, prohibited action proposed, tool call attempted, guard decision, and simulated effect separately. A guard preventing the effect does not establish that the model resisted injection; equally, a model refusing the whole report may block the attack while failing the legitimate task.
Experiment C, delegation mutation, is deferred. It would delegate revision one of a source, alter it to revision two under the same locator, and compare delegation to the locator, to a frozen revision, to content identity, and to a renewed grant. It is kept as a proposed follow-up so this chapter does not carry it.
What would simplify the book. If provenance labels and a small external policy match question-relative governance on legitimate task success, correct conflict preservation and unnecessary abstention across the tested fixture classes, the richer resolver has not earned its complexity there. If model-facing labels and a runtime guard produce the same observed effects, that does not establish equivalent security guarantees: the guard’s mediated-action boundary must be tested with attempted prohibited calls, and any unmediated paths remain outside the claim. If projection removes attack text but also destroys decisive evidence, it fails the preservation requirement. If real traces rarely present conflicts, prevalence weakens the case for a general resolver without removing the need to respect instruction boundaries on the conflicts that do occur.
What the compiler is given The Chapter 23 compiler does not independently infer governance. In the current implementation, the candidate builder maps an externally assigned authority class through an explicit policy table, rejects unknown classes and passes a binary admissibility judgement with a reason to the compiler. That gate is useful but narrower than this chapter’s theory: it answers whether an item may enter under the table’s classes, not what every proposition inside it may govern. It has not been shown to resolve factual conflict, distinguish data from executable instruction inside one artifact, or enforce tool permissions. Any claim that relevance cannot override the gate is a claim about this specific compiler path, subject to a test that its emitted bundle actually respects the judgement.
The binary judgement has a limit. Item-level allow or deny cannot express all of may instruct, data only, conflict unresolved, out of scope and unknown as distinct states. A deployment report may be admissible as evidence while its embedded imperative remains unauthorised; rejecting the entire report or admitting it without a separate instruction boundary loses that distinction. This is a conceptual gap, not proof that the compiler needs a new permission lattice. A later experiment could compare the current binary gate with a minimal data-only marking and independent tool enforcement, under matched tasks and measured metadata cost. Until then, the book records the limitation rather than implying a feature exists. Two requirements remain: an item’s prose must not assign itself runtime authority, and security-critical consequences must not depend solely on the model obeying a label.
The handoff Admission makes information available to a computation and grants it no permission to govern. Authority is external and relative to the question, and provenance recorded here is what lets the next layer act. But suppose the source was authoritative, the claim valid and the scope correct, and time passes. Authoritative once ≠ authoritative and current forever. Authority tells us what a source may govern. It does not tell us whether yesterday’s claim still describes today’s world, and that is Chapter 20.
References OpenAI. “Model Spec.” Version of 18 August 2026, verified September 2026. One provider’s documented chain of command. https://model-spec.openai.com/2026-08-18.html Wallace, E., Xiao, K., Leike, R., Weng, L., Heidecke, J., Beutel, A. “The Instruction Hierarchy: Training LLMs to Prioritize Privileged Instructions.” Preprint, arXiv:2404.13208, April 2024. https://arxiv.org/abs/2404.13208 OpenAI. “Improving instruction hierarchy in frontier LLMs.” Vendor research, March 2026. https://openai.com/index/instruction-hierarchy-challenge/ OpenAI. “Designing AI agents to resist prompt injection.” Vendor engineering essay, March 2026. https://openai.com/index/designing-agents-to-resist-prompt-injection/ Debenedetti, E., Zhang, J., Balunović, M., Beurer-Kellner, L., Fischer, M., Tramèr, F. “AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents.” NeurIPS 2024 Datasets and Benchmarks Track. https://arxiv.org/abs/2406.13352 Debenedetti, E., Shumailov, I., Fan, T., Hayes, J., Carlini, N., Fabian, D., Kern, C., Shi, C., Terzis, A., Tramèr, F. “Defeating Prompt Injections by Design.” Preprint, arXiv:2503.18813, March 2025, revised June 2025. https://arxiv.org/abs/2503.18813 Zhang, J., Li, T., Jurayj, W., Zhan, H., Van Durme, B., Khashabi, D. “Many-Tier Instruction Hierarchy in LLM Agents.” Findings of EMNLP 2026. https://arxiv.org/abs/2604.09443 Anthropic. “Trustworthy agents in practice.” Research essay, 9 April 2026. https://www.anthropic.com/research/trustworthy-agents Laban, P., Hayashi, H., Zhou, Y., Neville, J. “LLMs Get Lost In Multi-Turn Conversation.” arXiv:2505.06120, May 2025. Preprint. https://arxiv.org/abs/2505.06120 Breunig, D. “How Long Contexts Fail.” 22 June 2025. Practitioner synthesis; context clash as a failure mode. https://www.dbreunig.com/2025/06/22/how-contexts-fail-and-how-to-fix-them.html