The Compliance Lab

Three complete compliance frameworks, built over one synthetic bank branch: fraud surveillance, credit risk and IFRS 9, supervisory returns. Nine flows, 102 nodes. One pair of database tables, one set of node kinds, and no schema change between them — the three regimes differ only in what they say.

That exercise is the reason this post exists. It was meant to test a single claim, and the claim is the whole thing the Compliance Lab is for.

Why a lab and not just a product

Venapce was the first product where all of the business logic lives in FloMorphic workflows and the product itself is only the view. It worked well enough that the interesting question stopped being "can a whole product be a graph" and became "which domain needs that most."

Regulatory work needs it most, for a reason anyone who has sat in a bank's compliance function will recognise. The person who understands a control is never the person who can deploy one. A regulator amends a reporting requirement, or the internal policy committee tightens a threshold, and the path from we know what has to change to the system does it runs through a backlog, a sprint, a release window and a test cycle. Six weeks later the control is live and the regulator has moved again. Everyone involved knows this is absurd and nobody can individually fix it, because the control lives in code and code is engineering's to change.

So the Compliance Lab is the regulatory segment of Inflowenger: regulated processes, supervisory reporting, risk and fraud surveillance, and the evidence trail all three produce. Its main project is SurfStat.

SurfStat, in one shape

SurfStat is forked from Venapce and is the same computation with different nouns. Both face many sources that don't agree, none authoritative and none sharing a schema, and in both the valuable act is turning raw signal into a judged, evidenced, deduplicated record a person can act on and defend.

What it is, concretely: one fixed machine that an organization bends to its own structure by authoring rather than by shipping.

• Two tables. records is everything that came in. cases is what somebody has to do something about. Venapce's three-level stage → findings → issues became intake → exceptions → cases and then lost its middle level, because "exception" turned out to be one organization's word for one organization's intermediate step, and hard-coding it asserted that every firm draws its pipeline the same way. A firm that wants that level now defines a term in its own vocabulary, stamps it on a record and names a saved view over it. A firm that doesn't never sees it.
• A graph engine. A regulated process is a graph the compliance expert draws. Each validation stage is a node on it.
• An execution record. Every run leaves one, and that record is the evidence.

The schema never moves. The vocabulary, the classifications, the flows, the views and the pages are all rows, so fitting the system to an organization costs a row rather than a release. That's the claim the three frameworks were built to attack.

What the three frameworks actually showed

The data isn't noise with a few bad rows in it. The branch is a SQL Server install with 180 days of synthetic banking data: 40 borrowers, 93 facilities, 319 covenants, 17,163 transactions. It carries 38 planted findings with an answer key, and it's deliberately built so that lazy rules score badly. The fraud rate is about 1.0%, so flagging everything is useless. Six legitimate five-day foreign trips produce 54 card-present purchases, so a naive "foreign card-present" rule flags all 54 and learns nothing. Investment-grade borrowers sit at 0.8–2.0× leverage with DSCR of 5 to 15, so there's a real population to not flag. Two revolvers are in arrears with no payment rows at all, so a rule driven by payment history misses them silently.

Against that, three things came out of the exercise that I didn't fully expect.

The sweep flows are all the same eleven-node graph. Read the branch, turn rows into findings, write a record per finding, digest the sweep, ask whether it warrants cases, open a case per high-severity finding, mark the record promoted, report the judgement back to the branch. A new rule is a query and a scoring function. It isn't a new topology, and that re-use is the part worth pointing at.

The loop is a scope, not a canvas structure. $.hits[*] on the record-writer runs it once per finding, which is a queue inside one node. The promotion policy is $.hits[?(@.severity=='high')], which is a JSONPath filter you can read off the graph without opening a node. The rule that decides record-becomes-case is visible at a glance, which matters more in compliance than it does anywhere else, because that rule is exactly what an auditor will ask about.

Terminology is the only thing that differs structurally. Not one of the nine flows adds a column. A framework's vocabulary is stamps in tags, written <axis>.<value>: risk.fraud and rule.card-testing for the fraud batch, risk.credit and rule.covenant-breach for credit, return.kri and rule.sector-limit for returns. Three regimes, three vocabularies, one schema.

And one mistake, because it's the most useful thing in the exercise. Every finding carries source plus external_id as an idempotency key, so a sweep can be re-run without duplicating findings. The impossible-travel sweep first keyed on the arrival transaction, which collides: an A→B→C journey yields both B→C and A→C on the same arrival. The unique index caught it. Its key is the pair, not the arrival. I'd rather have a constraint surface a modelling error than discover it later as duplicate rows in front of a regulator.

The supervisory-returns batch is worth one note of its own: no LLM node, no writeback. A return is arithmetic against declared limits, reported upward. Nothing there needs prose and nothing goes back to the branch — which is a reasonable sanity check on a platform built around AI nodes.

Where this sits against Vanta and Drata

The honest version of this comparison isn't that SurfStat is better at their game.

Read that table as a competitive scorecard and SurfStat loses most rows. Framework library, auditor network, integration count, polish: those are years of accumulated product and relationships, and a fork of a security product doesn't have them. (The integration row in particular is one I've argued is a vanity metric, and I'm not going to start counting now that it's inconvenient.)

The two rows that matter are the first two, and they aren't feature wins. A bank under a data-residency regime, a ministry, a central bank's supervised entity, a healthcare system in a jurisdiction that forbids it — these organizations cannot legally ship control evidence to a US-hosted multi-tenant SaaS. For that buyer Vanta and Drata aren't worse options. They're disqualified at procurement, before anyone looks at a feature list. That's a different market rather than a better product, and it's the strongest card the Lab holds.

What makes the wedge real rather than rhetorical is narrower than the pitch: a single container, self-hosted, no phone-home, and collection by plugin in each branch reporting to a core the data is required to remain in. Vanta and Drata both do multi-entity too. They do it in their cloud.

The ISO package, and why it will refuse to be fully automated

The planned proof of the authoring claim is an ISO 27001 package. Drata markets roughly 85–90% automated evidence collection, and one review of it contains the caveat that the whole category lives with: the readiness score "can signal that we are fully prepared when certain controls still require manual evidence."

I want to be exact about this, because it's tempting to answer that with a bigger number. ISO 27001:2022 Annex A is 93 controls and a large share of them are organizational, people and physical. Risk assessment performed. Management review held. Policies approved. Training completed. Supplier agreements signed. No plugin can check those by inspection; they need a document, a signature, an attestation from a named human. "Fully automated ISO" inherits exactly the credibility problem that caveat describes — a green score that's partly hollow.

So the package is specified the other way around. It automates the technical subset — access control, logging, crypto, backup, vulnerability and patch state, endpoint configuration — through branch plugins that produce an execution record per check, which is a run that happened rather than a screenshot someone took. For the organizational subset it generates the obligation and the attestation task, with a due date and a named owner, so the un-automatable controls are tracked as governed records instead of being quietly marked done.

That's a smaller claim than Drata's and a more defensible one: nothing is ever green on an attestation it didn't actually receive. Being honest about the manual subset is the feature here, and a compliance officer who has ever been surprised during an audit will understand immediately why that's worth more than a higher percentage.

The AI, and the one way it could void the whole thing

"AI suggests remediation, maps findings to controls, drafts the obligation" is not distinctive. Vanta and Drata ship that already.

What's distinctive is AI reasoning over evidence that is never allowed to leave the building, and that's an architecture decision rather than a prompt. For a sovereign buyer, sending control evidence to a cloud model API is the same disqualification as the SaaS was. If the AI calls out to a hosted model, it reopens the exact hole the appliance was built to close, and no amount of careful prompting repairs that.

Which is why the framework demo runs its models locally — Ollama with qwen3.8 for prose and nimble for decisions, nothing external. In those flows the model gates rather than reasons: findings are already written to the records table by the time the decision node is asked, so an unavailable decider costs the promotion step, not the data, and the exception branch is drawn on the canvas rather than assumed. It's the discipline the claims walkthrough calls "money is not a model's job", and the one behind glass-box agents: scores computed in code, routes chosen by rules, the model's discretion bounded to the judgment it's actually good at.

What's built, what isn't

The parts that work and have been exercised: the API builds and its tests pass, the schema applies, the boot sequence seeds roles and bootstraps the first administrator, sign-in and the full access-control path were run end to end against Postgres, and the panel typechecks and builds with right-to-left output confirmed. Access control is the piece Venapce never had — one permission catalog declared in Go and served to the UI so there's nothing to drift, roles plus per-user overrides where a deny beats every role, five dual-control actions that record a pending approval instead of executing, entity-scoped assignments, and sessions as rows so suspending a user ends their access on the next request.

The pages the panel design calls for are not built, and they're greyed out in the menu so the shape is at least legible: Obligations, Controls, Evidence, Calendar and deadlines, Submissions, Retention. Obligations is the spine everything else hangs from and has to come first — the ISO package is content that attaches each check to an obligation row, so it can't precede it. I'd be overstating things badly if I described that package as anything other than specified.

Three named limits are the real gate, though, and they bite the moment a branch plugin produces evidence a regulator will inspect:

• Tamper-proof retention. Without it, on-prem evidence is worth less than Drata's cloud-signed evidence, and the entire argument inverts.
• Exactly-once on anything that leaves the building. A branch plugin reporting a check must not double-count or drop one. The idempotency key work in the demo is the beginning of this, not the end of it.
• A decision table an external auditor already recognises. If the output doesn't render as something an ISO or supervisory auditor accepts without being taught, the proof stays internal and convinces nobody who matters.

There's also an open policy question I don't have a good answer to yet: what happens to a run that's already parked on a human when the control it was executing gets amended. Resume under the old control, restart under the new one, or park it harder and escalate. Each is defensible and each is wrong in some case.

Solve those and the sentence worth saying is true: Vanta and Drata can't be deployed where this buyer must keep their evidence, SurfStat can, it proves controls with execution records instead of attestations, it's honest about the manual subset, and its AI reasons over that evidence without any of it leaving the building. Until they're solved, it's a substrate with three frameworks running on it and a good argument attached.

If you work in a regulated function and the six-week path from we know what changed to the system does it is familiar, I'd like to hear where you think this breaks.

The Compliance Lab · the regulatory segment of Inflowenger. SurfStat is in development; scope and dates will shift. Comparison figures for Vanta and Drata are from their own current materials — Drata's AI page and a published Drata compliance guide — and will age.