Technology principle
Clinical logic belongs in the governed engine. Product code, agents, and integrations should serve that engine, not redefine it.
High-level stack map
The system can be organized into seven technical layers. Some implementation details — language, runtime, vendors, hosting, and model providers — are marked as items to confirm with engineering.Engine schema and runtime
The engine schema is the clinical knowledge layer, containing the structured objects that define how interpretation works: biomarkers, reference sources, unit conversions, status rules, trend rules, derived formulas, calibrations, patterns, treatment flags, safety rules, the runtime output schema, the runtime facts catalog, and lifecycle controls. The v2.8.4 schema spans 67 tables, with each output tracing to a specific rule and cited source rather than to an opaque model. The deterministic runtime reads the schema and evaluates patient facts. It should not contain hidden clinical logic that bypasses the schema. When a rule fires, the runtime produces a structured output with decision ID, input facts, rule trace, calibration trace, evidence trace, resulting state, and visibility handling.Runtime validation responsibilities
The runtime is not only an evaluator. It is also a safety gate. Before serving, it runs boot-time validators confirming operator registry coverage, runtime facts coverage, template resolver coverage, unit single source of truth, and lifecycle enforcement. The runtime should fail safely. If a rule references a missing fact, an unknown operator, an unapproved lifecycle state, or an unresolved message, the system blocks affected output rather than improvising.AI agents layer
AI agents sit around the deterministic engine. Their role is operational: collecting information, organizing workflows, preparing records, and supporting communication. They handle intake, record consolidation, missing-data detection, follow-up, patient communication (in approved language), clinician support, and treatment pathway coordination (surfacing clinician-required advisory flags only). The agent layer is integrated through tool-use against the engine and structured data. It does not embed clinical thresholds in prompts or create treatment logic outside the schema.Member application
The member app is the patient-facing layer. Its job is to make preventive care understandable without overstating what the system knows. It may support account and subscription, intake, lab upload or ordering, results display (approved patient-visible states only), missing-data prompts, follow-up tasks, education, consent, and notifications.Operator application
The operator app is the clinic-facing or operations-facing layer. It supports the people who manage patients, clinicians, workflows, and follow-up, showing the patient list, intake completeness, lab status, review queue, engine states, decision trace, treatment flags (advisory only), safety flags, message drafts, and audit history. The operator app should never become a workaround around the Medical Director lifecycle. It should make governance easier to follow, not easier to bypass.Data and storage layer
The data layer stores sensitive clinical and operational records: patient profile, biomarker data (raw and normalized), derived values, context inputs, sensitive calibration inputs (where consented), engine outputs, decision records, clinician decisions, audit logs, and consent records. Clinical data and decision records are sensitive data under Ley 1581, with HIPAA-aligned handling planned for expansion, alongside least-privilege access, segregation, audit logging, and separate consent for de-identified data used to improve calibrations. The storage design must support both privacy and traceability — the system should explain decisions without exposing sensitive data to unauthorized roles.Integrations layer
Consensus depends on external services for parts of the care workflow.
This section remains cautious in the whitepaper. Vendor names, versions, regions, contracts, and data-handling terms should not be presented as final until engineering confirms them.
Evidence-source dependency
The evidence library is a special dependency because it supports clinical interpretation. The engine references clinical guidelines and genomic or pharmacogenomic references throughREF_SOURCES — 113 evidence sources in the reference layer. Evidence-source governance tracks the source ID, source type, clinical domain, rule linkage, evidence grade, review date, reviewer, status, and update trigger. A rule is only as defensible as the evidence and review process behind it.
Lab integration requirements
Lab integrations are clinically sensitive because upstream data quality affects downstream interpretation. A lab integration defines biomarker mapping to canonical engine biomarkers, unit handling through the single source of truth, reference metadata (stored but not blindly treated as engine logic), specimen metadata, result provenance, error handling for missing/duplicated/impossible/conflicting values, reconciliation so updated results do not silently overwrite prior decisions, and auditability. The engine should not assume all lab inputs are clean; it validates and normalizes before interpretation.Payment integration requirements
Payment systems are not clinical systems, but they can affect patient access and operational workflow, so they are separated from clinical interpretation. Subscription billing should not affect clinical state interpretation; plan status may affect access to services but not medical conclusions; failed payment should not alter stored clinical data or decision traces; refunds and receipts are operational; payment metadata is kept separate from sensitive clinical records.AI model provider requirements
AI model providers are a high-scrutiny dependency because agents may process sensitive context. This is a completion requirement, not a marketing detail. Before external release, engineering should confirm the provider name, model version, data handling, retention policy, training use, region, encryption (in transit and at rest), access control, change management, fallback behavior, and monitoring.Open-source and third-party inventory
Open-source and third-party components must be inventoried. Any OSS or third-party component incorporated into the engine or apps must be inventoried with its license and reconciled with the Engine IP Assignment, Exhibit A, so no license compromises the company’s ownership or ability to commercialize. The inventory includes the component name, version, license, usage location, linkage type, data access, security status, replacement risk, IP impact, owner, and review date. This is especially important for investor diligence: a strong clinical engine can still create company risk if its dependency licensing is unclear.Security posture
The baseline security posture is least-privilege access, clinical data segregation, decision traces for audit, data protection under Colombian Ley 1581, HIPAA-aligned handling for US expansion, secrets management, and encryption in transit and at rest, with standards to confirm. The security architecture covers identity and access (role-based, least privilege, MFA where appropriate), clinical data segregation, encryption, secrets management, audit logging, data minimization, consent enforcement, vendor review, incident response, backup and recovery, environment separation, and monitoring.Because the system handles clinical data, security is part of clinical safety. A breach, misrouting, or unauthorized access event can create patient harm even when the medical logic is correct.
Data protection and consent
Data protection is tied to the kinds of data the engine uses.
Ancestry and genotype data require express consent and heightened protection, and are used only for clinical calibration. Consent should not live only in legal text — the system enforces consent through data access, calibration eligibility, and audit logs.
Continuity and key-person risk
Engineering knowledge should not be single-threaded. The engine schema, runtime, and deployment should be documented so the system survives any one person’s departure. Continuity controls include architecture documentation, a schema dictionary, runtime documentation, a deployment runbook, an incident runbook, an access inventory, backup procedures, a dependency inventory, test suite documentation, clinical governance documentation, onboarding material, and administrative access continuity. This is a diligence requirement, not just operational maturity. A clinical infrastructure company must show its core system is maintainable beyond any single individual.Environment separation
The stack clearly separates environments. Clinical rules should not move from development to production without lifecycle approval, validation, and release gating.Deployment and release controls
Technology deployment must align with clinical governance. A normal software release process is not enough; a clinical-engine release confirms both technical and medical readiness.Schema version recorded, runtime version recorded, golden tests passed, boot validators passed, active clinical content reviewed, lifecycle status enforced, patient-facing templates resolved, security checks passed, dependency changes reviewed, rollback available, Medical Director release gate passed (for clinical content), and engineering sign-off recorded (for technical release).