Where the platform actually uses vfairness
A live map of every public library symbol — that is, every function or class the
vfairness package exports (such as CorrelationReducer or
demographic_parity_difference) — against the surfaces that consume it. Use it
to audit coverage, find unused capabilities, and trace which library function powers each step.
Navigator step → Library module → SVG template
Predictive AI and Generative AI audits run different canonical pipelines. Toggle between them to see which library modules each step invokes and which SVG templates those modules render. Empty steps are kept visible — they mark gaps where the library could grow.
Edge thickness = number of symbols flowing on that link. Hover any line for the exact count.
One task, one round trip
Pulse is the non-expert entry to the platform. The browser sends a single
vfairness_pulse_run task; everything below happens inside one call to
vfairness.operations.pulse.run_pulse.
What Pulse runs, per input kind
The engine routes on the artefact it is given. A dataset with outcomes gets the full eight-stage battery; a prompts-and-outputs file, a live endpoint, an agent trace export and an image manifest each get their own probe lane. The stage names below are read from the orchestrator's own progress calls, so this is the stage list the engine really emits and the UI really shows — not a redrawing of it.
Pulse stage → library module → SVG template
The same reading as the Navigator flow, for the selected pathway. Edge thickness is the number of symbols on that link.
Pulse engine files
Every file in vfairness/operations/pulse/, with the number of distinct library symbols it imports.
How a stage is attributed
A stage's symbols are the library imports inside the source range that stage announces, plus the imports of the helpers that range calls, followed one hop deep. A helper shared by two stages therefore shows under both — that is a true statement about the code, not a double count of work.
Which module reaches the engine, and which does not
Every assessment module the platform ships, in block order. A module is
engine-backed when its mounted component dispatches at least one
vfairness_* task; the rest are specification and governance work that
deliberately runs no compute. Claiming library coverage for those would be false, so they
are shown greyed with the reason. Click an engine-backed module to filter the matrix.
Module → library module → SVG template
Only engine-backed modules appear. The path behind every edge is module → task type → registered handler → library import.
Dispatched from elsewhere
Task types the platform really dispatches, but not from a module in the list above — the Iceberg hub, Book Studio, the validity workbench, the trust-incident pipeline and shared hooks.
Registered, never dispatched
Handlers the consumer registers that no surface in src/ sends a task to.
Each is either UI work still to come or a handler to retire — the map does not guess which.
Every library symbol, every call site
Each row is a symbol — a public function or class exported by the
vfairness package. Filter by track, SVG template or status; sort any column.
| Symbol | Library module | Navigator step(s) | Tracks | SVG templates | Uses | Status |
|---|
All Navigator entry points
Every file or notebook that imports vfairness. Click any row to focus the matrix.
Templates produced by tracks
Of every Jinja SVG template the library ships, how many are produced by at least one Navigator track. Orphans are listed for review. One caveat: _shared_defs is an internal defs partial the chart templates include, not a chart, so no track can ever produce it; if it appears below it is a counting artifact, not a real orphan.
How this map stays honest
vfairness/scripts/build_usage_map.py. It walks every
Navigator-class entry point in this repo, joins every imported symbol against
vfairness-manifest.json (which carries the canonical capability → SVG template mapping),
and emits docs/site/data/usage_map.json.
vfairness/scripts/build_platform_usage_map.py into
docs/site/data/platform_usage_map.json. It reads the Pulse orchestrator's own progress
calls for the stage list, and walks the platform checkout for the rest of the chain:
module code → mounted component → dispatched vfairness_* task →
@registered consumer handler → library import. Nothing on those two views is
hand-curated; a module with no engine call is reported as having none.
Both maps are rebuilt by CI, not by hand. The
Library Usage Map workflow runs on every push to main that touches the
library source, the manifest or either builder, on a nightly schedule, and on demand. It
regenerates both JSON files, commits them only if they changed, and then deploys the site, so the
numbers you are reading were produced by the same run that shipped this page. A rebuild that finds
nothing new is discarded rather than committed, so the Generated date above is when this
data last changed, not when it was last checked: an older date means checked and
unchanged. The upstream input,
vfairness-manifest.json, is separately gated by
test_manifest_is_fresh in the test suite, so it cannot drift underneath either map.
One honest limit, and it is worth knowing before you quote a number off this page. The Navigator view is rebuilt on a schedule. The Pulse and Platform-modules views are not: they are a snapshot of the platform commit printed above, refreshed on demand. If that commit is behind the platform's current state, so are those two views, by exactly that much. The maintainer note below says why and what refreshes them.
Maintainer How each view gets refreshed, and which one needs a human
Library Usage Map workflow rebuilds it
on every push to main that touches the library source, the manifest or a
builder, and again on a nightly schedule. It commits only when the content actually
changed, then deploys the site from the same run. Nothing to do by hand.
build_platform_usage_map.py against a platform checkout
and commits the refreshed JSON. That commit deploys the site on its own.
main:
if they differ, those two views are behind by exactly that much.
This box is a label, not a lock. These pages are served as static files with no authentication, so everything above is readable by anyone; credentials and the internal wiring they configure are deliberately not described here.