Technology — CorpX Analytics
Home Modules Technology Validation Company

Technology

How a module gets made, and what it does.

How it’s made What it does Provenance What has been checked

Part one

How a module is made.

STAGE 01

Study

Read the field before writing anything.

Reads everything published on that organ and that modality. The output is a cited specification: what the accepted methods are, what they measure, and — stated explicitly — the conditions under which they fail.

A specification that does not list its own failure modes is not finished.

Worked example

The hepatic run flagged its own weakness before a line of code existed. A 13 mm lesion sits in the range where these features become unstable, so every shape and high-order texture measurement was tagged low-trust from the start.

STAGE 02

Specify

Fix the claim, then fix the plan.

Two things get written down before implementation. The scope boundary — what this module may and may not claim. And the build plan — every measurement with its units, range, edge cases and interpretation.

The boundary is a sentence everything downstream is measured against. For that same liver build it reads: descriptive evidence, never a diagnosis — the final call is the radiologist’s.

STAGE 03

Build

One measurement at a time, each traceable.

Segmentation, then measurement, then the readout surface. One measurement per commit, each with its assumptions, its tests and the citation it came from.

STAGE 04

Prove

Ground truth it generates itself.

Generates synthetic scans with the anatomy and tissue properties specified, so the correct answer is known exactly. The module has to recover it.

This is what removes the dependency on labelled patient data — and it is why a module can be finished before a dataset exists. It was specified, built and verified with no liver scans in hand.

STAGE 05

Guard

The claim cannot creep.

Continuous integration re-reads the interface, the API, the documentation and this website, and fails the build if the product has drifted past the boundary set in stage 02.

Claim language decays silently as a product grows and more people edit it. Here it is a test that can go red.

Part two

Once it exists, here is what it runs.

01

Ingest

DICOM straight off the scanner, or NIfTI if that is what you already hold. De-identification runs first and has to pass before anything else does. No manual annotation, no linked worksheets.

02

Segment

Deep-learning segmentation labels the anatomy directly in the volume — a per-voxel map of what is where.

03

Quantify

Radiomic and morphometric features extracted per anatomical region: shape, texture, intensity, geometry, fat. In HeartX that includes the AHA-17 myocardial model. Around a hundred descriptive values, each one tied to a specific place in the body.

04

Contextualise

Every readout placed against a cohort baseline as a percentile. A number without a reference distribution is not yet an answer.

05

Render

Results drawn on the actual volume in an interactive 3D viewer. Not a report about the scan — the scan itself, with the measurements on it.

No generative upscaling anywhere in it. When the thing being measured is a volume, invented detail becomes measurement error.

Every value is computed directly from the patient’s volume, never read off a summary or joined from a metadata table.

It traces back to the voxels it came from.

Provenance

Every number carries its record.

PINNED

Each run records the pipeline version, model weights and library versions that produced it.

DOCUMENTED

Each measurement carries the extraction method and parameters behind it.

EXPORTABLE

Results leave as structured files with the full provenance record attached.

Where the human signs

It runs itself. It does not sign for itself.

Scope is authorised, not assumed — The stage 02 boundary is signed before implementation begins. Widening it is a decision with a date, a rationale and a signatory, recorded in a log.

Clinical meaning stays clinical — The loop quantifies, measures and cites. It does not adjudicate. Interpretation belongs to a qualified clinician, and the software is built so it cannot quietly assume that role.

Release is a gate, not a merge — Green against phantoms is necessary and not sufficient. Nothing reaches a user without a human review of what changed, what it claims, and whether the claim is still inside the boundary.

What has been checked

What has been checked, and how.

Standards

Feature extraction is IBSI-1.0 compliant, with preprocessing pinned in a version-controlled config. Segmentation runs on published, externally validated models rather than in-house weights.

Synthetic ground truth

Every module is required to recover the correct answer from volumes generated with the anatomy and tissue properties specified. This proves the measurement chain computes what it claims to compute. It is not a claim about clinical meaning — that requires real data, and is reported separately below.

A worked case

A complete de-identified prostate mpMRI study, quantified end to end: a 14.5 mm lesion, an ADC ratio of 0.51 against normal gland, every value carrying the method and parameters that produced it. Descriptive evidence at single-case scale, published exactly as the module produced it.

What is not claimed

No sensitivity, specificity or diagnostic accuracy. Those require a cohort, and the cohort work is what comes next.

Nothing moves up a maturity state without data behind it.

Why one engine covers any anatomy