The strongest due diligence posture is not “trust us.” It is: here is the rule, here is the evidence, here is the reviewer, here is the lifecycle state, here is the validation result, here is the runtime trace, here is the rollback path.
Due diligence principle
Every major claim about the engine should map to a document, schema object, validation result, or audit record.What each audience should verify
- Investors
- Clinical partners
- Regulators / compliance
Investors should verify whether Consensus Center has a defensible technical and clinical asset, not only a product interface: the technical moat (engine schema, runtime, validation framework, decision trace design), the scientific moat (calibration library, evidence sources, outcomes-learning loop), clinical governance, safety posture, AI defensibility, the data asset, regulatory readiness, IP and dependencies, key-person risk, and commercial readiness. The moat is not one clever rule, but the reviewed, evidence-graded calibration library plus the outcomes dataset that refines it over time.
Core diligence artifacts
The data room should include a structured set of artifacts so reviewers can move from high-level explanation to proof: engine architecture overview, schema workbook, clinical guardrails document, calibration methodology, ancestry and context input policy, validation strategy, data model and traceability document, AI architecture and governance, GLP-1 flow, technology stack and dependencies, data protection policy, release and rollback runbook, Medical Director sign-off queue, evidence library export, validation results report, and dependency and OSS inventory.Claims that should be avoided unless proven
The whitepaper should avoid claims that are not yet supported by completed evidence or validation.
Result fields must be filled with real validation outcomes; targets must not be presented as achieved results.
Diligence packages
The data room should let reviewers move from claim to proof in each area.Evidence package
Evidence package
Connects rules to sources:
REF_SOURCES export, rule-to-source map, calibration-to-source map, evidence grade table, Medical Director review notes, source update policy, outcomes monitoring plan, and deprecated source list. Calibrations link to the engine’s evidence library, which includes 113 sources such as ADA, ACC/AHA, KDIGO, NAMS, AASLD, and genomic or pharmacogenomic references.Validation package
Validation package
Distinguishes design, targets, and completed results: golden test case list, test execution report, pass/fail summary, boot validator results, calibration validation cases, suppression and hardening tests, treatment flag tests, runtime trace tests, release gate checklist, and open safety issue log. Representative cases include a healthy baseline, severe hyperkalemia escalation, and TSH affected by high-dose biotin routing to clinical correlation.
Clinical governance package
Clinical governance package
Shows who controls medical logic and how: Medical Director role description, lifecycle policy, sign-off queue, release gate policy, patient-language review policy, treatment pathway governance, calibration review workflow, incident review policy, and deprecation/retirement log. The lifecycle is
DRAFT → READY_FOR_MD_REVIEW → MD_APPROVED → ACTIVE → DEPRECATED → RETIRED, under Medical Director authority.AI governance package
AI governance package
Proves agents are bounded: agent roster, agent scope policy, tool-use architecture, model-provider register, prompt and template controls, monitoring plan, human-review sampling policy, incident response plan, treatment-boundary policy, and calibration-boundary policy. Agents are transparent as agents, do not prescribe, do not override the engine or clinician, and route ambiguous cases to clinician review.
Privacy and data governance package
Privacy and data governance package
Proves the dataset can become valuable without becoming uncontrolled: data classification matrix, consent flow, sensitive input policy, access control matrix, audit log policy, de-identification protocol, retention policy, vendor data-processing register, incident response plan, and outcomes-learning governance.
Technical and IP package
Technical and IP package
Shows the engine is maintainable, ownable, and free of hidden third-party risk: architecture diagram, schema documentation, runtime documentation, deployment runbook, rollback runbook, dependency inventory, OSS license review, IP assignment reconciliation, access continuity plan, security architecture, and backup and recovery plan. OSS and third-party components must be inventoried with licenses and reconciled with the Engine IP Assignment, Exhibit A.
Red flags diligence should eliminate
Used internally as a preparation checklist:Data room structure
Organized so reviewers can move from high-level explanation to proof. The purpose is not to overwhelm reviewers — it is to make each claim inspectable.Diligence readiness scorecard
A simple scorecard makes readiness visible across architecture, clinical governance, evidence, validation, AI governance, treatment pathways, privacy, security, dependencies, release management, continuity, and the data moat. For each area, mark:- Green — complete and evidence available.
- Yellow — designed but needs documentation or confirmation.
- Red — missing, unclear, or not ready for external diligence.
Suggested diligence narrative
Consensus Center is building a physician-governed clinical interpretation engine for preventive precision health. The core engine is deterministic and evidence-linked. AI agents coordinate workflow but do not make clinical decisions. Each output is traceable to patient facts, rules, calibrations, lifecycle state, and evidence. Ambiguous or high-stakes results route to clinicians. Treatment pathways produce clinician-required advisory flags, not prescriptions or authorizations. The system is designed to improve as consented, de-identified outcomes refine the calibration library over time.