Authority belongs to whichever component can act. Does it?

Execution is easy to mistake for ownership

A component that can write a file or call an API may look like the natural decision maker. It has the credential, the route and the timing. In a complex system, those conveniences can quietly become an assumption of authority.

A consumer may own scheduling and delivery while PHS owns the governed persona-turn decision under a proposed contract. A model may propose a reply without owning the policy gate. A tool runner may execute a transaction without owning the customer's consent or the ledger's rules.

Separate the request, decision and act

Suppose a meeting application asks whether a persona should speak. It knows the agenda and who has the floor. It should send that context to the governed persona service rather than produce a raw turn and ask for a ceremonial blessing afterward. The difference changes who can account for the reply.

PHS's Governor consumer contract proposes that the consumer orchestrates while PHS assembles context, governs generation and records consequence. Its authority note distinguishes a persona's valid wish to change a rule from permission to mutate it. Both are design claims whose live enforcement needs receipts, not assumptions from component names.

Pause here: Who granted authority, for which scope? Who requested, decided, executed and recorded the act?

Make boundaries visible before a crisis

A useful contract names who may request, who decides, who executes and who records. It should carry the authority of the human or service that initiated a protected change. When one component plays several roles, the boundaries still need to be explicit; convenience cannot substitute for authorization.

This is also how errors become diagnosable. If the wrong page was published, we can ask whether the request was authorized, the decision was sound, the tool did what it reported and the result was verified. The presence of a working lever answers none of those questions alone.