Governed hierarchy

This reference defines the canonical new-write topology for the Governed workflow. Use Governed workflow for the end-to-end operator journey and this page when verifying exact owners, paths, or stage transitions.

Governed is gate-qualified advanced work. It is available as a complete lifecycle only when a numbered root, full hierarchy, task implementation evidence, milestone reconciliation, read-only project review, explicit project-review persistence, and separate closeout can all be preserved.

Canonical new-write tree

.day-shift/planning/governed/<NN>-<slice-slug>/
├── slice-overview.md
├── phases/
│   └── <NN>-<phase-slug>/
│       ├── phase-overview.md
│       └── milestones/
│           └── <NN>-<milestone-slug>/
│               ├── milestone-overview.md
│               ├── reconciliation.md
│               └── tasks/
│                   └── <NN>-<task-slug>/
│                       ├── task-definition.md
│                       └── implementation-summary.md
├── decisions/
├── notes/
└── project-review.md

At the root, <NN> represents the registered specification order: values below 10 are zero-padded to two digits and larger values retain their full width. Phase, milestone, and task <NN> prefixes remain two-digit parent-local declared orders. The stable semantic ids remain independent of their display prefixes.

Canonical new writes never add .day-shift/planning/governed/<root>/overview.md and never insert .day-shift/planning/governed/<root>/slices/. Those shapes are legacy read or migration inputs only.

Artifact ownership

Artifact	Canonical owner	Evidence boundary
slice-overview.md	Governed work root	Specification binding, phase declarations, project rollup, terminal slice status
phase-overview.md	One ordered phase	Acceptance criteria, milestone declarations, scaffold projection, phase review handoff
milestone-overview.md	One ordered milestone	Task declarations, dependencies, target ownership, milestone validation and rollback
task-definition.md	One implementation agreement	Scope, targets, runtime delta, acceptance, validation, readiness authorization
implementation-summary.md	The paired task attempt	Baseline attribution, changed paths, validation records, decisions, exceptions, residual work, disposition and close
reconciliation.md	One milestone	Rollup of completed task summaries, criterion coverage, validation review, deviations and milestone verdict
project-review.md	Governed root review persistence	Explicit project disposition after read-only work review
lifecycle run evidence	The selected run	Indexed command results, receipts, gates, revisions, failures, and continuation evidence

Validation records and receipts belong to the lifecycle evidence of their artifact and attempt. They do not create sibling planning directories.

Creation commands

• work create --level governed previews or creates the numbered root from a canonical registered specification.
• slice new --spec-id <id> is the layer-specific registered-context alternative for the same root topology.
• phase new --slice-overview <path> --full-set creates only phases declared by the selected slice overview.
• milestone new --phase-overview <path> --full-set --phase-review-result <path> creates only declared milestones after current phase authoring readiness.
• task new --milestone-overview <path> --full-set creates only tasks declared by the active milestone.

The parent contract is authoritative. --full-set expands its complete declared set atomically; it is not permission to infer children. Complete and review one active milestone before delegating a later milestone.

Task evidence commands

The task spine is ordered and revision-bound:

1. link materialize --dry-run --artifact <task-definition.md> validates links and previews safe body-only materialization.
2. task readiness-review is read-only and emits the current readiness identity.
3. task readiness-authorize --review-result <current-review.json> is the separate authorization write.
4. task attempt-open establishes the stable attempt identity.
5. task baseline captures declared target hashes before implementation writes.
6. task validation-record executes or records declared validation under the current attempt.
7. implementation-summary build refreshes the canonical paired evidence artifact.
8. task implementation-complete freezes current implementation evidence.
9. implementation-summary review is read-only.
10. task disposition records an explicit accepted, rejected, or revision decision.
11. A fresh review verifies that disposition.
12. task close closes the task pair against current accepted review evidence.

A baseline-only attempt whose authorization became stale after an explicitly authorized contract revision may be eligible for task attempt-supersede. Eligibility fails closed when a target changed or validation, deviation, waiver, blocker, disposition, review, cancellation, closeout, or implementation evidence exists.

Milestone and project gates

reconciliation build derives the milestone artifact from completed task summaries. The body still requires concrete criterion, validation, deviation, residual-work, and verdict evidence. reconciliation review reads that contract; it does not accept or repair it. The supported reconciliation update records metadata only after the evidence is complete.

At the root, work status and work review are read-only. work project-review create is the explicit persistence boundary for the selected disposition. work close --project-review <path> is a later separate write that verifies the accepted persisted review and updates only slice-overview.md.

Reachability and audience boundary

Governed detail is intentionally reachable through the advanced workflow index, this reference, the core command reference, architecture-backed navigation, and recovery guidance. It is not inserted into Basic setup or ordinary Structured first-use steps. A reader who only needs a direct task or a numbered Structured overview should not have to traverse the hierarchy above.

Compatibility rules

• Read and migrate supported legacy layouts through the shipped inspection and migration commands.
• Do not hand-create a missing canonical parent, rename an ordered root, or move task evidence between levels.
• Do not treat agent autonomy or evidence profile as a workflow-level selector.
• Do not treat read-only review output as authorization, persistence, acceptance, metadata synchronization, or closeout.
• Preserve historical summaries, baselines, receipts, review records, and reconciliation evidence when work is resumed or revised.

See Core workflow commands for descriptor-grounded command posture and Resume, trace, archive, and release handoff for stale evidence and recovery boundaries.