Docs /How it fits together

The suite has two applications today: the core platform (previous page), and parable, which exists to answer one question the platform can’t answer about itself — how accurate is this, really?

Real patient scans have no independently-known correct answer to check the platform’s output against. There’s no ground truth to compare to — only the scan itself. parable solves that by generating synthetic limb data instead, where the correct answer is known by construction, because parable built it that way.

The loop

1. Generate — parable produces an anatomically plausible synthetic limb, statistically grounded in real population data (via a licensed open-source shape model — see Open source), with exact, known ground truth: origin, axis, shape.
2. Perturb — parable applies controlled, realistic damage to that clean synthetic case: pose variation, mesh decimation, scan discontinuities, surface noise — each independently tunable in severity, standing in for the kinds of imperfection a real clinical scan actually has.
3. Run the platform — the damaged case goes through the same processing the platform would run on a real patient scan, over a network API — parable never touches the platform’s own source code, only its inputs and outputs (see paralia_sdk).
4. Score — because the correct answer was known from step 1, parable can measure exactly how far the platform’s output deviated from truth, for that specific combination and severity of damage.
5. Review — results land in parable’s own viewer: per-case detail, aggregate accuracy curves against damage severity, and clustering to spot which kinds of defects the platform handles well versus poorly.

Why the split matters

This only works because parable and the platform are genuinely separate applications, talking over a network API rather than sharing code — parable can be open-sourced and handed to outside researchers without exposing anything about how the platform itself works internally. See Open source for exactly where that line sits.