Saiku + Ossie: Seven Investigation Tools From One Semantic Model
New! Listen to Concept to Cloud - Real stories from the trenches of software engineering
Seven Investigation Tools, 45 Million Companies, One Weekend
Strategy

Seven Investigation Tools, 45 Million Companies, One Weekend

TB
Tom Barber
July 12, 2026
0 min read

We keep telling clients their AI project is really a data project, and that with the right semantic layer underneath, everything on top gets fast and cheap to build. So we proved it. Over a weekend we pointed Saiku and Ossie at 45 million companies of public beneficial-ownership data and built seven investigation tools on top: a live ownership graph, dashboards, a risk radar, cross-border flows, plain-English querying and a case desk. One model underneath; every surface almost free. Here's what each piece does and how they fit.

Seven Investigation Tools, 45 Million Companies, One Weekend

We say the same sentence to almost every client who arrives holding an AI initiative: your AI project is a data project. People tend to hear that as bad news, as if it means more slog before the fun starts. It’s actually the opposite. Define what your data means once, in one place, and everything downstream, dashboards, chat, whatever you build next, becomes almost free.

So rather than say it again, we built the proof. Over a weekend we pointed our own stack, Saiku and Ossie, at a genuinely messy, genuinely large dataset: beneficial-ownership records for around 45 million companies pulled from public corporate registries across Europe and beyond. The result is a small investigation platform we called Enigma. You search a company or a person, watch its ownership climb through the corporate layers up to the actual humans in control, ask questions in plain English, and open a case on anything worth a second look.

The short version: define the model once, and the tools fall out of it. The graph, the dashboards, the risk radar, the plain-English questions, none of them needed bespoke query code. Each is just another view pointed at the same model, which is exactly why seven of them fit into a weekend.

What we actually built

Enigma ended up with seven ways to look at the same data, all of them live queries against the warehouse, none of them a pre-baked snapshot:

  • The Web, type a company, get its ownership graph: who owns it, who owns them, all the way up to the natural persons at the top.
  • The Deck, live dashboards over the whole corpus: ownership by jurisdiction, how control is actually held, company status breakdowns.
  • Signals, a risk-and-screening radar: sanctions, debarment and PEP hits cross-referenced with a computed risk score.
  • Borderlines, cross-border ownership corridors, rendered as a flow diagram: where the owners of a country’s companies actually sit.
  • Ask, natural language. “How many companies are active versus dissolved?” comes back as real numbers, no query language in sight.
  • Cases, a working case tool: pin an entity or a saved answer, give it a status and a priority, add notes, and keep an audit trail.
  • Reveal, a curated case file that pulls all of the above into one narrative page for a single subject.

Borderlines: cross-border ownership corridors in Enigma, owner nationality flowing into company jurisdiction, with the top corridors ranked by interest count. Every flow is a live aggregate through Saiku over the Ossie model.

Seven surfaces, one underlying model. That’s the whole point, and it’s worth explaining the two pieces that make it possible.

First, the two words you need: Ossie and Saiku

Most of the industry has settled on the idea that you need a semantic layer, a single, shared definition of your business concepts that sits between raw tables and everything that consumes them. The pitch is that “revenue” or “active customer” or, in our case, “beneficial owner” should be defined once, and every dashboard, spreadsheet and AI agent should read that one definition instead of reinventing it in a hundred slightly-different SQL queries.

Ossie is the model. It’s an implementation of the Open Semantic Interchange format, a document that describes your data in terms of meaning rather than storage: datasets, the fields on them, the metrics you can compute, the relationships between them, and hints for machines (synonyms, display names, context notes). It can be generated straight from dbt, or hand-written as YAML. For Enigma, the whole thing is a single file that says, in effect: here is the ownership fact table; here are companies and people; a company is owned via subject_id; a person owns via interested_party_id; here’s how to compute an ownership count or an average risk score. Nothing in that file is a query. It’s a description.

Saiku is the engine that makes the description do something. Saiku is our open-source analytics server, historically an OLAP layer built on Mondrian, and over the last year rebuilt around Apache Calcite so it can plan clean SQL against almost any warehouse. Its job is to take that one semantic model and serve it to everyone at once: to Excel over the classic MDX/XMLA protocol, to dashboards, and, the part that matters here, to AI agents through a typed API and MCP tools. You ask Saiku for “ownership count by jurisdiction” against the model, and it compiles that request into SQL, runs it on the warehouse, and hands back typed results. The agent never sees, and never needs to see, a line of SQL.

Put simply: Ossie says what the data means. Saiku turns that meaning into answers. Everything Enigma does is a consequence of getting those two things right, and once they’re right, they’re right for every surface at once.

The stack, end to end

The data lives in a ~28GB DuckDB database, served read-only over DuckDB’s new client-server wire protocol so Saiku can reach it across our private network without copying anything. Saiku holds the Ossie model, plans queries through Calcite, and exposes them as a typed AI Query API. Enigma itself is a small SvelteKit app that only ever talks to Saiku, it has no direct database access and no privileged knowledge of the schema. Natural-language questions go out to a Claude model, come back as a structured query against the Ossie model, and get executed exactly the same way a dashboard query would.

That separation is the entire architecture, and it’s the thing worth stealing even if you never touch our tools: the front-end is dumb, the model is smart, and the AI is a translator that only ever speaks the model’s language. No surface can ask the warehouse anything the semantic layer doesn’t already define. That’s not a limitation we worked around, it’s the safety property that makes the whole thing sane, and the reason adding a new tool never felt risky.

Even walking the ownership graph came from the same model

Here’s the part we thought would be extra work, and wasn’t. A semantic layer is built to aggregate, group by this, count that, average the other. But beneficial ownership isn’t an aggregation. It’s a graph. The genuinely useful question, “who ultimately controls this company?”, means walking from a company to its owners, to their owners, and up again until you hit a human. That’s a recursive traversal, not a GROUP BY.

We didn’t reach for a graph database or a second pipeline. We described one more thing in the model we already had, which columns link a company to its owners, and let Saiku generate the recursive walk over the warehouse, returning the whole ownership tree, cycles and all. The graph traversal reads the same declared relationships that the aggregate queries do. One model, two very different shapes of question, no duplication and no new source of truth.

It’s the reason The Web can show you a company climbing through a chain of offshore intermediaries all the way to the people at the top, rather than just a number in a bar chart:

A featured case file in Enigma: one company's ownership walked from the entity at the bottom all the way up to the two people in control, with the corporate layers and the humans listed alongside. Every link is a public-registry filing, assembled into one picture by Saiku.

Asking in plain English, the model does the work

The headline feature is Ask: type a question, get real numbers. It feels like the clever bit. It’s genuinely the least code.

It’s small because the model is rich. When someone asks “what are the most common ways control is held?”, the language model doesn’t need to know SQL, or the table names, or how the joins work. It picks a metric and a dimension from the semantic model, which Saiku hands it as a clean, typed catalogue, and Saiku does the rest: validates the choice against the live model, compiles it, runs it, and returns typed cells. If it reaches for something that doesn’t exist, it gets a structured error telling it what does exist, and it self-corrects.

That’s the whole trick, and it’s why we keep repeating the data-project line. The AI is only as good as the surface you give it to point at. Give it raw tables and it hallucinates joins. Give it a well-formed semantic model and it becomes a reliable translator between a human sentence and a query you’d have been happy to write by hand.

Reading is easy. Writing back is the capability.

Most analytics demos stop at reading. Ours needed to do something, because an investigator who can’t record a finding hasn’t got a tool, they’ve got a search box. So Cases is a genuine write path: saving an entity or an answer creates a case in a Postgres store, and from there it has a lifecycle, open, in review, escalated, closed, a priority, an assignee, free-text notes, and an append-only activity timeline that records every change. It’s deliberately modelled on the compliance case tools our regtech clients actually run, scaled down to the essentials.

The split is intentional and worth naming: everything reads through Saiku over a read-only warehouse; the only thing that writes is the casework. That’s a clean, auditable boundary, the analytical layer can never mutate the source data, and the human-decision layer is the only thing that persists state. If you’re building anything that mixes analysis with action, that separation is worth copying.

What this actually demonstrates

We built Enigma to make one argument physical: with the right semantic layer underneath, building on top is fast, safe, and almost anticlimactic. Define the model once and the AI stops being a risky science project, it becomes a predictable translator that can only ever ask questions the model already understands.

Every capability in the platform came from that one model, not from bespoke code behind each screen. The graph traversal, the dashboards, the risk radar, the cross-border flows, the English-language questions, all of them are just different consumers of one Ossie model, served by one Saiku instance, over one warehouse. Add a new surface and you write no new query logic; you point another view at the same model. That’s the leverage a semantic layer buys you, and it’s the reason “your AI project is a data project” isn’t a warning, it’s where the shortcut is.

If you’ve got an AI initiative and a data estate that doesn’t yet have a shared definition of what anything means, that missing definition is the thing that makes everything after it easy, and it’s the part we most like to help with. We build these systems for regtech, private equity and data-heavy startups: the semantic layer underneath, the analytics and agent surfaces on top, and the connective tissue that makes a demo survive contact with real data. If that’s the shape of your problem, let’s compare notes.


Saiku and Ossie are open source. If you’d rather read the deeper engineering write-ups, the graph traversal, the Calcite planner rewrite, the Arrow data path, they live over on the technical side of the house.

TB
Written by Tom Barber

Ex-NASA engineer and cloud architect with over a decade of experience building scalable systems for startups and enterprises.

Work with Tom →

Related Articles

Strategy

Why Your AI Project Is Actually a Data Project (and What That Costs You)

Most AI projects fail in the data layer, not the model layer. The slide deck is about agents and RAG; the work that decides the outcome is unglamorous data engineering nobody scoped or staffed.

Read More →
Strategy

Rebuilding Saiku: Bringing a Commercial Open Source OLAP Tool Back With AI

Years ago I walked away from Saiku, the commercial open source OLAP tool I'd built and run for the better part of a decade. This year, with a few weeks off and an agentic coding agent at my disposal, I rebuilt it, new UI, modernised dependencies, and a new SQL engine underneath. Here's what happened, and why I'm releasing it again.

Read More →
Tips

Entity Resolution in Postgres: Trigrams, Jaro-Winkler, and Vector Embeddings Compared

Deduping messy real-world data, companies, addresses, people, looks like a solved problem until you do it. Here's an honest comparison of the three techniques that actually matter inside Postgres, when each one wins, and where each one quietly breaks.

Read More →

Ready to Build Your Product?

Let's discuss how we can help you bring your vision to life with expert cloud solutions

Get Started