Getting started
Capability status
This platform is unusually strict about the difference between built, simulated, and gated. Every capability statement in this documentation carries exactly one of seven labels — no hedging, no qualifiers.
#The seven labels
| Label | Meaning |
|---|---|
| Implemented locally | Executable in the repository today, with test evidence. No external authority involved. |
| Simulated | A deterministic local stand-in exercising the same seam a real capability would use. Never presented as the real action. |
| Experimental | Implemented but explicitly unstable. Contracts may change without a deprecation window. |
| Requires licensed content | Blocked on a terminology, drug-database, or clinical-rules license. |
| Requires external authorization | Blocked on a legal, contractual, identity, or network agreement. |
| Requires certification | Blocked on a formal certification or regulatory outcome. |
| Not implemented | Absent. Requests fail closed. |
#Two rules that follow
1. A prescription is never labeled sent, delivered, accepted by a pharmacy, clinically approved, or legally signed when only a local simulation occurred. Simulation naming carries through end to end: domain, database, API, events, and UI.
2. A failed, unavailable, or skipped check is reported as exactly that. It is never converted into a passing result.
#Why this exists
Health software fails quietly when documentation describes intent instead of behavior. A reader who cannot distinguish "this works" from "this is planned" will eventually make a clinical or commercial decision on a claim that was never true.
The taxonomy makes that distinction mechanical rather than editorial. A capability either has executable evidence at the revision being assessed, or it carries a label saying what is missing and who must supply it. Qualifiers such as "partial" or "in part" are not permitted — a capability that is half-built is split into rows that each carry one honest label.
#Precedence when sources disagree
If checked-in code, an active contract, and documentation ever disagree, the resolution order is fixed:
- Code, migrations, and executable testsThese describe current behavior. Nothing outranks them.
- Checked OpenAPI and event artifactsThese describe the intended active wire contracts.
- Operational recordsThese describe the implemented slice and its safety boundary.
- Architecture and roadmap documentsThese describe constraints and future design, never current capability.
A disagreement is recorded as a defect and reconciled. The safer or more desirable behavior is never documented as though it already exists, and a passing design review is never production approval.
#Applying the labels
The engine, developer platform, and interface layer each carry per-capability labels. As a representative sample:
| Capability | Status |
|---|---|
| Synthetic draft creation, validation, and atomic commit | Implemented locally |
| One-time grant exchange and read-only review | Implemented locally |
| Tamper-evident audit hash chains | Implemented locally |
| Local outbox relay | Simulated |
| Deterministic terminology failure fixtures | Simulated |
| Approval, signing, transmission | Not implemented |
| Typed SDKs, CLI, webhook delivery | Not implemented |
| Interaction, allergy, and dose-range screening | Requires licensed content |
| Prescription-network transport | Requires external authorization |
| Production pilot at scale | Requires certification |