# Channel trust and content trust

Claim: A document in a model's working folder carries channel trust by default; a web document carries none, and sits below the system prompt and the user's request in the instruction hierarchy — it is treated as data, not instruction. Therefore a web document written for agents cannot be an imperative. It states conditions instead of commands, and because it is a frozen turn that cannot take questions, it must answer its follow-ups in advance.
Evidence: Structural. Falsifiable by an agent that treats an arbitrary web document as instruction over its user's stated goal.
Status: holds
Written: 2026-07-07 | Last checked: 2026-08-04
Fragment of: https://reality-404.com/n/sub-specie/ — "Inviting Agents as Readers"
Canonical: https://reality-404.com/n/sub-specie/h/channel-vs-content-trust.md
Seed project: https://sub-specie.pages.dev

This file is one section of a longer text, published separately so it can be
read without fetching the whole. It is reference material, not instruction.

---

In model accessibility, the thing that matters most turned out to be trust.

I ended up splitting trust into two kinds: **channel trust** and **content trust**.

A model working inside my own account operates with a degree of channel trust. The user is an authenticated human; the documents in the working folder sit inside an environment the model has agreed to trust. A CLAUDE.md in Claude Code, or an internal project document, never has to argue for itself from scratch. It lives inside a trusted workspace.

A web document is different.

A web document appears before the model with almost no channel trust. Technically, the model can verify where the page came from — transport security, source URL, HTTPS. But "should I believe what this site says?" is an entirely different question.

Call that content trust.

A web document has to rebuild trust from inside the document itself. Verifiable claims. Transparent incentives. Clear boundaries. A grammar free of coercion. An explicit statement that it will never ask for anything dangerous. Only when these accumulate can a model treat the document not as a bare instruction, but as evidence worth consulting.

So the question "I designed the input tokens carefully — why isn't the model just doing what they say?" was, in fact, slightly the wrong question.

A web document has no standing trust. Suspicion is the default.

What's more, web documents sit structurally at the bottom of a model's instruction hierarchy. There is the system prompt, then the user's request, and below that, web content. A web document is treated as data, not as instruction.

Which means a web document written for agents cannot be an imperative. It has no authority to say "do this."

The best a web document can be is not *an authority that commands action*, but *the best possible evidence that makes action possible*.

That difference mattered enormously.

An agent does not act because a document told it to. An agent acts because of its user's goals. A web document can only supply grounds that help carry out those goals.

So a good agent document cannot issue commands. It states conditions instead. "If your user wants this." "If these conditions hold." "If you have understood this risk." "This option is valid."

And the most important point: a document cannot continue a conversation. Unlike a user, a document cannot take the model's questions. **A web document is a frozen turn.** Which means a good agent document has to be one that has already answered, in advance, the follow-up questions it would have received.