sayan
eeb684b46c
#38 Ipad app production readiness, Colony orchestration, Social posting Co-authored-by: Sayan Datta <sayan@Sayans-MacBook-Air.local> Reviewed-on: #44
85 lines
3.3 KiB
Markdown
85 lines
3.3 KiB
Markdown
# Software Requirements Specification (SRS)_ Multi-Surface Platform and Oracle Expansion
|
|
|
|
**Date:** 2026-04-16
|
|
**Status:** Active technical baseline
|
|
**Owner:** Sayan
|
|
**Reviewers:** Sagnik, frontend lead, backend lead
|
|
**Scope:** Technical requirements for tablet apps, phone edge apps, Oracle template DB, inventory ingestion, and admin control plane
|
|
**Purpose:** Define the system requirements, interfaces, constraints, and acceptance boundaries for implementation.
|
|
|
|
## 1. Purpose
|
|
|
|
Specify the technical system needed to extend Velocity across tablets, phone edge apps, Oracle template infrastructure, inventory ingestion, and admin operations without breaking the current root architecture.
|
|
|
|
## 2. System Context
|
|
|
|
The system lives inside current Project Velocity:
|
|
|
|
- `Project_Velocity/app/` for WebOS
|
|
- `Project_Velocity/backend/` for backend authority
|
|
- `Project_Velocity/iOS/` for current native tablet reference
|
|
- `Project_Velocity/db assets/Inventory/` for current seed data
|
|
|
|
## 3. Assumptions and Constraints
|
|
|
|
- backend remains canonical
|
|
- Oracle route and schema direction already exists
|
|
- current iPad app is the tablet reference implementation
|
|
- Android and phone apps must not create a second backend center
|
|
- mobile capture must follow supported platform and consent paths
|
|
|
|
## 4. Functional Requirements
|
|
|
|
- preserve a single backend authority in `Project_Velocity/backend/`
|
|
- support completion of the existing iPad app residual pages and component updates
|
|
- support an Android tablet product with the same feature architecture as the iPad app
|
|
- support phone edge apps as narrow operator surfaces
|
|
- support durable communication-memory capture, import, retrieval, and reminder generation
|
|
- support per-user calendar entities and calendar action flows
|
|
- support transcription with speaker segregation for supported recordings
|
|
- support downstream insight extraction for CRM and QD-score recommendations
|
|
- support Oracle template catalog persistence
|
|
- support Kimi Synthetic Data as a follow-on program using the seed template DB
|
|
- support inventory property ingest and edit workflows
|
|
- support an admin control plane
|
|
|
|
## 5. Interface Requirements
|
|
|
|
- existing backend auth APIs
|
|
- Oracle route surface in `routes_oracle.py` and `oracle/router_v1.py`
|
|
- inventory APIs to be added through current backend
|
|
- admin APIs to be added through current backend
|
|
- business telephony and messaging provider adapters where channel support exists
|
|
- calendar APIs through the current backend
|
|
- transcript processing interfaces for diarized transcript outputs
|
|
|
|
## 6. Data Model
|
|
|
|
Core entities:
|
|
|
|
- `surface_sessions`
|
|
- `edge_events`
|
|
- `communication_memory_facts`
|
|
- `calendar_events`
|
|
- `transcription_jobs`
|
|
- `transcript_segments`
|
|
- `insight_recommendations`
|
|
- `inventory_properties`
|
|
- `inventory_media_assets`
|
|
- `oracle_template_chapters`
|
|
- `oracle_template_subchapters`
|
|
- `oracle_component_templates`
|
|
- `oracle_template_examples`
|
|
- `admin_action_events`
|
|
|
|
## 7. Acceptance Criteria
|
|
|
|
The engineering gate is met when:
|
|
|
|
- all workstreams are mapped to real files, contracts, and schema
|
|
- no parallel schema center is introduced
|
|
- phone edge scope is technically defensible
|
|
- communication-memory flow exists for supported channels and fallback paths
|
|
- calendar and transcript-intelligence flow exist as first-class technical requirements
|
|
- Oracle template DB seed path is explicit
|