# Deployment Operations and Release Readiness_ Founder CRM Platform

**Date:** 2026-04-18  
**Status:** Draft  
**Owner:** Sagnik  
**Reviewers:** Sayan, Sourik  
**Scope:** Deployment topology, operating posture, release gates, and sales-readiness expectations for the future CRM-centered Velocity platform  
**Purpose:** Define how the planned founder CRM architecture fits the current deployed system and what must be true before future implementation is treated as production-ready.  
**Decision Boundary:** This document describes target operational posture and release criteria. It does not itself deploy new services.

## 1. Purpose

This deployment and release plan exists to ensure the future CRM/client-graph implementation fits the current live topology instead of assuming a different runtime world.

## 2. Deployment Topology

- public entrypoint:
  - stable ingress-routed public domains
- internal service layout:
  - Linux origin hosts Velocity app/backend and related platform services
  - GPU/Comfy runtime stays on GPU worker infrastructure
- persistence authority:
  - canonical CRM and workflow persistence remains application/backend-side, not on GPU runtime
- governance boundary:
  - approval and audit sit in backend-controlled workflow domains

## 3. Environment Contract

Future implementation should expect environment groups for:

- database URL and credentials
- auth/session secrets
- Oracle backend routing
- CRM/import service toggles
- storage roots
- Comfy public base URL
- workflow policy/config values

## 4. Release Environments

- local
  - schema and contract validation, UI and route iteration
- staging
  - import replay, synthetic data verification, route integration
- production
  - approved schemas, approved routes, ingress-safe rollout only

## 5. Observability Requirements

Planned implementation must expose:

- import job logs
- review queue metrics
- route and client-360 latency metrics
- writeback audit logs
- QD-related lineage and evidence tracing

## 6. Release Gates

### Technical integrity

- canonical route families implemented and tested
- client 360 read model consistent with canonical data

### Governance integrity

- approval flows and audit trails proven
- raw evidence retention intact

### Operational integrity

- no direct GPU public IP assumptions
- infra truth remains consistent with ingress and Linux-origin reality

### Sales integrity

- contact list, account list, and client 360 demo flows work end to end

## 7. Failure Runbooks

Future runbooks must cover:

- failed import mapping
- identity merge conflicts
- client 360 partial-data rendering
- writeback rejection or rollback
- Oracle/CRM cross-surface inconsistency

## 8. Rollout Strategy

Recommended rollout:

1. canonical schemas and route family approval
2. CRM read surfaces
3. import and review surfaces
4. Oracle CRM-adjacent subtabs
5. advanced intelligence and automation expansions

## 9. Sales Readiness Criteria

For the future CRM release to be demo-safe:

- the product must show a true contact/account system
- imported records must be explainable
- client 360 must feel coherent
- Oracle must feel additive, not confusing

## 10. Ownership Model

- Founder:
  - CRM, import, client graph, monolithic truth
- Sayan:
  - Oracle template and inventory/admin dependencies
- Sourik:
  - runtime route-family and orchestration dependencies

## 11. Ticket Breakdown

- infra-safe CRM rollout plan
- import replay validation
- synthetic client data staging
- route contract verification
- audit/review queue validation

## 12. Bottom Line

The next CRM implementation phase should launch into the infrastructure that already exists, not into an imaginary clean-room architecture.