Trust boundary

The one-page artifact this topic produces for an AI system. It is an explicit, decision-by-decision line marking each decision "the system may decide and act alone," "a human must sign before it takes effect," or "do not ship," with every human-signs decision naming who signs and the conditions that make the signature real. It is one of the three artifacts Module 4 hands forward.

A point in an estate where an agent's action crosses from a system, team, or organization it is native to into one it is not, such as an agent acting on a different team's database or a partner organization's data feed. Actions crossing a trust boundary warrant full four-field logging under this topic's tiering guidance, regardless of how routine the action might otherwise seem.

The point at which one organisation's agent identity infrastructure stops being able to directly verify a claim and must instead rely on an external mechanism, such as a decentralised identifier or a trusted agent registry, to confirm who or what it is dealing with. Identity design gets materially harder at every trust boundary an agent crosses.

The line separating a system's owner or authenticated source from any other party or content source; a protocol that carries information across a trust boundary without marking which side it came from cannot support a downstream decision about how much to trust that information.

The line separating what a claim about a system is supported by verified evidence versus what it is supported by only where the system sits, who can reach it, or how long it has operated without incident. Mapping this boundary explicitly, for any node, is the practical mechanics behind the evidence-versus-position test.