Status: open/proposed
- The SDLC data model is a five-layer entity ontology — Product / Architecture / SDLC / Work /
Planning-meta — categorized in D-0003-datamodel-categorization.
- Every artifact with a schema that validates is an entity; the definition contract is
S-0005-entity-definition-contract and the definition architecture is
D-0004-entity-definition-architecture.
- This document carries the authoritative roster below: every entity type, its status, prefix,
and purpose. The filename shape itself is fixed by D-0002-entity-identifier-shape.
- Eleven entities are active today, all on the S0005 surface — Decision, Standard, Principle,
Term, Reference, Milestone, Task, Backlog, Capability, Driver, Product; the rest are planned or
deferred (Epic is retired into Task
parent_key).
- This is the roster and the target picture — not a re-derivation of the layer rationale (that lives
in D-0003-datamodel-categorization).
The single home for SDLC’s target data model: what entity types
exist, which are live, which are planned, and the shape each takes.
The target data model is the layered entity ontology catalogued in The roster below. Entity
categorization is decided in D-0003-datamodel-categorization and the definition architecture
(how each entity type is specified) in D-0004-entity-definition-architecture; this document is
the authoritative roster — the answer to “what entity types are in scope, and what is each one’s
status.” The deeper data-model work grows out of it: the Product→SDLC why→what→verify chain
(Product / Driver / Goal / Requirement / AcceptanceCriterion) is designed in
D-7F2M-why-what-verify-chain — chain shortened to
Task → Requirement → Capability → Product; Driver supplemental; Goal, Requirement, and
AcceptanceCriterion deferred.
| Status | Meaning |
|---|
active | Schema + definition surface present; in use today. |
planned | Scheduled for a later milestone; design direction set. |
deferred | Considered, value clear, but not on the near roadmap. |
discarded | Considered and rejected; rationale recorded. |
Activation rule (D-3PDM-cross-project-data-model-adoption): promoting an
entity planned → active requires the enacting milestone to name at least one producing
op/skill and at least one consuming projection/op. The same bar applies to new optional
fields on existing entities. Rationale: in both predecessor systems, schema without a workflow
that writes and reads it accumulated zero instances (evidence F3 in
D-3PDM-cross-project-data-model-adoption).
Statuses below are verified against the code (plugin/lib/model/entities/). The Prefix
column is each type’s abbreviation; the full filename shape (AA-NNNN-<optional-slug>) and the
per-type numbering style (incrementing vs base-36) are fixed by
D-0002-entity-identifier-shape. Existing ids are grandfathered.
| Entity | Prefix | Status | Purpose |
|---|
| Decision (ADR) | D | active | Project-level design choice: context, options, rationale, consequences. |
| Standard | S | active | Prescriptive, scoped rule; carries applies_to.paths, may name a validator. |
| Principle | P | active | Broad value driving design judgment; upstream of Standards. |
| Term | TM | active | One vocabulary entry; the generated glossary (docs/glossary.md) is assembled from Term instances (D-B4CA-term-entity-and-generated-glossary). |
| Reference | RF | active | One curated external source (documentation, research, artifact); optional url; the generated roster (docs/references.md) is assembled from Reference instances (D-0009-reference-entity-and-docs-appendix). |
| Entity | Prefix | Status | Purpose |
|---|
| Milestone | M | active | Release-shaped grouping with target date and success criteria. |
| Task | T | active | Atomic unit of executable work, base-36 ids. Carries parent_key; a Task with children is an epic (derived, not a separate type) — an organizational rollup that orchestration skips and the implementation-ready contract exempts (the contract governs leaves; a rollup states rollup criteria instead). |
| Epic | E | discarded | Retired as a distinct type — epic-ness is derived from a Task with children (parent_key), not a separate entity. The legacy instances E0001/E0002 are converted to parent Tasks and the epic schema and skill are removed. |
| Backlog | B | active | Stray idea captured before triage, base-36 ids. Carries an optional, non-binding likely_type hint (schema v2) — the triager’s guess at what the item becomes; never binds the promotion outcome. |
| Agent | AG | deferred | Actor performing work (human / AI / team); low marginal value over a string tag in markdown. |
| WorkSession | W | deferred | Time-bounded period of work; git history covers most of the use case. |
| Entity | Prefix | Status | Purpose |
|---|
| Capability | C | active | Unit of functionality; self-nests via parent_key — the only stored direction (children derived; contains dropped in schema v2). v2 (D-3PDM-cross-project-data-model-adoption amendment): optional 11-grain structural kind + audience (user | system) + locations[] five-form code anchors. Instance kind grading is follow-up triage (T-KDZ9-capability-structural-kind-regrade). |
| Constraint | CO | deferred | Non-negotiable boundary — donor-proven shape (D-3PDM-cross-project-data-model-adoption). Deferred 2026-07-17: its territory splits between Requirement (constraint-derived, deferred) and Standard (machine-checkable rules, active), and no concrete consumer materialized. Revisit only with a consumer neither of those covers. |
| Relation | RL | planned | Directional dependency-intent edge between Capabilities — relation_type: depends_on, the allowed direction of dependency (trimmed 2026-07-17, D-3PDM-cross-project-data-model-adoption P5 amendment: code-fact edge types are derived from the codebase, never stored); base-36 ids. The light half of the Relation/Contract split; ships with its first consuming projection per the activation rule. |
| Contract | CT | deferred | Rich agreement-edge between Capabilities (behavioral / environmental / prose); the lightweight typed-edge slice is Relation’s. Awaits modeling pressure — reconfirmed by donor evidence (3 instances, 1 broken; D-3PDM-cross-project-data-model-adoption). |
| Evidence | EV | deferred | Polymorphic per-claim support record; inline citations cover it until queryable storage justifies a type. The curated external-source-catalog slice of its territory is Reference’s (D-0009-reference-entity-and-docs-appendix). |
| Entity | Prefix | Status | Purpose |
|---|
| Product | PR | active | A product this project builds. Multi-instance (the project hosts several — SDLC plugin, OSS libraries, the harness); first instance is SDLC (PR-0001). Scopes the Drivers/Goals beneath it. |
| Driver | DR | active | A motivating driver — kind: pain-point / use-case / opportunity. De-chained 2026-07-17 (D-7F2M-why-what-verify-chain amendment): a standalone, supplemental why-note that products/decisions/capabilities wikilink freely — not a required traceability hop. Keeps its stored product: ref. |
| Goal | G | deferred | Desired outcome addressing a Driver; carries success_metrics. Deferred 2026-07-17 before scaffolding (zero instances): its success-metrics territory is partly Milestone success criteria today, and the why-chain’s shape is under review — revisit when Requirement activates and forces the up-target question. |
| Entity | Prefix | Status | Purpose |
|---|
| Requirement | R | deferred | What the system must do (functional / non-functional / constraint-derived / user-story). Deferred 2026-07-19 before scaffolding: per-task acceptance criteria carry the verify burden today, and no consumer reads a declared Requirement — revisit when one materializes. Attachment leaning recorded in D-7F2M-why-what-verify-chain (scope, not parentage). |
| AcceptanceCriterion | AC | deferred | Atomic testable unit (prose or BDD). Defers with Requirement — it exists only to prove one. |
| Specification | — | deferred | Behavioral elaboration of a Capability; currently collapsed into the Capability body. Resurrects if a Capability needs multiple independent specs. |
- Specification’s fate. Keep collapsed into the Capability body, or resurrect as
planned if a
Capability ends up with multiple distinct specs needing independent lifecycle. Re-check when
Requirement / AcceptanceCriterion land; stays deferred in the roster until then.
- Epic is derived, not a type. Epic folds into Task self-nesting: a Task with children is an
epic, derived from
parent_key, not a separate type. A parent Task is an
organizational rollup, not directly executable: orchestration dispatches leaf tasks (no
children) and never the parent, and the parent’s completion derives from its children (all
children closed ⇒ parent eligible to close). This leaf-only dispatch is interim scaffolding,
not the target — the intended end-state is nested orchestration traversal (a larger task
decomposed by an agent into child tasks, then traversed), at which point parents are walked, not
skipped. The orchestration and kind selection rules are recorded in
D-VSLI-distributed-work-runner-architecture. Milestone stays distinct — a release narrative
with a target date and success criteria, structurally unlike a parent task.
- Backlog promotion →
likely_type hint. Backlog carries an optional, non-binding
likely_type field (schema v2) recording the triager’s guess at what the item becomes (Task /
Milestone / Goal / Driver / …). A free entity-type slug, not an enum — the guess may name a type
that is deferred or not yet active. It does not constrain the triage outcome.
← Back to Decisions