state-hub/policies/work-item-dor.md

Definition of Ready (DoR)

Policy key: work-item-dor
applies_to: task, workplan (separate sections below)
Assessment outcomes: unassessed | DoR-Ok | DoR-Failed
Does not apply to: intake (use DoC), decision, engagement (no DoR yet)

DoR is the quality policy for implementation-readiness of delivery records. “Work-item” in the policy name means the delivery side of the work-record framework (executable units and their plans). In body text:

• task = unit work-item
• workplan = structure (collection/plan over tasks), not “a large task”

Lifecycle status is independent of DoR assessment:

• Workplan status=ready is a process claim; DoR-Ok means this checklist passed when last assessed.
• A workplan may be ready or active without DoR-Ok (quality debt).
• A task may enter progress without DoR-Ok; that is allowed but discouraged for non-trivial work.

Related:

• Comprehension (discovery): policies/intake-doc.md (DoC)
• Completion: policies/workstream-dod.md (DoD; exit companion)
• Model: docs/work-record-quality-gates.md
• Lifecycle: dashboard/src/docs/workstream-lifecycle.md

---

Shared criteria (task and workplan)

For DoR-Ok, the following always hold (kind sections add specifics):

• Outcome or done-condition — what “good enough to stop” looks like, or an explicit pointer to DoD / acceptance criteria.
• Scope in / out — what is included and what is explicitly out of scope (or “no material out-of-scope items”).
• Owning repo — delivery repo is known and matches ADR-001 anchoring (or the task’s parent workplan repo).
• Who executes — owner/assignee or named agent role is clear enough to start.
• Dependencies / blockers — known dependencies listed, or an explicit “none.” Unresolved hard blockers mean DoR-Failed until cleared or redesigned.
• Verification signal — how we will know it worked (test, check, manual verification note, or “N/A: pure docs” with reason).
• Lane / autonomy — lane is set or inherited where the record supports it; red/yellow work has human expectation stated if required by autonomy policy.

---

Section: task (kind: task)

Additional DoR-Ok criteria for a task:

• Parent workplan — task is attached to a workplan (or today’s ADHOC workplan) so execution context is not free-floating.
• Actionable title — describes a completable unit, not a multi-week program (programs belong in a workplan with multiple tasks).
• Status intent — starting progress is justified (not blocked on missing input that should keep the task in wait).

Tasks that are pure residual cleanup may be thin; still state done-condition and verification, even if one line each.

---

Section: workplan (kind: workplan)

Additional DoR-Ok criteria for a workplan:

• Goal — one paragraph (or equivalent) for why this plan exists.
• Task decomposition — open work is broken into tasks, or an explicit note that the first task is “decompose further” with a bound.
• Review vs execute — if status=ready, review metadata is present when the plan claims repo-state review (reviewed_at / reviewed_against_commit or equivalent narrative). Missing review metadata ⇒ prefer DoR-Failed for a ready claim, or leave unassessed.
• Structure role respected — the plan does not substitute for missing DoC on a vague external spark; if the plan was promoted from intake, origin link is present when available (origin: intake:…).

Workplan DoR-Ok does not require all child tasks to be DoR-Ok; it requires the plan itself to be ready to run as a structure. Child tasks should be assessed when they are about to be executed.

---

Outside-originated profile

When the work-item or plan came from outside structural knowledge (promoted intake with external origin, third-party response work, external demand):

• Origin link — origin / origin_ref or intake id / progress note ties back to the discovery record.
• Boundary decision recorded — ecosystem vs true third-party vs external demand into us.
• Our work only — scope describes our deliverable (patch, adapter, doc, decision), not control of an external backlog.
• External reference — issue/PR/URL or “none yet” with reason, when third-party interaction is in scope.
• Residual unknowns — still-open external uncertainties listed; none that would make the first implementation step pure guesswork.

---

Relationship to DoD and lifecycle

Gate	When	Policy
DoC	Discovery understood	intake-doc
DoR	Ready to implement	this file
DoD	Quality-complete when finishing	workstream-dod

Finishing a workplan (status=finished) without DoD-Ok is allowed; treat as quality debt. Prefer DoR-Ok before heavy implementation; prefer DoD-Ok before calling the outcome high-quality complete.

---

Assessment practice (convention)

• Assessors: workplan owner, executing agent, or human operator.
• Record DoR-Ok or DoR-Failed with date and failed criteria if any.
• Re-assess after major scope change; stale DoR-Ok after large context shift should be treated as unassessed or re-checked.
• Enforcement is convention only (STATE-WP-0076); no API hard-block.