Built the Sentinel Tab
This commit is contained in:
382
.Agent Context/Bibels/Desineuron Ops Control Plane Bibel.md
Normal file
382
.Agent Context/Bibels/Desineuron Ops Control Plane Bibel.md
Normal file
@@ -0,0 +1,382 @@
|
||||
# Desineuron Ops Control Plane Bibel
|
||||
|
||||
## Chapter Index
|
||||
|
||||
1. Purpose and Operating Model
|
||||
2. Architecture Map
|
||||
3. Linux Control-Plane Stack
|
||||
4. AWS Machine Profiles
|
||||
5. Market Data and Pricing Logic
|
||||
6. S3 Asset Model and Bucket Structure
|
||||
7. Model Hydration Lifecycle
|
||||
8. Model Ingest From Linux to S3
|
||||
9. Route Management Through the t4g Ingress
|
||||
10. Daily Operations Guide
|
||||
11. Launching a GPU Box
|
||||
12. Hydrating a Model
|
||||
13. Starting ComfyUI or Another Workload
|
||||
14. Tracking Session Time and Cost
|
||||
15. CSV Exports and Reporting
|
||||
16. Failure Recovery Runbooks
|
||||
17. Security Model and Access Control
|
||||
18. Adding a New Model
|
||||
19. Adding a New Instance Profile
|
||||
20. Adding a New Route or Service
|
||||
21. Backup and Restore
|
||||
22. Validated Live Behaviors
|
||||
23. Operator Retrieval Commands
|
||||
|
||||
## 1. Purpose and Operating Model
|
||||
|
||||
The Desineuron Ops Control Plane is the persistent Linux-hosted operator surface for AWS infrastructure. It centralizes machine launch, model hydration, workload control, cost estimation, route management, and audit history so the team no longer depends on ad hoc Windows terminals or fragile one-off SSH sessions.
|
||||
|
||||
Core planes:
|
||||
|
||||
- Linux box: control plane
|
||||
- S3: canonical asset plane
|
||||
- AWS GPU nodes: ephemeral compute plane
|
||||
- `t4g.micro` ingress: stable public edge
|
||||
|
||||
Current live endpoint:
|
||||
|
||||
- `https://ops.desineuron.in/login`
|
||||
|
||||
Current canonical S3 bucket:
|
||||
|
||||
- `desineuron-ops-control-plane-819079556187-us-east-1`
|
||||
|
||||
## 2. Architecture Map
|
||||
|
||||
```text
|
||||
Team
|
||||
-> ops.desineuron.in
|
||||
-> Linux control plane
|
||||
-> ops-web
|
||||
-> ops-api
|
||||
-> ops-worker
|
||||
-> ops-db
|
||||
-> AWS APIs
|
||||
-> S3 bucket
|
||||
-> ingress route helper
|
||||
-> GPU worker nodes
|
||||
```
|
||||
|
||||
## 3. Linux Control-Plane Stack
|
||||
|
||||
- Docker Compose stack under `/opt/desineuron-ops-control-plane`
|
||||
- PostgreSQL stores machine/session/job/audit state
|
||||
- API and web share the same FastAPI app
|
||||
- Worker refreshes markets, machines, and session costs
|
||||
- systemd keeps the stack persistent after reboot
|
||||
|
||||
Primary Linux service:
|
||||
|
||||
- `desineuron-ops-control-plane.service`
|
||||
|
||||
## 4. AWS Machine Profiles
|
||||
|
||||
Initial curated profiles:
|
||||
|
||||
- `g6-xlarge`
|
||||
- `g6-2xlarge`
|
||||
- `g6-4xlarge`
|
||||
- `g6-12xlarge`
|
||||
|
||||
Each profile contains:
|
||||
|
||||
- instance type
|
||||
- GPU label
|
||||
- vCPU / RAM
|
||||
- intended workloads
|
||||
- launch config: AMI, subnet, SGs, key, role/profile, root volume
|
||||
|
||||
## 5. Market Data and Pricing Logic
|
||||
|
||||
The control plane collects:
|
||||
|
||||
- instance offerings by region
|
||||
- on-demand pricing from AWS Pricing API
|
||||
- latest spot price history from EC2
|
||||
- runtime state of all visible machines
|
||||
|
||||
Estimated cost model v1:
|
||||
|
||||
- live instance price signal
|
||||
- gp3 storage cost estimate
|
||||
- public IPv4/EIP cost estimate
|
||||
|
||||
## 6. S3 Asset Model and Bucket Structure
|
||||
|
||||
Canonical bucket prefixes:
|
||||
|
||||
- `models/`
|
||||
- `workflows/`
|
||||
- `references/`
|
||||
- `outputs/`
|
||||
- `manifests/`
|
||||
- `bootstrap/`
|
||||
|
||||
Models are defined in the `model_catalog` table and hydrated to AWS NVMe on demand.
|
||||
|
||||
## 7. Model Hydration Lifecycle
|
||||
|
||||
1. Operator selects machine and model
|
||||
2. Worker ensures `s5cmd` exists on target
|
||||
3. Assets copy from S3 to `/opt/dlami/nvme/models/...`
|
||||
4. Operation result is logged
|
||||
5. Cache state is stored per machine
|
||||
|
||||
Hydration verification:
|
||||
|
||||
- if a manifest exists at `manifests/models/<model-key>.json`, the control plane verifies the expected files are present on the GPU node after copy
|
||||
|
||||
## 8. Model Ingest From Linux to S3
|
||||
|
||||
The control plane can now ingest a real model directory from the Linux box into S3 without manual bucket prep.
|
||||
|
||||
Source of truth on Linux:
|
||||
|
||||
- `/mnt/ServerStorage/ai-models/models`
|
||||
|
||||
Container mount inside the control plane:
|
||||
|
||||
- `/model-library`
|
||||
|
||||
Operator flow:
|
||||
|
||||
1. enter model key
|
||||
2. enter human label
|
||||
3. enter source path relative to the Linux model library root
|
||||
4. optionally set workload and compatibility tags
|
||||
5. submit `Upload to S3 + Generate Manifest`
|
||||
|
||||
Result:
|
||||
|
||||
- every file is uploaded under `models/<model-key>/`
|
||||
- manifest JSON is written to `manifests/models/<model-key>.json`
|
||||
- the model catalog entry is upserted in PostgreSQL
|
||||
- future hydrations can use that manifest for verification
|
||||
|
||||
## 9. Route Management Through the t4g Ingress
|
||||
|
||||
The ingress remains the stable public edge.
|
||||
|
||||
Managed route flow:
|
||||
|
||||
1. control plane writes hostname mapping through `manage_desineuron_routes.py`
|
||||
2. helper renders managed Caddy snippets
|
||||
3. Caddy reloads
|
||||
4. route becomes live
|
||||
|
||||
Static Linux-origin routes still flow through the existing tunnel/nginx path.
|
||||
|
||||
## 10. Daily Operations Guide
|
||||
|
||||
- open `ops.desineuron.in`
|
||||
- log in with internal ops credentials
|
||||
- review markets and costs
|
||||
- launch the required GPU profile
|
||||
- hydrate the model
|
||||
- start the workload
|
||||
- map the route if needed
|
||||
- export session CSVs for accounting or review
|
||||
|
||||
## 11. Launching a GPU Box
|
||||
|
||||
Use the Launch form in the GUI:
|
||||
|
||||
- choose profile
|
||||
- choose spot or on-demand
|
||||
- submit
|
||||
|
||||
Result:
|
||||
|
||||
- instance launches with Desineuron tags
|
||||
- session row is created
|
||||
- runtime and cost begin tracking
|
||||
- if spot capacity is unavailable, the UI records a failed launch job and shows an operator-facing error instead of crashing
|
||||
- the launcher automatically tries sibling subnets in the same VPC instead of hard-failing on one overloaded AZ
|
||||
|
||||
## 12. Hydrating a Model
|
||||
|
||||
Use the Hydrate form:
|
||||
|
||||
- choose machine
|
||||
- choose model
|
||||
|
||||
Hydration copies from S3 to the instance NVMe path.
|
||||
|
||||
## 13. Starting ComfyUI or Another Workload
|
||||
|
||||
Use the workload form:
|
||||
|
||||
- choose machine
|
||||
- choose workload
|
||||
|
||||
Current v1 workload profile:
|
||||
|
||||
- `comfyui`
|
||||
|
||||
## 14. Tracking Session Time and Cost
|
||||
|
||||
Each machine session is tracked in the DB and can be exported to CSV.
|
||||
|
||||
Cost components:
|
||||
|
||||
- compute
|
||||
- storage
|
||||
- public IPv4
|
||||
|
||||
v1 note:
|
||||
|
||||
- machine cost is estimate-based
|
||||
- instance pricing comes from AWS live data where available
|
||||
- storage and public IPv4 are blended in as estimated infrastructure cost
|
||||
|
||||
## 15. CSV Exports and Reporting
|
||||
|
||||
CSV export path:
|
||||
|
||||
- `exports/sessions_latest.csv`
|
||||
|
||||
Use this for:
|
||||
|
||||
- session duration review
|
||||
- estimated expenditure review
|
||||
- internal ops accounting
|
||||
|
||||
Current export path:
|
||||
|
||||
- `/opt/desineuron-ops-control-plane/exports/sessions_latest.csv`
|
||||
|
||||
The export is also logged in the database as a `csv_exports` record.
|
||||
|
||||
## 16. Failure Recovery Runbooks
|
||||
|
||||
If the worker stops:
|
||||
|
||||
- restart the systemd unit on Linux
|
||||
|
||||
If a GPU node is unhealthy:
|
||||
|
||||
- inspect machine state
|
||||
- inspect workload status
|
||||
- stop or terminate the node
|
||||
- relaunch from a clean profile
|
||||
|
||||
If route mapping fails:
|
||||
|
||||
- inspect the ingress helper
|
||||
- inspect Caddy reload status
|
||||
- verify the ops container has SSH access to the ingress node
|
||||
|
||||
If redeploy breaks PostgreSQL permissions:
|
||||
|
||||
- verify `/opt/desineuron-ops-control-plane/data/postgres` is owned by UID/GID `999:999`
|
||||
- restart `desineuron-ops-control-plane.service`
|
||||
- never sync runtime directories from repo into the live stack
|
||||
|
||||
## 17. Security Model and Access Control
|
||||
|
||||
- app is intended to be private
|
||||
- secrets stay on Linux, not in repo
|
||||
- actions are audited
|
||||
- AWS workers expose only minimal required ports
|
||||
- operator accounts can be provisioned as email-style usernames for team access
|
||||
|
||||
Current protected secrets:
|
||||
|
||||
- `/opt/desineuron-ops-control-plane/.env`
|
||||
- `/opt/desineuron-ops-control-plane/state/desineuron-l4-node.pem`
|
||||
|
||||
## 18. Adding a New Model
|
||||
|
||||
Preferred method:
|
||||
|
||||
1. place the model directory under `/mnt/ServerStorage/ai-models/models`
|
||||
2. use the `Model Library Ingest` form in the ops console
|
||||
3. let the control plane upload the files, create the manifest, and upsert the catalog entry
|
||||
|
||||
Fallback manual method:
|
||||
|
||||
1. upload to S3 canonical bucket
|
||||
2. add catalog entry
|
||||
3. define expected prefix and optional manifest/checksum
|
||||
|
||||
## 19. Adding a New Instance Profile
|
||||
|
||||
1. add curated profile definition
|
||||
2. set launch config
|
||||
3. verify market visibility
|
||||
4. test launch
|
||||
|
||||
## 20. Adding a New Route or Service
|
||||
|
||||
1. define hostname
|
||||
2. define target backend
|
||||
3. add route through GUI or helper
|
||||
4. reload ingress
|
||||
5. validate health
|
||||
|
||||
If the route is for a new public hostname:
|
||||
|
||||
6. create the Cloudflare DNS record pointing to `98.87.120.120`
|
||||
7. keep the record in `DNS only` mode
|
||||
8. validate TLS issuance on first public request
|
||||
|
||||
## 21. Backup and Restore
|
||||
|
||||
Persist:
|
||||
|
||||
- Postgres data
|
||||
- `.env`
|
||||
- exported CSVs
|
||||
- state directory
|
||||
- route helper state on ingress
|
||||
|
||||
Restore by:
|
||||
|
||||
- recreating the compose stack
|
||||
- restoring DB data
|
||||
- restoring config/env
|
||||
- validating machine, model, and route state
|
||||
|
||||
## 22. Validated Live Behaviors
|
||||
|
||||
As of the latest implementation pass, the following were validated against the live environment:
|
||||
|
||||
- `ops.desineuron.in` login and dashboard render correctly
|
||||
- `/api/markets/instances`, `/api/markets/pricing`, `/api/sessions`, `/api/costs`, and `/api/exports/csv` return live data
|
||||
- a `g6.xlarge` on-demand launch was executed through the control plane and then terminated through the same surface
|
||||
- a `g6.xlarge` spot launch failure was handled cleanly and recorded as `InsufficientInstanceCapacity`
|
||||
- managed ingress route upsert/delete was executed successfully through the route helper
|
||||
- session and audit data now persist because API DB writes are committed per request
|
||||
- a model ingest smoke test uploaded `ops-smoke-model` from the Linux model library into S3 and generated a manifest
|
||||
|
||||
## 23. Operator Retrieval Commands
|
||||
|
||||
Retrieve the admin password on Linux:
|
||||
|
||||
```bash
|
||||
sudo sed -n 's/^OPS_ADMIN_PASSWORD=//p' /opt/desineuron-ops-control-plane/.env
|
||||
```
|
||||
|
||||
Check stack health:
|
||||
|
||||
```bash
|
||||
sudo systemctl status desineuron-ops-control-plane.service
|
||||
sudo docker compose -f /opt/desineuron-ops-control-plane/docker-compose.yml ps
|
||||
```
|
||||
|
||||
Inspect recent API logs:
|
||||
|
||||
```bash
|
||||
sudo docker logs --tail 100 desineuron-ops-api
|
||||
sudo docker logs --tail 100 desineuron-ops-worker
|
||||
```
|
||||
|
||||
Inspect exports:
|
||||
|
||||
```bash
|
||||
ls -lah /opt/desineuron-ops-control-plane/exports
|
||||
```
|
||||
@@ -0,0 +1,796 @@
|
||||
# Kolkata Builder Intel and Meeting Map - April 2026
|
||||
|
||||
Document version: 1.0
|
||||
Prepared for: Founder outreach and builder meetings
|
||||
Document date: 2026-04-10
|
||||
Prepared by: Codex
|
||||
|
||||
## 1. Purpose
|
||||
|
||||
This document is not about selling to Rohit Darolia or Get My Ghar. It is a practical builder-intel sheet for meetings with Kolkata-region developers and project teams. The goal is to help you walk into each conversation with:
|
||||
|
||||
- the right project context
|
||||
- the right commercial frame
|
||||
- the right product wedge
|
||||
- the right meeting angle
|
||||
- the right escalation path after the first conversation
|
||||
|
||||
This is founder-use material. It is designed to help you get meetings, shape the first conversation, and move from "interesting AI demo" to "paid pilot / setup discussion."
|
||||
|
||||
## 2. Core Outreach Principle
|
||||
|
||||
Do not pitch all builders the same way.
|
||||
|
||||
Pitch structure should vary by context:
|
||||
|
||||
- premium project: lead with presentation quality, client handling precision, and shortening high-value sales cycles
|
||||
- mid-market project: lead with lead quality, rep productivity, faster follow-up, and inventory movement
|
||||
- multi-project builder: lead with property layer first, then show portfolio unlock after the second project
|
||||
- Kolkata-first relationship: lead with local proof and anti-SaaS private deployment
|
||||
|
||||
Always keep the opening frame as:
|
||||
|
||||
- private deployment
|
||||
- project-linked intelligence
|
||||
- sales-cycle compression
|
||||
- better control over representatives, leads, and presentation quality
|
||||
|
||||
## 3. What To Sell in the First Meeting
|
||||
|
||||
You are not trying to sell the full vision in the first meeting. You are trying to sell one of these:
|
||||
|
||||
1. A founder-led private pilot for one project
|
||||
2. A one-property setup with a 30-day implementation window
|
||||
3. A strategic workshop with the sales / marketing / CRM team using their current live pain points
|
||||
|
||||
The first meeting should not feel like:
|
||||
|
||||
- "buy our software"
|
||||
|
||||
It should feel like:
|
||||
|
||||
- "let us show you how your current project sales engine becomes sharper in 30 days without giving your data away"
|
||||
|
||||
## 4. Builder and Project Intel Map
|
||||
|
||||
## 4.1 Eden Realty - Eden Devprayag
|
||||
|
||||
### Public signal
|
||||
|
||||
- Project: `Eden Devprayag`
|
||||
- Location signal: Shibpur / Howrah riverfront
|
||||
- Official project messaging positions it as a premium river-facing development with 3, 4 and 5 BHK inventory and strong connectivity to Kolkata core.
|
||||
- A recent public report also says Eden launched the project alongside a larger `Rs 5,000 crore` Kolkata riverfront vision.
|
||||
|
||||
### Commercial reading
|
||||
|
||||
This is not a generic affordable housing story. This is premium aspiration plus location-led lifestyle positioning.
|
||||
|
||||
### Likely pain points
|
||||
|
||||
- premium lead qualification
|
||||
- low tolerance for weak reps or slow follow-up
|
||||
- project storytelling quality
|
||||
- investor / premium buyer presentation quality
|
||||
- cross-channel consistency
|
||||
|
||||
### Best Velocity wedge
|
||||
|
||||
Lead with:
|
||||
|
||||
- premium-property presentation intelligence
|
||||
- high-intent lead ranking
|
||||
- representative performance discipline
|
||||
- project-specific iPad demo and media workflows
|
||||
- executive visibility on premium lead handling
|
||||
|
||||
### Suggested opening line
|
||||
|
||||
"For a premium riverfront project, the cost of one mishandled serious buyer is too high. Velocity helps your sales team identify, present, and follow through on premium leads with far more control."
|
||||
|
||||
### Best first target roles
|
||||
|
||||
- Project Sales Head
|
||||
- Channel Sales Head
|
||||
- Marketing Head
|
||||
- CRM / digital sales operations lead
|
||||
|
||||
### Source links
|
||||
|
||||
- `https://www.eden-devprayag.com/`
|
||||
- `https://www.millenniumpost.in/bengal/eden-realty-unveils-eden-devprayag-eyes-rs-5k-cr-kolkata-riverfront-vision-648657`
|
||||
|
||||
## 4.2 Sugam Homes - Sugam Prakriti
|
||||
|
||||
### Public signal
|
||||
|
||||
- Project: `Sugam Prakriti`
|
||||
- Official positioning highlights South Kolkata / Sonarpur side connectivity and 2/3 BHK residential inventory.
|
||||
- Sugam publicly positions itself as a major Kolkata residential developer.
|
||||
|
||||
### Commercial reading
|
||||
|
||||
This looks like a broader-addressable, family-housing, mid-market sales motion rather than ultra-luxury.
|
||||
|
||||
### Likely pain points
|
||||
|
||||
- large lead pool with uneven quality
|
||||
- rep responsiveness
|
||||
- conversion leakage
|
||||
- source-to-site-visit drop-off
|
||||
- repeatable pitch discipline across a broader team
|
||||
|
||||
### Best Velocity wedge
|
||||
|
||||
Lead with:
|
||||
|
||||
- lead triage and prioritization
|
||||
- follow-up gap detection
|
||||
- rep productivity monitoring
|
||||
- campaign/source attribution
|
||||
- project-level operating control for faster movement
|
||||
|
||||
### Suggested opening line
|
||||
|
||||
"For projects with wider funnel volume, the biggest loss is not lack of leads but poor prioritization and inconsistent follow-up. Velocity fixes that operating layer."
|
||||
|
||||
### Best first target roles
|
||||
|
||||
- Sales Head
|
||||
- Channel Partner sales lead
|
||||
- CRM Head
|
||||
- Marketing operations lead
|
||||
|
||||
### Source links
|
||||
|
||||
- `https://prakriti.sugamhomes.com/`
|
||||
- `https://sugamhomes.com/`
|
||||
|
||||
## 4.3 Atri Group - Atri Aqua
|
||||
|
||||
### Public signal
|
||||
|
||||
- Project: `Atri Aqua`
|
||||
- Official messaging emphasizes location access and water-led thematic identity.
|
||||
- Public material points to South Kolkata / Southern Bypass connectivity.
|
||||
|
||||
### Commercial reading
|
||||
|
||||
This is a positioning-heavy residential project where presentation quality and differentiation matter.
|
||||
|
||||
### Likely pain points
|
||||
|
||||
- standing out against nearby residential competition
|
||||
- making project identity memorable
|
||||
- pushing reps beyond generic brochure selling
|
||||
- balancing volume and project storytelling
|
||||
|
||||
### Best Velocity wedge
|
||||
|
||||
Lead with:
|
||||
|
||||
- AI-assisted presentation layer
|
||||
- property-specific visual and storytelling workflows
|
||||
- rep guidance on buyer-fit
|
||||
- project-level lead intelligence
|
||||
|
||||
### Suggested opening line
|
||||
|
||||
"When multiple projects compete in the same decision space, the winner is often the one that presents and follows up with more precision. Velocity helps your team do that repeatedly."
|
||||
|
||||
### Best first target roles
|
||||
|
||||
- Project Director
|
||||
- Sales Head
|
||||
- Marketing lead
|
||||
- promoter / founder if reachable
|
||||
|
||||
### Source links
|
||||
|
||||
- `https://atrigroup.in/atri-aqua/`
|
||||
- `https://atrigroup.in/`
|
||||
|
||||
## 4.4 Atri Group - Atri Surya Toron
|
||||
|
||||
### Public signal
|
||||
|
||||
- Project: `Atri Surya Toron`
|
||||
- Public descriptions place it in Boral / Jayanpur, off Southern Bypass, with a larger multi-tower footprint and broader-market positioning.
|
||||
|
||||
### Commercial reading
|
||||
|
||||
This feels like a stronger operational-sales case than a pure premium-brand case.
|
||||
|
||||
### Likely pain points
|
||||
|
||||
- funnel management
|
||||
- project-scale rep control
|
||||
- channel alignment
|
||||
- inventory prioritization
|
||||
- site-visit to closure conversion
|
||||
|
||||
### Best Velocity wedge
|
||||
|
||||
Lead with:
|
||||
|
||||
- project sales control room
|
||||
- rep monitoring
|
||||
- site-visit follow-up intelligence
|
||||
- stage-by-stage conversion bottleneck visibility
|
||||
|
||||
### Suggested opening line
|
||||
|
||||
"Large residential projects usually do not lose only because demand is weak. They lose because operating discipline collapses between lead, visit, persuasion, and follow-up."
|
||||
|
||||
### Best first target roles
|
||||
|
||||
- Project Sales Head
|
||||
- Channel Sales Lead
|
||||
- CRM lead
|
||||
|
||||
### Source links
|
||||
|
||||
- `https://suryatoron.in/`
|
||||
- `https://www.wbpcb.gov.in/files/Fr-07-2023-07-55-3011th%20SEACnw%20Minutes.pdf`
|
||||
|
||||
## 4.5 Siddha Group - Siddha Suburbia Bungalow
|
||||
|
||||
### Public signal
|
||||
|
||||
- Project known in the market as bungalow/villa-led premium suburban inventory under Siddha branding.
|
||||
- Your listed price point places it firmly in high-value territory.
|
||||
|
||||
### Commercial reading
|
||||
|
||||
This is a premium storytelling and premium buyer handling opportunity.
|
||||
|
||||
### Likely pain points
|
||||
|
||||
- serious buyer identification
|
||||
- premium buyer experience
|
||||
- project presentation depth
|
||||
- longer and more consultative conversion cycles
|
||||
|
||||
### Best Velocity wedge
|
||||
|
||||
Lead with:
|
||||
|
||||
- premium lead scoring
|
||||
- executive-quality presentation workflows
|
||||
- guided project narrative for high-value inventory
|
||||
- centralized intelligence on high-intent buyers and rep response quality
|
||||
|
||||
### Suggested opening line
|
||||
|
||||
"At this ticket size, even a small improvement in identifying and handling serious buyers creates disproportionate value."
|
||||
|
||||
### Best first target roles
|
||||
|
||||
- Luxury / premium sales lead
|
||||
- Group sales head
|
||||
- marketing head
|
||||
|
||||
### Source links
|
||||
|
||||
- Siddha corporate: `https://www.siddhagroup.com/`
|
||||
|
||||
## 4.6 Merlin Group - Merlin Avana
|
||||
|
||||
### Public signal
|
||||
|
||||
- Project: `Merlin Avana`
|
||||
- Official project messaging positions it near Tollygunge / Motilal Gupta Road and frames it as premium South Kolkata living.
|
||||
- Merlin publicly presents itself as a long-established developer with projects across multiple Indian cities.
|
||||
|
||||
### Commercial reading
|
||||
|
||||
Merlin is a brand-sensitive, reputation-aware builder. Meeting quality and framing will matter.
|
||||
|
||||
### Likely pain points
|
||||
|
||||
- premium buyer funnel hygiene
|
||||
- high-quality digital and in-person presentation
|
||||
- consistency across sales representatives and channel partners
|
||||
- executive visibility into project demand quality
|
||||
|
||||
### Best Velocity wedge
|
||||
|
||||
Lead with:
|
||||
|
||||
- premium sales operating system
|
||||
- channel partner and internal team control
|
||||
- property-specific intelligent presentation layer
|
||||
- executive monitoring without losing project-level detail
|
||||
|
||||
### Suggested opening line
|
||||
|
||||
"The stronger the brand, the more damaging weak sales execution becomes. Velocity protects brand-level sales quality at the project layer."
|
||||
|
||||
### Best first target roles
|
||||
|
||||
- Sales Director
|
||||
- Channel Head
|
||||
- Marketing Director
|
||||
- digital transformation / CRM lead if present
|
||||
|
||||
### Source links
|
||||
|
||||
- `https://www.merlinprojects.com/projects/avana/`
|
||||
- `https://www.merlinaquaville.com/`
|
||||
|
||||
## 4.7 DTC Group - DTC Good Earth
|
||||
|
||||
### Public signal
|
||||
|
||||
- Project: `DTC Good Earth`
|
||||
- Public messaging frames it as a Madhyamgram / North Kolkata project with balanced lifestyle positioning.
|
||||
- DTC presents itself as a diversified group with a long business history and real-estate operations.
|
||||
|
||||
### Commercial reading
|
||||
|
||||
This is a practical operating-efficiency pitch, not a glamour-first pitch.
|
||||
|
||||
### Likely pain points
|
||||
|
||||
- rep efficiency
|
||||
- multi-source lead prioritization
|
||||
- operational leakage between inquiry and visit
|
||||
- structured follow-up for a broader market segment
|
||||
|
||||
### Best Velocity wedge
|
||||
|
||||
Lead with:
|
||||
|
||||
- lead operations control room
|
||||
- conversion funnel visibility
|
||||
- follow-up discipline
|
||||
- representative accountability
|
||||
|
||||
### Suggested opening line
|
||||
|
||||
"For a project like this, the difference between average and strong inventory movement is not only brand pull. It is how tightly the sales operation behaves every day."
|
||||
|
||||
### Best first target roles
|
||||
|
||||
- Project Sales Lead
|
||||
- Channel team lead
|
||||
- CRM / telecalling operations lead
|
||||
|
||||
### Source links
|
||||
|
||||
- `https://dtcgroup.in/dtc-good-earth/`
|
||||
- `https://dtcgroup.in/contact/`
|
||||
|
||||
## 4.8 Siddha Group - Siddha Serena
|
||||
|
||||
### Public signal
|
||||
|
||||
- Project: `Siddha Serena`
|
||||
- Official positioning places it in New Town with 2/3/4 BHK inventory and dual-gate access messaging.
|
||||
- Siddha publicly presents strong brand heritage and award-backed credibility.
|
||||
|
||||
### Commercial reading
|
||||
|
||||
This is a strong fit for a “modern premium project, structured operating intelligence” pitch.
|
||||
|
||||
### Likely pain points
|
||||
|
||||
- managing premium-but-broad demand bands
|
||||
- aligning marketing and sales
|
||||
- rep productivity visibility
|
||||
- maintaining premium project perception at scale
|
||||
|
||||
### Best Velocity wedge
|
||||
|
||||
Lead with:
|
||||
|
||||
- premium-project funnel discipline
|
||||
- source-to-closure intelligence
|
||||
- project presentation personalization
|
||||
- management monitoring layer
|
||||
|
||||
### Suggested opening line
|
||||
|
||||
"For a branded New Town premium project, the strongest differentiator is often not only product quality but how intelligently the sales engine behaves around the product."
|
||||
|
||||
### Best first target roles
|
||||
|
||||
- Project Sales Head
|
||||
- Marketing Head
|
||||
- CRM Head
|
||||
|
||||
### Source links
|
||||
|
||||
- `https://www.siddhagroup.com/projects/siddha-serena/`
|
||||
- `https://www.siddhagroup.com/`
|
||||
|
||||
## 4.9 Siddha Group - Siddha Sky Waterfront
|
||||
|
||||
### Public signal
|
||||
|
||||
- Project: `Siddha Sky`
|
||||
- Official messaging positions it as a luxury high-rise experience with skyline differentiation and prestige architecture.
|
||||
|
||||
### Commercial reading
|
||||
|
||||
This is ideal for a premium, reputation-preserving, white-glove pitch.
|
||||
|
||||
### Likely pain points
|
||||
|
||||
- premium buyer experience consistency
|
||||
- VIP lead handling
|
||||
- long-cycle decision support
|
||||
- representation quality across internal and channel teams
|
||||
|
||||
### Best Velocity wedge
|
||||
|
||||
Lead with:
|
||||
|
||||
- premium lead qualification
|
||||
- executive oversight for high-value buyer handling
|
||||
- high-impact project presentation flows
|
||||
- property-specific AI-assisted sales storytelling
|
||||
|
||||
### Suggested opening line
|
||||
|
||||
"At this level of inventory, one mishandled high-intent lead costs far more than the software. The operating layer needs to be premium too."
|
||||
|
||||
### Best first target roles
|
||||
|
||||
- luxury sales lead
|
||||
- business head
|
||||
- marketing director
|
||||
|
||||
### Source links
|
||||
|
||||
- `https://www.siddhagroup.com/projects/siddha-sky/`
|
||||
- `https://www.siddhagroup.com/`
|
||||
|
||||
## 4.10 Godrej Properties - Godrej Blue
|
||||
|
||||
### Public signal
|
||||
|
||||
- Project: `Godrej Blue`
|
||||
- Official Godrej page places it at BL Saha Road / New Alipore in Kolkata and positions it as premium 3 and 4 BHK inventory.
|
||||
- Godrej Properties is a nationally recognized developer, so the bar for enterprise credibility is much higher.
|
||||
|
||||
### Commercial reading
|
||||
|
||||
Do not approach this like a simple project pitch. Approach it like an enterprise-grade sales modernization wedge.
|
||||
|
||||
### Likely pain points
|
||||
|
||||
- regional project sales performance visibility
|
||||
- maintaining brand-standard customer handling
|
||||
- high-quality project presentation
|
||||
- internal approval and process discipline
|
||||
|
||||
### Best Velocity wedge
|
||||
|
||||
Lead with:
|
||||
|
||||
- one-project pilot framed as enterprise-ready
|
||||
- private deployment and data sovereignty
|
||||
- project-linked sales intelligence
|
||||
- repeatable rollout model for future properties if the pilot works
|
||||
|
||||
### Suggested opening line
|
||||
|
||||
"We are not asking you to adopt a SaaS tool across the organization. We are proposing a private project-level operating layer that can prove value on one property and later scale across more assets."
|
||||
|
||||
### Best first target roles
|
||||
|
||||
- Regional Sales Head
|
||||
- Project Sales Head
|
||||
- Digital / transformation lead
|
||||
- CRM or sales operations leadership
|
||||
|
||||
### Source links
|
||||
|
||||
- `https://www.godrejproperties.com/landing-page/kolkata/residential/godrej-blue/`
|
||||
- `https://www.godrejproperties.com/`
|
||||
|
||||
## 4.11 DTC Group - DTC Sojon
|
||||
|
||||
### Public signal
|
||||
|
||||
- Project: `DTC Sojon`
|
||||
- Public messaging places it in the Joka / Behala side and positions it as a large lifestyle residential project.
|
||||
|
||||
### Commercial reading
|
||||
|
||||
This is a project where structured selling and disciplined team behavior should resonate strongly.
|
||||
|
||||
### Likely pain points
|
||||
|
||||
- volume funnel management
|
||||
- representative productivity
|
||||
- site-visit conversion
|
||||
- competition within the Joka / Behala belt
|
||||
|
||||
### Best Velocity wedge
|
||||
|
||||
Lead with:
|
||||
|
||||
- project sales command center
|
||||
- lead-to-visit-to-booking analytics
|
||||
- rep-wise performance clarity
|
||||
- project-specific AI selling assistance
|
||||
|
||||
### Suggested opening line
|
||||
|
||||
"Projects in a competitive suburban belt do not only need more marketing. They need a tighter operating system between lead capture and booking."
|
||||
|
||||
### Best first target roles
|
||||
|
||||
- Project Head
|
||||
- Channel Head
|
||||
- Sales operations / CRM lead
|
||||
|
||||
### Source links
|
||||
|
||||
- `https://dtcprojectjoka.com/`
|
||||
- `https://sojonjoka.com/`
|
||||
|
||||
## 4.12 Shriram Properties - Shriram Grand City
|
||||
|
||||
### Public signal
|
||||
|
||||
- Project: `Shriram Grand City`
|
||||
- Public material positions it as a very large township-style development at Uttarpara / Hindmotor scale, often described around `314 acres`.
|
||||
- Shriram is a listed developer and will expect more operational seriousness.
|
||||
|
||||
### Commercial reading
|
||||
|
||||
This is not only a project pitch. This is a township operating pitch.
|
||||
|
||||
### Likely pain points
|
||||
|
||||
- massive inventory movement over time
|
||||
- phase-wise sales intelligence
|
||||
- wide lead funnel and long-cycle nurturing
|
||||
- channel ecosystem complexity
|
||||
- monitoring across a large master development
|
||||
|
||||
### Best Velocity wedge
|
||||
|
||||
Lead with:
|
||||
|
||||
- township-scale project monitoring
|
||||
- phase and cluster-level intelligence
|
||||
- representative and channel control
|
||||
- long-cycle conversion management
|
||||
|
||||
### Suggested opening line
|
||||
|
||||
"For a development of this scale, the problem is not just sales. It is maintaining intelligence and discipline across a very large and long-lived inventory engine."
|
||||
|
||||
### Best first target roles
|
||||
|
||||
- Project Sales Director
|
||||
- business head for east / Kolkata
|
||||
- CRM / digital sales head
|
||||
- marketing leadership
|
||||
|
||||
### Source links
|
||||
|
||||
- `https://shriram-grandcity.com/`
|
||||
- `https://www.shriramproperties.com/sites/default/files/assets/pdf/annual_reports/Annual%20Report%20FY23_LoRes.pdf`
|
||||
|
||||
## 4.13 Godrej Properties - Godrej Elevate
|
||||
|
||||
### Public signal
|
||||
|
||||
- Project: `Elevate at Godrej Se7en`
|
||||
- Official Godrej page places it in Joka near Diamond Harbour Road / Pailan and positions it as a residential offering starting around your listed band.
|
||||
|
||||
### Commercial reading
|
||||
|
||||
This is a cleaner wedge than Godrej Blue because it can be framed as a project-level pilot before larger enterprise adoption.
|
||||
|
||||
### Likely pain points
|
||||
|
||||
- project-level funnel discipline
|
||||
- source quality
|
||||
- rep productivity
|
||||
- conversion in a developing corridor
|
||||
|
||||
### Best Velocity wedge
|
||||
|
||||
Lead with:
|
||||
|
||||
- one-property pilot
|
||||
- private deployment
|
||||
- lead quality scoring
|
||||
- rep workflow discipline
|
||||
- future multi-property rollout logic if it succeeds
|
||||
|
||||
### Suggested opening line
|
||||
|
||||
"The cleanest way to prove value is to install Velocity against one project, improve sales operating discipline measurably, and then decide how far to expand."
|
||||
|
||||
### Best first target roles
|
||||
|
||||
- Project Sales Head
|
||||
- regional digital / CRM lead
|
||||
- transformation-minded sales leader
|
||||
|
||||
### Source links
|
||||
|
||||
- `https://www.godrejproperties.com/kolkata/residential/elevate-godrej-se7en`
|
||||
- `https://www.godrejproperties.com/blog/experience-elevate-at-godrej-seven-in-kolkata`
|
||||
|
||||
## 4.14 Ambuja Neotia Group - Ambuja Utpaala
|
||||
|
||||
### Public signal
|
||||
|
||||
- Project: `Utpalaa`
|
||||
- Official site positions it off EM Bypass near Ruby and frames it as a premium residential project.
|
||||
- Ambuja Neotia is a major Kolkata corporate house with diversified business interests beyond real estate.
|
||||
|
||||
### Commercial reading
|
||||
|
||||
This is a high-credibility, high-bar conversation. Do not pitch this as a startup tool. Pitch it as a private strategic operating layer.
|
||||
|
||||
### Likely pain points
|
||||
|
||||
- premium project conversion quality
|
||||
- executive visibility without operational clutter
|
||||
- cross-team sales coordination
|
||||
- maintaining a premium buyer experience
|
||||
|
||||
### Best Velocity wedge
|
||||
|
||||
Lead with:
|
||||
|
||||
- private deployment and data control
|
||||
- premium property sales intelligence
|
||||
- monitoring layer for leadership
|
||||
- property-specific generation and presentation capability
|
||||
|
||||
### Suggested opening line
|
||||
|
||||
"For a premium urban project, Velocity is not about more dashboards. It is about giving leadership and sales teams a private operating edge that improves how serious buyers are identified, handled, and converted."
|
||||
|
||||
### Best first target roles
|
||||
|
||||
- Business Head
|
||||
- Project Sales Head
|
||||
- Marketing Head
|
||||
- leadership office / strategic initiatives contact if available
|
||||
|
||||
### Source links
|
||||
|
||||
- `https://utpalaa.com/`
|
||||
- `https://www.ambujaneotia.com/`
|
||||
|
||||
## 4.15 Srijan Group / Srijan Realty
|
||||
|
||||
### Public signal
|
||||
|
||||
- Srijan publicly positions itself as one of the leading eastern India developers, with presence in Kolkata and beyond.
|
||||
- Public materials describe the company as having evolved from real-estate marketing roots into development.
|
||||
|
||||
### Commercial reading
|
||||
|
||||
Srijan is especially relevant because the company history itself suggests sensitivity to market movement, buyer behavior, and project commercialization.
|
||||
|
||||
### Likely pain points
|
||||
|
||||
- multi-project management
|
||||
- balancing project-specific selling with higher-level monitoring
|
||||
- structured growth from one property operating layer into portfolio intelligence
|
||||
|
||||
### Best Velocity wedge
|
||||
|
||||
Lead with:
|
||||
|
||||
- one-project deployment first
|
||||
- portfolio intelligence unlocked as more properties are added
|
||||
- private deployment
|
||||
- channel and sales monitoring discipline
|
||||
|
||||
### Suggested opening line
|
||||
|
||||
"Velocity is strongest when it starts at the property layer and then grows into portfolio intelligence as more projects enter the operating system. That maps well to how serious builders actually scale."
|
||||
|
||||
### Best first target roles
|
||||
|
||||
- Sales Head
|
||||
- CRM / operations head
|
||||
- management / promoter office
|
||||
- digital transformation or strategic initiatives lead
|
||||
|
||||
### Source links
|
||||
|
||||
- `https://www.srijanrealty.com/`
|
||||
- `https://www.srijanrealty.com/contact/`
|
||||
|
||||
## 5. Builder Priority Ranking for Meetings
|
||||
|
||||
Suggested meeting priority based on strategic leverage, not just prestige:
|
||||
|
||||
1. `Ambuja Neotia`
|
||||
2. `Godrej Properties`
|
||||
3. `Siddha Group`
|
||||
4. `Srijan Realty`
|
||||
5. `Merlin Group`
|
||||
6. `Shriram Properties`
|
||||
7. `Eden Realty`
|
||||
8. `Sugam Homes`
|
||||
9. `DTC Group`
|
||||
10. `Atri Group`
|
||||
|
||||
Reasoning:
|
||||
|
||||
- the top half gives you stronger brand leverage if meetings convert
|
||||
- the bottom half may convert faster and become easier pilots
|
||||
- you want a mix of prestige targets and practical early adopters
|
||||
|
||||
## 6. Recommended Meeting Strategy
|
||||
|
||||
### 6.1 First Meeting Goal
|
||||
|
||||
Do not try to close the full commercial package in meeting one.
|
||||
|
||||
Meeting one goal:
|
||||
|
||||
- secure a second conversation with the actual project or sales operating team
|
||||
|
||||
### 6.2 What To Show
|
||||
|
||||
Show only four things:
|
||||
|
||||
1. Project-level monitoring layer
|
||||
2. Lead prioritization and rep accountability
|
||||
3. Property-specific presentation / generation layer
|
||||
4. Portfolio unlock logic after the second property
|
||||
|
||||
### 6.3 What Not To Show Too Early
|
||||
|
||||
Avoid drowning them in:
|
||||
|
||||
- internal architecture
|
||||
- agent terminology
|
||||
- too many workflow variants
|
||||
- broad platform fantasies
|
||||
- generic AI claims
|
||||
|
||||
## 7. Questions To Ask in Builder Meetings
|
||||
|
||||
Use these to diagnose pain without sounding generic:
|
||||
|
||||
1. Where do you currently lose the most momentum between lead capture and booking?
|
||||
2. How do you know which representatives are handling the best leads properly?
|
||||
3. How do you currently decide which project should be pushed for which buyer profile?
|
||||
4. How consistent is the project presentation experience across your team and channel partners?
|
||||
5. If you had one project where sales operations became visibly sharper in 30 days, what would that be worth to you?
|
||||
|
||||
## 8. Recommended Close for Meeting One
|
||||
|
||||
Your close should be:
|
||||
|
||||
"Let us take one project, deploy privately, and prove that your sales engine becomes sharper within a month. If we cannot demonstrate operational improvement, we should not ask you to scale it."
|
||||
|
||||
That is far stronger than:
|
||||
|
||||
"Would you like to buy the platform?"
|
||||
|
||||
## 9. Final Founder Recommendation
|
||||
|
||||
For builders, your winning motion is:
|
||||
|
||||
- one project
|
||||
- one private deployment
|
||||
- one measurable improvement story
|
||||
- one clear expansion path
|
||||
|
||||
Do not try to win on features. Win on:
|
||||
|
||||
- seriousness
|
||||
- privacy
|
||||
- project-level value
|
||||
- operational intelligence
|
||||
- founder conviction
|
||||
|
||||
If you can get the first meaningful builder to say, "show me this on one project," the real sales motion has begun.
|
||||
2319
.Agent Context/Sprint 1/Project Velocity - The Oracle.md
Normal file
2319
.Agent Context/Sprint 1/Project Velocity - The Oracle.md
Normal file
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,239 @@
|
||||
### Software Requirements Specification (SRS): The Sentinel Quantum Dynamics Engine & Active Pipeline
|
||||
|
||||
Updated: April 2, 2026
|
||||
Status: Current truth after code implementation and AWS/NVMe deployment recovery
|
||||
|
||||
#### 1. Purpose
|
||||
|
||||
The Sentinel is the biometric and engagement intelligence module inside Project Velocity. It combines local perception capture, broker-facing live session controls, scene-aware biometric scoring, trackable asset notifications, and automated lead enrichment into one operational pipeline.
|
||||
|
||||
The current implementation is no longer a purely planned architecture. The backend, frontend session flow, PostgreSQL schema, CCTV ingestion path, scene upload path, notification center, and test harness all exist in the repository. The live backend deployment has also been rebuilt on the AWS NVMe-backed node.
|
||||
|
||||
#### 2. Current Architectural Truth
|
||||
|
||||
The architecture now operates as four cooperating layers:
|
||||
|
||||
1. Perception Layer
|
||||
MediaPipe Face Landmarker runs in the frontend via `app/src/hooks/useMediapipeFaceLandmarker.ts`. The browser captures webcam frames locally and emits compact blend-shape packets rather than raw video.
|
||||
|
||||
2. Application Layer
|
||||
FastAPI runs from `backend/main.py`. It exposes Sentinel WebSocket endpoints, Vault endpoints, Scenes upload endpoints, CCTV ingestion endpoints, and authentication.
|
||||
|
||||
3. Data Layer
|
||||
PostgreSQL is the system of record. The core schema is in `backend/db/schema.sql` and `backend/db/schema_addendum.sql`. Session, CCTV, vault, consent, scene maps, and omnichannel logs are persisted here.
|
||||
|
||||
4. Reasoning Layer
|
||||
NemoClaw prompt logic is implemented in `backend/services/nemoclaw_client.py`. The current production-truth inference path is NVIDIA-hosted OpenAI-compatible chat completions, not local Ollama. OpenShell and Ollama still exist on the node as related runtime infrastructure, but the FastAPI backend currently uses NVIDIA as the primary scoring path.
|
||||
|
||||
#### 3. Current Runtime Topology
|
||||
|
||||
AWS node public IP as of April 2, 2026: `54.152.236.10`
|
||||
|
||||
Ports:
|
||||
|
||||
- `22` SSH
|
||||
- `443` nginx TLS reverse proxy
|
||||
- `127.0.0.1:8001` FastAPI/Uvicorn backend
|
||||
- `127.0.0.1:5432` PostgreSQL
|
||||
- `8080` OpenShell gateway / NemoClaw gateway bootstrap target
|
||||
- `11434` local Ollama runtime
|
||||
|
||||
Storage and runtime paths:
|
||||
|
||||
- Backend release root: `/opt/dlami/nvme/velocity/current`
|
||||
- Backend environment file: `/opt/dlami/nvme/velocity/env`
|
||||
- Backend virtualenv: `/opt/dlami/nvme/velocity/venv`
|
||||
- Backend TLS cert/key: `/opt/dlami/nvme/velocity/tls/velocity.crt` and `/opt/dlami/nvme/velocity/tls/velocity.key`
|
||||
- Prompt directory: `/opt/dlami/nvme/nemoclaw/prompts`
|
||||
- PostgreSQL data directory: `/opt/dlami/nvme/pgdata/14/velocity`
|
||||
- Asset directory: `/opt/dlami/nvme/assets`
|
||||
- Marketing-video directory: `/opt/dlami/nvme/assets/videos`
|
||||
- Marketing-video catalog: `/opt/dlami/nvme/assets/videos/catalog.json`
|
||||
|
||||
Systemd units:
|
||||
|
||||
- `velocity-backend.service`
|
||||
- `postgresql@14-velocity.service`
|
||||
- `nginx`
|
||||
- `nemoclaw-velocity.service`
|
||||
|
||||
#### 4. Frontend Truth
|
||||
|
||||
Implemented frontend components:
|
||||
|
||||
- `app/src/components/modules/Sentinel.tsx`
|
||||
Provides the Sentinel subtab structure with `Overview` and `Live Session`.
|
||||
|
||||
- `app/src/components/modules/sentinel/SentinelLiveSession.tsx`
|
||||
Implements the live workflow with:
|
||||
`select-video -> select-mode -> select-lead -> session -> summary`
|
||||
It now also includes scene CSV upload in the video-management flow, searchable assigned-mode lead selection, and hover-preview marketing video cards sourced from the backend catalog.
|
||||
|
||||
- `app/src/components/modules/sentinel/PerceptionPlayer.tsx`
|
||||
Plays the video, opens webcam capture, emits biometric packets every 500ms, receives QD updates, and closes the session through the backend on video end.
|
||||
|
||||
- `app/src/components/layout/NotificationCenter.tsx`
|
||||
Displays live notifications from the backend for vault opens, QD spikes, and lead-tagging events.
|
||||
|
||||
- `app/src/hooks/useVelocitySocket.ts`
|
||||
Uses the correct backend WebSocket namespace:
|
||||
`/api/sentinel/ws/notifications`
|
||||
`/api/sentinel/ws/perception`
|
||||
|
||||
#### 5. Backend Truth
|
||||
|
||||
Implemented backend routers:
|
||||
|
||||
- `backend/routers/sentinel.py`
|
||||
Handles:
|
||||
`/api/sentinel/ws/notifications`
|
||||
`/api/sentinel/ws/perception`
|
||||
`/api/sentinel/consent`
|
||||
`/api/sentinel/session/complete`
|
||||
`/api/sentinel/tag-lead`
|
||||
`/api/sentinel/qd-score/{lead_id}`
|
||||
|
||||
- `backend/routers/vault.py`
|
||||
Handles trackable asset delivery and `WS_ASSET_OPENED` broadcast.
|
||||
|
||||
- `backend/routers/scenes.py`
|
||||
Handles:
|
||||
`POST /api/scenes/upload`
|
||||
`GET /api/scenes/{video_asset_id}`
|
||||
|
||||
- `backend/routers/videos.py`
|
||||
Handles:
|
||||
`GET /api/videos/marketing`
|
||||
Returns catalog-driven or directory-scanned marketing videos for the live-session picker.
|
||||
|
||||
- `backend/routers/cctv.py`
|
||||
Handles:
|
||||
`POST /api/cctv/event`
|
||||
`POST /api/cctv/finalize-auto-mode`
|
||||
|
||||
Implemented backend services:
|
||||
|
||||
- `backend/services/nemoclaw_client.py`
|
||||
NVIDIA API primary inference client, scene-aware QD scoring, lead tagging, CCTV visitor profiling, and malformed JSON recovery.
|
||||
|
||||
- `backend/services/auto_mode_matcher.py`
|
||||
Post-session matching for auto mode using plate history, tag overlap, and fallback auto-lead creation.
|
||||
|
||||
- `backend/db/pool.py`
|
||||
asyncpg connection pool for FastAPI.
|
||||
|
||||
#### 6. Database Truth
|
||||
|
||||
The following tables are part of the current truth:
|
||||
|
||||
- `users_and_roles`
|
||||
- `leads_intelligence`
|
||||
- `velocity_vault_assets`
|
||||
- `omnichannel_logs`
|
||||
- `consent_log`
|
||||
- `video_scene_maps`
|
||||
- `perception_sessions`
|
||||
- `cctv_events`
|
||||
|
||||
The addendum schema is no longer optional planning material. It is part of the required production schema.
|
||||
|
||||
#### 6A. Marketing Video Asset Truth
|
||||
|
||||
The Sentinel live-session picker is no longer hardcoded to mock cards. The current truth is:
|
||||
|
||||
- The frontend requests `GET /api/videos/marketing`
|
||||
- The backend reads `/opt/dlami/nvme/assets/videos/catalog.json` when present
|
||||
- The backend falls back to recursive video discovery inside `/opt/dlami/nvme/assets/videos`
|
||||
- The selected asset is streamed through `/assets/videos/<file>`
|
||||
- The four current walkthrough assets are:
|
||||
- `eden-devprayag.mp4`
|
||||
- `sugam-prakriti.mp4`
|
||||
- `atri-aqua.mp4`
|
||||
- `atri-surya-toron.mp4`
|
||||
|
||||
This matters because adding more walkthrough assets is now a backend-content operation, not a frontend rebuild requirement.
|
||||
|
||||
#### 7. NemoClaw / Reasoning Truth
|
||||
|
||||
The original plan assumed local agent-contained reasoning through OpenShell plus local Ollama. That is no longer the active scoring path.
|
||||
|
||||
Current truth:
|
||||
|
||||
- The backend client uses NVIDIA-hosted OpenAI-compatible completions as primary inference.
|
||||
- Current primary model: `nvidia/nemotron-3-super-120b-a12b`
|
||||
- Current fallback model: `nvidia/llama-3.3-nemotron-super-49b-v1`
|
||||
- Local Ollama remains installed on `11434` but is not the active backend primary.
|
||||
- OpenShell gateway remains present on `8080` and is bootstrapped by `nemoclaw-velocity.service`.
|
||||
|
||||
Reason for this change:
|
||||
|
||||
- The local Ollama path was not reliably producing the strict JSON contract needed for QD scoring.
|
||||
- The NVIDIA path is OpenAI-compatible and easier to integrate directly from FastAPI.
|
||||
- The NVIDIA path is now what the code and live environment are configured to use.
|
||||
|
||||
#### 8. Milestone Truth
|
||||
|
||||
Milestone 1: Complete
|
||||
Database schema, auth dependencies, store/types, and live PostgreSQL deployment exist.
|
||||
|
||||
Milestone 2: Complete
|
||||
Vault generation, notification ingestion, and frontend notification center are implemented.
|
||||
|
||||
Milestone 3: Complete
|
||||
Perception pipeline frontend, live session flow, and packet emission are implemented.
|
||||
|
||||
Milestone 4: Complete
|
||||
NemoClaw prompt system and backend scoring/tagging routes are implemented. The inference truth changed from local Ollama-first planning to NVIDIA-primary production use.
|
||||
|
||||
Milestone 5: Code complete, operational feed integration still pending
|
||||
CCTV router, OCR bridge script, and auto-mode matcher exist. What remains is wiring a real ONVIF/RTSP/OCR producer into `/api/cctv/event`.
|
||||
|
||||
Milestone 6: Complete
|
||||
Scene upload backend, scene lookup, frontend upload UI, and scene-aware packet correlation are implemented.
|
||||
|
||||
Milestone 7: Complete
|
||||
NVMe-backed backend deployment, env file, PostgreSQL, systemd, nginx TLS, and prompt placement are in place.
|
||||
|
||||
Milestone 8: Complete at repo test level, still desirable to run a broker-facing live acceptance pass
|
||||
Backend pytest tests and frontend Playwright tests exist and pass locally.
|
||||
|
||||
#### 9. Known Risks
|
||||
|
||||
1. NVIDIA model JSON consistency
|
||||
The NVIDIA model is reachable and active, but it does not always honor strict JSON perfectly for the full QD prompt. The client now includes malformed-response recovery, but this remains the main live inference risk.
|
||||
|
||||
2. Dynamic public IP churn
|
||||
The node public IP changed during execution. The system still needs either an Elastic IP or a stable DNS record.
|
||||
|
||||
3. Self-signed TLS
|
||||
nginx currently serves TLS, but a trusted certificate path is still preferable for production rollout.
|
||||
|
||||
4. External CCTV source not yet hard-connected
|
||||
The ingest API exists, but a real external bridge process still needs to be pointed at it in production.
|
||||
|
||||
5. Video catalog hygiene
|
||||
If operators copy MP4s to NVMe without updating `catalog.json`, the fallback scan will keep the assets visible, but broker-facing order and labels may become inconsistent.
|
||||
|
||||
#### 10. Acceptance Criteria
|
||||
|
||||
The Sentinel is considered aligned with current truth when all of the following hold:
|
||||
|
||||
- `https://54.152.236.10/health` returns backend status `ok`
|
||||
- PostgreSQL is live on NVMe and all eight tables exist
|
||||
- `velocity-backend.service` is active
|
||||
- `nginx` is active on `443`
|
||||
- `nemoclaw-velocity.service` is active
|
||||
- `POST /api/scenes/upload` accepts a valid CSV
|
||||
- `POST /api/cctv/event` persists a CCTV event
|
||||
- `POST /api/sentinel/session/complete` finalizes assigned or auto sessions
|
||||
- `GET /api/videos/marketing` returns the current marketing-video catalog
|
||||
- Live QD updates are visible in the frontend through the Sentinel WebSocket path
|
||||
- Playwright tests and backend tests pass
|
||||
|
||||
#### 11. Appendices
|
||||
|
||||
Related documents:
|
||||
|
||||
- `velocity_status_report.md`
|
||||
- `nemoclaw_setup_truth.md`
|
||||
- `The Sentinel Bibel.md`
|
||||
277
.Agent Context/Sprint 1/The Sentinel Bibel.md
Normal file
277
.Agent Context/Sprint 1/The Sentinel Bibel.md
Normal file
@@ -0,0 +1,277 @@
|
||||
# The Sentinel Bibel
|
||||
|
||||
Updated: April 2, 2026
|
||||
|
||||
## 1. What The Sentinel Is
|
||||
|
||||
The Sentinel is the biometric, session-intelligence, and attention-scoring engine inside Project Velocity. It exists to help brokers understand how a prospect reacts to a guided property walkthrough in real time, without streaming raw webcam video to a remote backend.
|
||||
|
||||
It fuses:
|
||||
|
||||
- browser-side facial blend-shape capture
|
||||
- scene-aware timestamp correlation
|
||||
- CRM context
|
||||
- asset-open notifications
|
||||
- CCTV-assisted auto-mode enrichment
|
||||
- lead tagging and session finalization
|
||||
|
||||
The output is not just a number. The output is operational intelligence.
|
||||
|
||||
## 2. Core Principles
|
||||
|
||||
### Local-first perception
|
||||
|
||||
The webcam is processed in the browser through MediaPipe. The backend receives only compact biometric packets, not raw video.
|
||||
|
||||
### NVMe-first deployment
|
||||
|
||||
Runtime data, prompts, PostgreSQL, certificates, and backend release assets belong on `/opt/dlami/nvme`, not the root volume.
|
||||
|
||||
### PostgreSQL is the source of truth
|
||||
|
||||
No Supabase database runtime is used for the Sentinel workflow. Session, consent, vault, CCTV, and sentiment history all land in PostgreSQL.
|
||||
|
||||
### Broker-facing intelligence must be real time
|
||||
|
||||
The system pushes QD updates and vault-open signals back through WebSockets so the broker can act during or immediately after the session.
|
||||
|
||||
### Architecture follows truth, not plan nostalgia
|
||||
|
||||
The original plan centered more heavily on local Ollama/OpenShell inference. The current deployed truth is NVIDIA-primary reasoning with OpenShell/Ollama still present as neighboring infrastructure.
|
||||
|
||||
## 3. How The Sentinel Works
|
||||
|
||||
### Assigned Mode
|
||||
|
||||
1. Broker selects a marketing video
|
||||
2. Broker selects `Assigned Mode`
|
||||
3. Broker selects an existing lead
|
||||
4. Prospect watches the video while the browser emits biometric packets
|
||||
5. Backend scores QD using scene context plus CRM context
|
||||
6. Lead score updates and notifications are visible in real time
|
||||
|
||||
### Auto Mode
|
||||
|
||||
1. Broker selects a marketing video
|
||||
2. Broker selects `Auto Mode`
|
||||
3. Session runs without a pre-bound lead
|
||||
4. Browser emits biometric packets tied to a session UUID
|
||||
5. CCTV events enrich the same session through `/api/cctv/event`
|
||||
6. Session closes through `/api/sentinel/session/complete`
|
||||
7. Auto-mode matcher links an existing lead or creates a new one
|
||||
|
||||
## 4. The Files That Matter
|
||||
|
||||
### Frontend
|
||||
|
||||
`app/src/components/modules/Sentinel.tsx`
|
||||
Sentinel shell and tab structure.
|
||||
|
||||
`app/src/components/modules/sentinel/SentinelLiveSession.tsx`
|
||||
The broker-facing session wizard. This is the orchestration UI.
|
||||
|
||||
`app/src/components/modules/sentinel/PerceptionPlayer.tsx`
|
||||
Video playback, webcam capture, packet emission, and session closeout.
|
||||
|
||||
`app/src/hooks/useMediapipeFaceLandmarker.ts`
|
||||
MediaPipe bootstrap and frame detection.
|
||||
|
||||
`app/src/hooks/useVelocitySocket.ts`
|
||||
Notification and perception WebSocket connection logic.
|
||||
|
||||
`app/src/components/layout/NotificationCenter.tsx`
|
||||
Top-bar operational notification panel.
|
||||
|
||||
### Backend
|
||||
|
||||
`backend/main.py`
|
||||
FastAPI entrypoint and router registration.
|
||||
|
||||
`backend/routers/sentinel.py`
|
||||
Perception WebSocket, notifications, consent, session completion, tag-lead route, QD score endpoint.
|
||||
|
||||
`backend/routers/vault.py`
|
||||
Trackable links and vault-open broadcast flow.
|
||||
|
||||
`backend/routers/scenes.py`
|
||||
Scene CSV upload and scene retrieval.
|
||||
|
||||
`backend/routers/videos.py`
|
||||
Marketing-video catalog loading and fallback filesystem discovery.
|
||||
|
||||
`backend/routers/cctv.py`
|
||||
CCTV event ingestion and auto-mode finalization.
|
||||
|
||||
`backend/services/nemoclaw_client.py`
|
||||
NVIDIA-primary prompt client and response parsing.
|
||||
|
||||
`backend/services/auto_mode_matcher.py`
|
||||
Auto-mode session-to-lead attribution logic.
|
||||
|
||||
`backend/db/schema.sql`
|
||||
Core Sentinel relational model.
|
||||
|
||||
`backend/db/schema_addendum.sql`
|
||||
Scene maps, perception sessions, CCTV events.
|
||||
|
||||
## 5. The Tables That Matter
|
||||
|
||||
`users_and_roles`
|
||||
RBAC and broker identity.
|
||||
|
||||
`leads_intelligence`
|
||||
Lead record, tags, QD score, broker assignment.
|
||||
|
||||
`velocity_vault_assets`
|
||||
Trackable asset share records.
|
||||
|
||||
`omnichannel_logs`
|
||||
Event history and sentiment spikes.
|
||||
|
||||
`consent_log`
|
||||
Biometric consent actions.
|
||||
|
||||
`video_scene_maps`
|
||||
Scene labels and timestamp ranges for each marketing video.
|
||||
|
||||
`perception_sessions`
|
||||
Assigned or auto-mode session records.
|
||||
|
||||
`cctv_events`
|
||||
OCR/vehicle/visitor-derived session evidence.
|
||||
|
||||
## 6. Ports and Paths
|
||||
|
||||
Public/backend-facing truth:
|
||||
|
||||
- `22` SSH
|
||||
- `443` nginx TLS
|
||||
- `127.0.0.1:8001` Uvicorn
|
||||
- `127.0.0.1:5432` PostgreSQL
|
||||
- `8080` OpenShell gateway
|
||||
- `11434` Ollama
|
||||
|
||||
Paths:
|
||||
|
||||
- `/opt/dlami/nvme/velocity/current`
|
||||
- `/opt/dlami/nvme/velocity/env`
|
||||
- `/opt/dlami/nvme/velocity/venv`
|
||||
- `/opt/dlami/nvme/velocity/tls`
|
||||
- `/opt/dlami/nvme/nemoclaw/prompts`
|
||||
- `/opt/dlami/nvme/pgdata/14/velocity`
|
||||
- `/opt/dlami/nvme/assets`
|
||||
- `/opt/dlami/nvme/assets/videos`
|
||||
- `/opt/dlami/nvme/assets/videos/catalog.json`
|
||||
|
||||
## 7. What Is True About NemoClaw
|
||||
|
||||
The Sentinel still conceptually uses NemoClaw as its reasoning layer, but the active truth is:
|
||||
|
||||
- The backend uses NVIDIA-hosted completions as primary inference
|
||||
- The active primary model is `nvidia/nemotron-3-super-120b-a12b`
|
||||
- The backend prompt layer is implemented in repo code, not hidden inside a separate agent black box
|
||||
- OpenShell and Ollama still exist on the node, but they are not the active primary scoring path
|
||||
|
||||
This distinction matters. If someone assumes the live QD score is coming from local Ollama, they are wrong.
|
||||
|
||||
## 8. Event Flows
|
||||
|
||||
### QD update flow
|
||||
|
||||
Frontend packet
|
||||
-> `/api/sentinel/ws/perception`
|
||||
-> scene lookup in `video_scene_maps`
|
||||
-> QD scoring in `nemoclaw_client.py`
|
||||
-> `perception_sessions` and `omnichannel_logs`
|
||||
-> QD broadcast
|
||||
-> frontend QD ring and notifications
|
||||
|
||||
### Marketing video flow
|
||||
|
||||
Frontend live-session picker
|
||||
-> `GET /api/videos/marketing`
|
||||
-> catalog read from `/opt/dlami/nvme/assets/videos/catalog.json`
|
||||
-> fallback recursive scan of `/opt/dlami/nvme/assets/videos`
|
||||
-> MP4 served through `/assets/videos/...`
|
||||
-> hover-preview card and full `PerceptionPlayer` playback
|
||||
|
||||
### Vault flow
|
||||
|
||||
Broker generates velocity link
|
||||
-> prospect opens `/vault/{tracking_hash}`
|
||||
-> backend logs `WS_ASSET_OPENED`
|
||||
-> notification broadcast
|
||||
-> NotificationCenter shows the event
|
||||
|
||||
### Auto-mode CCTV flow
|
||||
|
||||
OCR bridge posts to `/api/cctv/event`
|
||||
-> backend profiles plate/vehicle via `cctv_profiler`
|
||||
-> `cctv_events` row is written
|
||||
-> session evidence is updated
|
||||
-> session closes
|
||||
-> `auto_mode_matcher.py` links or creates lead
|
||||
|
||||
## 9. What Can Break
|
||||
|
||||
### Structured output from the model
|
||||
|
||||
The NVIDIA path is reachable, but model output is not always perfect JSON under the full prompt. This is the main runtime fragility.
|
||||
|
||||
### Wrong WebSocket path
|
||||
|
||||
The correct Sentinel socket namespace is `/api/sentinel/ws/...`. Any client using `/ws/...` directly will miss the router prefix and fail.
|
||||
|
||||
### Root-volume drift
|
||||
|
||||
If deployment scripts start writing runtime state back to root instead of NVMe, disk-pressure regressions will return.
|
||||
|
||||
### Video catalog drift
|
||||
|
||||
If new walkthrough files are copied to NVMe without catalog updates, the system still loads them, but the presentation order and labels can become unreliable.
|
||||
|
||||
### Dynamic public IP assumptions
|
||||
|
||||
If external scripts hardcode an old public IP, they will fail. Current truth must be rechecked whenever AWS reassigns the address.
|
||||
|
||||
## 10. What “Done” Actually Means
|
||||
|
||||
The Sentinel is done at the engineering level when:
|
||||
|
||||
- all milestone code exists
|
||||
- backend services start cleanly on NVMe-backed runtime
|
||||
- PostgreSQL schema is live
|
||||
- frontend build succeeds
|
||||
- backend tests pass
|
||||
- Playwright tests pass
|
||||
- health endpoint is live over TLS
|
||||
|
||||
The Sentinel is done at the operational level only when:
|
||||
|
||||
- a stable DNS or Elastic IP is assigned
|
||||
- trusted TLS is installed
|
||||
- production CCTV/OCR source is wired in
|
||||
- a live broker walkthrough has been accepted on the deployed system
|
||||
|
||||
## 11. Commands Worth Remembering
|
||||
|
||||
```bash
|
||||
curl -k https://54.152.236.10/health
|
||||
sudo systemctl status velocity-backend.service
|
||||
sudo systemctl status postgresql@14-velocity.service
|
||||
sudo systemctl status nginx
|
||||
sudo systemctl status nemoclaw-velocity.service
|
||||
sudo -u postgres psql -d velocity -c '\dt'
|
||||
```
|
||||
|
||||
## 12. Final Rule
|
||||
|
||||
Do not maintain two truths.
|
||||
|
||||
If deployment reality changes, update:
|
||||
|
||||
- the SRS
|
||||
- `nemoclaw_setup_truth.md`
|
||||
- this Bibel
|
||||
|
||||
before anyone else builds on stale assumptions.
|
||||
@@ -0,0 +1,503 @@
|
||||
# Velocity Kolkata Customer 0 Strategy - Get My Ghar
|
||||
|
||||
Document version: 1.0
|
||||
Prepared for: Founder sales, product architecture, GTM execution
|
||||
Document date: 2026-04-10
|
||||
Primary audience: Sagnik, Sayan, Abantika
|
||||
|
||||
## 1. Executive Summary
|
||||
|
||||
Rohit Darolia and Get My Ghar should be treated as `Customer 0` for the Tier 3 city-channel deployment of Velocity Suite in Kolkata. This is not just a sales opportunity. This is the founding field deployment that lets Velocity prove three things at once:
|
||||
|
||||
- the product can operate as a city-level sales operating system for a top channel partner
|
||||
- the same deployment can showcase multiple builder inventories without diluting data privacy
|
||||
- the CP deployment becomes the wedge into Tier 2 and Tier 1 builder relationships across India
|
||||
|
||||
The strategic rule is simple:
|
||||
|
||||
- Kolkata Tier 3 should be exclusive to Get My Ghar during the pilot and early rollout window
|
||||
- builders in Kolkata and outside Kolkata should see Velocity first through live proof, not a pitch deck
|
||||
- the demo must show property-level intelligence today and portfolio-level logic as the obvious next paid unlock
|
||||
|
||||
The business objective is not only to close Get My Ghar. The objective is to use one high-trust CP deployment to unlock builder conversations with groups such as Ambuja Neotia, Godrej, Siddha, Merlin, Eden, Sugam, DTC, Srijan, and others.
|
||||
|
||||
## 2. Business Context
|
||||
|
||||
### 2.1 Commercial Thesis
|
||||
|
||||
Velocity is not being positioned as SaaS. It is being positioned as a private AI sales operating system that gives builders and channel partners a competitive edge while keeping data under their control.
|
||||
|
||||
Revenue model:
|
||||
|
||||
- Initial setup fee
|
||||
- Monthly maintenance and innovation fee
|
||||
- Inventory-linked performance fee
|
||||
|
||||
Commercial logic:
|
||||
|
||||
- every property is a high-value commercial unit
|
||||
- every property deserves a serious setup because the sales cycle and inventory value justify it
|
||||
- second and later properties unlock portfolio-level intelligence rather than requiring a separate codebase
|
||||
|
||||
### 2.2 Role of Get My Ghar
|
||||
|
||||
Get My Ghar is strategically useful for five reasons:
|
||||
|
||||
- high-trust founder access through Rohit
|
||||
- live inventory across multiple builders
|
||||
- enough operational complexity to prove the product is real
|
||||
- direct builder relationships that compress outbound sales effort
|
||||
- Kolkata exclusivity can motivate partnership behavior instead of passive curiosity
|
||||
|
||||
### 2.3 Why Kolkata Matters First
|
||||
|
||||
Kolkata is the ideal proving ground because:
|
||||
|
||||
- founder access is stronger
|
||||
- Rohit can become an active design partner
|
||||
- success in one city creates a referenceable operating model
|
||||
- the same pattern can later be repeated city by city in Bangalore, Gurgaon, Pune, Mumbai, then Dubai and Abu Dhabi
|
||||
|
||||
## 3. Product Positioning
|
||||
|
||||
### 3.1 What Velocity Is
|
||||
|
||||
Velocity is a private sales operating system for premium real estate inventory. It combines:
|
||||
|
||||
- CRM operating layer
|
||||
- AI reasoning layer
|
||||
- inventory intelligence
|
||||
- media and generation layer
|
||||
- iPad-assisted project presentation flows
|
||||
- monitoring and performance layer
|
||||
|
||||
### 3.2 What Velocity Is Not
|
||||
|
||||
Velocity is not:
|
||||
|
||||
- just a CRM
|
||||
- just a lead-management tool
|
||||
- just a ComfyUI demo
|
||||
- just a dashboard
|
||||
- generic builder software
|
||||
|
||||
The product promise is:
|
||||
|
||||
- faster movement of inventory
|
||||
- shorter sales cycle
|
||||
- sharper broker and representative decision-making
|
||||
- better presentation quality
|
||||
- better follow-up precision
|
||||
- private ownership of customer and inventory data
|
||||
|
||||
### 3.3 Packaging Logic
|
||||
|
||||
Velocity should be explained as one platform with scope-based unlocks:
|
||||
|
||||
- `Property Layer`
|
||||
- `Portfolio Layer`
|
||||
- `Enterprise Control Layer`
|
||||
|
||||
For the Get My Ghar demo, the visible focus should be:
|
||||
|
||||
- property-linked intelligence
|
||||
- city-channel workflows
|
||||
- cross-builder inventory intelligence within Kolkata
|
||||
|
||||
For builders, the visible focus should shift to:
|
||||
|
||||
- project-specific deployment
|
||||
- property-specific generation
|
||||
- multi-property portfolio monitoring after the second project
|
||||
|
||||
## 4. Customer 0 Architecture
|
||||
|
||||
### 4.1 Core Model
|
||||
|
||||
For Get My Ghar, Velocity should be framed as a `Kolkata City Deployment`.
|
||||
|
||||
This deployment is:
|
||||
|
||||
- one private city operating environment
|
||||
- one city-specific sales intelligence layer
|
||||
- one deployment containing multiple builder properties in Kolkata
|
||||
- one team operating surface for CP workflows
|
||||
|
||||
This is not a company-wide pan-India deployment on day one. It is a Kolkata operating system.
|
||||
|
||||
### 4.2 Functional Layers for the Demo
|
||||
|
||||
#### A. Monitoring Layer
|
||||
|
||||
Shows:
|
||||
|
||||
- lead inflow by property
|
||||
- source quality
|
||||
- pipeline health
|
||||
- broker activity
|
||||
- follow-up gaps
|
||||
- inventory movement signals
|
||||
- QD-weighted lead prioritization
|
||||
|
||||
#### B. Interaction Layer
|
||||
|
||||
Shows:
|
||||
|
||||
- lead cards and enrichment
|
||||
- follow-up and assignment workflows
|
||||
- property comparison views
|
||||
- client interaction memory
|
||||
- page-level or project-level insights
|
||||
- chat-to-action operational flows
|
||||
|
||||
#### C. Generation Layer
|
||||
|
||||
Shows:
|
||||
|
||||
- property-linked AI visual generation
|
||||
- iPad-friendly presentation assets
|
||||
- project-specific walkthrough content
|
||||
- agent-facing creative variation workflows
|
||||
|
||||
Important principle:
|
||||
|
||||
- generation should remain property-linked
|
||||
- monitoring can aggregate across properties
|
||||
- portfolio intelligence can be explained as a future unlock rather than the initial visible center
|
||||
|
||||
### 4.3 Deployment Architecture for Customer 0
|
||||
|
||||
Recommended architecture for the demo and first paid deployment:
|
||||
|
||||
```text
|
||||
Get My Ghar Kolkata Deployment
|
||||
-> Private app environment
|
||||
-> PostgreSQL
|
||||
-> object/model storage
|
||||
-> Velocity web app
|
||||
-> iPad presentation surfaces
|
||||
-> AI reasoning service
|
||||
-> media/generation worker
|
||||
-> monitoring dashboards
|
||||
-> project/property data namespaces
|
||||
```
|
||||
|
||||
Operationally:
|
||||
|
||||
- one deployment
|
||||
- many Kolkata properties
|
||||
- property-level isolation in the data model
|
||||
- city-level aggregate dashboards for Rohit and management
|
||||
|
||||
### 4.4 Data Model View
|
||||
|
||||
For Get My Ghar, the key top-level entities are:
|
||||
|
||||
- City
|
||||
- Builder
|
||||
- Property
|
||||
- Unit / inventory type
|
||||
- Lead
|
||||
- Broker / sales representative
|
||||
- Interaction
|
||||
- Presentation asset
|
||||
- Visit / response signal
|
||||
- Sales stage
|
||||
|
||||
The hierarchy should be:
|
||||
|
||||
```text
|
||||
Kolkata
|
||||
-> Builder
|
||||
-> Property
|
||||
-> Inventory
|
||||
-> Leads
|
||||
-> Interactions
|
||||
-> Media / generation assets
|
||||
```
|
||||
|
||||
This lets the same city deployment prove:
|
||||
|
||||
- property-specific workflows
|
||||
- builder-specific views
|
||||
- city-level channel-partner intelligence
|
||||
|
||||
## 5. Demo Property Map
|
||||
|
||||
The following properties should be used as the first Kolkata showcase inventory set:
|
||||
|
||||
| # | Property | Builder | URL | Starting Price |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| 1 | Eden Devprayag | Eden Realty | `https://getmyghar.com/properties/eden-devprayag/` | `₹ 1.50 Cr Onwards` |
|
||||
| 2 | Sugam Prakriti | Sugam Homes | `https://getmyghar.com/properties/sugam-prakriti/` | `₹ 35 Lakhs Onwards` |
|
||||
| 3 | Atri Aqua | Atri Group | `https://getmyghar.com/properties/atri-aqua/` | `₹ 32.50 Lakhs Onwards` |
|
||||
| 4 | Atri Surya Toron | Atri Group | `https://getmyghar.com/properties/atri-surya-toron/` | `₹ 23 Lakhs Onwards` |
|
||||
| 5 | Siddha Suburbia Bungalow | Siddha Group | `https://getmyghar.com/properties/siddha-suburbia-bungalow/` | `₹ 96 Lacs Onwards` |
|
||||
| 6 | Merlin Avana | Merlin Group | `https://getmyghar.com/properties/merlin-avana/` | `₹ 78 Lakhs Onwards` |
|
||||
| 7 | DTC Good Earth | DTC Group | `https://getmyghar.com/properties/dtc-good-earth/` | `₹ 42 Lakhs Onwards` |
|
||||
| 8 | Siddha Serena | Siddha Group | `https://getmyghar.com/properties/siddha-serena/` | `₹ 69 Lakhs Onwards` |
|
||||
| 9 | Siddha Sky Waterfront | Siddha Group | `https://getmyghar.com/properties/siddha-sky/` | `₹ 1.40 Cr Onwards` |
|
||||
| 10 | Godrej Blue | Godrej Properties Ltd | `https://getmyghar.com/properties/godrej-blue/` | `₹ 2.57 Cr Onwards` |
|
||||
| 11 | DTC Sojon | DTC Group | `https://getmyghar.com/properties/dtc-sojon/` | `₹ 48 Lakhs Onwards` |
|
||||
| 12 | Shriram Grand City | Shriram Properties Limited | `https://getmyghar.com/properties/shriram-grand-city/` | `₹ 22 Lakhs Onwards` |
|
||||
| 13 | Godrej Elevate | Godrej Properties Ltd | `https://getmyghar.com/properties/godrej-elevate/` | `₹ 56 Lacs Onwards` |
|
||||
| 14 | Ambuja Utpaala | Ambuja Neotia Group | `https://getmyghar.com/properties/ambuja-utpalaa/` | `₹ 2.17 Cr Onwards` |
|
||||
| 15 | Srijan Group Properties | Srijan Group | `TBD per property selection` | `TBD` |
|
||||
|
||||
### 5.1 Why This Property Mix Works
|
||||
|
||||
This list is commercially useful because it spans:
|
||||
|
||||
- affordable to premium price bands
|
||||
- multiple major builder brands
|
||||
- repeat builder presence, which helps show cross-property insight
|
||||
- obvious buyer segmentation possibilities
|
||||
- obvious premium property storytelling use cases
|
||||
|
||||
This means the demo can show:
|
||||
|
||||
- low-ticket, high-volume movement logic
|
||||
- mid-market comparison logic
|
||||
- premium property white-glove selling logic
|
||||
|
||||
## 6. Demo Narrative for Rohit
|
||||
|
||||
The demo must not feel like software browsing. It must feel like Rohit is seeing his future operating advantage.
|
||||
|
||||
### 6.1 Narrative Arc
|
||||
|
||||
#### Part 1: Control
|
||||
|
||||
Show Rohit that Kolkata inventory can be monitored from one surface:
|
||||
|
||||
- which projects are active
|
||||
- which representatives are following up properly
|
||||
- which inventory is getting traction
|
||||
- where interest is stalling
|
||||
|
||||
#### Part 2: Precision
|
||||
|
||||
Show that Velocity helps decide:
|
||||
|
||||
- which lead deserves immediate attention
|
||||
- which property should be pushed for a given buyer profile
|
||||
- where the broker team is leaking momentum
|
||||
- how presentations can be tailored faster
|
||||
|
||||
#### Part 3: Advantage
|
||||
|
||||
Show that Get My Ghar can become the smartest CP operation in Kolkata:
|
||||
|
||||
- faster inventory movement
|
||||
- better project pitching
|
||||
- stronger builder reporting
|
||||
- stronger broker accountability
|
||||
- more premium operational image
|
||||
|
||||
#### Part 4: Expansion
|
||||
|
||||
Show that this same deployment pattern becomes:
|
||||
|
||||
- the Kolkata CP operating system today
|
||||
- the proof point used to win builders tomorrow
|
||||
|
||||
## 7. Selling Strategy
|
||||
|
||||
### 7.1 Strategic Goal
|
||||
|
||||
Close Get My Ghar as the founding Kolkata Tier 3 partner while using the deployment as the live demonstration environment for Tier 2 and Tier 1 builder sales.
|
||||
|
||||
### 7.2 Positioning for Rohit
|
||||
|
||||
Pitch to Rohit as:
|
||||
|
||||
- exclusive Kolkata CP partner during the pilot period
|
||||
- early strategic design partner
|
||||
- operator with first access to AI-enhanced city inventory workflows
|
||||
- trusted launch ally, not just a paying customer
|
||||
|
||||
What he gets emotionally:
|
||||
|
||||
- status
|
||||
- exclusivity
|
||||
- first-mover advantage
|
||||
- influence on product shape
|
||||
|
||||
What he gets commercially:
|
||||
|
||||
- sharper conversion machinery
|
||||
- better builder reporting
|
||||
- a differentiated operating layer that smaller CPs cannot match
|
||||
|
||||
### 7.3 Positioning for Builders
|
||||
|
||||
Pitch to builders as:
|
||||
|
||||
- the system already trusted by a top CP in Kolkata
|
||||
- a private, anti-SaaS deployment model
|
||||
- project-specific or portfolio-specific deployment
|
||||
- a system that reduces time-to-sale, improves presentation quality, and creates better operational discipline
|
||||
|
||||
For builders, the main proof is not your code. The main proof is:
|
||||
|
||||
- a live CP deployment operating on real properties
|
||||
- a known operator they trust
|
||||
- a founder-led product with industry insight and technical depth
|
||||
|
||||
### 7.4 Recommended Founder Sales Sequence
|
||||
|
||||
1. Close Rohit as Customer 0.
|
||||
2. Use his live Kolkata deployment as proof.
|
||||
3. Use Rohit's introductions to open Tier 2 and Tier 1 conversations.
|
||||
4. Lead with live use cases, not feature lists.
|
||||
5. Sell one-month beta setup as a founder-stage privileged engagement.
|
||||
6. Use signed setup fees to buy time and runway for Sayan and Abantika.
|
||||
|
||||
## 8. Commercial Strategy
|
||||
|
||||
### 8.1 Get My Ghar Commercial Frame
|
||||
|
||||
Since this is a founding deployment, the pitch should be:
|
||||
|
||||
- one-month setup window
|
||||
- founder-led implementation
|
||||
- priority roadmap influence
|
||||
- Kolkata exclusivity on the Tier 3 city-channel side for the agreed early term
|
||||
|
||||
Possible structure:
|
||||
|
||||
- discounted or specially structured setup fee relative to future city deployments
|
||||
- formal monthly maintenance agreement
|
||||
- clear success metrics tied to operational usage and inventory movement
|
||||
|
||||
### 8.2 Builder Commercial Frame
|
||||
|
||||
Builders should be sold on:
|
||||
|
||||
- one property as the initial operating unit
|
||||
- serious setup fee because every premium property justifies it
|
||||
- second property unlocks portfolio visibility and cross-property intelligence
|
||||
- monthly maintenance keeps them current
|
||||
- inventory-linked fee aligns your upside with their sales velocity
|
||||
|
||||
### 8.3 Why This Is Profitable
|
||||
|
||||
This model is profitable because:
|
||||
|
||||
- every deployment is high-value
|
||||
- support remains standardized if the architecture stays modular
|
||||
- second-property expansion is easier than first deployment
|
||||
- references compound
|
||||
- one CP deployment can source multiple builder deals
|
||||
|
||||
## 9. Competitive Strategy
|
||||
|
||||
### 9.1 Strategic Moat
|
||||
|
||||
Your moat is not one model or one workflow. It is the combination of:
|
||||
|
||||
- real-estate operating understanding
|
||||
- anti-SaaS private deployment stance
|
||||
- AI reasoning plus sales workflow integration
|
||||
- generation and presentation layer linked to actual inventory
|
||||
- founder-led speed in a market where incumbents move slowly
|
||||
|
||||
### 9.2 Why Others Will Struggle
|
||||
|
||||
Most competitors will fall into one of these traps:
|
||||
|
||||
- generic CRM with no project intelligence
|
||||
- marketing demo with no operational depth
|
||||
- AI toy with no deployment discipline
|
||||
- enterprise software with no founder velocity
|
||||
|
||||
Velocity wins if it becomes the real operational layer, not just a shiny demo.
|
||||
|
||||
## 10. Founding Team Execution Logic
|
||||
|
||||
This GTM motion is also your hiring and runway bridge.
|
||||
|
||||
Desired outcome:
|
||||
|
||||
- Get My Ghar signs
|
||||
- setup fee lands
|
||||
- monthly maintenance starts
|
||||
- founder confidence increases
|
||||
- that lets you pull Sayan out of TCS
|
||||
- that lets Abantika operate more fully in the venture
|
||||
|
||||
This is not just sales revenue. This is team-conversion capital.
|
||||
|
||||
## 11. Risks and Controls
|
||||
|
||||
### 11.1 Risks
|
||||
|
||||
- demo looks impressive but not operationally credible
|
||||
- too much is promised before install discipline exists
|
||||
- exclusivity is given without enough commercial commitment
|
||||
- founders get dragged into excessive custom work
|
||||
- builders interpret beta status as product weakness rather than founder access
|
||||
|
||||
### 11.2 Controls
|
||||
|
||||
- keep the demo grounded in real operational flows
|
||||
- define exactly what is included in the one-month setup
|
||||
- keep architecture modular
|
||||
- avoid bespoke one-off branches per client
|
||||
- position beta as founder-led privileged access, not instability
|
||||
|
||||
## 12. Immediate Action Plan
|
||||
|
||||
### 12.1 Demo Build
|
||||
|
||||
Build the demo around these views:
|
||||
|
||||
- Kolkata inventory overview
|
||||
- builder-by-builder property map
|
||||
- price-band segmentation
|
||||
- property-specific lead prioritization
|
||||
- representative performance
|
||||
- follow-up leakage
|
||||
- premium property AI presentation layer
|
||||
- iPad property pitch experience
|
||||
|
||||
### 12.2 Sales Material
|
||||
|
||||
Prepare:
|
||||
|
||||
- founder narrative deck
|
||||
- one-page commercial sheet
|
||||
- one-page architecture sheet
|
||||
- one-page privacy and anti-SaaS argument
|
||||
- one-page rollout timeline
|
||||
|
||||
### 12.3 Meeting Goal
|
||||
|
||||
The objective of the Rohit meeting is:
|
||||
|
||||
- not “what do you think?”
|
||||
- but “let’s make this your Kolkata operating edge and launch it together”
|
||||
|
||||
## 13. Recommended Founder Script
|
||||
|
||||
Use this logic in conversation:
|
||||
|
||||
"We are not building software for everyone and then trying to fit you into it. We are building the sales operating system that should exist for premium real-estate movement. Kolkata is the first city where we want to prove it properly. You are one of the few people who can make that proof real at city scale. We want Get My Ghar to become the founding Kolkata partner, and once that engine is live, we use that proof to walk into the builders together."
|
||||
|
||||
## 14. Final Recommendation
|
||||
|
||||
Treat Rohit and Get My Ghar as:
|
||||
|
||||
- founding Kolkata partner
|
||||
- city-channel Customer 0
|
||||
- proof engine for builder acquisition
|
||||
- reference deployment for the anti-SaaS sales thesis
|
||||
|
||||
The right next move is not to overbuild. It is to build the smallest high-conviction live operating demo that proves:
|
||||
|
||||
- city-level CP control
|
||||
- project-level intelligence
|
||||
- premium-property sales enhancement
|
||||
- clear path from CP deployment to builder deployment
|
||||
|
||||
If this works, Kolkata becomes the template. If Kolkata becomes the template, the rest of India becomes a rollout problem, not a product-definition problem.
|
||||
327
.Agent Context/Sprint 1/nemoclaw_setup_truth.md
Normal file
327
.Agent Context/Sprint 1/nemoclaw_setup_truth.md
Normal file
@@ -0,0 +1,327 @@
|
||||
# NemoClaw Setup Truth
|
||||
|
||||
Updated: April 2, 2026
|
||||
|
||||
## 1. Purpose
|
||||
|
||||
This document records the actual NemoClaw-related deployment state for Project Velocity. It explains what exists, where it exists, why it exists, which ports are involved, and how the reasoning path works today.
|
||||
|
||||
This is not the original intended architecture. This is the current operational truth.
|
||||
|
||||
## 2. High-Level Summary
|
||||
|
||||
Project Velocity uses the term "NemoClaw" for the reasoning and prompt layer attached to the Sentinel QD Engine. In practice, this is now split into two different concerns:
|
||||
|
||||
1. Prompted reasoning used by the FastAPI backend
|
||||
2. OpenShell / gateway infrastructure that remains installed on the AWS node
|
||||
|
||||
The active FastAPI inference path is NVIDIA-hosted OpenAI-compatible chat completions.
|
||||
|
||||
The OpenShell gateway and Ollama are still installed and running as adjacent infrastructure, but they are not the active primary scoring path used by `backend/services/nemoclaw_client.py`.
|
||||
|
||||
## 3. Node and Network Truth
|
||||
|
||||
AWS region: `us-east-1`
|
||||
Current public IP: `54.152.236.10`
|
||||
SSH user: `ubuntu`
|
||||
|
||||
### Port Map
|
||||
|
||||
`22`
|
||||
SSH access to the AWS node.
|
||||
|
||||
`443`
|
||||
nginx TLS reverse proxy. Public entry point for the backend.
|
||||
|
||||
`127.0.0.1:8001`
|
||||
FastAPI/Uvicorn backend. Not directly public.
|
||||
|
||||
`127.0.0.1:5432`
|
||||
PostgreSQL. Local-only.
|
||||
|
||||
`8080`
|
||||
OpenShell/NemoClaw gateway target. Internal service path for gateway bootstrap and sandbox-related flows.
|
||||
|
||||
`11434`
|
||||
Local Ollama runtime. Installed and reachable on the node, but not the current primary backend scoring path.
|
||||
|
||||
`/api/videos/marketing`
|
||||
Backend catalog endpoint for Sentinel live-session marketing videos.
|
||||
|
||||
## 4. File and Directory Layout
|
||||
|
||||
### NVMe-backed runtime directories
|
||||
|
||||
`/opt/dlami/nvme/velocity/current`
|
||||
Active backend code.
|
||||
|
||||
`/opt/dlami/nvme/velocity/env`
|
||||
Environment file used by `velocity-backend.service`.
|
||||
|
||||
`/opt/dlami/nvme/velocity/venv`
|
||||
Python virtual environment for the backend.
|
||||
|
||||
`/opt/dlami/nvme/velocity/tls`
|
||||
TLS cert and key used by nginx.
|
||||
|
||||
`/opt/dlami/nvme/nemoclaw/prompts`
|
||||
Prompt files used by the backend reasoning client.
|
||||
|
||||
`/opt/dlami/nvme/assets/videos`
|
||||
Runtime marketing-video directory served by FastAPI static assets.
|
||||
|
||||
`/opt/dlami/nvme/assets/videos/catalog.json`
|
||||
Optional checked catalog that controls video ordering, labels, and display metadata for the live-session picker.
|
||||
|
||||
`/opt/dlami/nvme/pgdata/14/velocity`
|
||||
PostgreSQL 14 data directory.
|
||||
|
||||
### Repo paths
|
||||
|
||||
`backend/services/nemoclaw_client.py`
|
||||
Primary reasoning client used by the FastAPI backend.
|
||||
|
||||
`backend/routers/videos.py`
|
||||
Marketing-video catalog endpoint for the Sentinel live-session picker.
|
||||
|
||||
`backend/config/marketing_videos.catalog.json`
|
||||
Checked source catalog for the four current property walkthrough videos.
|
||||
|
||||
`backend/nemoclaw_prompts/qd_calculator.md`
|
||||
QD scoring prompt.
|
||||
|
||||
`backend/nemoclaw_prompts/lead_tagger.md`
|
||||
Lead enrichment prompt.
|
||||
|
||||
`backend/nemoclaw_prompts/cctv_profiler.md`
|
||||
CCTV vehicle and plate profiling prompt.
|
||||
|
||||
`backend/scripts/nemoclaw_deploy.sh`
|
||||
Historical deployment/bootstrap script for OpenShell/Ollama-style setup. Useful as reference, but no longer fully aligned with the active NVIDIA-primary truth.
|
||||
|
||||
## 5. Services
|
||||
|
||||
### `velocity-backend.service`
|
||||
|
||||
Purpose:
|
||||
Runs FastAPI/Uvicorn from the NVMe release tree.
|
||||
|
||||
Why it exists:
|
||||
Provides the production API and WebSocket layer for Sentinel, Vault, Scenes, CCTV, and Auth.
|
||||
|
||||
Key behavior:
|
||||
- Reads `/opt/dlami/nvme/velocity/env`
|
||||
- Starts `uvicorn backend.main:app --host 127.0.0.1 --port 8001`
|
||||
|
||||
### `nemoclaw-velocity.service`
|
||||
|
||||
Purpose:
|
||||
Bootstraps the OpenShell/NemoClaw gateway state.
|
||||
|
||||
Why it exists:
|
||||
Keeps the local gateway selection and related tooling available on the node even though FastAPI currently scores against NVIDIA directly.
|
||||
|
||||
Current truth:
|
||||
- Implemented as a non-blocking `oneshot` systemd unit
|
||||
- Leaves the service in `active (exited)` when successful
|
||||
|
||||
### `nginx`
|
||||
|
||||
Purpose:
|
||||
TLS reverse proxy for the backend.
|
||||
|
||||
Why it exists:
|
||||
Exposes the backend on `443`, terminates TLS, and forwards both HTTP and WebSocket traffic to Uvicorn.
|
||||
|
||||
### `postgresql@14-velocity.service`
|
||||
|
||||
Purpose:
|
||||
Owns the NVMe-backed PostgreSQL cluster.
|
||||
|
||||
Why it exists:
|
||||
The Sentinel and Vault flows persist state in PostgreSQL, not Supabase.
|
||||
|
||||
## 6. Environment Variables
|
||||
|
||||
Active variables relevant to NemoClaw reasoning:
|
||||
|
||||
`NVIDIA_API_KEY`
|
||||
Used by the backend to authenticate against NVIDIA hosted completions.
|
||||
|
||||
`NVIDIA_BASE_URL`
|
||||
Set to `https://integrate.api.nvidia.com/v1`
|
||||
|
||||
`NVIDIA_MODEL`
|
||||
Set to `nvidia/nemotron-3-super-120b-a12b`
|
||||
|
||||
`NVIDIA_FALLBACK_MODEL`
|
||||
Set to `nvidia/llama-3.3-nemotron-super-49b-v1`
|
||||
|
||||
`ALLOW_LOCAL_FALLBACK`
|
||||
Currently `false`
|
||||
|
||||
`NEMOCLAW_PROMPT_DIR`
|
||||
Set to `/opt/dlami/nvme/nemoclaw/prompts`
|
||||
|
||||
Historical-but-not-primary variables:
|
||||
|
||||
`OLLAMA_BASE_URL`
|
||||
Still relevant if local fallback is re-enabled.
|
||||
|
||||
`NEMOCLAW_BASE_URL`
|
||||
No longer the primary path for backend scoring.
|
||||
|
||||
## 7. Inference Flow
|
||||
|
||||
### Current backend inference flow
|
||||
|
||||
1. Frontend emits biometric packet over `/api/sentinel/ws/perception`
|
||||
2. `backend/routers/sentinel.py` receives the packet
|
||||
3. Scene context is resolved from `video_scene_maps` if `video_asset_id` and `video_ts_ms` are present
|
||||
4. `backend/services/nemoclaw_client.py` builds an OpenAI-compatible messages payload
|
||||
5. The backend calls NVIDIA hosted completions using `nvidia/nemotron-3-super-120b-a12b`
|
||||
6. The result updates QD score state and is broadcast back over WebSocket
|
||||
|
||||
### Current lead-tagging flow
|
||||
|
||||
1. Broker or system calls `/api/sentinel/tag-lead`
|
||||
2. `tag_lead()` uses the NVIDIA path
|
||||
3. Lead tags are updated in `leads_intelligence`
|
||||
4. `LEAD_TAGGED` is broadcast to notifications
|
||||
|
||||
### Current CCTV flow
|
||||
|
||||
1. OCR/bridge posts to `/api/cctv/event`
|
||||
2. `profile_cctv_visitor()` uses the NVIDIA path
|
||||
3. `cctv_events` row is written
|
||||
4. Session evidence is updated
|
||||
5. Session can later be finalized through auto-mode matching
|
||||
|
||||
### Current live-session video flow
|
||||
|
||||
1. Frontend calls `GET /api/videos/marketing`
|
||||
2. Backend reads `/opt/dlami/nvme/assets/videos/catalog.json` if present
|
||||
3. Backend falls back to scanning `/opt/dlami/nvme/assets/videos` recursively for playable files if the catalog is missing or incomplete
|
||||
4. FastAPI serves the MP4 files through `/assets/videos/...`
|
||||
5. `SentinelLiveSession.tsx` renders smaller preview cards that autoplay in 3-second bursts on hover and advance 10 seconds between bursts
|
||||
6. `PerceptionPlayer.tsx` plays the selected asset through the same `/assets/videos/...` path
|
||||
|
||||
## 8. OpenShell and Ollama Truth
|
||||
|
||||
OpenShell and Ollama still matter, but in a narrower way than originally planned.
|
||||
|
||||
### Ollama
|
||||
|
||||
Location:
|
||||
Runs locally on port `11434`
|
||||
|
||||
Why it still exists:
|
||||
- Historical deployment compatibility
|
||||
- Potential local fallback if NVIDIA is disabled
|
||||
- OpenShell-related infrastructure expectations
|
||||
|
||||
### OpenShell gateway
|
||||
|
||||
Location:
|
||||
Gateway target on port `8080`
|
||||
|
||||
Why it still exists:
|
||||
- NemoClaw sandbox bootstrap
|
||||
- Local gateway control path
|
||||
- Operational continuity for the previously onboarded sandbox
|
||||
|
||||
What it is not:
|
||||
- It is not the current primary inference path for backend scoring
|
||||
|
||||
## 9. Prompts
|
||||
|
||||
Prompt source-of-truth in repo:
|
||||
|
||||
- `backend/nemoclaw_prompts/qd_calculator.md`
|
||||
- `backend/nemoclaw_prompts/lead_tagger.md`
|
||||
- `backend/nemoclaw_prompts/cctv_profiler.md`
|
||||
|
||||
Prompt runtime location on node:
|
||||
|
||||
- `/opt/dlami/nvme/nemoclaw/prompts/qd_calculator.md`
|
||||
- `/opt/dlami/nvme/nemoclaw/prompts/lead_tagger.md`
|
||||
- `/opt/dlami/nvme/nemoclaw/prompts/cctv_profiler.md`
|
||||
|
||||
Why copied to NVMe:
|
||||
- Keeps runtime prompts off the root volume
|
||||
- Aligns with the NVMe-first deployment strategy
|
||||
- Prevents storage-eviction regressions
|
||||
|
||||
## 10. Known Operational Risks
|
||||
|
||||
### JSON compliance risk
|
||||
|
||||
The NVIDIA model sometimes returns malformed or partially malformed JSON for the full QD prompt. The backend now includes partial-response recovery, but this is the biggest remaining correctness risk.
|
||||
|
||||
### Dynamic IP risk
|
||||
|
||||
The public IP has changed during execution. A stable Elastic IP or DNS entry is still recommended.
|
||||
|
||||
### Trust-chain risk
|
||||
|
||||
nginx TLS exists, but a production-trusted certificate should replace self-signed cert material.
|
||||
|
||||
### External producer gap
|
||||
|
||||
The OCR bridge script exists, but a production ONVIF/RTSP/OCR producer still needs to be pointed at the ingestion endpoint.
|
||||
|
||||
### Catalog drift risk
|
||||
|
||||
If new property videos are copied to NVMe without updating `catalog.json`, they will still be discoverable through directory scanning, but order, title, and display color may drift from the intended broker-facing presentation.
|
||||
|
||||
## 11. Validation Commands
|
||||
|
||||
Health:
|
||||
|
||||
```bash
|
||||
curl -k https://54.152.236.10/health
|
||||
curl -k https://54.152.236.10/api/videos/marketing
|
||||
```
|
||||
|
||||
Backend service:
|
||||
|
||||
```bash
|
||||
sudo systemctl status velocity-backend.service
|
||||
```
|
||||
|
||||
Gateway bootstrap:
|
||||
|
||||
```bash
|
||||
sudo systemctl status nemoclaw-velocity.service
|
||||
```
|
||||
|
||||
PostgreSQL:
|
||||
|
||||
```bash
|
||||
sudo systemctl status postgresql@14-velocity.service
|
||||
sudo -u postgres psql -d velocity -c '\dt'
|
||||
```
|
||||
|
||||
Local inference health from backend env:
|
||||
|
||||
```bash
|
||||
source /opt/dlami/nvme/velocity/env
|
||||
PYTHONPATH=/opt/dlami/nvme/velocity/current /opt/dlami/nvme/velocity/venv/bin/python - <<'PY'
|
||||
import asyncio, json
|
||||
from backend.services.nemoclaw_client import health_check
|
||||
print(asyncio.run(health_check()))
|
||||
PY
|
||||
```
|
||||
|
||||
## 12. What to Update If the Truth Changes
|
||||
|
||||
Update this document whenever any of the following change:
|
||||
|
||||
- Public IP or DNS target
|
||||
- Primary inference provider
|
||||
- Primary model
|
||||
- Prompt directory
|
||||
- nginx port or TLS behavior
|
||||
- OpenShell gateway port
|
||||
- service unit names
|
||||
- NVMe runtime paths
|
||||
@@ -0,0 +1,27 @@
|
||||
# Sentinel QD Engine Execution Tracker
|
||||
|
||||
Updated: April 2, 2026
|
||||
|
||||
| Milestone | Scope | Current Status | Completed Truth | What Is Left |
|
||||
|---|---|---|---|---|
|
||||
| 1 | Database & Auth | Complete | Types, store slice, schema, addendum schema, asyncpg pool, RBAC dependencies, FastAPI entrypoint, NVMe PostgreSQL deployment, and schema application are done. | Nothing required to satisfy the original milestone. |
|
||||
| 2 | Velocity Link & Notifications | Complete | Vault link generation, vault-open logging, notification socket hook, notification center UI, and App wiring are implemented. | A live broker acceptance pass on the deployed frontend is still useful, but the milestone itself is complete. |
|
||||
| 3 | Perception Pipeline | Complete | Landmark encoder, MediaPipe hook, PerceptionPlayer, Sentinel live session wizard, and Sentinel subtab split are implemented. | No code gap remains for the milestone definition. |
|
||||
| 4 | NemoClaw Sandbox | Complete with architecture change | Prompt files, Sentinel router, backend reasoning client, AWS gateway bootstrap, and active env configuration are in place. The live reasoning path is now NVIDIA-primary instead of local Ollama-primary. | The only remaining improvement is better structured-output robustness from the NVIDIA model. |
|
||||
| 5 | CCTV & Auto Mode Integration | Code complete, external producer hookup pending | `backend/routers/cctv.py`, `backend/scripts/cctv_ocr_bridge.py`, `backend/services/auto_mode_matcher.py`, and prompt placement to NVMe are done. | A real ONVIF/RTSP/OCR producer still needs to post to `/api/cctv/event` in production. |
|
||||
| 6 | Video Scene CSV Upload | Complete | `backend/routers/scenes.py`, scene-aware backend lookup, frontend scene CSV upload UI, and scene-linked session packets are implemented. | Optional broker training and a production CSV content pass remain operational tasks, not engineering blockers. |
|
||||
| 7 | AWS Deployment | Complete | NVMe-backed backend tree, env file, PostgreSQL on NVMe, schema execution, `velocity-backend.service`, `nemoclaw-velocity.service`, nginx TLS proxy, and backend health recovery on the current node IP are complete. | Replace dynamic IP and self-signed TLS with stable production networking and certificate management. |
|
||||
| 8 | Integration Tests | Complete at repo level | Backend NemoClaw scoring test, backend vault notification flow test, Playwright live-session tests, and Playwright notification-center test are implemented and passing locally. | A live deployed end-to-end acceptance run through the broker-facing UI is still recommended before declaring production signoff. |
|
||||
|
||||
## Residual Risks
|
||||
|
||||
1. NVIDIA structured output remains imperfect on the full QD prompt. The client now includes malformed-response recovery, but this is still the main inference correctness risk.
|
||||
2. The AWS public IP is dynamic. The system should move to an Elastic IP or a stable DNS record.
|
||||
3. CCTV ingestion is implemented at the API boundary, but the production camera/OCR producer is not yet hard-wired.
|
||||
4. TLS is functional, but the deployment still needs a trusted certificate chain for full production readiness.
|
||||
|
||||
## April 2 Addendum
|
||||
|
||||
1. The live-session video picker now loads catalog-backed marketing videos from `GET /api/videos/marketing` instead of hardcoded mock cards.
|
||||
2. The assigned-mode lead selection step now includes client-side search.
|
||||
3. The current four walkthrough assets are intended to live under `/opt/dlami/nvme/assets/videos` with broker-facing metadata in `catalog.json`.
|
||||
71
.Agent Context/Sprint 1/velocity_status_report.md
Normal file
71
.Agent Context/Sprint 1/velocity_status_report.md
Normal file
@@ -0,0 +1,71 @@
|
||||
# Project Velocity: Sentinel QD Engine Status Report
|
||||
*Generated: April 1, 2026*
|
||||
|
||||
This artifact provides a comprehensive overview of the current status of the **Sentinel Quantum Dynamics (QD) Engine**. It maps the architectural decisions and milestones directly to the codebase, detailing what has been completed, deployed, and what remains to be done.
|
||||
|
||||
---
|
||||
|
||||
## 1. Architectural Adjustments & Realities
|
||||
During the NemoClaw deployment (Milestone 4 & 7), several key architectural realities emerged that forced an adjustment to the original design:
|
||||
|
||||
1. **Inference Pipeline Switch (NVIDIA API vs. Ollama)**
|
||||
- **Original Plan**: Route traffic through the OpenShell mTLS gateway locally holding `qwen3.5:27b`.
|
||||
- **The Reality**: The `qwen3.5:27b` model under Ollama currently runs in an extended "think mode" (chain-of-thought) which exhausts token limits before outputting JSON, causing timeouts. The OpenShell Gateway also expects internal sandbox client certificates (mTLS).
|
||||
- **The Pivot**: We have updated `nemoclaw_client.py` to use the **NVIDIA API directly** (`llama-3.3-nemotron-super-49b-v1`) as the primary inference engine since it is OpenAI-compatible, fast, and reliable. Ollama remains a fallback (with a known TODO to fix the `think` parameter parsing).
|
||||
|
||||
2. **Storage Eviction Issues Resolved**
|
||||
- **The Reality**: k3s and Docker were exhausting the root `/dev/root` volume, triggering disk pressure evictions and crashing OpenShell pods.
|
||||
- **The Pivot**: We migrated the 103GB model cache and the `/var/lib/rancher` k3s storage to the 3.4TB `/opt/dlami/nvme` partition, restoring disk health and allowing NemoClaw to successfully "onboard" and enter a "Ready" state.
|
||||
|
||||
3. **Port Collisions**
|
||||
- **The Reality**: Both the existing `velocity-oracle` and the OpenShell gateway wanted port `8080`.
|
||||
- **The Pivot**: We migrated `velocity-oracle` to bind to port **`8081`**.
|
||||
|
||||
---
|
||||
|
||||
## 2. Codebase Map: What is Done
|
||||
|
||||
### ✅ **Milestone 1: Database & Auth**
|
||||
- **Types:** `app/src/types/index.ts` (BiometricPacket, QDScore, Notifications)
|
||||
- **State:** `app/src/store/useStore.ts` (Notification state management)
|
||||
- **Schema:** `backend/db/schema.sql`, `backend/db/schema_addendum.sql`
|
||||
- **Pool Data:** `backend/db/pool.py`, `backend/auth/dependencies.py`
|
||||
- **Entrypoint:** `backend/main.py` (FastAPI lifecycle and router integration)
|
||||
|
||||
### ✅ **Milestone 2: Velocity Link & Notifications**
|
||||
- **Routers:** `backend/routers/vault.py`
|
||||
- **Hooks:** `app/src/hooks/useVelocitySocket.ts`
|
||||
- **UI:** `app/src/components/layout/NotificationCenter.tsx` + `App.tsx` wiring.
|
||||
|
||||
### ✅ **Milestone 3: Perception Pipeline (Frontend)**
|
||||
- **WASM Encoders:** `app/src/utils/landmarkPacketEncoder.ts`
|
||||
- **Vision Feed:** `app/src/hooks/useMediapipeFaceLandmarker.ts`
|
||||
- **Live UI:** `app/src/components/modules/sentinel/PerceptionPlayer.tsx` + `SentinelLiveSession.tsx`
|
||||
|
||||
### ✅ **Milestone 4 & 7: NemoClaw Sandbox & AWS Env**
|
||||
- **Client Logic:** `backend/services/nemoclaw_client.py` (Now pointed to NVIDIA API)
|
||||
- **Prompts:** Uploaded to NVMe (`cctv_profiler.md`, `lead_tagger.md`, `qd_calculator.md`)
|
||||
- **System Service:** `nemoclaw-velocity.service` created and enabled.
|
||||
- **Environment:** `/opt/dlami/nvme/velocity/env` written.
|
||||
- **NemoClaw Onboarding:** Succeeded; the sandbox is completely ready (`Phase: Ready`).
|
||||
|
||||
---
|
||||
|
||||
## 3. Pending Workflow: What is Left
|
||||
|
||||
### ⏳ **Database Initialization (Finalizing Milestone 1/7)**
|
||||
While the backend code and schema files exist, the AWS database instance itself has not been booted.
|
||||
- **Action Required:** Instantiate PostgreSQL on `/opt/dlami/nvme/pgdata` and execute `schema.sql` and `schema_addendum.sql`.
|
||||
- **Action Required:** Point FastAPI to the PostgreSQL instance.
|
||||
|
||||
### ⏳ **Milestone 5: CCTV & Auto Mode Integration**
|
||||
- **Action Required:** Build `backend/routers/cctv.py` to ingest frames.
|
||||
- **Action Required:** Build OCR bridging logic to pass plates and cars to the NemoClaw prompt (`cctv_profiler.md`) and into the DB.
|
||||
- **Action Required:** Build `backend/services/auto_mode_matcher.py` (matching CCTV feed data to post-session lead attribution).
|
||||
|
||||
### ⏳ **Milestone 6: Video Scene CSV Upload**
|
||||
- **Action Required:** Implement `backend/routers/scenes.py` (/api/scenes/upload endpoint).
|
||||
- **Action Required:** Integrate the scene context into the frontend `PerceptionPlayer` to correlate timestamped video annotations with real-time biometric feeds.
|
||||
|
||||
### ⏳ **Milestone 8: End-to-End Integration Testing**
|
||||
- **Action Required:** E2E testing of the full pipeline (Frontend → FastAPI → PostgreSQL/NemoClaw → Frontend Notifications).
|
||||
BIN
.Agent Context/Tech/MediaPipe-1906.08172v1.pdf
Normal file
BIN
.Agent Context/Tech/MediaPipe-1906.08172v1.pdf
Normal file
Binary file not shown.
Binary file not shown.
158
.Agent Context/Tech/README-MediaPipe.md
Normal file
158
.Agent Context/Tech/README-MediaPipe.md
Normal file
@@ -0,0 +1,158 @@
|
||||
---
|
||||
layout: forward
|
||||
target: https://developers.google.com/mediapipe
|
||||
title: Home
|
||||
nav_order: 1
|
||||
---
|
||||
|
||||
----
|
||||
|
||||
**Attention:** *We have moved to
|
||||
[https://developers.google.com/mediapipe](https://developers.google.com/mediapipe)
|
||||
as the primary developer documentation site for MediaPipe as of April 3, 2023.*
|
||||
|
||||

|
||||
|
||||
**Attention**: MediaPipe Solutions Preview is an early release. [Learn
|
||||
more](https://developers.google.com/mediapipe/solutions/about#notice).
|
||||
|
||||
**On-device machine learning for everyone**
|
||||
|
||||
Delight your customers with innovative machine learning features. MediaPipe
|
||||
contains everything that you need to customize and deploy to mobile (Android,
|
||||
iOS), web, desktop, edge devices, and IoT, effortlessly.
|
||||
|
||||
* [See demos](https://goo.gle/mediapipe-studio)
|
||||
* [Learn more](https://developers.google.com/mediapipe/solutions)
|
||||
|
||||
## Get started
|
||||
|
||||
You can get started with MediaPipe Solutions by by checking out any of the
|
||||
developer guides for
|
||||
[vision](https://developers.google.com/mediapipe/solutions/vision/object_detector),
|
||||
[text](https://developers.google.com/mediapipe/solutions/text/text_classifier),
|
||||
and
|
||||
[audio](https://developers.google.com/mediapipe/solutions/audio/audio_classifier)
|
||||
tasks. If you need help setting up a development environment for use with
|
||||
MediaPipe Tasks, check out the setup guides for
|
||||
[Android](https://developers.google.com/mediapipe/solutions/setup_android), [web
|
||||
apps](https://developers.google.com/mediapipe/solutions/setup_web), and
|
||||
[Python](https://developers.google.com/mediapipe/solutions/setup_python).
|
||||
|
||||
## Solutions
|
||||
|
||||
MediaPipe Solutions provides a suite of libraries and tools for you to quickly
|
||||
apply artificial intelligence (AI) and machine learning (ML) techniques in your
|
||||
applications. You can plug these solutions into your applications immediately,
|
||||
customize them to your needs, and use them across multiple development
|
||||
platforms. MediaPipe Solutions is part of the MediaPipe [open source
|
||||
project](https://github.com/google/mediapipe), so you can further customize the
|
||||
solutions code to meet your application needs.
|
||||
|
||||
These libraries and resources provide the core functionality for each MediaPipe
|
||||
Solution:
|
||||
|
||||
* **MediaPipe Tasks**: Cross-platform APIs and libraries for deploying
|
||||
solutions. [Learn
|
||||
more](https://developers.google.com/mediapipe/solutions/tasks).
|
||||
* **MediaPipe models**: Pre-trained, ready-to-run models for use with each
|
||||
solution.
|
||||
|
||||
These tools let you customize and evaluate solutions:
|
||||
|
||||
* **MediaPipe Model Maker**: Customize models for solutions with your data.
|
||||
[Learn more](https://developers.google.com/mediapipe/solutions/model_maker).
|
||||
* **MediaPipe Studio**: Visualize, evaluate, and benchmark solutions in your
|
||||
browser. [Learn
|
||||
more](https://developers.google.com/mediapipe/solutions/studio).
|
||||
|
||||
### Legacy solutions
|
||||
|
||||
We have ended support for [these MediaPipe Legacy Solutions](https://developers.google.com/mediapipe/solutions/guide#legacy)
|
||||
as of March 1, 2023. All other MediaPipe Legacy Solutions will be upgraded to
|
||||
a new MediaPipe Solution. See the [Solutions guide](https://developers.google.com/mediapipe/solutions/guide#legacy)
|
||||
for details. The [code repository](https://github.com/google/mediapipe/tree/master/mediapipe)
|
||||
and prebuilt binaries for all MediaPipe Legacy Solutions will continue to be
|
||||
provided on an as-is basis.
|
||||
|
||||
For more on the legacy solutions, see the [documentation](https://github.com/google/mediapipe/tree/master/docs/solutions).
|
||||
|
||||
## Framework
|
||||
|
||||
To start using MediaPipe Framework, [install MediaPipe
|
||||
Framework](https://developers.google.com/mediapipe/framework/getting_started/install)
|
||||
and start building example applications in C++, Android, and iOS.
|
||||
|
||||
[MediaPipe Framework](https://developers.google.com/mediapipe/framework) is the
|
||||
low-level component used to build efficient on-device machine learning
|
||||
pipelines, similar to the premade MediaPipe Solutions.
|
||||
|
||||
Before using MediaPipe Framework, familiarize yourself with the following key
|
||||
[Framework
|
||||
concepts](https://developers.google.com/mediapipe/framework/framework_concepts/overview.md):
|
||||
|
||||
* [Packets](https://developers.google.com/mediapipe/framework/framework_concepts/packets.md)
|
||||
* [Graphs](https://developers.google.com/mediapipe/framework/framework_concepts/graphs.md)
|
||||
* [Calculators](https://developers.google.com/mediapipe/framework/framework_concepts/calculators.md)
|
||||
|
||||
## Community
|
||||
|
||||
* [Slack community](https://mediapipe.page.link/joinslack) for MediaPipe
|
||||
users.
|
||||
* [Discuss](https://groups.google.com/forum/#!forum/mediapipe) - General
|
||||
community discussion around MediaPipe.
|
||||
* [Awesome MediaPipe](https://mediapipe.page.link/awesome-mediapipe) - A
|
||||
curated list of awesome MediaPipe related frameworks, libraries and
|
||||
software.
|
||||
|
||||
## Contributing
|
||||
|
||||
We welcome contributions. Please follow these
|
||||
[guidelines](https://github.com/google/mediapipe/blob/master/CONTRIBUTING.md).
|
||||
|
||||
We use GitHub issues for tracking requests and bugs. Please post questions to
|
||||
the MediaPipe Stack Overflow with a `mediapipe` tag.
|
||||
|
||||
## Resources
|
||||
|
||||
### Publications
|
||||
|
||||
* [Bringing artworks to life with AR](https://developers.googleblog.com/2021/07/bringing-artworks-to-life-with-ar.html)
|
||||
in Google Developers Blog
|
||||
* [Prosthesis control via Mirru App using MediaPipe hand tracking](https://developers.googleblog.com/2021/05/control-your-mirru-prosthesis-with-mediapipe-hand-tracking.html)
|
||||
in Google Developers Blog
|
||||
* [SignAll SDK: Sign language interface using MediaPipe is now available for
|
||||
developers](https://developers.googleblog.com/2021/04/signall-sdk-sign-language-interface-using-mediapipe-now-available.html)
|
||||
in Google Developers Blog
|
||||
* [MediaPipe Holistic - Simultaneous Face, Hand and Pose Prediction, on
|
||||
Device](https://ai.googleblog.com/2020/12/mediapipe-holistic-simultaneous-face.html)
|
||||
in Google AI Blog
|
||||
* [Background Features in Google Meet, Powered by Web ML](https://ai.googleblog.com/2020/10/background-features-in-google-meet.html)
|
||||
in Google AI Blog
|
||||
* [MediaPipe 3D Face Transform](https://developers.googleblog.com/2020/09/mediapipe-3d-face-transform.html)
|
||||
in Google Developers Blog
|
||||
* [Instant Motion Tracking With MediaPipe](https://developers.googleblog.com/2020/08/instant-motion-tracking-with-mediapipe.html)
|
||||
in Google Developers Blog
|
||||
* [BlazePose - On-device Real-time Body Pose Tracking](https://ai.googleblog.com/2020/08/on-device-real-time-body-pose-tracking.html)
|
||||
in Google AI Blog
|
||||
* [MediaPipe Iris: Real-time Eye Tracking and Depth Estimation](https://ai.googleblog.com/2020/08/mediapipe-iris-real-time-iris-tracking.html)
|
||||
in Google AI Blog
|
||||
* [MediaPipe KNIFT: Template-based feature matching](https://developers.googleblog.com/2020/04/mediapipe-knift-template-based-feature-matching.html)
|
||||
in Google Developers Blog
|
||||
* [Alfred Camera: Smart camera features using MediaPipe](https://developers.googleblog.com/2020/03/alfred-camera-smart-camera-features-using-mediapipe.html)
|
||||
in Google Developers Blog
|
||||
* [Real-Time 3D Object Detection on Mobile Devices with MediaPipe](https://ai.googleblog.com/2020/03/real-time-3d-object-detection-on-mobile.html)
|
||||
in Google AI Blog
|
||||
* [AutoFlip: An Open Source Framework for Intelligent Video Reframing](https://ai.googleblog.com/2020/02/autoflip-open-source-framework-for.html)
|
||||
in Google AI Blog
|
||||
* [MediaPipe on the Web](https://developers.googleblog.com/2020/01/mediapipe-on-web.html)
|
||||
in Google Developers Blog
|
||||
* [Object Detection and Tracking using MediaPipe](https://developers.googleblog.com/2019/12/object-detection-and-tracking-using-mediapipe.html)
|
||||
in Google Developers Blog
|
||||
* [On-Device, Real-Time Hand Tracking with MediaPipe](https://ai.googleblog.com/2019/08/on-device-real-time-hand-tracking-with.html)
|
||||
in Google AI Blog
|
||||
* [MediaPipe: A Framework for Building Perception Pipelines](https://arxiv.org/abs/1906.08172)
|
||||
|
||||
### Videos
|
||||
|
||||
* [YouTube Channel](https://www.youtube.com/c/MediaPipe)
|
||||
Reference in New Issue
Block a user