Deterministic test data that kills flaky CI.
A test that passes or fails depending on the data it drew is not a test. It's a coin flip with a CI bill.
Where flakiness comes from
Randomised fixtures, shared mutable test accounts, and recorded data that drifts from the live schema all make CI nondeterministic. Teams respond by retrying, quarantining, or deleting the test — and lose the coverage.
One pinned company, every run
Save a company in Fictix and it gets a short ID like fix-7kq. Fictix stores it, so every run reads the same transactions, the same IDs, the same planted issues. Pin the ID in CI and the only thing that changes between runs is your code. (Regenerating from a seed gets close, but not identical — pin the ID, not the seed.)
Wired into the pipeline
CI talks to the REST API with your project key in X-API-Key: point tests at the company's API base URL, restore a checkpoint if tests write data, advance the simulation clock to the state a test needs, and fail the build when a test run's precision or recall drops below your thresholds. A packaged CLI is coming.
Questions
What makes the data deterministic?
Fictix stores the saved company, so everyone who reads it by ID gets exactly the same transactions and IDs. Test inputs don't vary between runs. Regenerating from the same seed gets close, but isn't identical.
How does it integrate with CI?
Over the REST API. Keep your project key as a CI secret and send it as X-API-Key; your pipeline reads the company, advances time, and checks a test run's precision and recall against your thresholds. A packaged CLI is coming.
Can different tests need different points in time?
Yes. Advance the simulation clock as far as a test needs, and save checkpoints so each test can restore the exact state it starts from.