KrinosAI — Product Requirements Document (PRD)
Template ID: TPL-02-01 | Stage: 02-Requirements | Version: 0.3
Record: KAI-VORAL-PRD-001 — retrospective draft for Visionary Oral. Not approved.
Purpose: Describe the product problem, users, goals, journeys and scope so that the SRS can be written from it.
Required inputs: Approved charter; stakeholder register; interview notes; analytics; initiation risk screen.
Document control
| Field |
Required entry |
| Document ID |
KAI-VORAL-PRD-001 |
| Template used |
TPL-02-01 Product Requirements Document (PRD) v0.3 |
| Product / project / software version or commit SHA |
VORAL (Visionary Oral) / PRJ-001 / a6b4429e3165 (branch app_dev of AI-Dental-Project/Visionary_Oral) |
| Record status and version |
Draft v0.1 |
| Author / technical reviewer / quality reviewer |
Claude Code (drafted with Claude Code for KrinosAI) / Tech Lead (name to be assigned) / Security & Privacy Officer (name to be assigned) |
| Created / updated / approved dates |
2026-10-27 / 2026-10-27 / Pending |
| Applicable SOP and revision |
SOP-LC-02 v0.3 |
| Related issue, commit, requirement and evidence links |
KAI-VORAL-BRF-001, KAI-VORAL-IRS-001, KAI-VORAL-CHR-001, KAI-VORAL-DEC-001; KAI-VORAL-SRS-001 |
| Approver and decision record |
Pending |
Applicability and evidence baseline
Product / system boundary: Web app and API (dentalapp/), doctor/admin mobile app (mobile/), PDF Lambda (dentalapp/pdf-lambda/) at a6b4429e3165, and the external services they call (see KAI-VORAL-IRS-001).
Related approved requirements, risks and change records: None approved. Related drafts are listed in document control.
Retrospective record? Yes — follows the Retrospective Documentation Protocol (KrinosAI lifecycle pack, 05-References/). Items are labelled Observed (code or Git at a6b4429), Measured (dated run), Stated (named person, dated) or Not recorded. The existing PRD (docs/Prd - Visionary_Oral …md) describes an earlier 5-view design; this record describes the product as built and lists the differences (OPEN-005).
Acceptable evidence: an implementation reference (file:line at a commit SHA), a dated test record, a signed decision, a vendor agreement, or another independently verifiable artifact. Never invent approvals, clinical results, measurements or performance data.
1. Problem and user personas
| Persona ID |
Role / setting |
Goal |
Current pain (with evidence) |
Source |
| PER-01 |
Dentist / doctor at a clinic (web and mobile) |
Screen patients quickly and give them a report |
Proposed (Claude Code, for confirmation): measure scans per month and active clinics from the scans and profiles collections |
Role in code: dentalapp/src/lib/auth-helpers.js:20 |
| PER-02 |
Doctor working without internet (mobile) |
Keep scanning and showing reports offline |
Proposed (Claude Code, for confirmation): measure scans per month and active clinics from the scans and profiles collections |
mobile/src/lib/offline/ @ a6b4429 |
| PER-03 |
KrinosAI administrator |
Onboard, approve, suspend doctors; watch usage |
Proposed (Claude Code, for confirmation): measure scans per month and active clinics from the scans and profiles collections |
mobile/app/(admin)/index.tsx; dentalapp/src/app/admin/dashboard/page.jsx |
| PER-04 |
Patient (QR self-registration, patient dashboard) |
Understand oral health and see a dentist |
Proposed (Claude Code, for confirmation): measure scans per month and active clinics from the scans and profiles collections |
dentalapp/src/app/api/public/patient-registration/route.js:30 |
2. Business objectives and non-goals
| ID |
Objective or non-goal |
Metric / note |
| OBJ-1 (proposed) |
Close security and privacy blockers |
OPEN-007, OPEN-008, OPEN-026 closed |
| OBJ-2 (proposed) |
Lawful, documented processing of health data |
DPIA approved (OPEN-009) |
| OBJ-3 (proposed) |
Known detector performance |
Validation study (OPEN-011) |
| NG-1 |
Non-goal: diagnosis or treatment advice |
KAI-VORAL-BRF-001 §4 |
| NG-2 |
Non-goal: left/right views in V1 |
ADR 0008 |
3. User journeys and workflow diagrams
| Journey |
Step |
Actor |
System response |
| J1 Scan to report |
1 |
Doctor |
Opens patient, taps New scan |
| J1 Scan to report |
2 |
Doctor |
Captures front, upper, lower; each photo quality-checked (REQ-012, REQ-013) |
| J1 Scan to report |
3 |
System |
Saves photos, runs detectors, uploads, stores findings (REQ-014–REQ-019) |
| J1 Scan to report |
4 |
System |
Shows the report with findings, score and AI text; PDF download (REQ-020–REQ-023) |
| J2 Doctor onboarding |
1–3 |
Admin / Doctor |
Invite or self sign-up → (approval) → doctor area (REQ-005–REQ-007) |
| J3 Patient QR registration |
1–3 |
Patient |
Scans clinic QR → registers → public scan session (REQ-029) |
| J4 Offline work |
1–3 |
Doctor |
Works offline within the limit → syncs later; lock and suspension after the limit (REQ-011, REQ-025, REQ-026) |
Figure 1 — User journeys J1 to J4.
flowchart TD
subgraph J2["J2 Doctor onboarding"]
a1["Admin invites<br/>or doctor signs up"] --> a2{"Self sign-up?"}
a2 -->|yes| a3["Pending until<br/>admin approves"] --> a4["Doctor area"]
a2 -->|no, invited| a4
end
subgraph J1["J1 Scan to report"]
b1["Open patient → New scan"] --> b2["Capture front, upper, lower<br/>quality check per photo"]
b2 --> b3["Save, detect, upload,<br/>store findings"] --> b4["Report: findings, score,<br/>AI text, PDF"]
end
subgraph J3["J3 Patient QR registration"]
c1["Patient scans clinic QR"] --> c2["Registers"] --> c3["Public scan session"]
end
subgraph J4["J4 Offline work"]
d1["Doctor works offline"] --> d2{"Within the<br/>offline limit?"}
d2 -->|yes| d3["Sync when back online"]
d2 -->|no| d4["App locks;<br/>account suspended"]
end
a4 --> b1
c3 --> b4
4. Functional capabilities with IDs
| CAP ID |
Capability |
Journey |
Priority |
| CAP-01 |
Sign-in, roles and account status |
All |
Must |
| CAP-02 |
Doctor administration (invite, approve, suspend, offline limit) |
J2 |
Should |
| CAP-03 |
Patient management (online and offline) |
J1, J4 |
Should |
| CAP-04 |
Guided 3-view capture with quality check |
J1 |
Must |
| CAP-05 |
Photo upload and scan records |
J1 |
Must |
| CAP-06 |
AI detection (server and on-device) |
J1 |
Must |
| CAP-07 |
Report: findings, score, AI text, PDF, languages |
J1 |
Must |
| CAP-08 |
Offline operation and offline access limit |
J4 |
Should |
| CAP-09 |
Clinic information, QR registration and public scans |
J3 |
Should |
| CAP-10 |
Plans, payments and usage |
All |
Should |
| CAP-11 |
Support and notifications |
All |
Should |
| CAP-12 |
Security and privacy controls |
All |
Must |
5. Nonfunctional quality attributes with thresholds
| NFR ID |
Attribute |
Threshold |
Measured how |
| NFR-01 |
Availability of the web app and API |
Proposed (Claude Code, for confirmation): 99.5 % monthly |
Uptime monitoring (stage 09) |
| NFR-02 |
Time from last photo to report (online / offline) |
Proposed (Claude Code, for confirmation): ≤ 60 s online, ≤ 5 min on-device |
Timed test on reference phones (stage 07) |
| NFR-03 |
Offline operation period |
Admin-set per doctor (REQ-009) |
Configuration |
| NFR-04 |
Security: no unauthenticated access to personal data |
Zero unprotected routes (REQ-034) |
Route inventory re-run |
| NFR-05 |
Accessibility |
Proposed (Claude Code, for confirmation): WCAG 2.1 AA for web pages; screen-reader labels and system text scaling in the app |
Accessibility review |
6. Data privacy and clinical safety needs
| Need |
Source |
Becomes |
| Lawful basis and consent for health data and photos |
KAI-VORAL-IRS-001 §6 |
DPIA KAI-VORAL-DPIA-001; OPEN-009, OPEN-031 |
| No diagnostic claims in report wording |
KAI-VORAL-IRS-001 §3 |
Regulatory hold point OPEN-006 |
| Clinical performance of detectors and score |
KAI-VORAL-IRS-001 §3 |
Validation, OPEN-011 |
7. Dependencies constraints and assumptions
| Type |
Item |
Owner |
Validate by |
| Dependency |
ML service Visionary_oral_ML (Hugging Face Space) |
ML Lead |
Stage 03 HLD |
| Dependency |
Clerk, MongoDB, Cloudflare R2, AWS, OpenRouter, Groq, Resend, Cashfree, Expo EAS |
Tech Lead |
OPEN-012, OPEN-022 |
| Constraint |
Offline-first mobile with on-device models |
Mobile Lead |
Stage 03 LLD |
| Assumption |
Clinics in India are the primary market |
Product Owner |
OPEN-006 |
8. Priority and release scope
| CAP ID |
Release |
Priority |
| CAP-01 |
Current release (retrospective) |
Must |
| CAP-02 |
Current release (retrospective) |
Should |
| CAP-03 |
Current release (retrospective) |
Should |
| CAP-04 |
Current release (retrospective) |
Must |
| CAP-05 |
Current release (retrospective) |
Must |
| CAP-06 |
Current release (retrospective) |
Must |
| CAP-07 |
Current release (retrospective) |
Must |
| CAP-08 |
Current release (retrospective) |
Should |
| CAP-09 |
Current release (retrospective) |
Should |
| CAP-10 |
Current release (retrospective) |
Should |
| CAP-11 |
Current release (retrospective) |
Should |
| CAP-12 |
Current release (retrospective) |
Must |
9. Acceptance and signoff
| Role |
Name |
Decision |
Date |
| Product Owner |
Product Owner (name to be assigned) |
Pending |
Pending |
| Sponsor |
Sponsor (name to be assigned) |
Pending |
Pending |
Open issues and decisions
| ID |
Specific gap or decision |
Responsible owner |
Due date |
Blocks gate? |
Evidence required |
Status |
| OPEN-001 |
Tracker project ID, named requester and sponsor, and named reviewers are not recorded |
Product Owner |
2026-11-10 (proposed) |
Yes |
Tracker entry; names with roles |
Open |
| OPEN-002 |
No quantitative evidence of the problem (users, clinics, scans, support data) and no market/duplicate search |
Product Owner |
2026-11-30 (proposed) |
No |
Usage analytics, clinic data or customer interviews, dated |
Open |
| OPEN-005 |
Documents disagree with code: PRD/system flow say 5 views, Cloudinary and direct Gemini; code uses 3 views, Cloudflare R2/S3 storage and OpenRouter/Groq |
Tech Lead |
2026-11-30 (proposed) |
No |
Updated PRD, or a recorded decision to keep the code behaviour |
Open |
| OPEN-006 |
Medical-device applicability not assessed in any jurisdiction |
Qualified regulatory reviewer |
2026-11-30 (proposed) |
Yes |
Written regulatory determination |
Open |
| OPEN-007 |
Credential files committed to Git: dentalapp/google-credentials.json, dentalapp/mongoDb_usernamePassword (contents not opened) |
Security & Privacy Officer |
2026-10-31 (proposed) |
Yes |
Credentials rotated; files removed and purged from history; confirmation |
Open |
| OPEN-008 |
Database backups with personal data committed to Git: 9 files under dentalapp/backups/ (commit 92a4b77; contents not opened) |
Security & Privacy Officer |
2026-10-31 (proposed) |
Yes |
Files purged from history; breach/incident assessment recorded |
Open |
| OPEN-009 |
No DPIA |
Security & Privacy Officer |
2026-11-30 (proposed) |
Yes |
DPIA |
Open |
| OPEN-011 |
No clinical validation |
Clinical advisor with ML Lead |
2026-12-15 (proposed) |
Yes |
Validation study |
Open |
| OPEN-012 |
No vendor DPAs |
Security & Privacy Officer |
2026-11-30 (proposed) |
Yes |
DPAs |
Open |
| OPEN-022 |
Production hosting (Vercel vs Render), deployed version and dated integration checks for Clerk, MongoDB, R2, AWS, OpenRouter, Groq, Cashfree and Resend not recorded |
Tech Lead |
2026-11-30 (proposed) |
No |
Environment record (stage 05) with dated checks |
Open |
| OPEN-026 |
Critical: 20 API routes have no authentication check, incl. /api/admin/patient-sample (patient emails) and /api/admin/api-usage (doctor names and emails), support tickets/messages, and paid AI routes (/api/detect-gemini, /api/speech-to-text, /api/validate-scan) — see docs/lifecycle/_evidence/api-inventory-a6b4429.md |
Backend Lead |
2026-10-31 (proposed) |
Yes |
Auth added to each route; re-run of the inventory shows none unprotected |
Open |
| OPEN-028 |
No nonfunctional targets (response time, availability, analysis time, offline period) are defined |
Product Owner |
2026-11-30 (proposed) |
No |
Approved NFR targets |
Open |
| OPEN-030 |
No accessibility requirements or checks (contrast, screen readers, text size) |
Product Owner |
2026-12-15 (proposed) |
No |
Accessibility requirements and a test record |
Open |
| OPEN-031 |
No recorded patient consent or privacy notice for photo capture, AI processing and QR self-registration |
Security & Privacy Officer |
2026-11-30 (proposed) |
Yes |
Consent text, where it is shown, and stored consent records |
Open |
Review and approval
| Review role |
Named individual |
Decision |
Date |
Signed / controlled record |
| Author |
Claude Code (drafted with Claude Code) |
Draft |
2026-10-27 |
This file at the commit that adds it |
| Technical reviewer |
Tech Lead (name to be assigned) |
Pending |
Pending |
Pending |
| Quality / regulatory reviewer (if applicable) |
Qualified regulatory reviewer (name to be assigned) |
Pending |
Pending |
Pending |
| Authorized approver |
Product Owner (name to be assigned) |
Pending |
Pending |
Pending |