FlowProof — Outcome Assurance for automated back-office flows

Why this is not monitoring

Monitoring watches the machine. FlowProof checks the result.

Your job can run, exit 0, and still be wrong — five invoices silently dropped, a batch half-posted, a report that never refreshed, a nightly export skipped. Uptime tools were never designed to catch that. This is a different question.

Monitoring / observability asks

"Did the job run and the box stay up?"

Process exited 0, CPU and memory look fine.
The API returned 200; the queue drained.
Alerts fire on infrastructure failing, not on a correct-looking run producing a wrong result.
No durable, portable evidence of the business outcome.

FlowProof asks

"Did the outcome the flow promised actually happen — and can I prove it later?"

All 50 source invoices reached the target system.
Counts and amounts reconcile between the two sides.
When they don't, it names the exact missing records.
Every result is a hash-chained, tamper-evident receipt.

Three rules we cannot break — by design

The client owns the proof

Every workspace, its data and its receipts belong to the CLIENT — your firm holds delegated access. The proof is never owned by the party being checked, and a client can take every receipt with them and still verify it.

Fail-closed — by content and by time

No evidence means unverified, never "probably matched". If evidence doesn't arrive before the window closes, that absence itself becomes a recorded, receipted fact.

Verify everything offline

Receipts and reports carry cryptographic hashes and ship with an open offline verifier. Anyone holding the document can check it — no account, no network, no trust in us required.

Priced per active client. Your firm pays one subscription and resells assurance to its clients — onboarding clients cost nothing until you deliberately activate them.

Client assurance report, in German, with verdicts, coverage and doctrine footer — The hand-over report — printable, hash-stamped, German-first.

The attention queue in German: severity-ranked incidents, unverified outcomes, coverage gaps — The operator's morning — unverified outcomes first, never hidden.

A complete client provisioned from a blueprint in one click — A new client, provisioned from a blueprint — in under a second.

All screenshots show the real product running on a fully synthetic estate — a pre-release engineering build. No customer data exists anywhere in FlowProof today, and no claim here goes beyond what the live demo can show.

The app speaks Deutsch, Français and English — the operator picks per device. This page is English-only for now; we would rather say so than half-translate it.

What it proves · a worked example

One failed invoice export, reduced to a receipt.

This is FlowProof's synthetic hero — Adlerhof Pharma AG, entirely fictional. The engine ingested both sides of an invoice export, found five invoices that never reached Business Central, and rendered the receipt below. Same inputs always produce the same PDF bytes — so the receipt has one stable fingerprint.

1 Expected. The source system (Yokoy) reported 50 invoices totalling CHF 48,230.10 for the business day.
2 Observed. The target (Business Central) received only 45, totalling CHF 46,110.10.
3 Where to look. The receipt lists the five missing invoices by ID, counterparty and amount — the exact gap of CHF 2,120.00.
4 Proof. The bundle is canonical JSON; the PDF is byte-deterministic. Re-run it and the pdf_sha256 is identical — that's what CI checks every push (Gate A).

FlowProof receipt Yokoy → Business Central · invoice export

FAILED · HIGH

Incident: INC-2041
Business date: 2026-07-06
Check: id_match
Source · Yokoy: 50 · CHF 48,230.10
Target · BC: 45 · CHF 46,110.10
Amount gap: CHF 2,120.00

Missing records (5)

Invoice	Counterparty	Amount (CHF)
INV-4476	Basel BioTools AG	718.00
INV-4480	Simmental Diagnostics AG	522.00
INV-4471	Alpina Chemicals AG	424.00
INV-4472	Elpharm AG	298.00
INV-4491	Rhein-Analytik GmbH	158.00
Total missing		2,120.00

pdf_sha256 — the receipt's fingerprint a42cb4056c162d0f64fa207a815ff001bb4108fef30d3caa3c3b61929f1f30e2

Every name, number and hash on this page is synthetic. There is no real customer, and no customer data has ever touched FlowProof.

What it does today

A working engine, driven by API, CLI, and a read-only console.

FlowProof today is a reconciliation engine with a signed ingest API, a receipt renderer, a hash-chained audit trail, and a read-only, server-rendered console over synthetic worlds — exercised by a suite of 749 passing tests across 56 spec files. It is operator-gated and synthetic-only; there is no self-serve product yet.

Ingest

Signed batch intake

POST /v1/ingest/batch accepts both sides of a flow over a local HTTP API, authenticated with HMAC-SHA256 and a ±300 second replay window.

Reconcile

Verdict engine

A time-zone-correct sweeper compares source and target, applies the check, and produces a verdict with a confidence level — one incident per real breach, not per row.

Evidence

Deterministic receipt

A canonical JSON bundle and a byte-identical one-page A4 PDF. Same inputs → same bytes → same pdf_sha256, so the receipt is verifiable by anyone who re-runs it.

Audit

Hash-chained trail

Incidents append to a SHA-256 hash chain with a verifyChain check — append-only and tamper-evident, so a silently edited history fails verification.

Read

Operator view

A token-gated, read-only surface serves incidents and their receipt.pdf. Bearer-token auth, constant-time compare — no public browsing, no editing.

Deliver

Alert seam

An optional delivery layer can dispatch Slack / email alerts on a breach, with a bounded outbound timeout. Off by default — the base pipeline emits incidents and audit only.

Built vs. not-yet — no rounding up

The honest capability matrix.

What actually exists in the repo, what's partial, and what is still on the roadmap. Filter it — nothing here is hidden behind a "coming soon".

Signed ingest API Built

HMAC-SHA256, ±300s replay window, POST /v1/ingest/batch + GET /healthz.

Reconciliation + verdicts Built

Org-safe, DST-correct sweeper; one incident per breach; confidence levels.

Deterministic receipt (JSON + PDF) Built

Canonical bundle + byte-identical A4 PDF; stable pdf_sha256 checked by CI.

Forwardable receipt · id_match today Partial

Only id_match produces a client-forwardable receipt today; the other three working checks stop at verdict + incident + audit.

Hash-chained audit trail Built

Append-only SHA-256 chain with verifyChain — tamper-evident by design.

Token-gated operator read view Built

Bearer-token, constant-time auth; serves incidents + receipt.pdf. Read-only.

Postgres persistence Built

Real Postgres store + migrations; runs on a single box with local Postgres.

Alert delivery (Slack / email) Partial

Delivery layer + bounded timeouts exist; off by default, opt-in per deploy.

Blob storage backends Partial

memory / fs / s3 seam in code; no cloud object store is provisioned (R-05).

Rule coverage Partial

4 of 6 check types implemented; two remain on the roadmap (R-10).

Key custody Partial

Env-provided KEK wraps tenant keys; not managed KMS/Vault, pending crypto review (R-02).

Public receipt sharing Not yet

Share route is implemented but held OFF until a DPA + counsel sign-off (R-03).

Self-serve dashboard / UI Not yet

No end-user screens, no onboarding flow — the surface today is API + CLI + operator read.

Self-serve / multi-tenant product Not yet

A private single-box synthetic demo is live and operator-gated; there is no self-serve tenancy or managed database product.

The checks · 4 of 6 built

The business failures it can catch today.

Each check is a small, testable kernel that maps to a real back-office failure. Four are implemented and exercised by the test suite; two are specified but not yet built — shown here rather than quietly omitted.

id_match

Every record arrives

Each source item must appear in the target. Catches dropped invoices, lost orders, half-posted batches.

Built the Adlerhof hero

count_match

The totals reconcile

Row counts (and amounts) agree between two systems. Catches "50 in, 45 out" without needing per-row IDs.

Built batch integrity

freshness_sla

It landed in time

An expected output arrives before its deadline. Catches an export that's late or never completes for the day.

Built deadline breaches

missed_schedule

The run happened

A scheduled job actually executed in its window. Catches a nightly sync that silently didn't fire.

Built silent no-shows

zero_output

It produced something

A run that completed but emitted nothing when it should have. Specified; kernel not yet implemented.

Not yet roadmap · R-10

heartbeat

The source is alive

A feed that stops reporting entirely. Specified; kernel not yet implemented.

Not yet roadmap · R-10

All four working checks produce a verdict, an incident, and a hash-chained audit row. Only id_match also produces a client-forwardable receipt PDF today — generalising the receipt to the other families is later platform work, not a claim we make now.

Hosted demo · synthetic, operator-gated

A live demo you can be walked through — on synthetic data only.

FlowProof runs as a live, server-rendered console over synthetic worlds — real provision → real evidence → real verdict → real anchored receipt, on invented data. It is private and operator-gated, off by default, and no real customer data has ever been loaded. It is shown by the founder in a walkthrough, not opened to the public.

What the hosted demo is

Data100% synthetic · enforced allowlist

Accessoperator-gated · off by default

Hostingsingle Swiss box · Let's Encrypt TLS

HeroAdlerhof INC-2041 · 50 / 45 · CHF 2,120.00

Receipt hashreproduces on box, in CI, locally ✓

Customer datanone — ever

What the demo proves

The deploy path is real, persistent, and server-rendered — not a slide.
The same golden pdf_sha256 reproduces off a live host, in CI, and locally.
One lane is deliberately prod-shaped but locked — the console is off, proving "prod-shaped" ≠ "customer-ready".
Every world is synthetic by an enforced allowlist, not by good intentions.

What it does not prove

Nothing about production hardening, uptime, or scale.
It is not a self-serve product and not a purchase surface.
It uses local Postgres on the box — not a managed database.
No real data: the console is synthetic-only even after any future unlock.

The line we will not cross yet

We can run the infrastructure. Customer data stays locked.

FlowProof can stand up production-grade infrastructure — but real customer data stays out until a written checklist of legal and security gates is complete. That decision is explicit and separate; a green demo does not unlock it.

Gates that must close first

R-02managed key custody + external crypto review

R-03data-processing agreement + counsel sign-off

R-05durable off-box storage + backup/restore

Statuscustomer data LOCKED

What "locked" means, plainly

No real customer data has ever been processed — not in the demo, not on the box, not in CI.
The synthetic demo lanes stay synthetic-only by an enforced control, even after any future unlock.
Unlock is a deliberate, gated decision — never a side effect of a passing test.

One spine · many workflow-shaped problems

The same engine already spans three domains.

FlowProof adjudicates workflow-shaped outcome problems: the promised result should be in the system of record — is it? The four working checks already serve finance, reporting, and operations with the same verdict, incident, and audit vocabulary. Other domains are the same engine plus configuration — not a new product, and not a packaged integration we claim today.

Finance

Settlement reconciles

Money promised equals money landed, key by key. The Adlerhof hero.

Works todayid_match

Reporting / BI

The dataset refreshed

An expected report or extract landed before its deadline.

Works todayfreshness_sla

Operations

The counts agree

Record counts reconcile across two systems; the scheduled run fired.

Works todaycount_match · missed_schedule

HR onboarding

Provisioned by day one

Every new hire exists in every system on schedule.

Templateconfig, not new code

Sales · Marketing · Support

Closed-won became real

Every won deal created an invoice; the nightly audience sync populated; the queue drained.

Templateexisting rules, new config

A genuinely new shape

Produced anything · still alive

"This job emitted something at all", "this feed is still reporting" — the reserved checks.

Not builtzero_output · heartbeat

"Works today" means the check runs on synthetic data with a verdict, incident, and audit trail. "Template" means it is expressible with today's rules as configuration — not a shipped connector. FlowProof ships no packaged integration to any named product.

Open risks · carried in the open

What isn't ready — and why we say so.

FlowProof keeps a live risk register. These four are open right now. Each is graded by blast radius (how bad if it bites) and cure (how it gets closed). None of them is hidden from a buyer.

R-02 Open

Key custody & crypto review

The key that wraps each tenant's signing key is provided via env today — not managed KMS/Vault, no rotation, and pending an external crypto review. Downgraded from its original severity, but not closed.

Blast · Trust Cure · External

R-03 Open

Legal gate on public sharing

The public receipt-share route stays OFF until a data-processing agreement and counsel sign-off are in place. The code exists; the gate is legal, not technical.

Blast · Legal Cure · External

R-05 Open

Cloud object storage

The blob storage seam supports an S3-style backend, but no cloud bucket is provisioned. Durable off-box receipt storage is code-ready, not deployed.

Blast · Contained Cure · Slice

R-10 Open

Rule coverage (4 of 6)

Two specified checks — zero_output and heartbeat — are not yet implemented. The four that are cover the reconciliation and timeliness cases shown above.

Blast · Contained Cure · Phase

✓ What we do claim

Append-only, hash-chained, tamper-evident audit trail.
Deterministic receipt — same inputs reproduce the same bytes and hash.
4 of 6 checks implemented, exercised by 749 passing tests.
A live, private synthetic demo — operator-gated, no customer data.
100% synthetic data throughout.

✕ What we never claim

"Immutable" — it's tamper-evident, a real distinction.
SOC 2 / ISO / GDPR / GoBD / "compliant" / "audit-ready".
"We integrate with Yokoy / Business Central" — those name the scenario, not shipped connectors.
"Managed Postgres" / "hosted product" / "production-ready" / "customer-data-ready".
Any real customer, logo, or dataset.

From proof to product

An honest roadmap, not a promise with dates.

FlowProof is a proven engine, not a finished product. Here is the real distance between the two — the "next" and "later" work is scoped but unbuilt, and dated to no one.

Now · proven

The engine + one verified deploy

Signed ingest, reconciliation, deterministic receipt, audit chain.
Operator-gated read-only console over synthetic worlds.
CI reproduces the golden receipt hash; a live private synthetic demo runs on a Swiss box.

Next · scoped

Close the open risks

Build zero_output + heartbeat (R-10).
Managed key custody + external crypto review (R-02).
Provision durable cloud object storage (R-05).
DPA + counsel to open public sharing (R-03).

Later · product

Beyond a single operator

A read UI beyond the operator view.
Multi-tenant, self-serve onboarding.
A hosted offering — designed, not yet built or promised.

For automation agencies

Hand clients evidence

When you run RPA, iPaaS or scripts for a client, a receipt that names what was and wasn't delivered is worth more than "the job is green".

For founders & operators

Sleep through the nightly run

Know the invoice export, payment batch or data sync actually moved every record — and get named specifics the moment it didn't.

For finance & ops

Answer "prove it" after the fact

A tamper-evident, reproducible receipt per breach — the difference between "we think it reconciled" and evidence you can show.

See the proof, not a pitch.

FlowProof is pre-release and privately built — there is no signup and nothing to buy. If you run automations that move records or money between systems, a walkthrough is a conversation: the synthetic INC-2041 incident, its one-page receipt, and the hash reproducing byte-for-byte.

Founder-led · synthetic demo · no obligation.

Request a walkthrough