IoT Data Flow Core Is Now Certified Research
Germany's certification body for R&D has recognised the core of IoT Data Flow as research. Here is what that means, what it doesn't, and which three problems it is about.
I have received a notice from the BSFZ, the Bescheinigungsstelle Forschungszulage. It says the core of IoT Data Flow counts as research and development under the German Research Allowance Act, and it comes with the seal for 2026.
The project has the kind of title only a German application form can produce:
Entwicklung einer zentral governten, engine-übergreifenden Datenzugriffsschicht mit Zero-Downtime-Aktualisierung für KI- und BI-Clients ("IoT Data Flow Core")
In English: a centrally governed, engine-independent data access layer with zero-downtime updates for AI and BI clients. Every part of that sentence is a real problem I work on, so this post unpacks it.
What the seal says, and what it doesn't
The BSFZ works on behalf of the federal government and answers one question about a project: is this research and development, or is it ordinary engineering? The yardstick is the one the OECD uses. The work has to be new, it has to be systematic, and its outcome has to be uncertain when you start.
That last criterion is the interesting one. Building a dashboard is not research, however good the dashboard is. Research starts where you can't look the answer up and have to find out whether an approach works at all.
So the seal is not a quality badge for the software, and nobody at the BSFZ has load-tested my box. What it confirms is narrower and, to me, more useful: an independent reviewer read what I claim is unsolved and agreed that it is.
Why a one-person business applies
The seal is meant for companies. As a sole proprietor, I am the company, so that part was simple.
The honest reason I applied is the application itself. You have to write down, precisely, what you don't know yet and how you intend to find out. That is a better planning exercise than most roadmaps I've seen, including mine. The financial side runs through the tax office afterwards and isn't what this post is about.
Problem one: governance in one place
IoT Data Flow already runs in production across 3,900+ machines and 40+ tenants. Leadership asks questions in Claude, finance refreshes numbers in Excel, engineers write SQL. Three very different clients, one set of data.
The question behind centrally governed is whether the rules can live in exactly one place. The same question from Claude and from an Excel refresh should hit the same permissions, produce the same answer, and land in the same query log. Today the database account is read-only, and that stays the real boundary. The research is about everything above it: making sure no client gets a side door just because it speaks a different protocol.
Problem two: one layer across many engines
Customers don't have one database. A typical deployment has Postgres for telemetry, SQL Server for an ERP extract, and a warehouse that group IT calls the single source of truth. Each speaks its own dialect, maps types its own way, and handles time zones in its own creative fashion.
For a language model this matters more than for a human. Every dialect the AI side has to generate is another set of edge cases, and another way to produce an answer that looks plausible and is wrong. Engine-independent means one query surface on top, with the differences pushed down to where they can be tested. The uncertain part is whether that can be done without losing correctness on the things fleet data is made of: timestamps, decimals, and very large event tables that must never be pulled across the wire in full.
Problem three: updates nobody notices
Each IoT Data Flow box is a single binary inside the customer's network, and I have no physical access to it. At the same time, someone in leadership may be halfway through a conversation in Claude, and a finance workbook may be scheduled to refresh at 6 am.
Zero-downtime sounds like an ops checkbox. For this setup it is a research question: how do you replace the software underneath long-lived AI and BI sessions without dropping them, and without an answer changing halfway because the rules changed underneath it? Web services solve this with load balancers and a fleet of identical servers. A single isolated box doesn't have that luxury, and I don't want to give up the isolation to get it.
What changes
For customers, nothing changes in the architecture. The box still sits inside your network, still reads only from databases you already own, and still never copies your fleet into someone else's cloud. The software comes to your data. That was the premise before the notice and it is the premise of the research.
What changes is that the hard parts now have a name, a scope and an outside reviewer who agrees they are hard. I'll write up results here as they come in, including the approaches that don't work.
Running a fleet whose data has to stay where it is? Tell me what leadership keeps asking that nobody can answer.