Decision Lifecycle

A DecisionOps record moves through a clear lifecycle so teams can tell which choices are still being formed and which ones should guide active work. In practice, the lifecycle is simple: create a draft, review and refine it, accept it when the team is ready to rely on it, and supersede it when a newer decision replaces it.

Statuses

• proposed means the decision is still being discussed or refined
• accepted means the team has approved it and expects it to guide work
• deprecated means the decision is no longer preferred
• superseded means a newer decision has explicitly replaced it

Versions, Revisions, And Suggestions

DecisionOps keeps more than the latest text. Each decision also carries version history and revision history so you can understand how it changed over time. Version history is the append-only record of the decision as it evolved. Revision history summarizes field-level changes for important create, update, approve, and supersede events.

Suggestion panels add another layer. They do not change the record automatically. Instead, they point out potential document improvements or operational follow-up work after the decision has been saved and indexed.

Web And IDE Mapping

In the web app, users usually create or edit decisions on /decisions/new, /decisions/:decisionId, and /decisions/:decisionId/edit. In the IDE path, the equivalent flow is search, create draft, validate, then publish through MCP. Both paths end in the same decision record and the same lifecycle states.

When To Supersede

Supersede a decision when the team has made a new choice that should replace an earlier accepted one. Do not use supersede for ordinary cleanup edits or typo fixes. Those belong in normal revision history. Supersede is the signal that historical guidance has changed.