TASK, BUG and PROB: three sibling Work Types
TASK is known, defined work. BUG is behavior that violates an established requirement or expectation. PROB is uncertainty indicating that the current requirement, plan, architecture, assignment or implementation may be insufficient. They are sibling Work Types that classify actionable work, not extra Core phases.
This classification supports Controlled Iteration in AI Architect Mastery's AI Driven Development Methodology. A Work Item carries the actual assignment, context and verification; its type describes the nature of the work, not its place in a second workflow.
How to classify the work
- TASK: the work is defined
- The team knows what should be done and can delegate a bounded result. See the canonical TASK definition for its relationship to an approved PLAN.
- BUG: an expectation is violated
- Record the established expectation and observed failure. Correct it within scope and prove the fix.
- PROB: the current model may be insufficient
- Record the uncertainty and evidence. The human decides whether the issue belongs in PRD, PLAN, TASK or a correction within implementation.
Why the distinction matters
Calling every problem a bug encourages patching undefined behavior. Calling every failure uncertainty avoids correcting a clear violation. Classify against the established intent and evidence, not just the severity or the folder holding the record.
Constructed examples from one export feature
- TASK: implement the approved owner-only export rule.
- BUG: a non-owner receives data despite that rule.
- PROB: ownership of shared records was never defined, so the correct behavior cannot yet be established.
Classification is not automatic routing
A BUG may reveal a related PROB. Record both relationships rather than erasing the established failure. The Human Architect chooses what to correct and where to return; AAM does not assume an automatic routing engine.