tegwick
3008d9e2f0
Add Intake Definition of Comprehension and work-item Definition of Ready as hub policies with dashboard edit surfaces, document the Definition family and DoX-Ok/Failed badge convention, and mark STATE-WP-0076 finished.
4 KiB
Intake Definition of Comprehension (DoC)
applies_to: intake
Assessment outcomes: unassessed | DoC-Ok | DoC-Failed
Does not apply to: workplan, task, decision, engagement, register-entry
An intake is a discovery work record (a find / spark). DoC is the quality policy for “we understand this demand or signal well enough to route or promote.” It is not implementation design and not Definition of Ready.
Lifecycle status (open / vetted / routed / closed) is independent of DoC
assessment. Prefer: treat DoC-Ok as the quality bar before confident
vetted → routed → promote. Process may still move without DoC-Ok; that is
quality debt, not forbidden.
Related:
- Work-record umbrella:
dashboard/src/docs/work-records.md - Quality model:
docs/work-record-quality-gates.md - Delivery readiness:
policies/work-item-dor.md(DoR) - Intake reference:
dashboard/src/docs/intakes.md
Core checklist (all intakes)
An intake may be assessed DoC-Ok when all of the following hold:
- Signal stated — title (and description if non-obvious) says what was observed, asked, or found, not a vague “look into X.”
- Why it matters — at least one sentence of consequence if ignored (risk, opportunity, blocker, cost of delay).
- Known unknowns listed — what we do not know yet (owner, repo, scope, feasibility, counterparty intent, …), or an explicit “no material unknowns.”
- Provisional ownership — at least one of:
topic_id/workplan_id/repo_id/ domain hypothesis — or an explicit statement that ownership is still unknown and who will decide. - Next action — one of: route, promote (to which kind if known), decline, absorb, or “needs more discovery” with a named follow-up.
- Not a premature workplan — the intake does not pretend to be a full task breakdown, DoD, or implementation design (those belong after promotion under DoR).
If any core item fails after assessment, record DoC-Failed and note the gap.
Outside-originated profile
Use this section when the signal is external or structurally sparse:
external demand into the fleet, true third-party/upstream, mail/founder note
without repo context, or origin / tags such as external-demand /
third-party.
Additional criteria for DoC-Ok (on top of the core checklist):
- Source of signal —
originand, when available,origin_ref(or equivalent note) identify where the demand came from. - Boundary named — one of: ecosystem (another fleet repo), true third-party, external demand into us, or unknown with a plan to classify.
- No invented foreign structure — we do not schedule their backlog as our workplan graph; we only record our understanding and our possible response.
- Enough context to avoid premature promote — promoting to task/workplan would not require guessing the owning repo or outcome shape; if it would, keep the intake open/vetted and list the missing facts under known unknowns.
- Counterparty or channel (when third-party or external) — who/what is outside, even if only “unknown maintainer of package X.”
Ecosystem-only signals (work for another registered repo) usually need routing clarity, not the full third-party bar; still record boundary as ecosystem.
Assessment practice (convention)
- Assessors: owning agent, domain owner, or human operator.
- Record outcome in a note, progress event, or later frontmatter/badge field:
DoC-OkorDoC-Failedplus date and short reason if failed. - Re-assess after material new information; a prior DoC-Ok can become Failed or be superseded by a new Ok.
- DoC-Ok does not authorize implementation — only comprehension for routing/promotion. Delivery readiness is DoR on the resulting task or workplan.
Explicit non-requirements
DoC does not require:
- Task breakdown, estimates, or acceptance tests
- Full solution design
- DoR or DoD criteria
- A workplan file to already exist