Observe Declared Authority Across Governed Dispatch¶
Status¶
Accepted: A blueprint may require provider-owned authority observations before and after a dispatched step. The provider, not the generic runtime, defines the meaning and strength of the comparison.
Context¶
A readiness check establishes whether an authority can admit an operation. It does not establish what happened to that authority while another system was executing the step. Completion therefore needs a separate contract when the operation depends on the authority remaining stable or producing an expected change.
Different authorities expose different evidence. An object revision can prove that one Kubernetes object did not remain unchanged. A current inventory read may be fresh without proving which actor caused a change. The runtime must not convert these different signals into a stronger common claim.
Decision¶
A step can declare an authority_observation policy with:
- the expected interval outcome: unchanged or operation-related change; and
- the treatment of an interval the provider cannot verify: fail or record.
The selected provider performs both observations and returns its native
verdict, completion freshness, scope, and detection strength. Drift and stale
completion evidence fail closed. An unverifiable interval fails by default;
record permits completion while retaining that weaker result. If strict
evidence is unavailable by design, dispatch is rejected before execution.
Observation tokens and persisted receipts must remain free of credentials.
Consequences¶
Positive¶
- Authority readiness and completion evidence remain separate.
- Provider-specific evidence strength is visible in the operation record.
- The runtime can fail before dispatch when the requested proof is impossible.
Negative¶
- Not every authority can prove writer attribution or interval causality.
- Blueprint authors must choose an unverifiable policy that matches the operation's acceptance boundary.
Alternatives considered¶
- Treat a successful dispatch as authority completion: rejected because execution success does not establish authority continuity.
- Interpret every revision change as caused by the operation: rejected because concurrent writers cannot be excluded without provider evidence.