SurfStat
The intelligence & orchestration fabric for data governance and enterprise
Most organizations already hold what they need to answer their own hardest questions, and almost none of them can reach it. The data sits in systems that were never meant to be read together, with no shared vocabulary over them and no shared account of who may see what. SurfStat is the layer that makes that estate reachable and then governs it. What a firm builds once that exists is its own business.
It's the project behind the Compliance Lab, and it's forked from Venapce — the same computation under governance nouns. Its own definition is deliberately not a category: an authoring substrate for governed data. One fixed machine an organization bends to its own structure by authoring rather than by shipping.
A fabric, and a flow drawn across it
The part we can build, and the part we set out to solve, is interconnection. A department, a legal entity, a branch office, a vendor, a warehouse — each of them already works, and each of them is an island. What's missing between them isn't a better system anywhere. It's the fabric.
Which is why the comparison that fits is a network, and specifically the unglamorous half of one. Cable, patch panels, switches, routers: none of it makes any single machine better, and all of it exists so that anything can reach anything. Before it's in, you have a building full of computers. After it's in, you have a network, and nothing about the computers changed.
SurfStat lays that fabric over an organization's resources rather than its machines. Nothing is migrated and nothing is replaced. The branch's SQL Server stays where it is, the vendor keeps its own estate, the questionnaire stays a questionnaire — and each one becomes addressable, under one protocol, from one place.
Every resource addressable from one place, without being moved, rewritten or replaced.
Then the half that pays for the first. Once every resource is addressable, a process is a flow drawn across them, and each resource takes part in that flow as a node. One graph reaches the branch, the warehouse, the vendor and the document store in a single run, in the order the work actually needs them, waiting where it has to wait and asking a person where only a person will do. The flow isn't a description of the process. It is the process.
One flow, one run. Each node is a resource the fabric made reachable or a decision taken over what it returned, and every step of it leaves an execution record behind.
What those flows produce is whatever the organization needs done across its own estate, and it's a short list of verbs rather than a product catalogue.
Detection
A rule sweeping resources that have never been compared before, because until the fabric existed there was nowhere to compare them. Fraud, breach, a limit crossed, a control that didn't hold.
Ontology
Six systems with six names for the same customer, the same exposure, the same asset. A flow reconciles them into terms the organization actually uses, and the terms are rows, so they move when the firm does.
Clean data
Validation, deduplication and correction happening on the way through rather than as a quarterly project — and the correction itself is on the record, so the cleaned figure can still be traced to what arrived.
Aggregation
Figures from a thousand branches becoming one number, with every row that contributed to it still attached. The same flow runs inside a single branch computing what it sends upward.
Rules
The threshold, the condition, the policy — written down once by whoever actually owns it, and living on the graph instead of inside somebody's code. A rule you can read off the canvas is a rule the person responsible for it can check, argue with and change.
KPIs and indices
Any index the organization runs on: a KPI, a risk score, a KRI, a readiness or exposure index. A flow computes it across the fabric and lands it on the row as score, so one number can be thresholded, sorted, charted and alerted on like everything else.
AI decision and recommendation
An AI node sitting inside the flow rather than beside it, reading what the other nodes gathered and either recommending or deciding, bounded by the graph drawn around it. Its reasoning lands in the execution record with everything else, and the evidence it read never leaves the building.
None of that list is novel and it isn't trying to be. It's the same set of things a team ends up with after coding a data platform by hand: the ingestion, the rule engine, the metric layer, the model calls, the audit trail. What differs is where each one comes from. Here they are authored over the fabric by whoever owns the subject, instead of being specified, queued, built, deployed and then owned by engineering for the rest of their life.
Those are capabilities rather than products, and which product an organization ends up with depends entirely on what it points them at. Point them at a supervisor's requirements and you arrive at regtech. Point them at an ISO 27001 programme and you arrive at an ISMS. Point them at nothing in particular and you still have one register of what the organization knows. The fabric and the flows don't change between those.
A thousand handles, one protocol
Fixed at the core, not at the edge. The same install is an orchestrator holding handles into places that are heterogeneous, distributed, and mostly not in this building: a branch's SQL Server, a database nobody documented, a questionnaire a counterparty fills in, a folder where somebody drops an Excel file every Thursday, a vendor's own estate, a portal whose only interface is a web UI someone clicks through.
What keeps that from becoming a thousand integrations is that every handle is the same kind of thing. Each is a plugin speaking inflowv1, the protocol the whole Inflowenger platform is extended through, and the plugin runs where its data lives rather than here. It holds no logic and stores no secret. A source nobody has written yet is a plugin written once against a published SDK, and it then runs on any host that speaks the protocol.
Each handle becomes a channel: one row, with a name, a kind that is just vocabulary, and a credential handed outward. SurfStat registers the extension, FloMorphic mints its identity, and the credential never appears on a canvas. That row is the outlet in the wall — and adding one costs a row, not a release.
The protocol in the middle is what lets the bottom stay fixed while the top keeps changing.
Reachable is not yet governed
A fabric on its own gets you reach. Something still has to decide what each piece of it is, who may look at it, which entity and which reporting period it belongs to, and what happened to it the last time anything ran. That's the governed part, and it's where most of the machine lives.
Two tables
records is everything that came in. cases is what somebody has to do something about. Venapce's three levels lost their middle one, because "exception" turned out to be one firm's word for one firm's step. A firm that wants that level defines a term and names a saved view; a firm that doesn't never sees it.
A graph, not code
The process is a graph somebody drew rather than code somebody deployed, and every stage of it is a node on that graph. The rule that decides record-becomes-case is readable off the canvas without opening a node, which matters more here than anywhere else because that rule is what an auditor asks about.
An execution record
Every run leaves one, and that record is the evidence. Not a screenshot, not an attestation that a thing was done — the trace of the run that did it, with machine judgement and human comment in the same stream.
Terminology as rows
entity, period and batch are base columns; everything particular to a firm or a regime is a term stamped into tags. An axis declares how it's entered — a list, an ordered progress, a scale, a range, a number, a date — and the value still lands as a term id either way.
Access control with a deny rule
One permission catalog declared in Go and served to the panel, so there's nothing to drift. Roles plus per-user overrides where a deny beats every role. Five dual-control actions record a pending approval instead of executing. Role assignments scope to a legal entity, and sessions are rows, so suspending someone ends their access on the next request.
Obligations, authored per organization
The register everything else points back at: the instrument an obligation derives from, which entities it binds, who owns it, how often it must be tested. Every organization's set is its own. Nothing can write it from outside, and nothing can write it before the estate is reachable, so it's authored over the fabric rather than shipped as somebody else's content.
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 below were built to attack.
One demo scenario, three frameworks, one schema
The claim that an organization can author its way to a control is worth exactly as much as the attempt to break it, so we built a scenario to attempt it, at the hardest setting available. Regulated finance asks more of a schema than anything else the substrate is likely to carry, and if the schema holds there it holds in the easier cases by default. Three compliance frameworks were authored over one synthetic bank branch: fraud surveillance, credit risk and IFRS 9, and supervisory returns. The branch is a SQL Server install with 180 days of synthetic banking data — 40 borrowers, 93 facilities, 319 covenants, 17,163 transactions — carrying 38 planted findings with an answer key, and deliberately built so lazy rules score badly.
Those three are a scenario, not a scope. They are not what SurfStat is for and they are not a list of the things being worked on: anything could stand where they stand — a hospital's patient-safety reporting, a ministry's procurement checks, a manufacturer's quality holds, a group that simply wants one register of what it knows. Any organization, with any mission. What the scenario tests is whether the machine underneath stays still while the work on top changes, and that is the only thing the numbers below report.
Three things came out of it that weren't fully expected. All six sweep flows turned out to be 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. A new rule is a query and a scoring function, not a new topology. The loop is a scope rather than a canvas structure, so the promotion policy reads as one JSONPath filter you can see without opening a node. And terminology is the only thing that differs: not one of the nine flows adds a column, because a framework's vocabulary is stamps in tags.
The useful part was a mistake. The impossible-travel sweep first keyed its idempotency 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 find it later as duplicate rows in front of a regulator.
A high-level flow reaches the whole organization
This is the payoff of building in that order, and it's the part that's hard to sell before the fabric exists. Once every system is a channel and every record carries its entity, its period and its vocabulary, a flow is no longer limited to the one database somebody thought to wire it to. It crosses the whole estate, because the whole estate was made reachable first.
A compliance team sketching "every counterparty exposure above this threshold, across all branches, in this quarter, with the covenant status attached" is drawing one graph. Underneath it the handles fan out into a dozen systems that have never agreed with each other, and the answer comes back as records and cases that look like everything else in the register. The organization's own intelligence turns out to be accessible at the level people actually think at, rather than at the level the data happens to be stored at.
Which is why the same install lands in places that look nothing alike, at scales that have nothing in common. A firm with a supervisor to answer to arrives at regtech — supervisory returns, control testing, an evidence trail somebody external will read. A firm running an ISO 27001 programme arrives at its ISMS instead. A group with neither gets the thing underneath both: one register of what it knows, with a decision trail over it, which is as close as most organizations get to a brain they can query. Regtech is a destination some organizations reach from here. It isn't the road.
What generalised is governed data with a decision trail over it. Nothing about this machine makes it good at anything that isn't that.
Third-party risk is the clearest example of the same idea. Nobody builds a TPRM module here. You add a channel of kind TPRM, install a framework whose own rules work that channel's data, and the outcome is a record or a case like everything else in the system. The AI nodes in those flows reason over evidence that never leaves the building, which is the one architectural line that can't be crossed without voiding the whole argument.
One image, one Postgres, inside the building
SurfStat ships as a single container image on a permanent base image, supervised by supervisord behind one origin. It runs as a FloMorphic plugin and reaches the instance over the shared network, authenticated with FloMorphic's own secret — the installer captures it from whatever instance it finds, or installs one.
Go backend
The service the panel talks to and the bridge to FloMorphic. It orchestrates flows and serves what they produced; the compliance logic isn't in it.
Vue web app
Records, cases, the activity log, packages, access. Three languages — English, Persian and Arabic — with direction following the language, so two of them are right-to-left.
Dashboard builder
A full chart and dashboard builder over the pipeline tables. Superset, run synchronously: no Redis, no Celery, its metadata in the same Postgres.
nginx
Ties the web app, the API and the dashboards together behind a single origin.
Nothing is migrated into SurfStat. A control reaches each system where it already sits and answers in place. Three things get set up once — connections, where credentials live so no secret is ever drawn on a diagram; entities, your legal entities and branches, which is also where the isolation boundary sits; and obligations, the register everything else hangs from. The first two are configuration. The third is authoring: an obligation register is particular to your instruments, your entities and your owners, which is why it's written over the fabric rather than shipped with the product.
Controls then arrive as packages — a versioned, installable pack per obligation or control family, with this firm's own thresholds, jurisdictions and materiality filled in at install time. A readiness check runs first and names anything missing; a dry run plans the change and reports every problem before anything lands. When the regulator amends the text you take the new version, and binding-by-key replaces the right control even if someone renamed it on the canvas a year ago. That is how a framework changes without an engineering cycle — a package version, not a release.
curl -fsSL https://raw.githubusercontent.com/SurfStatLab/getting-started/main/install.sh | bash
:8080, Superset's own UI on :8090. On a fresh database it creates one administrator and prints a generated password to the log, once — a first-login credential, not a password, and it stops working the moment you change it. A different market, not a better feature set
Point this substrate at a compliance programme and it lands in a market that already has products in it, so that comparison is worth making plainly rather than leaving implied. It's one of the things a fabric and the flows over it can carry, not the thing they're for.
Vanta and Drata are both multi-tenant cloud SaaS and neither offers a self-hosted deployment. They're good at what they do and SurfStat is not trying to out-feature them. The claim is narrower and, I think, harder to argue with: a bank, a ministry or a healthcare system under a data-sovereignty regime cannot legally ship control evidence to a US-hosted service. For that buyer those products aren't worse options, they're disqualified at procurement. That's a different market rather than a feature win.
| Dimension | Vanta & Drata | SurfStat |
|---|---|---|
| Deployment | Multi-tenant cloud SaaS | On-prem single-container appliance |
| Where evidence lives | Their cloud | Inside the building, no phone-home |
| Evidence model | Automated API pulls plus attestation | The execution record of a run |
| Framework content | Large pre-built libraries, auditor networks | You author it — a flow and a vocabulary |
| Collection across branches | Cloud connectors in their cloud | A plugin per branch, reporting to a core the data must stay in |
| AI | Cloud-hosted over cloud-held evidence | Reasoning over evidence that never leaves the building |
The ISO 27001 package takes the same stance, and it refuses the obvious marketing line. Annex A is 93 controls and a large share of them are organizational, people and physical: a risk assessment performed, a management review held, a policy approved, training completed. No plugin can check those by inspection. So the package automates the technical subset with an execution record per check, and for the rest it generates the obligation and the attestation task with its due date and owner. Nothing is ever green on an attestation it did not actually receive. Being honest about the manual subset is the feature, not a gap in it.
What ships, and what gets authored
There is a version, and it installs. v0.1.3 is published for amd64 and arm64, and the one command above puts it on a machine: the panel comes up, the boot sequence seeds the roles and bootstraps the first administrator, and from there you have records, cases, the activity log, packages, the access screen and the dashboard builder — in three languages, two of them right-to-left. The access model is the one described above rather than a placeholder for it: roles, per-user grants and denials, the four-eyes points, entity scoping, revocation on the next request. Sign-in and the full access-control path have run end to end against Postgres, the schema applies, the API's tests pass, and the panel builds with right-to-left output confirmed.
Everything an organization needs governed data for comes next, and it comes as flow design rather than as product features: the obligation register, the controls, the evidence a given regime expects, the calendar a given supervisor imposes, the returns it submits. The menu carries them in that order — Obligations, Controls, Evidence, Calendar and deadlines, Submissions, Retention — because the estate has to be reachable before anything written over it means much. Data governance is the part we provide. The programme on top is drawn to the requirements of the environment it runs in, by the people who own it, and it arrives as flows and packages instead of as somebody else's defaults.
Three pieces of engineering we're taking to the standard that evidence deserves:
Tamper-proof retention
Evidence has to be provably unchanged since the run that produced it. That guarantee is what makes evidence kept inside your building stronger than evidence signed in someone else's cloud, and it's what we're hardening now.
Exactly-once on egress
A branch plugin reporting a check must not double-count or drop one. The idempotency keys in the demo are the foundation of that guarantee; the end-to-end version is the next piece of it.
An auditor-recognisable decision table
The output has to render as something an ISO or supervisory auditor accepts without being taught, so we're shaping that table with the people who sign it off rather than guessing at it.
One choice belongs to the organization rather than to us: what happens to a run already parked on a human when the control it was executing gets amended. Resume under the old control, restart under the new one, or escalate. Each is right in some setting and wrong in another, which is exactly why it's a decision taken in the flow, per environment, instead of a default buried in an engine nobody can see into.
SurfStat · built in the Compliance Lab, Inflowenger's regulatory segment, and not bounded by it. In development — scope and dates will shift. Comparison figures for Vanta and Drata come from their own current materials and will age.