A verified worked example.
Pair approved synthetic input with actual output checked against the reference engine. Identify the versions and run date, and label the demonstration as saved.
Development uses synthetic cases, educational material, regression tests, and external benchmark comparisons. Independent validation remains a separate goal.
Research and educational prototype. Not validated for clinical use.
Status reviewed October 3, 2026 · Based on the project handoff; engine tests were not rerun for this website update.

| Capability | Status | What that means |
|---|---|---|
| Research reference engine | Implemented | A working reference engine is documented. It remains a research prototype, with continuing development. |
| Development evaluation | Ongoing | Regression tests and external benchmark comparisons inform development. They do not establish clinical readiness. |
| Public project explanation | Available | Overview, approach, and development pages describe the work and its boundaries. |
| Verified worked example | Planned | Publish approved synthetic inputs with their actual saved output, engine/knowledge-base/policy versions, and run date. |
| Live structured-input demo | Planned | Connect an explicit execution service and verify website outputs against direct runs of the same engine. |
| Reviewed photo input | Planned | Implement extraction, editable observations, required human review, and verified data handling before enabling uploads. |
Disagreements are examined to distinguish software defects, missing information, differences in interpretation policy, and limits in the available reference answer.
Agreement with a source label is one endpoint. It is not, on its own, a measure of clinical safety or utility. Demonstrating value requires evidence beyond a passing test suite or a benchmark score.
Synthetic cases and regression tests help check whether implemented behavior matches defined expectations and whether changes break previously tested behavior. Benchmark comparisons expose disagreements worth examining. These activities support development; they are not substitutes for independent clinical validation.
Any published result should carry its cohort, denominator, engine version, endpoint, and reference-standard limitations. Method scope, evidence thresholds, source-label sufficiency, historical context, and blinding all affect interpretation. Development test counts should not be presented as general diagnostic accuracy.
The initial scope is routine red-cell alloantibody interpretation. It is not a comprehensive solution to every reference-laboratory problem. Incomplete observations, unresolved findings, method-dependent evidence, and the need for expert review must remain visible. Planned output semantics and workflows should not be mistaken for implemented features.
Pair approved synthetic input with actual output checked against the reference engine. Identify the versions and run date, and label the demonstration as saved.
Validate structured inputs, retain unknown values, and compare website results with direct engine runs before describing the integration as working.
Show the source image alongside editable observations. Require confirmation before inference, with clear and verified data-handling behavior.
No public engine demonstration or upload function is currently enabled. The conceptual output on the overview page illustrates the design without presenting fabricated case results.
A physician-led research project. This site makes no claim of institutional sponsorship, regulatory clearance, clinical readiness, or demonstrated patient-outcome improvement.
Red-cell illustrations by Sarbasst Braian, via Wikimedia Commons: BloodCellState 001 and BloodCellState 159. Released under CC0 1.0. Illustrations, not microscopy or case evidence.