# Federated Governance and Decision Rights

Use this reference when multiple domains must remain coherent without routing every
choice through a central board.

## Start with the decision

For each decision record its scope, affected capabilities, reversibility, blast
radius, regulatory obligations, evidence, and accountable owner. Then select a path:

- **Local decision:** the domain owns the outcome and compatibility is bounded.
- **Federated decision:** a domain decides within published enterprise constraints
  and affected peers can raise a conflict.
- **Advice process:** the proposer owns the choice after consulting those bearing
  material consequences; advice is not an unrecorded veto.
- **Central decision:** a named authority decides when impact, irreversibility,
  mandatory control, or unresolved cross-domain conflict exceeds local authority.

These are governance choices, not maturity levels. Automate objective checks where
possible, but do not turn a judgment into a false pass/fail rule.

## Make conflicts resolvable

Every standard or decision should name the proposer, accountable owner, affected
parties, required consultation, decision authority, evidence threshold, exception
path, expiry or revisit trigger, and appeal/escalation route. When two owners have
legitimate authority over the same boundary, first separate the decision into
outcome, constraint, implementation, and operating responsibilities. If authority
still conflicts, escalate to the named enterprise sponsor; never silently choose.

Review feedback from delivery, operations, cost, incidents, adoption, and exceptions.
Revise or retire a control when it no longer prevents a meaningful failure. Keep the
historical decision and reason for change visible.

Technology standards and radar posture remain with `technology-radar`; durable
decision history remains with `adr-authoring`.