Governance

Every governed record follows the same lifecycle shape, even though the exact status names differ per type: an editable draft state → a review state (reached either by requesting a review or by editing your own status field directly, both do the same thing) → approved or rejected, where rejected sends it back a step rather than to the very start → eventually superseded/retired/archived as a terminal state. What "approved" means varies by type — for a Decision or Principle it's the record becoming authoritative; for an Architectural Service, counter-intuitively, the *governed* transition is retiring it, not launching it, since decommissioning a service (especially a critical one) is the operation with real blast radius; for a Position Paper it's publication, which also bumps the paper's version number.

Two ways to route a review, both driving the exact same status field: Review Requests asks one specific stakeholder for a yes/no, resolved as soon as they respond (or once every requested reviewer has responded, if more than one was asked). Approval Chains (Automation & Workflow) is for when a record needs a defined, ordered sequence of sign-offs rather than one ad-hoc request — configure the steps once, then every review for that chain follows the same path. Either way, every transition is recorded to a permanent sign-off history (who, from-status, to-status, notes, when) visible on the record and via Reports — this is what makes an "approved" status defensible later, not just a label that happened to get set.

Who's currently governed, so you know where this applies: Decisions, Principles, Reference Library entries, Solution Designs, Service Blueprints, Customer Journey Maps, Engagements, Architectural Services, and Strategic Position Papers.

Architecture decision records move through draft → review_required → approved/rejected → superseded. Each decision has a decision ID, category (business/application/technology/data/security/integration), rationale, implications, decision maker, linked entities and a full change/sign-off history. Decisions support comments, subscriptions, and CSV/print export, and a Solution Design's recommended option can be "promoted" directly into a pending decision so the two records stay linked.

EA principles are organised by category (business/application/technology/information) and follow the same draft→review→approved→superseded workflow. Adherence to a principle can be assessed against any entity as weak/partial/moderate/strong, with a distribution chart per principle, and a Pattern's Links panel can cite the principles that motivate or govern its use.

A governed, exportable strategic-direction document for multi-million-dollar platform moves and similar big architectural bets, at Architecture Catalog → Position Papers. A paper moves through Framing (scope, assumptions, and a capability-fit evaluation grid scoring how well the current estate meets the direction), Positioning (a weighted Strategic Options Comparison — executive criteria like Strategic Alignment and Transition Complexity, scored 0–5 per option, purpose-built for this document rather than reusing the Solution Architecture decision matrix so Position Papers stay usable without the sa module — plus Transition Propositions as guardrails), Transitioning (Work Packages sized on an xs–xl cost scale with a complexity rating, and a Consultation Log of workshops/specialist input), then in_review → published through the same Review Requests / Approval Chain mechanism as everything else in this chapter. Publishing bumps the paper's version to the next whole number (e.g. 0.3 → 1.0) and locks it read-only; the only way to revise a published paper is Supersede, which spins up a new draft copy and links the two records together. A published paper's Work Packages can be promoted straight into the Business Engagement demand pipeline as new intake, carrying their cost tier and notes across as the starting effort estimate — turning a strategic decision directly into tracked delivery work without re-keying it. Like every other artifact in Eidon, a paper can link to and be linked from other catalog objects, with its own Related Artifacts panel showing what references it back.

Embedded directly in Decisions, Principles, Solution Designs, Service Blueprints, Engagements, Architectural Services (see Solution Architecture) and Position Papers (above) rather than a standalone page. A review can be requested from a stakeholder and moves through pending → approved/rejected via a stepper UI, with the full sign-off history (who, status change, notes, timestamp) kept on the record — every governed record gets this audit trail automatically the moment it's wired into the review mechanism, not just Decisions and Principles. The same panel doubles as an entry point into a multi-step Approval Chain (see Automation & Workflow) when a record needs more than a single reviewer's sign-off.