Governance APIs

After this lesson, the reader should understand:

• 01Specify the request and response shape of an authority evaluation.
• 02Return outcomes that carry their own authority binding.
• 03Handle referral, unavailability, and expired authority.

Authority as a shared service

Six systems apply the same policy. Should each implement it?

No — six implementations are six interpretations, and they will diverge on the first amendment. A single evaluation service means one artifact, one version in force, and one record format across every calling system. The organisational difficulty is not technical: it is deciding which body owns the artifact when six teams previously owned six copies.

• Should evaluation be synchronous, and what happens when it is unavailable?
• Who owns the artifact when many systems depend on it?
• How are breaking changes to an artifact communicated?

Specify one governance endpoint.

1. 01Define the request payload and required facts.
2. 02Define the response, including trace and binding.
3. 03Define behaviour for referral and for missing facts.
4. 04Define behaviour when no version is in force.

• API design and contract versioning.
• Policy decision points in access-control architectures.
• Service governance in public-sector platforms.