47 KiB
Executable File
InfoTechCanon Task Model
Short Name: ITC-TASK
Document Status: Seed Standard Release Candidate 1
Version: RC1-seed
Date: 2026-05-22
Repository Context: info-tech-canon
Document Type: InfoTechCanon Domain Standard
Intended Audience: Product owners, project managers, platform builders, agentic tooling designers, developers, service owners, governance designers, task-system maintainers, issue-tracker administrators, personal-organization system designers, knowledge-system builders, standards authors, and AI agents.
1. Purpose
The InfoTechCanon Task Model defines a canonical seed model for representing work, possible work, committed work, actionable steps, issues, requests, incidents, experiments, reviews, approvals, remediation, progress, blockers, dependencies, outcomes, and execution state.
It exists to support interoperable information-processing systems where humans and agents need to coordinate work without forcing every workflow into the same tool, methodology, board, or project-management doctrine.
This standard provides:
- a canonical vocabulary for work items,
- a distinction between options, tasks, actions, steps, moves, and experiments,
- a commitment model,
- a readiness and actionability model,
- a decomposition and dependency model,
- a workflow state model,
- interfaces to organization, governance, landscape, tagging, DevSecOps, access-control, and service models,
- mapping hooks to external tools and methodologies,
- seed patterns for practical task modeling,
- profile hooks for concrete implementation contexts,
- and retrieval-friendly structure for humans, agents, and markdown-based infospaces.
2. Position in InfoTechCanon
The Task Model is a domain standard within InfoTechCanon.
It should become the canonical owner of work semantics that should not be hidden inside tagging, project management tools, issue trackers, or governance models.
InfoTechCanon
├── InfoTechCanonCore
├── InfoTechCanonLandscapeModel
├── InfoTechCanonOrganizationModel
├── InfoTechCanonGovernanceModel
├── InfoTechCanonTaskModel <-- this standard
├── InfoTechCanonTaggingStandard <-- should import task concepts
├── InfoTechCanonAccessControlModel
├── InfoTechCanonSecurityModel
├── InfoTechCanonDevSecOpsModel
├── InfoTechCanonPatternLanguage
└── Application Profiles
The foundational dependency chain is:
Landscape = what exists and what work may apply to.
Organization = who acts, owns, is assigned, and is accountable.
Governance = which rules, decisions, risks, and obligations create or constrain work.
Task = what work exists, whether it is committed, and how it progresses.
Tagging = how work and other entities are classified and filtered.
3. Boundary with Adjacent Standards
3.1 Boundary with Organization
The Organization Model owns:
Actor
Person
Agent
Team
Role
Membership
Assignment
Responsibility
Authority
Accountability
Capacity
Availability
The Task Model owns:
WorkItem
Option
Task
Action
NextAction
Step
Move
Experiment
Issue
Request
BacklogItem
Blocker
Dependency
Commitment
TaskState
WorkOutcome
AcceptanceCriteria
DefinitionOfDone
Boundary rule:
Organization defines who can act and carry responsibility.
Task defines what work exists and how it becomes actionable, committed, executed, waiting, completed, or canceled.
3.2 Boundary with Governance
The Governance Model owns:
Policy
Rule
Decision
Approval
Review
Risk
Control
Exception
Evidence
Obligation
Requirement
The Task Model may reference these when work is created by or constrained by governance.
Examples:
Obligation creates Task
Finding creates RemediationTask
ApprovalTask satisfies GovernanceReview
ExceptionRequest is governed_by Policy
RiskTreatment creates Task
3.3 Boundary with Landscape
The Landscape Model owns services, software systems, artifacts, deployments, runtime resources, network entities, data objects, and observability signals.
The Task Model can attach work to those entities.
Examples:
Task affects ApplicationService
IncidentTask affects RuntimeResource
ChangeTask changes DeploymentRecord
RemediationTask fixes Finding
Experiment explores ArchitectureDecision
3.4 Boundary with Tagging
The Tagging Standard should own tag syntax, tag categories, tag governance, tag composition, and tag validation.
The Task Model owns the semantics of work items that tags may classify.
Boundary rule:
Task status, commitment, actionability, dependency, and outcome semantics belong here.
Tagging may encode or reference them, but should not define them.
4. Research Basis and External Alignment
This seed standard draws on multiple bodies of work knowledge.
4.1 Project Management and Work Breakdown Structures
Project-management practice distinguishes deliverables, work packages, activities, schedules, dependencies, responsibilities, milestones, and acceptance. Work Breakdown Structures emphasize decomposition of total project scope into manageable parts, while allowing context-specific levels of detail.
4.2 Agile, Scrum, and Product Backlogs
Scrum distinguishes product backlog, sprint backlog, sprint goal, product backlog items, increments, and commitments. The Task Model should map to these concepts without becoming Scrum-specific.
4.3 Kanban and Flow-Based Work Management
Kanban emphasizes visualizing work, managing flow, limiting work in progress, making policies explicit, and improving collaboratively. The Task Model should support flow states, WIP, blockers, pull readiness, and classes of service without requiring a board.
4.4 Getting Things Done and Personal Work Systems
GTD-style personal organization emphasizes capture, clarification, projects, contexts, and next actions. The Task Model uses the distinction between not-yet-actionable material, options, tasks, and next actions.
4.5 IT Service Management
ITSM practice distinguishes incidents, service requests, problems, changes, tasks, approvals, and remediation. The Task Model should support these as task types or profiles while leaving service definitions to Landscape and governance decisions to Governance.
4.6 Software Issue Tracking
Tools such as GitHub Issues, Jira, Azure DevOps, and GitLab provide practical work item types: issue, bug, story, task, epic, subtask, milestone, label, project, dependency, pull request, and status. These are mapping and profile targets, not the internal foundation.
4.7 Complex Work and Adaptive Action
Some work is predictable and decomposable; other work is exploratory, uncertain, emergent, and path-dependent. The Task Model should distinguish direct execution from exploration and experimentation.
5. Seed Standard Design Stance
This standard is a seed standard, not a final complete theory of work.
It shall:
- define enough canonical concepts to support practical work coordination,
- distinguish possible work from committed work,
- distinguish planned progress from actual action,
- support human and agent work,
- support personal, team, project, product, operational, service, and governance work,
- support predictable and exploratory work,
- avoid being captured by any one tool such as Jira, GitHub Issues, or Azure DevOps,
- expose mapping hooks to external methodologies and products,
- provide profile hooks for implementation contexts,
- remain markdown-first and agent-retrievable,
- and support future assimilation of task, project, issue, and workflow models.
6. Scope
6.1 In Scope
This standard covers canonical representation of:
- work items,
- options,
- tasks,
- actions,
- next actions,
- steps,
- moves,
- experiments,
- explorations,
- issues,
- requests,
- incidents as work items,
- problem-investigation work,
- change work,
- remediation work,
- review and approval work,
- backlog items,
- stories,
- bugs,
- epics as mapped/profiled concepts,
- decomposition,
- dependencies,
- blockers,
- prerequisites,
- commitment,
- due dates,
- readiness,
- actionability,
- reachability,
- effort,
- estimates,
- progress,
- workflow state,
- priority,
- urgency,
- importance,
- value,
- risk,
- outcome,
- acceptance criteria,
- definition of done,
- assignment references,
- and task evidence.
6.2 Out of Scope
This standard does not fully define:
- all project management methodology,
- all agile or Scrum practice,
- all Kanban practice,
- all ITIL practice,
- all personal productivity practice,
- detailed scheduling algorithms,
- portfolio management,
- resource management,
- financial project accounting,
- HR performance management,
- detailed access control,
- or all tag syntax and tag governance.
Those may be mapped, assimilated, profiled, or handled by adjacent standards.
7. Normative Language
The following terms are used normatively:
- SHALL indicates a mandatory rule for conformance.
- SHOULD indicates a recommended practice.
- MAY indicates an optional capability.
- MUST NOT indicates a prohibited practice.
- SEED marks a concept defined provisionally here but open to later refinement.
- EXTRACT marks a concept that may later move to a more specialized standard.
8. Core Principles
8.1 Work Is Broader Than Task
A task is a committed kind of work item.
The Task Model SHALL distinguish general work items from tasks.
8.2 Option Is Not Task
An option is possible work without commitment.
A task is committed work with an expectation of action, outcome, or consequence.
8.3 Action Is Not Task
A task represents intended or committed work.
An action is the actual doing or executable unit of progress.
8.4 Next Action Matters
When a work item is not directly executable, the model SHOULD support extraction of a next action.
8.5 Commitment Is First-Class
Commitment SHOULD be explicit.
A work item may be waiting, ready to do, in progress, done, or canceled while its commitment remains explicit.
8.6 Actionability and Reachability Are Distinct
A work item may be actionable in principle but not reachable because no actor with sufficient skill, willingness, authority, tools, or time is available.
8.7 Decomposition Is Contextual
Work may be decomposed into smaller work items, but decomposition depth is context-dependent.
8.8 Workflow State Is Not Semantic Type
A bug, story, incident, or request is a type of work item.
WAIT, TODO, PROG, DONE, and CNCL are states.
The model MUST NOT confuse work type with workflow state.
8.9 External Tools Are Mapped, Not Obeyed
The Task Model MAY map to GitHub Issues, Jira, Azure DevOps, GitLab, Scrum, Kanban, ITIL, PMBOK, GTD, or similar systems.
It MUST NOT subordinate its internal semantics to any single tool or methodology.
9. Canonical Seed Metadata
Every task artifact SHOULD support structured metadata.
Recommended front matter:
---
id: itc-task:Task
type: concept
standard: InfoTechCanonTaskModel
standard_version: RC1-seed
status: candidate
canonical_owner: InfoTechCanonTaskModel
preferred_label: Task
related:
- itc-task:WorkItem
- itc-task:Option
- itc-task:Action
- itc-task:Commitment
mappings:
- itc-map:task-to-github-issue
- itc-map:task-to-jira-task
---
Recommended artifact statuses:
idea
draft
candidate
release-candidate
adopted
stable
deprecated
retired
Recommended concept statuses:
proposed
experimental
candidate
canonical
deprecated
retired
10. Root Task Taxonomy
TaskEntity
├── WorkEntity
│ ├── WorkItem
│ ├── Option
│ ├── Task
│ ├── Action
│ ├── NextAction
│ ├── Step
│ ├── Move
│ ├── Exploration
│ └── Experiment
├── WorkTypeEntity
│ ├── Request
│ ├── Issue
│ ├── Bug
│ ├── Story
│ ├── Feature
│ ├── Epic
│ ├── IncidentTask
│ ├── ProblemTask
│ ├── ChangeTask
│ ├── ReviewTask
│ ├── ApprovalTask
│ ├── RemediationTask
│ └── DecisionTask
├── WorkStructureEntity
│ ├── Backlog
│ ├── WorkPackage
│ ├── Milestone
│ ├── Sprint
│ ├── Iteration
│ ├── Project
│ ├── ProgramReference
│ └── PortfolioReference
├── WorkRelationEntity
│ ├── Dependency
│ ├── Blocker
│ ├── Prerequisite
│ ├── ParentChildRelation
│ ├── DuplicateRelation
│ ├── RelatedWorkRelation
│ └── FollowUpRelation
├── CommitmentEntity
│ ├── Commitment
│ ├── AssignmentReference
│ ├── DueDate
│ ├── Deadline
│ ├── Promise
│ ├── Escalation
│ └── WaitingFor
├── FlowEntity
│ ├── Workflow
│ ├── WorkflowState
│ ├── Transition
│ ├── WIPLimit
│ ├── Queue
│ ├── PullSignal
│ └── ThroughputMeasure
├── EvaluationEntity
│ ├── Priority
│ ├── Urgency
│ ├── Importance
│ ├── Value
│ ├── Risk
│ ├── EffortEstimate
│ ├── CostEstimate
│ ├── Confidence
│ └── Complexity
└── CompletionEntity
├── Outcome
├── Deliverable
├── AcceptanceCriteria
├── DefinitionOfReady
├── DefinitionOfDone
├── CompletionEvidence
└── Result
11. Core Concepts
11.1 TaskEntity
A TaskEntity is any identifiable concept used to represent work, possible work, committed work, actual action, flow, progress, outcome, or work-related relationship.
Recommended attributes:
id:
entity_type:
canonical_name:
display_name:
lifecycle_state:
source_system:
created_at:
updated_at:
Optional attributes:
owner:
assignee:
requester:
accountable_actor:
governance_scope:
affected_landscape_entity:
source_confidence:
valid_from:
valid_to:
tags:
external_references:
11.2 WorkItem
A WorkItem is the root concept for an identifiable unit of possible, planned, committed, or actual work.
A work item may represent:
idea
option
task
issue
request
bug
story
incident
change
review
approval
experiment
remediation
Canonical rule:
All tasks are work items, but not all work items are tasks.
11.3 Option
An Option is possible intended work without commitment.
An option may be captured because it might become useful, valuable, necessary, or interesting.
Examples:
try a new library
explore a business model
write an article
refactor a module someday
investigate a potential standard
Canonical rule:
An option SHOULD NOT be treated as overdue merely because it exists.
11.4 Task
A Task is a committed work item with an expectation of action, outcome, responsibility, or consequence.
A task may be self-committed, assigned, delegated, required by governance, requested by another actor, or created by a system.
A task SHOULD have:
description
commitment state
responsible or assigned actor reference
desired outcome or acceptance criteria
status
11.5 Action
An Action is the actual doing of work.
Actions may be recorded as events, steps, or evidence of progress.
Examples:
send email
run script
call customer
deploy artifact
review pull request
write standard section
11.6 NextAction
A NextAction is the next concrete action that can move a work item forward.
A next action SHOULD be:
clear
specific
physically or digitally executable
small enough to start
linked to a context or actor
Canonical rule:
A work item that is not actionable SHOULD be clarified until a next action can be identified, or reclassified as an option, exploration, or blocked item.
11.7 Step
A Step is a planned unit of progress in a relatively clear or decomposable path.
Steps are useful when the problem is sufficiently understood.
11.8 Move
A Move is an action or step taken in a complex, uncertain, or adaptive context where progress changes the situation and may reveal new options.
Moves are useful when planning cannot fully determine the path.
11.9 Exploration
An Exploration is a work item whose primary purpose is to reduce uncertainty, discover options, clarify a problem, or understand a domain.
Exploration may produce:
knowledge
questions
options
experiments
tasks
decisions
11.10 Experiment
An Experiment is a structured action intended to learn from a controlled or bounded intervention.
Recommended attributes:
hypothesis:
expected_signal:
safe_to_fail:
timebox:
success_indicator:
learning_result:
11.11 Request
A Request is a work item initiated by an actor asking another actor, team, service, or system to do something.
Requests may become tasks, options, tickets, service requests, change requests, or rejected items.
11.12 Issue
An Issue is a work item that captures something needing attention, discussion, decision, correction, or tracking.
Issue is a broad external-tool-friendly concept.
11.13 Bug
A Bug is a work item representing a defect, error, malfunction, or unwanted behavior.
A bug SHOULD reference the affected system, observed behavior, expected behavior, reproduction information, and severity when known.
11.14 Story
A Story is a user- or stakeholder-oriented work item that describes desired value or behavior.
A story SHOULD reference:
beneficiary
desired capability
value or reason
acceptance criteria
11.15 Feature
A Feature is a coherent capability or behavior that delivers value to users, systems, or stakeholders.
A feature may be decomposed into stories, tasks, experiments, or implementation steps.
11.16 Epic
An Epic is a large work item or goal that is expected to be decomposed into smaller work items.
Epic is often a profile-specific concept used by issue trackers and agile tools.
11.17 IncidentTask
An IncidentTask is work triggered by an incident or service degradation.
It SHOULD reference the affected service, urgency, impact, workaround, and resolution state.
11.18 ProblemTask
A ProblemTask is work intended to investigate or eliminate the underlying cause of incidents or recurring issues.
11.19 ChangeTask
A ChangeTask is work intended to alter a system, service, configuration, process, artifact, or environment.
Change tasks may require governance approval depending on profile.
11.20 ReviewTask
A ReviewTask is work intended to examine an artifact, proposal, decision, control, design, code change, document, or result.
11.21 ApprovalTask
An ApprovalTask is work requiring an authorized actor to approve or reject something.
Approval semantics are owned by Governance; the Task Model owns the work representation of the approval action.
11.22 RemediationTask
A RemediationTask is work intended to correct a finding, risk condition, defect, compliance gap, vulnerability, or nonconformity.
11.23 DecisionTask
A DecisionTask is work required to reach, record, or escalate a decision.
Decision semantics are owned by Governance; the Task Model owns the work representation.
11.24 Backlog
A Backlog is an ordered or unordered collection of work items that may be selected, refined, prioritized, committed, or executed.
Backlogs may exist for:
product
project
team
service
personal system
incident response
technical debt
governance remediation
11.25 WorkPackage
A WorkPackage is a larger bounded unit of work that may be decomposed into tasks, activities, deliverables, or sub-work items.
WorkPackage is useful for project-management mappings.
11.26 Milestone
A Milestone is a significant point, target, event, or grouping marker used to track progress.
A milestone is not itself necessarily a task.
11.27 Commitment
A Commitment is a declared expectation that a work item will be acted upon, completed, decided, reviewed, or otherwise progressed.
Commitment may be created by:
self-commitment
assignment
delegation
acceptance of request
governance obligation
contract
due date
sprint selection
incident response duty
11.28 AssignmentReference
An AssignmentReference links a work item to an actor or organizational entity expected to act.
The organization semantics of actor and assignment are owned by Organization.
11.29 DueDate and Deadline
A DueDate is a target date or time by which work is expected.
A Deadline is a stricter boundary where missing it has consequence.
Canonical rule:
A date on an option SHOULD NOT be interpreted as a deadline unless commitment semantics are present.
11.30 WaitingFor
WaitingFor is a state or relationship indicating that progress depends on another actor, event, decision, input, or condition.
11.31 Dependency
A Dependency is a relationship where one work item requires another work item, condition, artifact, decision, or resource.
Dependency types:
finish_to_start
start_to_start
external_dependency
information_dependency
decision_dependency
resource_dependency
technical_dependency
governance_dependency
11.32 Blocker
A Blocker is an active impediment preventing progress.
A blocker may be caused by:
missing information
unavailable actor
unresolved decision
access limitation
technical fault
policy constraint
resource shortage
unclear scope
11.33 Readiness
Readiness indicates whether a work item is sufficiently clear, scoped, authorized, resourced, and unblocked to start.
11.34 Actionability
Actionability indicates whether a work item has enough clarity and feasible next action to be acted upon.
Actionability depends on:
clarity
scope
context
required resources
known next action
risk of failed attempt
11.35 Reachability
Reachability indicates whether an actionable work item can actually be reached by an available actor with sufficient skill, willingness, authority, tools, access, and time.
Canonical rule:
A work item may be actionable but not reachable.
11.36 Priority
Priority is an ordering signal used to choose between work items.
Priority SHOULD NOT be used as a substitute for urgency, importance, value, risk, or commitment.
11.37 Urgency
Urgency indicates time sensitivity.
11.38 Importance
Importance indicates significance relative to goals, values, strategy, obligations, or consequences.
11.39 Value
Value indicates expected benefit or contribution to goals.
Value may be economic, operational, strategic, learning-oriented, safety-related, compliance-related, or emotional.
11.40 EffortEstimate
An EffortEstimate is an estimate of work required.
Effort may be represented as time, story points, t-shirt size, Joules, cost, complexity, or another profile-defined unit.
11.41 Complexity
Complexity indicates uncertainty, interdependence, emergence, or difficulty of predicting outcomes.
Complexity SHOULD influence whether work is modeled as step, move, exploration, or experiment.
11.42 Workflow
A Workflow is a set of states and transitions used to manage work progress.
The Task Model provides generic workflow concepts. Profiles define concrete workflows.
11.43 WorkflowState
A WorkflowState is a state in a workflow.
Recommended seed states:
| Code | Recommended value | Meaning |
|---|---|---|
WAIT |
wait |
Blocked, paused, or waiting on another actor, event, decision, input, or condition. |
TODO |
todo |
Ready or planned work that is not actively being worked. |
PROG |
progress |
Active work in focus. |
DONE |
done |
Completed successfully. |
CNCL |
cancel |
Stopped because the work is no longer relevant, wanted, or valid. |
Profiles MAY map richer local workflow states to these seed states when local tools need more board columns, review lanes, or intake states.
11.44 Transition
A Transition is a movement from one workflow state to another.
Recommended seed transitions:
| Current state | Allowed next states | Reason / when to transition |
|---|---|---|
WAIT |
TODO, CNCL |
The blocking issue is resolved, or the task is no longer relevant. |
TODO |
PROG, WAIT, CNCL |
Work starts, the task becomes blocked, or the task is no longer needed. |
PROG |
DONE, WAIT, TODO, CNCL |
Work completes, becomes blocked, needs rework, or is canceled. |
DONE |
PROG |
Reopen only when major changes require renewed active work. |
CNCL |
none | Final state; canceled work should not be reopened. |
Transitions SHOULD have criteria when used in mature workflows. PROG SHOULD be the only state where active work is happening. CNCL is final. DONE is terminal by default and SHOULD only reopen through an explicit profile rule.
11.45 WIPLimit
A WIPLimit is a limit on the number of work items allowed in a workflow state, lane, person, team, class of service, or context.
11.46 Outcome
An Outcome is the result or intended result of a work item.
A task without an outcome may still be valid, but unclear outcomes reduce actionability.
11.47 Deliverable
A Deliverable is a tangible or verifiable output of work.
11.48 AcceptanceCriteria
AcceptanceCriteria define conditions that must be met for a work item to be accepted.
11.49 DefinitionOfReady
A DefinitionOfReady defines the conditions under which a work item may be started or selected.
11.50 DefinitionOfDone
A DefinitionOfDone defines the conditions under which a work item may be considered complete.
11.51 CompletionEvidence
CompletionEvidence is information supporting that work was completed.
Examples:
merged pull request
deployment record
test result
signed approval
written document
customer confirmation
monitoring signal
12. Core Relationship Vocabulary
Recommended root relationship types:
contains
part_of
decomposes_into
depends_on
blocks
blocked_by
duplicates
relates_to
follows_up
created_by
requested_by
assigned_to
owned_by
accountable_to
committed_by
accepted_by
rejected_by
approved_by
reviewed_by
affects
changes
fixes
mitigates
satisfies
implements
produces
consumes
evidenced_by
converted_to
promoted_to
derived_from
scheduled_for
waiting_for
Relationship records SHOULD support:
id:
relationship_type:
source_work_item:
target_entity:
scope:
valid_from:
valid_to:
source_system:
confidence:
evidence:
rationale:
13. Task State Model
13.1 Work Item Lifecycle States
Recommended concrete lifecycle:
| Code | Lowercase value | Color | Hex | CSS suggestion | Visual meaning |
|---|---|---|---|---|---|
WAIT |
wait |
Orange | #F59E0B |
bg-orange-500 text-white |
Caution / blocked |
TODO |
todo |
Blue | #3B82F6 |
bg-blue-500 text-white |
Ready / planned |
PROG |
progress |
Purple | #8B5CF6 |
bg-violet-500 text-white |
Active / in focus |
DONE |
done |
Green | #10B981 |
bg-emerald-500 text-white |
Success / complete |
CNCL |
cancel |
Red | #EF4444 |
bg-red-500 text-white |
Stopped / canceled |
Softer palette option:
| Code | Hex |
|---|---|
WAIT |
#FB923C |
TODO |
#60A5FA |
PROG |
#A855F7 |
DONE |
#34D399 |
CNCL |
#9CA3AF |
Recommended flow:
New Task
|
WAIT ---> TODO ---> PROG ---> DONE
^ ^ ^ ^
|________|_________|_________|
|
CNCL
13.2 Commitment States
uncommitted
self_committed
assigned
accepted
delegated
scheduled
obligated
withdrawn
completed
13.3 Actionability States
unclear
needs_clarification
actionable
needs_decomposition
needs_decision
needs_resource
blocked
reachable
not_reachable
13.4 Outcome States
undefined
defined
partially_met
met
not_met
superseded
no_longer_relevant
13.5 Review States
not_required
review_required
in_review
changes_requested
approved
rejected
14. Task Patterns
14.1 Pattern: Capture Without Commitment
Context: Ideas, possibilities, obligations, and requests arrive faster than they can be evaluated.
Problem: Treating every captured item as a task creates false pressure and overload.
Solution: Capture work as a WorkItem or Option first. Promote to Task only when commitment exists.
Result: The system can hold possibility without pretending everything is equally urgent.
14.2 Pattern: Option-to-Task Promotion
Context: An option becomes relevant, valuable, or necessary.
Problem: Work systems often lack a clear transition from “could do” to “will do.”
Solution: Promote Option to Task by adding:
commitment
responsible actor or owner
desired outcome
readiness or next action
priority or reason
14.3 Pattern: Next Action Extraction
Context: A task is too vague to execute.
Problem: Actors avoid or defer unclear work.
Solution: Extract the smallest concrete next action that can move the work forward.
14.4 Pattern: Step vs Move
Context: Some work is predictable and decomposable; some is complex and uncertain.
Problem: Forcing complex work into rigid steps creates false confidence.
Solution: Use Step for clear progress in known paths and Move for adaptive action in uncertain situations.
14.5 Pattern: Experiment for Learning
Context: The best next action is unknown.
Problem: Planning becomes speculation.
Solution: Create a bounded Experiment with hypothesis, expected signal, safety boundary, and learning result.
14.6 Pattern: Blocker as First-Class Entity
Context: Work stops.
Problem: Blocked status alone does not reveal what must change.
Solution: Model blockers explicitly with cause, owner, required resolution, and affected work.
14.7 Pattern: Commitment Boundary
Context: An item has a due date, assignee, or request.
Problem: Teams misinterpret metadata as commitment.
Solution: Model commitment explicitly and distinguish due date, assignment, request, and obligation.
14.8 Pattern: Definition Before Execution
Context: Teams start work before it is clear.
Problem: Execution reveals missing scope, criteria, or authority too late.
Solution: Use DefinitionOfReady for starting and DefinitionOfDone for completion.
14.9 Pattern: Work Item as Integration Handle
Context: A change touches landscape, governance, security, and code.
Problem: Work is fragmented across tools.
Solution: Use WorkItem as the integration handle linking service, repo, artifact, policy, decision, evidence, and actor references.
15. Task Profiles
15.1 Profile Format
A Task Profile SHALL declare:
id:
profile_name:
status:
implements:
- InfoTechCanonTaskModel
target_context:
included_concepts:
required_relationships:
required_metadata:
workflow_states:
source_of_truth_rules:
mapping_files:
validation_rules:
examples:
known_deviations:
15.2 Seed Profile: Personal Task and Option Profile
Purpose:
Support personal organization with options, tasks, next actions, waiting-for, and lightweight completion.
Included concepts:
WorkItem
Option
Task
NextAction
ProjectReference
WaitingFor
DueDate
Context
Actionability
Reachability
Outcome
Required relationships:
Task has_next_action NextAction
Task waiting_for ActorOrCondition
Option promoted_to Task
Task part_of ProjectReference
15.3 Seed Profile: GitHub Issues Task Profile
Purpose:
Map GitHub Issues into InfoTechCanon task concepts.
Example mappings:
Issue -> WorkItem / Issue
Sub-issue -> Child WorkItem
Task list item -> Task / Subtask
Assignee -> AssignmentReference
Label -> TagReference
Milestone -> Milestone
Project field Status -> WorkflowState
Issue type -> WorkType
Linked pull request -> CompletionEvidence / RelatedWork
15.4 Seed Profile: Jira Work Item Profile
Purpose:
Map Jira work items into InfoTechCanon task concepts.
Example mappings:
Epic -> Epic
Story -> Story
Task -> Task
Bug -> Bug
Sub-task -> Child Task
Issue status -> WorkflowState
Assignee -> AssignmentReference
Fix version -> ReleaseReference
Sprint -> Sprint / Iteration
Priority -> Priority
15.5 Seed Profile: DevSecOps Work Profile
Purpose:
Represent work associated with software delivery, security findings, reviews, approvals, releases, and remediation.
Included concepts:
Bug
Story
Task
ReviewTask
ApprovalTask
RemediationTask
ChangeTask
FindingReference
PullRequestReference
DeploymentReference
CompletionEvidence
Required relationships:
RemediationTask fixes Finding
ReviewTask reviews PullRequest
ApprovalTask approves Release
ChangeTask changes RuntimeResource
Task produces Artifact
CompletionEvidence evidences Task
15.6 Seed Profile: ITSM Work Profile
Purpose:
Represent incidents, service requests, problems, changes, approvals, and remediation tasks.
Included concepts:
IncidentTask
Request
ProblemTask
ChangeTask
ApprovalTask
RemediationTask
ServiceReference
Impact
Urgency
Priority
Workaround
Resolution
Required relationships:
IncidentTask affects Service
ProblemTask investigates IncidentTask
ChangeTask changes LandscapeEntity
ApprovalTask approves ChangeTask
RemediationTask fixes ProblemTask
15.7 Seed Profile: Agentic Work Profile
Purpose:
Support human-agent collaboration and agent-executable work.
Included concepts:
Task
Action
NextAction
AgentAssignment
CapabilityRequirement
AuthorityRequirement
ToolRequirement
ExecutionEvidence
HumanReview
SafetyBoundary
Required relationships:
Task assigned_to Agent
Task requires Capability
Task requires Authority
Action uses Tool
ExecutionEvidence evidences Action
HumanReview reviews AgentOutput
16. Mapping Model for the Task Standard
Mappings relate InfoTechCanon task concepts to external standards, methods, products, and regulations.
16.1 Mapping Types
Recommended mapping types:
exactMatch
closeMatch
broadMatch
narrowMatch
relatedMatch
conflictMatch
gapMatch
derivedFrom
regulatoryReference
16.2 Mapping Record
Example:
id: itc-map:task-to-jira-task
source_concept: itc-task:Task
target_body: Jira Cloud
target_version: "2026"
target_concept: Task work type
mapping_type: closeMatch
scope:
- generic work tracking
not_valid_for:
- commitment semantics
- next-action modeling
- governance obligations
rationale: >
Jira's Task work type is a practical representation of generic work,
but InfoTechCanon Task includes explicit commitment, actionability,
reachability, and outcome semantics that may not be represented in Jira by default.
confidence: medium
status: candidate
owner: InfoTechCanonTaskModel
16.3 Seed Mapping Targets
The Task Model SHOULD maintain mappings to:
PMBOK / PMI work breakdown and activity concepts
ISO 21502 project management guidance
Scrum Guide
Kanban Guide
Getting Things Done
ITIL incident, request, problem, and change concepts
GitHub Issues
GitHub Projects
Jira work types
Azure DevOps work item types
GitLab Issues
Linear issues
Trello cards
Asana tasks
RACI / responsibility assignment models
DevSecOps pipeline tasks and gates
17. Assimilation Hooks
The Task Model SHALL be able to receive new task, work, project, issue, workflow, and productivity bodies of knowledge through the InfoTechCanon assimilation process.
17.1 Assimilation Triggers
Assimilation may be triggered by:
new issue-tracker model
new project-management standard
new agile practice
new personal productivity method
new ITSM process model
new workflow automation tool
new agentic work system
new coding-agent execution pattern
new recurring work classification conflict
17.2 Task Assimilation Output
A task assimilation SHOULD produce:
source summary
extracted task concepts
concept comparison matrix
gap list
conflict list
mapping file
candidate new concepts
candidate relationship changes
candidate pattern changes
candidate profile changes
open questions
17.3 Recommended First Assimilation Candidates
GitHub Issues and Projects
Jira work types and workflows
Scrum Guide
Official Kanban Guide
GTD
ITIL incident/request/problem/change concepts
PMI WBS / PMBOK work concepts
Azure DevOps work item types
18. Integration with Other InfoTechCanon Standards
18.1 Organization Model
Task imports organization concepts for:
assignee
owner
accountable actor
requester
reviewer
approver
team
capacity
availability
authority
responsibility
18.2 Governance Model
Task imports governance concepts for:
obligation
decision
approval
review
exception
risk
control
finding
evidence
requirement
18.3 Landscape Model
Task applies to landscape concepts such as:
BusinessService
ApplicationService
SoftwareComponent
Repository
Artifact
Pipeline
RuntimeResource
NetworkEndpoint
Dataset
Environment
18.4 Tagging Standard
Tagging imports task concepts for:
work type
workflow state
priority
status
domain
scope
risk
blocked state
commitment state
18.5 DevSecOps Model
DevSecOps imports task concepts for:
bug
review task
approval task
remediation task
change task
release task
pipeline action
19. Canon Interface Card Usage
Subsystems that implement or produce task knowledge SHOULD publish a Canon Interface Card.
Example:
subsystem: github-issues-importer
implements:
- InfoTechCanonTaskModel
- GitHubIssuesTaskProfile
produces:
- Issue
- Task
- WorkItem
- Milestone
- WorkflowState
- AssignmentReference
consumes:
- Person
- Team
- Repository
relations:
- Issue assigned_to Person
- Issue scheduled_for Milestone
- Issue relates_to PullRequest
source_of_truth:
issue_body: GitHub
issue_status: GitHub Projects
known_deviations:
- commitment semantics are inferred unless explicit fields exist
- next actions may be embedded in issue body text
20. Retrieval Requirements
The Task Model is designed for markdown-based infospaces.
20.1 Required Retrieval Properties
Every major concept SHOULD provide:
- stable heading,
- stable identifier,
- short definition,
- longer explanation,
- examples,
- distinction notes,
- relationship examples,
- mapping hooks,
- profile references,
- and common mistakes.
20.2 Agent Brief
A mature Task Model SHOULD include an agent-brief.md file with:
purpose
scope
owned concepts
imported concepts
core distinctions
do / do not rules
relationship patterns
minimal examples
common mistakes
profile list
mapping list
20.3 Indexes
The task information space SHOULD provide indexes by:
concept
relationship
work type
workflow state
commitment state
profile
pattern
mapping target
status
source system
21. Conformance Levels
21.1 Reference-Conformant
A document or system is reference-conformant if it uses Task Model terminology consistently but does not implement structured metadata or validation rules.
21.2 Metadata-Conformant
A system is metadata-conformant if it uses stable identifiers, concept names, lifecycle states, source metadata, and relationship types.
21.3 Relationship-Conformant
A system is relationship-conformant if it represents decomposition, dependencies, blockers, assignment references, commitments, and evidence as explicit relationships.
21.4 Actionability-Conformant
A system is actionability-conformant if it distinguishes options, tasks, next actions, blockers, readiness, actionability, and reachability.
21.5 Profile-Conformant
A system is profile-conformant if it implements a declared Task Profile and passes its validation rules.
21.6 Assimilation-Conformant
A system or repository is assimilation-conformant if it can accept external task/work concepts through the InfoTechCanon assimilation workflow and produce mappings, gaps, conflicts, and proposed changes.
22. Validation Rules
Initial validation rules:
VAL-TASK-001: Option and Task SHOULD be modeled as distinct concepts.
VAL-TASK-002: A Task SHOULD declare or imply a Commitment.
VAL-TASK-003: A Task SHOULD have a desired Outcome, AcceptanceCriteria, or DefinitionOfDone unless intentionally exploratory.
VAL-TASK-004: A WorkItem that is unclear SHOULD be marked as needs_clarification or converted to Exploration.
VAL-TASK-005: A WorkItem that cannot be started SHOULD identify a NextAction, Blocker, Dependency, or WaitingFor relation.
VAL-TASK-006: AssignmentReference SHOULD resolve to an Organization Model actor or declared external identity mapping.
VAL-TASK-007: DueDate SHOULD NOT be treated as Deadline unless consequence semantics are declared.
VAL-TASK-008: Priority SHOULD NOT be used as a substitute for Urgency, Importance, Value, or Risk.
VAL-TASK-009: WorkflowState MUST NOT be treated as WorkType.
VAL-TASK-010: A Blocker SHOULD declare cause, owner or resolver, and affected work item.
VAL-TASK-011: A RemediationTask SHOULD reference the Finding, Risk, Bug, Nonconformity, or Issue it remediates.
VAL-TASK-012: A ReviewTask or ApprovalTask SHOULD reference the artifact, decision, release, change, or request being reviewed or approved.
VAL-TASK-013: Profiles MUST NOT redefine canonical concepts. They may constrain them.
VAL-TASK-014: Imported external task concepts SHOULD be represented through mapping records rather than silently reused.
VAL-TASK-015: Agent-executable tasks SHOULD declare capability, authority, tool, and safety requirements where relevant.
VAL-TASK-016: CompletionEvidence SHOULD reference the work item or outcome it supports.
VAL-TASK-017: Profiles using the seed task lifecycle SHOULD constrain WorkflowState to wait, todo, progress, done, and cancel, with cancel final and done reopenable only by explicit profile rule.
23. Anti-Patterns
23.1 Everything Is a Task
Treating every idea, option, request, obligation, issue, and action as the same kind of task.
23.2 Metadata as Commitment
Assuming an assignee, due date, label, or board column automatically means commitment.
23.3 Priority Soup
Using priority to encode urgency, importance, value, risk, stakeholder pressure, and due dates all at once.
23.4 Vague Task
Creating tasks such as “fix system” or “think about architecture” without next action, outcome, or clarification state.
23.5 Blocked Without Blocker
Moving a task to WAIT without modeling what blocks it and what would unblock it.
23.6 Tool-Captured Semantics
Letting Jira, GitHub, or another tool define the internal task model.
23.7 Status as Type
Using workflow states such as “progress” or “wait” as if they were task types.
23.8 Action Without Outcome
Recording activity without knowing what result it should produce.
23.9 Exploration Pretending to Be Delivery
Treating uncertain learning work as if it were straightforward execution.
23.10 Agent Task Without Authority
Assigning work to an agent without declaring capability, authority, tool access, or review boundary.
24. Initial Repository Placement
Recommended repository layout:
info-tech-canon/
standards/
task/
InfoTechCanonTaskModel.md
agent-brief.md
concepts/
relationships/
patterns/
profiles/
mappings/
assimilation/
examples/
validation/
Seed files:
standards/task/InfoTechCanonTaskModel.md
standards/task/agent-brief.md
standards/task/concepts/work-item.md
standards/task/concepts/option.md
standards/task/concepts/task.md
standards/task/concepts/action.md
standards/task/concepts/next-action.md
standards/task/concepts/blocker.md
standards/task/concepts/commitment.md
standards/task/concepts/workflow-state.md
standards/task/patterns/capture-without-commitment.md
standards/task/patterns/option-to-task-promotion.md
standards/task/patterns/next-action-extraction.md
standards/task/patterns/step-vs-move.md
standards/task/profiles/personal-task-option-profile.md
standards/task/profiles/github-issues-task-profile.md
standards/task/profiles/jira-work-item-profile.md
standards/task/profiles/agentic-work-profile.md
standards/task/mappings/github-issues.yaml
standards/task/mappings/jira.yaml
standards/task/mappings/scrum.yaml
standards/task/mappings/kanban.yaml
25. Roadmap
Phase 1: Seed Stabilization
- Establish this standard as
InfoTechCanonTaskModel. - Add seed concepts, relationship vocabulary, patterns, and profiles.
- Define validation rules.
- Align with Organization, Governance, and Landscape.
Phase 2: Tagging Dependency
- Create or refactor
InfoTechCanonTaggingStandard. - Ensure tagging imports task semantics instead of defining them.
- Define task tag profiles based on work type, state, domain, priority, risk, commitment, and blocker semantics.
Phase 3: First Assimilations
Recommended first assimilations:
GitHub Issues
Jira work types and workflows
Scrum Guide
Official Kanban Guide
GTD
ITIL incident/request/problem/change concepts
PMI WBS / PMBOK concepts
Phase 4: Tooling Integration
- Generate concept indexes.
- Generate agent brief.
- Create machine-readable YAML/JSON exports.
- Add validation scripts.
- Use in task CLI, project tooling, issue importers, agentic coding workflows, and markdown infobase workflows.
Phase 5: Agentic Work Maturity
- Mature the Agentic Work Profile.
- Add tool-use requirements.
- Add authority and review constraints.
- Connect execution evidence to Governance and Landscape models.
26. Summary
The InfoTechCanon Task Model is the seed standard for representing possible work, committed work, actionable progress, and work execution across humans, agents, tools, repositories, services, and governance systems.
Its most important commitments are:
Separate option, task, action, next action, step, move, exploration, and experiment.
Make commitment explicit.
Make actionability and reachability explicit.
Separate work type from workflow state.
Use task work items as integration handles across organization, governance,
landscape, DevSecOps, security, and tagging.
Use mappings and assimilation to stay connected to external tools and methods
without surrendering internal semantic autonomy.
Use profiles to make the model practical in GitHub, Jira, ITSM, personal,
DevSecOps, and agentic work contexts.
This makes the Task Model the fourth foundational seed of InfoTechCanon and the necessary precursor to a clean Canonical Tagging Standard.