Project_Velocity/.Agent Context/Sprint 1/Founder CRM and Platform Delivery Pack/12 - Deployment Operations and Release Readiness_ Founder CRM Platform.md

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.