Skip to content

Governance and History

OpenEA separates the lifecycle of an architecture object from its governance state.

An Application can be lifecycle Active while its governance status is Draft, Approved, or Needs Review.

General governance flow

The standard governance workflow is:

Draft ──► Submitted ──► Approved
  ▲           │             │
  │           ├──► Rejected │
  │           └──► Needs Review ◄──┘
  └──────── Rejected / Needs Review

Supported transitions are validated server-side.

Architecture Principles

Principles use their own status model:

Draft → Proposed → Approved → Deprecated → Retired

A Proposed principle can also return to Draft.

Architecture Decisions

Architecture Decisions use ADR-style statuses:

  • Draft
  • Proposed
  • Accepted
  • Rejected
  • Superseded
  • Deprecated
  • Expired

OpenEA assigns decision identifiers such as ADR-0001. The display identifier is separate from the object's UUID.

An Accepted decision can supersede another decision through the governed supersedes relationship.

Reviews

Objects can have review frequencies of Monthly, Quarterly, Semiannual, or Annual. A Contributor, Architect, or Architecture Administrator can mark a record reviewed, enter notes, and specify the next review date.

If an explicit next date is not provided, OpenEA derives it from the review frequency.

The Reviews workspace lists non-archived records whose explicit Next Review Date is overdue. It also explains all applicable attention reasons without broadening that overdue-record scope.

Comments and audit history

Comments are collaboration records attached to an architecture object. They are not architecture objects and do not participate in the relationship graph.

Significant writes generate audit events containing actor, action, entity, time, source, and before/after state where applicable. PostgreSQL protects the audit-event table with an immutable-table trigger that rejects updates and deletes.

Archival and restoration

OpenEA uses soft archival instead of destructive deletion for architecture objects. Archiving sets the Record Status to Archived, records an archival timestamp, preserves audit history, and preserves existing relationships. Operational views exclude archived objects unless the user explicitly requests historical records.

Explore can search Archived or All records. The Relationships tab hides historical entries by default and exposes them through Show archived. Authorized Architects and Architecture Administrators can restore an archived object; preserved relationships return to current-state views automatically.