Initiatives & Work Hierarchy

How work is organized from strategic goals down to actionable tasks.

Hierarchy

Initiative
    │
    ├── Epic (optional)
    │   ├── Issue
    │   ├── Bug
    │   └── Task
    │
    └── Issue (can also be direct)
        └── Task

Initiatives

Top-level strategic goals that evolve through research and iteration.

Initiatives are NOT fixed scope - they start as hypotheses and refine based on evidence.

Lifecycle

1. Draft - Initial idea, not yet researched
2. Researching - Actively investigating approach
3. Active - Committed, work underway
4. Achieved - Goal accomplished
5. Abandoned - Killed based on evidence

Success Criteria

Each initiative has evolving success criteria with confidence levels:

Confidence	Meaning
hypothesis	Assumed true, needs validation
testing	Actively being verified
validated	Confirmed with evidence
rejected	Proven incorrect

Research Runs

Initiatives track research performed:

• ai_web - External AI/web research
• codebase - File exploration
• internal_docs - Devlogs, guides, tickets
• infrastructure - Services, dependencies
• past_initiatives - Prior attempts

Decisions

Every pivot, persevere, or kill decision is logged with rationale and evidence.

Epics

Large bodies of work broken into multiple issues.

Epics group related work under a theme. They can belong to an initiative or stand alone.

Example

Initiative: "Improve deployment reliability"
├── Epic: "Automated rollback system"
│   ├── Issue: Design rollback API
│   ├── Issue: Implement health check integration
│   └── Issue: Add rollback UI to Argus
└── Epic: "Deployment observability"
    ├── Issue: Add deployment metrics
    └── Issue: Create deployment dashboard

Tickets

Actionable work items that can be completed in a single session.

Types

Type	Purpose
issue	Standard feature or enhancement
bug	Defect to fix
spike	Research/investigation (timeboxed)
task	Small, specific action

Status Flow

backlog → ready → in_progress → review → done
                                    ↓
                               cancelled

Priority

• low - Nice to have
• normal - Standard priority
• high - Important, do soon
• critical - Drop everything

Relationships

Parent/Child

Tickets can have parent tickets:

Epic: "User authentication"
├── Issue: "Implement login flow"
│   ├── Task: "Create login form"
│   └── Task: "Add session handling"
└── Issue: "Implement logout"

Service Linking

Tickets can link to services:

{
  "ticket_type": "bug",
  "title": "Fix health check timeout",
  "service_id": "argus"
}

Artifact Linking

Completed tickets can link to devlogs as proof of work.

Janus MCP Tools

Initiatives

• janus_initiative_create - Create initiative
• janus_initiative_get - Get with criteria/decisions
• janus_initiative_update - Update status/details
• janus_criteria_add - Add success criterion
• janus_decision_log - Log pivot/persevere decision
• janus_research_start - Begin research run

Tickets

• janus_ticket_create - Create ticket
• janus_ticket_list - List with filters
• janus_ticket_claim - Claim for work
• janus_ticket_complete - Mark done

API

# Create initiative
POST /api/initiatives
{
  "title": "Improve deployment reliability",
  "rationale": "Too many failed deploys causing downtime"
}

# Create epic under initiative
POST /api/tickets
{
  "ticket_type": "epic",
  "title": "Automated rollback system",
  "initiative_id": "..."
}

# Create issue under epic
POST /api/tickets
{
  "ticket_type": "issue",
  "title": "Design rollback API",
  "parent_id": "..."
}