# Ticket Breakdown and Dependency Matrix_ Founder CRM and Platform Planning

**Date:** 2026-04-18  
**Status:** Draft  
**Owner:** Sagnik  
**Reviewers:** Sayan, Sourik  
**Scope:** Planning-to-implementation ticket graph for founder CRM, imports, client graph, and related cross-team dependencies  
**Purpose:** Convert the founder architecture into a safe ticket graph with dependency order and owner boundaries.  
**Decision Boundary:** This matrix is planning-grade and approval-oriented. It is not yet a live issue tracker.

## 1. Purpose

This ticket matrix governs the eventual build program required to turn the founder planning pack into implementation.

## 2. Dependency Rules

Implementation layers in order:

1. reconciliation and infra truth
2. canonical domains and route families
3. import contracts
4. frontend CRM shell
5. client 360 aggregation
6. Oracle CRM-adjacent integrations
7. advanced evidence and workflow automation

## 3. Ticket Matrix

| Ticket ID | Scope | Depends On | Blocks | Owner |
| --- | --- | --- | --- | --- |
| `FND-01` | Reconcile Sprint 1 fact table with repo truth | none | all CRM planning | Founder |
| `FND-02` | Consolidate infra/operator truth | `FND-01` | route and rollout planning | Founder |
| `FND-03` | Define CRM IA and top-level module strategy | `FND-01` | frontend CRM implementation | Founder |
| `FND-04` | Define canonical CRM and interaction domains | `FND-01` | schema and route implementation | Founder |
| `FND-05` | Define import contracts and adapter posture | `FND-04` | import services and review UI | Founder |
| `FND-06` | Define client 360 aggregate model | `FND-04` | client 360 page and Oracle CRM tabs | Founder |
| `FND-07` | Define identity/access target over `users_and_roles` | `FND-04` | future admin and RBAC work | Founder + Sayan |
| `FND-08` | Define inventory canonical persistence posture | `FND-04` | inventory/CRM integration | Sayan + Founder |
| `FND-09` | Define Oracle template DB adjacency to CRM | `FND-04` | Oracle component/template work | Sayan |
| `FND-10` | Define runtime and route-family implications for colony/workflow | `FND-04` | Sourik-side runtime planning | Sourik |
| `FND-11` | Build synthetic client graph brief | `FND-04`, `FND-05`, `FND-06` | swarm data generation | Founder |
| `FND-12` | Seed monolithic truth artifact | `FND-01` through `FND-11` | future onboarding and planning | Founder |

## 4. Parallelization Guidance

Can run in parallel after canonical domains are clear:

- Sayan-side inventory and Oracle template planning
- Sourik-side route-family/runtime planning
- synthetic data brief drafting

Must not run in parallel before canonical domains are clear:

- implementation of final CRM routes
- import review UX
- client 360 data model

## 5. Acceptance Gates by Ticket Group

- truth gate:
  - `FND-01`, `FND-02`
- architecture gate:
  - `FND-03`, `FND-04`, `FND-05`, `FND-06`
- cross-team alignment gate:
  - `FND-07`, `FND-08`, `FND-09`, `FND-10`
- readiness gate:
  - `FND-11`, `FND-12`

## 6. Suggested Ownership Split

- Founder
  - FND-01 through FND-06, FND-11, FND-12
- Sayan
  - FND-08, FND-09
- Sourik
  - FND-10
- Shared review
  - FND-07

## 7. Bottom Line

The ticket graph should force the team to define the data model first. If implementation starts before that, Velocity will simply create another layer of partial truth.