Know what every release exposes and breaks, before it ships.
0 exposedAll data arriving
Mapping the system
From vendor feeds to customer surfaces. Hover, tap or tab to any element to see its evidence.
Companies whose product is data ship changes faster than anyone can review them, and two things go wrong: data gets exposed to people who shouldn't see it, and data stops arriving or arrives wrong.
Bokkale starts with releases. It checks each one for both, follows every problem to the customers it hits, finds the smallest fix and re-tests it.
The bigger idea: every data-heavy company should have a live, proven picture of how all its systems and data connect, so any change, a release, a new vendor, a migration, is checked before it reaches a customer.
Agents will build that picture by reading a company's code, configs and data flows, and a deterministic engine checks everything they find, so Bokkale only ever reports what it can prove.
Financial data first, then every company whose product is data.
The bigger idea
Scroll to run the steps on the demo map.
Agents explore: reading a company's code, configs and data flows.
Engine proves: a deterministic engine checks everything they find.
Checks each release for both: exposed, and stops arriving or arrives wrong.
Follows every problem to the customers it hits.
Finds the smallest fix and re-tests it.
Note 1
Release check, working end to end on a demo platform I built. One release, 11 changes, two failures staged by me. It caught premium estimate history answering without login, and November options lost at ingest. Check: about 2 seconds. Smallest fix: one change undone, one access check put back. Re-check: 0 open issues, 10 of 11 changes kept.
relcheck · release check for Larkfield
1 EXPOSURE ✕ estimateHistory now answers anyone, no account
premium data · before: login required · after: answered
✓ dividends is new and public: intended, not flagged
2 DATA FLOW ✕ expiry 2026-11-20 no longer reaches option_quotes
vendor 96 → table 0 (was 96) → API 0 (was 96)
3 FIX → put back the access check estimateHistory had before (1 line)
→ undo the release's change to third_friday() (3 lines)
✕ rejected: undo estimate_history(), locked out paying customers
re-check 0 open issues · 10 of 11 release changes kept
Note 2
First engine, tested on 20 public apps. Pre-registered; labels written by an AI before any tool ran; source code only, no live app contacted. By the labels, 17 of 20 had a path from an outsider to user data. It raised too many false alarms, so a re-test on a fresh set is next.
Note 3
Where it started. In October 2026 I found two failures like these at real companies, by hand: a listed Nordic research house whose API appeared to give away its paid research without login, and a market data vendor whose API was missing whole months of option data because of a bug between its own databases.
| When | What |
|---|---|
| NEXT | Agents that set the check up on any company's codebase; the check itself stays deterministic. |
| JAN 2027 | A first design partner running it on their own releases. |
| AFTER FIXES | Re-test the engine on a fresh set once the false alarms are fixed. |