I modeled EU AI Act compliance as a state machine, not a checkbox list

Every EU AI Act control I track moves through the same five states. None of them is "done": satisfied, evidence_missing, evidence_stale, pending_review, waived.

The third one is the state most compliance tooling skips. A control isn't just satisfied or not. The evidence behind it can expire.

Opencomplai's control register attaches a freshness TTL to every piece of evidence backing a control. So a bias-testing result from eight months ago, against a model you have since retrained three times, doesn't silently keep counting as satisfied. It ages into evidence_stale and shows up in opencomplai controls status as something that needs a fresh run, not something to rediscover at next year's audit.

It's cache invalidation, applied to legal evidence instead of application data. The hard part was never storing the value. It was knowing when the value you stored stopped being true.

Each control maps to one specific article of the Act, has an owner, and moves through those five states on every CI run. "Are we still compliant" becomes a query against current state, not an annual archaeology project through old spreadsheets.

waived exists on purpose. Sometimes a control genuinely doesn't apply to a system, and pretending otherwise is its own kind of lying.

The full lifecycle, what triggers each transition and what "stale" means for different evidence types, is documented next to the code, not in a whitepaper: github.com/Opencomplai/opencomplai, see the Controls Lifecycle doc and services/evidence-vault.