Goals
- Define a formal project model that scales from early design to long-term maintenance.
- Create a paved road for artifacts, decisions, planning cadence, implementation, and review.
- Support flat but explicit roles and responsibilities without collapsing accountability.
- Make progress legible through milestones, phases, definitions of done, and metrics.
Desired outcomes
- Less ambiguity about what to build, why now, and what “done” means.
- Lower coordination overhead across docs, repos, reviews, and stakeholder updates.
- Better prioritization by expected value, risk, effort, and strategic fit.
- A durable feedback loop from implementation back into specs and planning.
Operating model
1. Strategy
Set direction through goals, expected outcomes, constraints, and project policy.
2. Specification
Shape work through RFCs, specs, architecture notes, and communication guidance.
3. Planning
Translate specs into prioritized milestones, phases, review gates, and executable work.
4. Execution
Integrate with repositories, tasks, delivery workflows, and implementation telemetry.
5. Review
Continuously check quality, alignment, risks, drift, and readiness against definition of done.
6. Maintenance
Handle stewardship, stakeholder reporting, updates, archival policy, and lifecycle hygiene.
Key systems inside Calathea
- PRD / goals system: goals, outcomes, success metrics, hero metrics
- Paved road: standard artifact types, repo conventions, AI tool policy, integrations
- Prioritization system: risk, leverage, urgency, strategic fit, dependency awareness
- Planning system: phases, milestones, breakdown rules, review points
- Review system: design review, implementation review, rollout review, maintenance review
- Feedback loop: implementation findings update specs, plans, and future priority
Communication surfaces
- Charter / project summary
- RFCs and specs
- Planning documents and milestone reports
- Status summaries and decision logs
- Repository-integrated task and implementation notes
- Archive records for historical traceability
Lifecycle flow
Intake and framing
Capture the problem, context, goals, outcomes, constraints, and stakeholders.
Shaping and specification
Produce RFCs, specs, diagrams, paved-road guidance, and success metrics.
Prioritization and planning
Sequence work into phases and milestones using a repeatable evaluation model.
Implementation and review
Execute in repositories with explicit review gates and definition-of-done checks.
Operational learning
Feed implementation outcomes, incidents, surprises, and maintenance realities back upstream.
Maintenance and archive
Steward active work, sunset stale paths, and preserve historical decisions and artifacts.
Artifact model
| Artifact | Purpose | Typical content | When it matters most |
|---|---|---|---|
| Project Summary / Charter | Shared frame for the project | Mission, scope, constraints, stakeholders | Project formation |
| PRD / Outcomes Doc | Define goals, outcomes, and metrics | Hero metric, leading indicators, non-goals | Before planning and prioritization |
| RFC / Spec | Shape important decisions | Design, alternatives, trade-offs, policy | When change has architectural weight |
| Plan / Milestone Doc | Convert intent into execution | Phases, milestones, dependencies, review gates | Active delivery |
| Implementation Feedback | Prevent planning drift | Findings, blockers, deviations, lessons | During and after implementation |
| Archive Record | Preserve history and rationale | Status, closure reason, successor paths | Retirement or supersession |
Definition of done
- Artifact done: clear, reviewable, internally consistent
- Phase done: agreed scope and exit criteria met
- Milestone done: outcome demonstrated, not just work completed
- Project done: goals met or consciously closed with archive path
Phase and milestone policy
- Each phase should have intent, entry criteria, exit criteria, and review owner(s).
- Milestones should represent validated outcomes, not ticket counts.
- Cross-phase changes should update planning artifacts rather than relying on tribal memory.
- Late discovery should feed back into prioritization and spec maintenance.
Repository integration strategy
- Map project artifacts to repo structure and workflow triggers.
- Keep design intent close to implementation without forcing everything into code comments.
- Allow review systems to inspect both artifact state and repository state.
- Create a standard path for AI skills, plugins, extensions, and policy guardrails.
Long-term stewardship
- Define owners without imposing unnecessary hierarchy.
- Establish maintenance cadence and stakeholder update patterns.
- Track drift, stale plans, and orphaned artifacts.
- Archive intentionally to preserve signal and reduce clutter.
Summary in one line
Calathea is a project operating framework that connects goals, specifications, prioritization, planning, implementation, review, maintenance, and archival into one durable system. It is designed to align closely with Anthesis, acting as the execution and project-layer counterpart to Anthesis’ governance, RFC, and agentic SDLC model.
Relationship to Anthesis
Calathea and Anthesis are complementary systems. Anthesis provides the governance layer — RFCs, invariant rules, agent coordination, and secure SDLC principles — while Calathea provides the project operating model that structures how work flows through planning, prioritization, execution, and maintenance.
- Anthesis: Defines how decisions are made, governed, and enforced (RFCs, invariants, agent workflows).
- Calathea: Defines how work is shaped, sequenced, executed, and maintained over time.
- Integration point: RFCs and specs produced in Anthesis feed directly into Calathea planning and prioritization systems.
- Feedback loop: Implementation results from Calathea feed back into Anthesis artifacts, preventing governance drift.