# 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