Why the schema matters
A preventive health system needs to change over time. New biomarkers may be added, medical guidance may evolve, a calibration may be updated, a threshold may need review, a treatment rule may need to be deprecated, or a safety rule may need to become stricter. If clinical logic is hidden inside application code, every change becomes harder to review and harder to explain. It also increases the risk that different parts of the product apply different logic. Consensus avoids this by treating the clinical engine as a governed knowledge system. The schema is the single source of truth for biomarker identity, interpretation, trends, formulas, calibration, patterns, treatment flags, safety, runtime output format, and governance lifecycle. This gives the company one controlled place to review clinical logic.Schema layer map
The schema can be understood as nine major layers.Reference data layer
The reference layer defines the basic clinical language of the engine. It answers questions such as: what is the canonical name of this biomarker, what aliases can appear from different labs, what unit should be used internally, what evidence source supports a rule, and which sources are accepted in the evidence library. The evidence library contains 113 referenced sources, including clinical guidelines and genomic or pharmacogenomic references. This layer is preventive because it reduces silent errors. A value should not be interpreted differently because one lab uses a different label, unit, or reporting convention.Interpretation layer
The interpretation layer converts biomarker values into structured states. It does not simply mark results as “normal” or “abnormal.” It supports a more preventive clinical vocabulary: favorable or normal, early signal, actionable concern, critical concern, insufficient or ambiguous, and clinician-only review. This is where the engine translates data into meaning, and where it must be careful. A preventive signal is not automatically a diagnosis, and an out-of-range biomarker is not always a stable disease state. The interpretation layer works together with hardening, suppression, and review-routing logic.Derived computation layer
Some clinical signals are calculated rather than directly measured. The derived computation layer handles these formulas in a structured way:
Derived formulas are not hidden in application code. They are part of the governed clinical schema, which means they can be reviewed, tested, versioned, and audited.
Calibration layer
The calibration layer adjusts interpretation when defined biological or contextual conditions change what a biomarker means. A calibration is not a vague personalization feature. It is a structured rule with a defined shape:- Biomarker — identifies what is being calibrated.
- Applies-when condition — defines when the calibration is allowed to apply.
- Machine-readable logic — allows deterministic evaluation.
- Human-readable rationale — allows clinician review.
- Evidence level — shows the strength of support.
- Version and provenance — makes historical reproduction possible.
- Review status — controls whether the calibration can be used.
Pattern layer
The pattern layer evaluates combinations of biomarkers, because many preventive signals are not visible in one value. They emerge through relationships:
The pattern layer remains deterministic. A pattern exists because it has been encoded, reviewed, and governed. It is not invented by a generative model during runtime. A clinician can review the anchors, exclusions, supporting markers, and rule logic that produced the pattern.
Treatment and protocol linkage layer
The treatment layer does not prescribe. It creates structured clinician-required flags. In the GLP-1 flow, the engine may evaluate fasting status, BMI, glucose, HbA1c, HOMA-IR, insulin state, a contraindication screen, and over-diagnosis hardening rules. If conditions are met, the system raises an advisory flag for clinician review. It does not tell the patient they are “eligible,” and it does not authorize treatment. This layer supports scalable preventive workflows without crossing into automated medical decision-making.Safety layer
The safety layer is where the system prevents over-interpretation. It includes suppression rules (hide or delay interpretation when context makes a result unreliable), clinical hardening (require confirmation before stronger assertions), conflict rules (detect contradictions or incompatible signals), review states (route ambiguity or high-stakes findings to clinicians), and contraindication logic (prevent treatment flags from advancing without safety review). Examples include pregnancy suppression, recent acute illness suppression, recent strenuous exercise suppression, diabetes hardening, CKD chronicity, and fasting gates. This layer gives the engine a preventive posture: it can detect earlier signals, but it cannot freely overstate them.Runtime layer
The runtime layer defines how the engine receives facts and how it emits decisions. The runtime output is a structured decision record with a uniquedecision_id, organization and patient references, inputs considered, rules fired, calibrations applied, resulting state, and cited evidence. It also defines the input contract through runtime facts: profile fields, derived values, biomarker states, derived flags, specimen quality facts, and longitudinal data.
A simplified runtime contract:
1
Input facts
The validated facts available for evaluation.
2
Rule evaluation
The deterministic logic applied to those facts.
3
Calibration trace
The context-aware adjustment applied, if any.
4
Evidence trace
The source supporting the interpretation.
5
Output state
The resulting clinical state.
6
Review routing
Whether the output can be patient-visible or requires clinician review.
7
Decision record
The audit unit for future review.
Governance layer
The governance layer controls whether clinical content can run. Clinical content moves through a formal lifecycle:In this architecture, existence is not activation. A rule can be drafted, reviewed, approved, deprecated, or retired — but only properly gated clinical content should affect patient-facing interpretation.
Boot-time validators
Before serving, the engine runs integrity validators that check the system is internally coherent before any patient is exposed to output:
These boot-time validators prevent silent misconfiguration from reaching a patient. They are part of the validation stack alongside golden test cases, Medical Director review, and outcomes monitoring.
The key architectural principle
The engine schema is not just a database design. It is a safety design. The schema allows Consensus Center to answer the questions that matter in clinical AI:
The schema is the foundation that makes preventive interpretation scalable without becoming uncontrolled automation.