generated from coulomb/repo-seed
2101 lines
44 KiB
Markdown
2101 lines
44 KiB
Markdown
# 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.
|
|
|
|
```text
|
|
InfoTechCanon
|
|
├── InfoTechCanonCore
|
|
├── InfoTechCanonLandscapeModel
|
|
├── InfoTechCanonOrganizationModel
|
|
├── InfoTechCanonGovernanceModel
|
|
├── InfoTechCanonTaskModel <-- this standard
|
|
├── InfoTechCanonTaggingStandard <-- should import task concepts
|
|
├── InfoTechCanonAccessControlModel
|
|
├── InfoTechCanonSecurityModel
|
|
├── InfoTechCanonDevSecOpsModel
|
|
├── InfoTechCanonPatternLanguage
|
|
└── Application Profiles
|
|
```
|
|
|
|
The foundational dependency chain is:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
Actor
|
|
Person
|
|
Agent
|
|
Team
|
|
Role
|
|
Membership
|
|
Assignment
|
|
Responsibility
|
|
Authority
|
|
Accountability
|
|
Capacity
|
|
Availability
|
|
```
|
|
|
|
The Task Model owns:
|
|
|
|
```text
|
|
WorkItem
|
|
Option
|
|
Task
|
|
Action
|
|
NextAction
|
|
Step
|
|
Move
|
|
Experiment
|
|
Issue
|
|
Request
|
|
BacklogItem
|
|
Blocker
|
|
Dependency
|
|
Commitment
|
|
TaskState
|
|
WorkOutcome
|
|
AcceptanceCriteria
|
|
DefinitionOfDone
|
|
```
|
|
|
|
Boundary rule:
|
|
|
|
```text
|
|
Organization defines who can act and carry responsibility.
|
|
Task defines what work exists and how it becomes actionable, committed, executed, blocked, completed, or abandoned.
|
|
```
|
|
|
|
## 3.2 Boundary with Governance
|
|
|
|
The Governance Model owns:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
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:
|
|
|
|
1. define enough canonical concepts to support practical work coordination,
|
|
2. distinguish possible work from committed work,
|
|
3. distinguish planned progress from actual action,
|
|
4. support human and agent work,
|
|
5. support personal, team, project, product, operational, service, and governance work,
|
|
6. support predictable and exploratory work,
|
|
7. avoid being captured by any one tool such as Jira, GitHub Issues, or Azure DevOps,
|
|
8. expose mapping hooks to external methodologies and products,
|
|
9. provide profile hooks for implementation contexts,
|
|
10. remain markdown-first and agent-retrievable,
|
|
11. 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 captured, considered, planned, committed, delegated, blocked, completed, abandoned, or converted.
|
|
|
|
## 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.
|
|
|
|
Open, in progress, blocked, and done 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:
|
|
|
|
```yaml
|
|
---
|
|
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:
|
|
|
|
```text
|
|
idea
|
|
draft
|
|
candidate
|
|
release-candidate
|
|
adopted
|
|
stable
|
|
deprecated
|
|
retired
|
|
```
|
|
|
|
Recommended concept statuses:
|
|
|
|
```text
|
|
proposed
|
|
experimental
|
|
candidate
|
|
canonical
|
|
deprecated
|
|
retired
|
|
```
|
|
|
|
---
|
|
|
|
# 10. Root Task Taxonomy
|
|
|
|
```text
|
|
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:
|
|
|
|
```yaml
|
|
id:
|
|
entity_type:
|
|
canonical_name:
|
|
display_name:
|
|
lifecycle_state:
|
|
source_system:
|
|
created_at:
|
|
updated_at:
|
|
```
|
|
|
|
Optional attributes:
|
|
|
|
```yaml
|
|
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:
|
|
|
|
```text
|
|
idea
|
|
option
|
|
task
|
|
issue
|
|
request
|
|
bug
|
|
story
|
|
incident
|
|
change
|
|
review
|
|
approval
|
|
experiment
|
|
remediation
|
|
```
|
|
|
|
Canonical rule:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
try a new library
|
|
explore a business model
|
|
write an article
|
|
refactor a module someday
|
|
investigate a potential standard
|
|
```
|
|
|
|
Canonical rule:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
clear
|
|
specific
|
|
physically or digitally executable
|
|
small enough to start
|
|
linked to a context or actor
|
|
```
|
|
|
|
Canonical rule:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
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:
|
|
|
|
```yaml
|
|
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:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
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.
|
|
|
|
Seed states:
|
|
|
|
```text
|
|
captured
|
|
clarifying
|
|
option
|
|
ready
|
|
committed
|
|
planned
|
|
in_progress
|
|
waiting
|
|
blocked
|
|
in_review
|
|
approved
|
|
done
|
|
rejected
|
|
abandoned
|
|
converted
|
|
```
|
|
|
|
---
|
|
|
|
## 11.44 Transition
|
|
|
|
A **Transition** is a movement from one workflow state to another.
|
|
|
|
Transitions SHOULD have criteria when used in mature workflows.
|
|
|
|
---
|
|
|
|
## 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:
|
|
|
|
```text
|
|
merged pull request
|
|
deployment record
|
|
test result
|
|
signed approval
|
|
written document
|
|
customer confirmation
|
|
monitoring signal
|
|
```
|
|
|
|
---
|
|
|
|
# 12. Core Relationship Vocabulary
|
|
|
|
Recommended root relationship types:
|
|
|
|
```text
|
|
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:
|
|
|
|
```yaml
|
|
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
|
|
|
|
```text
|
|
captured
|
|
triaged
|
|
clarifying
|
|
option
|
|
ready
|
|
committed
|
|
planned
|
|
in_progress
|
|
waiting
|
|
blocked
|
|
in_review
|
|
approved
|
|
done
|
|
rejected
|
|
abandoned
|
|
converted
|
|
```
|
|
|
|
## 13.2 Commitment States
|
|
|
|
```text
|
|
uncommitted
|
|
self_committed
|
|
assigned
|
|
accepted
|
|
delegated
|
|
scheduled
|
|
obligated
|
|
withdrawn
|
|
completed
|
|
```
|
|
|
|
## 13.3 Actionability States
|
|
|
|
```text
|
|
unclear
|
|
needs_clarification
|
|
actionable
|
|
needs_decomposition
|
|
needs_decision
|
|
needs_resource
|
|
blocked
|
|
reachable
|
|
not_reachable
|
|
```
|
|
|
|
## 13.4 Outcome States
|
|
|
|
```text
|
|
undefined
|
|
defined
|
|
partially_met
|
|
met
|
|
not_met
|
|
superseded
|
|
no_longer_relevant
|
|
```
|
|
|
|
## 13.5 Review States
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
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:
|
|
|
|
```yaml
|
|
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:
|
|
|
|
```text
|
|
Support personal organization with options, tasks, next actions, waiting-for, and lightweight completion.
|
|
```
|
|
|
|
Included concepts:
|
|
|
|
```text
|
|
WorkItem
|
|
Option
|
|
Task
|
|
NextAction
|
|
ProjectReference
|
|
WaitingFor
|
|
DueDate
|
|
Context
|
|
Actionability
|
|
Reachability
|
|
Outcome
|
|
```
|
|
|
|
Required relationships:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
Map GitHub Issues into InfoTechCanon task concepts.
|
|
```
|
|
|
|
Example mappings:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
Map Jira work items into InfoTechCanon task concepts.
|
|
```
|
|
|
|
Example mappings:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
Represent work associated with software delivery, security findings, reviews, approvals, releases, and remediation.
|
|
```
|
|
|
|
Included concepts:
|
|
|
|
```text
|
|
Bug
|
|
Story
|
|
Task
|
|
ReviewTask
|
|
ApprovalTask
|
|
RemediationTask
|
|
ChangeTask
|
|
FindingReference
|
|
PullRequestReference
|
|
DeploymentReference
|
|
CompletionEvidence
|
|
```
|
|
|
|
Required relationships:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
Represent incidents, service requests, problems, changes, approvals, and remediation tasks.
|
|
```
|
|
|
|
Included concepts:
|
|
|
|
```text
|
|
IncidentTask
|
|
Request
|
|
ProblemTask
|
|
ChangeTask
|
|
ApprovalTask
|
|
RemediationTask
|
|
ServiceReference
|
|
Impact
|
|
Urgency
|
|
Priority
|
|
Workaround
|
|
Resolution
|
|
```
|
|
|
|
Required relationships:
|
|
|
|
```text
|
|
IncidentTask affects Service
|
|
ProblemTask investigates IncidentTask
|
|
ChangeTask changes LandscapeEntity
|
|
ApprovalTask approves ChangeTask
|
|
RemediationTask fixes ProblemTask
|
|
```
|
|
|
|
---
|
|
|
|
## 15.7 Seed Profile: Agentic Work Profile
|
|
|
|
Purpose:
|
|
|
|
```text
|
|
Support human-agent collaboration and agent-executable work.
|
|
```
|
|
|
|
Included concepts:
|
|
|
|
```text
|
|
Task
|
|
Action
|
|
NextAction
|
|
AgentAssignment
|
|
CapabilityRequirement
|
|
AuthorityRequirement
|
|
ToolRequirement
|
|
ExecutionEvidence
|
|
HumanReview
|
|
SafetyBoundary
|
|
```
|
|
|
|
Required relationships:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
exactMatch
|
|
closeMatch
|
|
broadMatch
|
|
narrowMatch
|
|
relatedMatch
|
|
conflictMatch
|
|
gapMatch
|
|
derivedFrom
|
|
regulatoryReference
|
|
```
|
|
|
|
## 16.2 Mapping Record
|
|
|
|
Example:
|
|
|
|
```yaml
|
|
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:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
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
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
assignee
|
|
owner
|
|
accountable actor
|
|
requester
|
|
reviewer
|
|
approver
|
|
team
|
|
capacity
|
|
availability
|
|
authority
|
|
responsibility
|
|
```
|
|
|
|
## 18.2 Governance Model
|
|
|
|
Task imports governance concepts for:
|
|
|
|
```text
|
|
obligation
|
|
decision
|
|
approval
|
|
review
|
|
exception
|
|
risk
|
|
control
|
|
finding
|
|
evidence
|
|
requirement
|
|
```
|
|
|
|
## 18.3 Landscape Model
|
|
|
|
Task applies to landscape concepts such as:
|
|
|
|
```text
|
|
BusinessService
|
|
ApplicationService
|
|
SoftwareComponent
|
|
Repository
|
|
Artifact
|
|
Pipeline
|
|
RuntimeResource
|
|
NetworkEndpoint
|
|
Dataset
|
|
Environment
|
|
```
|
|
|
|
## 18.4 Tagging Standard
|
|
|
|
Tagging imports task concepts for:
|
|
|
|
```text
|
|
work type
|
|
workflow state
|
|
priority
|
|
status
|
|
domain
|
|
scope
|
|
risk
|
|
blocked state
|
|
commitment state
|
|
```
|
|
|
|
## 18.5 DevSecOps Model
|
|
|
|
DevSecOps imports task concepts for:
|
|
|
|
```text
|
|
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:
|
|
|
|
```yaml
|
|
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:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
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.
|
|
```
|
|
|
|
---
|
|
|
|
# 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
|
|
|
|
Marking a task blocked 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 “in review” or “blocked” 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:
|
|
|
|
```text
|
|
info-tech-canon/
|
|
standards/
|
|
task/
|
|
InfoTechCanonTaskModel.md
|
|
agent-brief.md
|
|
concepts/
|
|
relationships/
|
|
patterns/
|
|
profiles/
|
|
mappings/
|
|
assimilation/
|
|
examples/
|
|
validation/
|
|
```
|
|
|
|
Seed files:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
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:
|
|
|
|
```text
|
|
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.
|