CAIPE public roadmap: Initiatives, Epics, Features, and milestone backfill

[sriaradhyula]

CAIPE now has a public, evidence-backed roadmap that connects our long-term product direction to delivered issues, pull requests, and release milestones.

The goal is to make the roadmap useful to contributors, maintainers, users, and reviewers—including our CNCF Sandbox preparation—without losing the history of how the platform evolved.

Roadmap mind map

Editable source: Download the XMind mind map. The ZIP contains the editable .xmind file.

The mind map is a planning snapshot. The public CAIPE project remains the live source of truth.

The hierarchy

Initiative
└── Epic (often v1 or v2)
    ├── Feature
    ├── Task
    ├── Bug
    └── Pull-request delivery evidence

Initiative

An Initiative is a durable portfolio or capability area, such as Harness Engine, Agent Memory, Workflows, Skills, Identity, or Web UI.

• Initiatives describe enduring product direction.
• They do not carry v1/v2 names.
• They do not receive release milestones.
• They contain both previously delivered and future Epics.

Epic

An Epic is an independently understandable product outcome.

• Epics may be versioned, such as Slack Bot v1, Skills Gateway v1, or Dynamic Agents v2.
• An Epic should have a clear outcome and a bounded delivery surface.
• Completed historical Epics are closed as completed.
• Planned Epics receive a minor-release milestone when maintainers schedule them.
• Discovery work can be represented as a time-boxed Spike Epic with explicit exit criteria.

Feature, Task, and Bug

These are the granular implementation or validation units beneath an Epic.

• Each item should have one canonical parent Epic.
• Cross-cutting work should be split when it represents separate deliverables.
• The issue type communicates the nature of the work; labels communicate technical area and ownership context.

Pull requests

Pull requests are delivery evidence rather than roadmap containers.

• Merged PRs are linked or cross-referenced from the Epic they delivered.
• Superseded or duplicate PRs are documented without double-counting delivery.
• The Epic explains how multiple PRs combine into one user-visible outcome.

How we backfilled the historical roadmap

We used repository history rather than treating the roadmap as a forward-looking wishlist:

1. Reviewed historical issues, closed issues, merged PRs, release notes, and current roadmap items.
2. Grouped work by delivered capability—not merely by directory, component, or team.
3. Created granular historical v1 Epics where the capability had already shipped, such as Slack Bot v1, Webex Bot v1, Event Hooks v1, runtime integrations, RAG capabilities, and administration surfaces.
4. Added Initiative → Epic → Feature/Task/Bug parent relationships.
5. Added issue types and consistent Epic/area labels.
6. Linked merged PRs as delivery evidence and documented unmerged precursors or duplicate merge paths.
7. Assigned the minor-release milestone in which the outcome shipped.
8. Closed completed Epics and allowed the project workflow to move them to Done.
9. Left future Epics open and unmilestoned until maintainers schedule them.

We intentionally do not create milestones for patch releases. Historical work from any 0.5.x release is represented by the 0.5.0 minor milestone; the same convention applies to other minor release lines.

Example: Scheduled Agents v1

Scheduled Agents v1 was created after its implementation had already landed. Its backfill now records:

• PR #2114 as the primary scheduler delivery.
• PR #2292 for administration and UI follow-ups.
• PR #2139 for scheduled and interval-triggered autonomous execution.
• The 0.5.0 minor-release milestone.
• A completed Epic state and Done project status.

This gives reviewers a traceable path from roadmap outcome to implementation and release history.

Public roadmap views

• Initiatives — durable capability areas.
• Feature Roadmap — current and upcoming delivery outcomes.
• Delivered Epics — completed, evidence-backed outcomes.
• Task Board — granular execution tracking.

Working agreement

Going forward:

• Initiatives remain durable and unversioned.
• Only Epics carry release milestones.
• Milestones represent minor releases, not patch releases.
• Broad umbrella Epics should be split along user-visible or architectural delivery boundaries.
• Completed outcomes should be closed; discontinued work should be closed with the reason documented.
• Every Feature, Task, and Bug should have the most specific valid parent Epic.
• Historical PR evidence should be preserved so roadmap claims remain auditable.

Feedback welcome

Please comment if:

• An Initiative boundary does not match the product or architecture.
• An Epic is still too broad or overlaps another Epic.
• A delivered capability or merged PR is missing from the historical backfill.
• An issue has the wrong parent or minor-release milestone.
• You would like to own or help refine a future Epic.

This is a living roadmap, and community review is part of keeping it accurate.