# Founder CRM and Platform Delivery Pack Guide

**Date:** 2026-04-18  
**Status:** Draft  
**Owner:** Sagnik  
**Reviewers:** Sayan, Sourik  
**Scope:** Founder-owned CRM, client graph, import architecture, infra truth, and planning consolidation for Sprint 1  
**Purpose:** Provide the canonical founder document system for planning the remaining Velocity CRM and platform work from first principles.  
**Decision Boundary:** This pack defines the planning truth and approval-ready target architecture. It does not itself authorize code or schema migrations without follow-up approval.

## 1. Purpose

This pack is the founder-owned planning layer for the parts of Project Velocity that still need convergence:

- CRM as a first-class product module
- canonical client graph and AI-native database structure
- import architecture
- infra and operator truth
- ownership boundaries across Founder, Sayan, and Sourik

It intentionally mirrors the discipline of the Sayan and Sourik packs, but it is focused on the founder problem: making Velocity legible, operationally grounded, and commercially credible as a Salesforce replacement for premium real estate teams.

## 2. Why This Pack Exists Now

The current repo has substantial real implementation, but the planning truth is fragmented:

- the Sprint 1 fact table is stale in important places
- CRM exists in overlapping partial forms
- Oracle already exists as a real runtime and canvas surface
- inventory truth exists in raw onboarding assets, not yet as a canonical operational database
- infra truth exists across multiple handoff docs, not one founder-owned operator reference

This pack exists to turn that fragmented reality into an approval-ready plan set.

## 3. Working Order

This pack should be used in the following order:

1. read the reconciliation matrix
2. read the infra/operator truth doc
3. read the first-principles document
4. review the PRD and SRS
5. review the CRM + DB blueprint and root API spec
6. review the execution backlog and dependency matrix
7. only then roll the material up into the monolithic truth artifact

## 4. Mandatory Metadata

Every document in this pack must include:

- title
- date
- status
- owner
- reviewers
- scope
- purpose
- decision boundary

## 5. Document Map

Use these documents for the following outcomes:

- `00 - Founder Pack Guide.md`
  - how to use this pack
- `01 - First Principles_ Founder CRM and Platform Planning.md`
  - founder problem framing and architecture logic
- `02 - PRD_ Founder CRM and Platform Planning.md`
  - product scope and user outcomes
- `03 - SRS_ Founder CRM and Platform Planning.md`
  - technical requirements and interfaces
- `04 - Sprint Plan_ Founder CRM and Platform Planning.md`
  - sequencing and deliverables
- `05 - Implementation Blueprint_ Founder CRM and Platform Planning.md`
  - current repo truth and target implementation map
- `06 - Execution Backlog_ Founder CRM and Platform Planning.md`
  - workstreams, ownership, and delivery order
- `07 - Contracts and Schema Blueprint_ Founder CRM and Platform Planning.md`
  - canonical artifacts and schema contracts
- `08 - Adapter Detailed Implementation Spec_ CRM Import and Client 360.md`
  - operational CRM adapter and import workflow
- `09 - Database Schema and Root API Spec_ Founder CRM Canonical Domains.md`
  - canonical tables and API targets
- `10 - TypeScript Module Spec_ Founder CRM Surface and Oracle Integration.md`
  - frontend CRM and Oracle integration surface
- `11 - Role Spec_ NemoClaw Import Intelligence and Data Stewardship.md`
  - AI and human stewardship boundaries
- `12 - Deployment Operations and Release Readiness_ Founder CRM Platform.md`
  - runtime and release truth
- `13 - Ticket Breakdown and Dependency Matrix_ Founder CRM and Platform Planning.md`
  - implementation slicing
- `14 - Reconciliation Matrix_ Sprint 1 Fact Table vs Current Repo.md`
  - what is current, stale, partial, and missing
- `15 - Infrastructure and Operator Truth_ Linux Ingress GPU Comfy.md`
  - canonical infrastructure reference
- `16 - Coding Agent Swarm Brief_ Synthetic Client Graph Generation.md`
  - synthetic data generation tasking

## 6. Review Rule

Every document in this pack should be reviewed by:

- Founder for product truth
- Sayan for UI, Oracle template, inventory, and admin implications
- Sourik for runtime, route family, and orchestration implications

If a document changes ownership or architectural boundaries, it should not be treated as approved until all three views have been checked.

## 7. Quality Rule

A document in this pack is incomplete if it still contains:

- unresolved placeholders presented as facts
- contradictions against the current repo
- unresolved ownership ambiguity
- route families with no stated owner
- target schemas with no migration posture
- UI intentions with no operational meaning

## 8. Writing Rule

All founder-pack docs must do four things at once:

1. describe current state truth
2. define the target state
3. show the gap between the two
4. state what still needs approval

This pack is not allowed to become a purely aspirational strategy set.

## 9. Relationship to Other Packs

This pack does not replace:

- `Sayan Multi-Surface and Oracle Delivery Pack`
- `Biomimetic Agentic Orchestration Layer`

It complements them by defining the founder-owned platform truth those packs depend on.

## 10. Bottom Line

This pack is the bridge between the current repo and the future sellable system. It is where Project Velocity stops being a collection of real but uneven subsystems and starts becoming one legible product architecture.