figurant — synthetic HR and identity data for testing identity governance

A reproducible generator of organisations that look like real ones: an org tree, people with Dutch names and plausible ages, employments and registrations over a history, accounts on several systems, and an answer key so a consuming system can be scored rather than eyeballed.

It is an exporter, not a connector. It writes files that resemble what a source system holds; it never reads from or writes into a live directory or HR system, and it has no code path that can be pointed at real data. No organisation it produces is recognisable as a real one, and no national identifier is produced in any mode.

pip install -e .
figurant --scenario examples/acme-small.toml --out ./set

That is a 400-person installer with its answer key, from a declaration you can read in one screen. Three ship to start from: examples/acme.toml (the full one), examples/acme-small.toml (the same organisation, smaller and faster) and examples/loop.toml (four weeks of one organisation, for the simulation loop).

Nothing is on by default. A set is clean until a declaration asks for a fault, a malformed value or a policy breach — so a clean set is the control that proves a consumer is not reporting problems that are not there.

The sixty-second version

# 1. Generate, and serve it where a consuming system can reach it
figurant --simulation examples/loop.toml --run ./run --reference 2026-10-12 --step 0
(cd run/current && python3 -m http.server 8080)   # GET /json/index.json

# 2. Import it. Then say next, and import the same URL again
figurant --simulation examples/loop.toml --run ./run --reference 2026-10-12 --next

# 3. Reconcile backwards instead of reloading
figurant --simulation examples/loop.toml --run ./run --reference 2026-10-12 --revert

--reference is the anchor every step counts back from, and it is required rather than defaulted: nothing in the package reads the clock, so running the loop in a later week is --reference "$(date -I)" at the call site and the whole loop shifts with it — the same people, the same units, every event date moved.

run/current/ is the same path at every step, so a consuming system is pointed at it once and never reconfigured, and run/feed/ holds what changed since the last step — in both directions, so a revert is a reconciliation rather than a reload. Next week the same declaration, anchored seven days later, replays the same situations against the same organisation. See the loop.

What you get

Sixteen tables — the organisation tree, people, employments over a history, teams, and the access layer of systems, accounts, resources and assignments — written as CSV, JSON pages, NDJSON, Parquet or a WireMock stub. Beside them, in set/key/, a separate answer key: every planted fault with the value the data held before, every malformed value and what it replaced, which personnel numbers belong to one human, and the right answer for every copy of every attribute rather than only the wrong ones. Full tables and formats in the output.

Where to go

The walkthrough is the place to start if you have not seen a set before: it goes through one, defect by defect, and says what each is a test of.

What it is built against

docs/requirements.md holds every requirement, each with how to verify it and — where one was settled by measurement — the number that settled it. tests/TRACEABILITY.md records which requirement each test covers, and tools/check_requirements.py fails when one is covered by nothing.

The case mapping records which set carries which scorable case, because the cases live across sets rather than within one: a clean set is the control, so the faults are in another.

Three more records exist because a claim nobody measured is a claim: platforms (the same set on Windows and Linux, hash for hash), importing (PostgreSQL accepting 46,290 rows with every foreign key in place) and the mutation score (what the suite detects when faults are injected into the generator on purpose).