Decisions

The decision register lists the decisions ddx PMO has extracted from your project’s communications, and those recorded by closing a task. Each row is one decision, with its title, the decision itself, its state, and when it was decided. Click a row to expand its full relationship context.

A row marked From task was recorded when someone closed a task on the Tasks page and ticked Record in the Decision Log: its text is that task’s outcome note, word for word, and it carries the task’s clearance level and compartment. Reopening the task withdraws the decision — it is archived, marked Withdrawn, never deleted. A partner that can see the task reads it on its portal’s Decisions page — as the close wrote it (the task’s outcome note), never as you have edited the row here. The task leaves that page if you give its decision another status, archive it, supersede it or raise its clearance above the third-party ceiling; the outcome note stays on the task.

State is derived, not just stored

Every decision shows a state badge. This is the decision’s effective state. Some states are worked out from how the decision relates to others and whether it has been archived — not read straight from a status field. The states you’ll see:

State	What it means
current	The live decision.
proposed	Raised but not yet agreed.
rejected	Considered and turned down.
superseded	Replaced by a later decision.
duplicate	The same decision recorded more than once; folded under the kept copy.
archived	Archived.
retired	Archived as stale history (for example by an import sweep), which reads differently from an ordinary archive.
withdrawn	Archived because the task that recorded it was reopened; shown as Withdrawn.

superseded, duplicate, archived, and retired are derived — from resolved relations between decisions (the links built when ddx PMO works out that one decision replaces or repeats another) and from how a decision was archived. proposed and rejected are read from the decision’s status; if a decision is none of those, it reads as current. See Evidence & relationships for how the relation links are formed and reviewed.

Note

Because state is derived, a decision can read as current even when its stored status says something else. That’s deliberate: an earlier deduplication pass left some live decisions stamped with the wrong status, so the page trusts the resolved relations and the archive flag, and only falls back to the stored status for proposed and rejected.

Current vs all versions

The register opens on Current, showing the live head of each decision — nothing superseded, duplicated, or archived. When a decision has been revised, its older versions and any duplicates are grouped underneath — click a row to expand its history (oldest to newest), the duplicates folded in, and any decisions it contradicts or is related to.

Switch to All to list every version as its own row. In All you can also tick Show archived to include archived and retired decisions.

Relation badges on a row tell you at a glance how connected it is — for example “3 prior” (the older versions it supersedes), “2 duplicates”, a contradiction warning, or related decisions.

Adding decisions

Use Import to bring existing decisions in from pasted text or an uploaded .csv / .md file — handy when seeding a project that’s already underway. You preview the parsed rows and adjust the column mapping before committing. See Import your data.

Decisions are also recorded by closing a task: the close dialog asks whether the outcome reads as a decision and pre-ticks Record in the Decision Log; the closer decides. See Closing a task.