# Implementation Ticket Breakdown and Dependency Matrix

**Date:** 2026-04-14  
**Status:** Draft implementation artifact  
**Purpose:** Convert the biomimetic architecture into an execution-ready ticket graph with dependencies, gating logic, and parallelization boundaries.

## 1. Purpose

This document is the handoff layer between architecture and implementation management. It defines what tickets exist, what depends on what, and what can be built in parallel without creating merge chaos.

## 2. Dependency Rules

The system should be built in layers.

Layer 1:

- contracts
- root schema
- root repository

Layer 2:

- root gateway and routes
- colony service bootstrap
- root client and persistence facades

Layer 3:

- planner
- prompt master
- librarian

Layer 4:

- researcher
- workers
- scheduler

Layer 5:

- aggregation
- reviewer
- policy bridge

Layer 6:

- Oracle adapter
- CRM adapter
- Catalyst adapter

Layer 7:

- observability
- release operations
- operator tooling

## 3. Ticket Matrix

### T1. Contract Layer

Scope:

- create or finalize TypeScript contracts and Zod schemas
- align contracts with mission schema doc

Depends on:

- none

Blocks:

- all runtime work

### T2. Root Database Schema

Scope:

- create `backend/db/schema_colony.sql`
- add indexes

Depends on:

- T1

Blocks:

- repository and root APIs

### T3. Root Repository

Scope:

- implement `colony_repository.py`

Depends on:

- T2

Blocks:

- gateway, routes, approval flows

### T4. Colony Service Bootstrap

Scope:

- scaffold `services/colony-orchestrator`
- add `app.ts`, `index.ts`, health route

Depends on:

- T1

Blocks:

- service-side feature tickets

### T5. Python Root Client and Persistence Facades

Scope:

- implement `python-root-client.ts`
- implement `mission-store.ts`
- implement `artifact-store.ts`

Depends on:

- T3
- T4

Blocks:

- planner-through-review pipeline

### T6. Root Gateway and Routes

Scope:

- implement `colony_gateway.py`
- implement `routes_colony.py`
- mount in `backend/main.py`

Depends on:

- T3
- T4

Blocks:

- external mission initiation

### T7. Planner

Scope:

- mission normalization
- task DAG generation

Depends on:

- T1
- T5

Blocks:

- prompt master
- worker execution

### T8. Prompt Master

Scope:

- template registry
- exemplar registry
- prompt package builder

Depends on:

- T7

Blocks:

- worker execution

### T9. Librarian

Scope:

- source catalog
- route-card builder
- cache index

Depends on:

- T7

Blocks:

- worker execution

### T10. Researcher

Scope:

- search provider abstraction
- browser provider abstraction
- citation normalization

Depends on:

- T1
- T5

Blocks:

- research-enabled missions

### T11. Workers and Scheduler

Scope:

- worker factory
- scheduler
- worker runner

Depends on:

- T8
- T9

Blocks:

- aggregation

### T12. Aggregation and Review

Scope:

- aggregator
- contradiction detector
- reviewer
- release gate

Depends on:

- T11

Blocks:

- reviewed output delivery

### T13. Policy and Governance Bridge

Scope:

- risk classifier
- tool policy
- model routing policy
- writeback policy

Depends on:

- T6
- T12

Blocks:

- production-grade release

### T14. Oracle Adapter

Scope:

- map Oracle prompt flow to colony missions

Depends on:

- T12
- T13

### T15. CRM Adapter

Scope:

- map CRM lead intelligence flow to colony missions

Depends on:

- T12
- T13

### T16. Catalyst Adapter

Scope:

- map Catalyst strategy missions

Depends on:

- T12
- T13

### T17. Observability and Operations

Scope:

- traces
- metrics
- runbooks
- release dashboards

Depends on:

- T6
- T12

### T18. Sales Demo Readiness

Scope:

- curated demo missions
- operator script
- approval queue visibility
- artifact inspection path

Depends on:

- T14
- T15
- T17

## 4. Parallelization Guidance

Safe parallel tracks:

- T2 and T4 after T1
- T7 and T10 after prerequisite facades exist
- T14 and T15 after core and governance are stable

Unsafe parallel tracks:

- implementing adapters before contracts stabilize
- building reviewer before worker result contract exists
- building production demo flows before observability exists

## 5. Acceptance Gates by Ticket Group

Gate A:

- T1 through T6 complete
- root and service are connected

Gate B:

- T7 through T12 complete
- one reviewed mission can execute end to end

Gate C:

- T13 through T15 complete
- one Oracle and one CRM mission are governed

Gate D:

- T17 and T18 complete
- system is demo-safe and sales-usable

## 6. Suggested Ownership Split

- engineer 1: root schema, repository, gateway, routes
- engineer 2: service bootstrap, contracts, persistence facades
- engineer 3: planner, prompt master, librarian
- engineer 4: workers, aggregation, review
- engineer 5: governance, adapters, observability

If the team is smaller, keep ownership by layer, not by file count.

## 7. Bottom Line

This dependency matrix should be used to create actual tickets. It keeps the team from building the colony out of order and makes it clear what can proceed in parallel without damaging the architecture.