Sealed, signed, declared, external: why source class matters

Not every fact an agent reads deserves the same weight. A record sealed by its issuer, a document signed by an accountable person, a statement declared by a known customer, and a claim arriving from outside differ in how far they can be trusted. Source class matters because it decides which actions a fact can support, and some classes cannot support some actions at all.

What are the four classes?

Each class describes how the fact reached you and what stands behind it, not whether it happens to be true.

A sealed source is the strongest because tampering can be detected and the issuer can be checked. A declared source is useful and often necessary, since much of what firms know about customers is what customers tell them, but it rests on the honesty of the declarer.

Why can't the model just judge each fact on its merits?

A model reads content. It can notice that an invoice looks odd, or that a figure contradicts another document. It cannot tell, from the text alone, whether a perfectly formed invoice came from the supplier or from a fraudster who copied the supplier's template. The content is the same; only the provenance differs.

So provenance has to travel with the fact, set by the system that brought the fact in, not inferred by the model reading it. An email gateway knows the message came from outside. A document store knows whether a file carries a valid seal. An authenticated session knows the customer is who they say they are. Each of these can stamp the fact with its class before the agent ever sees it.

Once the class is attached, the rules can use it. The model does not need to decide how much to trust an invoice. The platform already knows it is external.

Which actions should each class be able to support?

The useful question is not "how trustworthy is this source?" in the abstract. It is "what may this fact, from this class, be used to justify?". A practical mapping looks like this.

• Inform and answer questions: any class, with the class shown where it matters. An agent may summarise an external article, as long as it does not present it as the firm's own position.
• Draft for a person to review: any class, provided the draft shows which facts rest on declared or external sources.
• Execute routine changes within bounds: sealed, signed or declared. A customer's declared new address can update a record in an authenticated session, because the declarer is known and the change is reversible.
• Move money or take hard-to-undo actions: sealed or signed only, or declared where the firm has accepted that risk for a specific capability. Never external.

The last line is the one that stops a common fraud. The reasoning is set out in why an external claim should never authorise a payment.

What happens when facts of different classes are combined?

Most decisions rest on several facts. A refund might rest on the transaction record (sealed by the ledger), the refund policy (signed by its owner), the customer's explanation (declared) and a screenshot they attached (external). The question is which fact is load-bearing for the action.

The safe rule is that the action takes the class of its weakest load-bearing fact. If the refund destination comes from the external screenshot, the refund is bounded as external, however strong the other facts are. If the destination comes from the account on file, and the screenshot only explains why the customer is unhappy, the screenshot is context, not authority.

This is why the record should show which facts the agent relied on for each action, with their classes. A reviewer can then see whether an action rested on something too weak to carry it.

How do you keep track of which source is which?

Every source an agent can use should be listed with its class, its owner and how the class is established. A source provenance register is the working document. It also forces useful questions: is this knowledge base signed by anyone, or is it a collection of pasted notes? Is this data feed sealed by its issuer, or merely received from them?

Sources sometimes need reclassifying. A policy library that loses its owner stops being signed in any meaningful sense. A partner feed that adds verification may move up. The register should be reviewed whenever sources change, and the classes it records should be what the platform enforces.

Where Pryme fits

The Pryme Context Protocol stamps every fact reaching an agent with one of these four classes: sealed, signed, declared or external. The class travels with the fact into every decision, the minimum chain checks it at the moment of action, and an external claim cannot authorise a payment. For the wider architecture, see the governed agentic operating system, explained.

What should you do differently?

Map your agents' sources to the four classes, starting with any that feed actions at depth 3 or 4. Make the systems that bring facts in responsible for stamping the class, so the model never has to guess. Then set rules for which classes may support which actions, and make the weakest load-bearing fact decide the bound. The playbook on how to stop external claims from authorising payments is a good first application.