Files
magnus919_agent-skills/enterprise-architecture/references/federated-governance-and-decision-rights.md
T
Magnus HedemarkandGitHub 8174e820e2 feat: add enterprise architecture methodology (#359)
Add capability and portfolio mapping, state transitions, operating models, decision rights, stakeholder information, templates, evals, and neighboring-owner routing.\n\nAI-assisted: Jasper orchestrated implementation and verification with OpenCode.

Signed-off-by: Magnus Hedemark <magnus919@pm.me>
2026-08-21 02:49:55 -04:00

1.8 KiB

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.