KrinosAI — Acceptance Criteria
Template ID: TPL-02-05 | Stage: 02-Requirements | Version: 0.3
Record: KAI-VORAL-ACR-001 — retrospective draft for Visionary Oral. Not approved.
Purpose: Define binary pass/fail scenarios for a story or requirement, including boundaries and failures.
Required inputs: User stories; SRS requirements; use-case flows.
Document control
| Field |
Required entry |
| Document ID |
KAI-VORAL-ACR-001 |
| Template used |
TPL-02-05 Acceptance Criteria 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-SRS-001; KAI-VORAL-UST-001; KAI-VORAL-UCS-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. Acceptance criteria are written for the implemented behaviour; no acceptance run has been recorded yet (stage 07).
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. Story or requirement ID
| AC set |
Story |
REQ |
| AC set 1 |
US-01 |
REQ-012, REQ-013, REQ-017, REQ-020, REQ-022 |
| AC set 2 |
Admin |
REQ-003, REQ-007, REQ-008, REQ-026 |
| AC set 3 |
Security |
REQ-034, REQ-036 |
2. Preconditions and actor permissions
| AC ID |
Role |
Preconditions / data |
| AC-01 |
Doctor (active) |
Patient exists; phone online |
| AC-02 |
Doctor |
Blurred synthetic photo |
| AC-03 |
Doctor |
Scan just taken |
| AC-04 |
Doctor |
Phone offline |
| AC-05 |
Doctor (suspended) |
Admin suspended the account |
| AC-06 |
Admin |
Doctor with a 2-minute offline limit |
| AC-07 |
Anonymous caller |
No session |
| AC-08 |
Self-registered doctor |
No invitation |
3. Given-When-Then scenarios
| AC ID |
Given |
When |
Then |
| AC-01 |
an active doctor and a patient |
front, upper and lower photos are accepted |
a report with 3 photos, findings per photo and an overall score is shown |
| AC-02 |
a blurred photo |
it is captured |
a retake is requested |
| AC-03 |
a scan just taken on the phone |
the report is opened three times |
all three openings show the same photos and findings |
| AC-04 |
the phone is offline |
a scan is taken |
the report is shown from the phone and photos upload when back online |
| AC-05 |
a suspended doctor |
the app is brought to the foreground |
the account-suspended screen is shown |
| AC-06 |
a 2-minute offline limit |
the app is used offline for more than 2 minutes, then reconnected |
the app locks, then the account is suspended |
| AC-07 |
no session |
GET /api/admin/patient-sample is called |
HTTP 401 is returned (fails today — OPEN-026) |
| AC-08 |
a doctor without an invitation |
they finish sign-up |
the account is pending and "Waiting for approval" is shown |
4. Happy path and boundary scenarios
| AC ID |
Boundary |
Expected |
| AC-01 |
Upper/lower photos |
Only cavity and calculus boxes (REQ-017) |
| AC-06 |
Limit of 1 minute; limit removed |
Lock after 1 minute; no lock when removed |
5. Failure rejection and recovery behavior
| AC ID |
Failure |
Expected behavior |
| AC-04 |
Upload fails 5 times |
Manual retry offered; photos kept |
| AC-05 |
Admin unsuspends |
"Try again" restores access |
6. Nonfunctional measurable thresholds
| AC ID |
Threshold |
Measurement |
| AC-01 |
Report shown within Proposed (Claude Code, for confirmation): ≤ 60 s online, ≤ 5 min on-device after the last photo |
Stopwatch on a reference phone |
7. Evidence references and acceptance decision
| AC ID |
Evidence |
Result |
Accepted by |
| AC-01 … AC-08 |
Not run yet — test cases in stage 07 (OPEN-032) |
Not recorded |
Product Owner (name to be assigned) |
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-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-032 |
Design (DES) and test (TC) links for requirements are added by stages 03 and 07; requirements without them stay open |
Tech Lead |
2026-12-15 (proposed) |
No |
RTM with DES and TC links |
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 |