Work Products and Work Items
A Work Product is an artifact produced through the workflow. A Work Item is an actionable Work Product: a bounded unit of development work that carries scope, context, expected outputs and verification. It is broader than a coding task alone.
This conceptual reference clarifies artifacts used in AI Architect Mastery's AI Driven Development Methodology. “Work Model” is a collective term for Work Products, Work Items and Work Types, not another workflow or a software product. PRD → PLAN → TASK → IMPLEMENTATION remains the canonical workflow.
Artifact, action and classification
A PRD or PLAN is a Work Product. An assigned investigation or correction is actionable and therefore a Work Item. Its Work Type describes the situation: TASK for known work, BUG for an established failure or PROB for uncertainty.
These types are siblings. BUG and PROB are not additional mandatory phases appended to PRD → PLAN → TASK → IMPLEMENTATION.
How to define an actionable item
- Link the approved intent or the finding that requires attention.
- State the question or change within scope and the expected output.
- Provide relevant context and the responsible role.
- Set permissions, autonomy boundaries and stop conditions.
- Specify verification and the human decision the output should support.
Constructed example: investigate before changing code
Exports behave inconsistently for shared records, but the intended ownership policy is unclear. An investigation can be a PROB Work Item whose output is evidence and a return recommendation. It does not authorize the agent to invent a policy or rewrite the export path.
Storage does not determine semantics
A practical tasks/ directory may contain TASK, BUG and PROB records. The folder name does not turn every item into known work. The actionable boundary and classification should remain explicit wherever the artifact is stored.