SVC/DATA — Data & applied AI

Numbers people trust, and AI that earns its place.

Most data problems are not modelling problems. They are that the pipeline broke in March, nobody noticed, and the dashboard has been confidently wrong ever since.

CAP/ — Capabilities

What we build.

DATA/ING

Ingestion & pipelines

Getting data out of the systems it is trapped in, on a schedule, with failures that are visible rather than silent.

DATA/WH

Warehouse modelling

Dimensional models and transformation layers, so that two people asking the same question get the same number.

DATA/RPT

Reporting & dashboards

Dashboards that answer a specific question for a specific person. Not a wall of charts nobody opens twice.

DATA/LLM

Applied LLM features

Retrieval, extraction, classification and summarisation — scoped to tasks where being occasionally wrong is survivable.

AI/ — On the AI part

Where LLMs actually pay, and where they don't.

Worth doing

Extraction from unstructured documents — invoices, contracts, forms — where a human already checks the output
Classification and routing at volumes too high to do by hand and too irregular for rules
Search over your own content, where the answer cites the source and the user can verify it
Drafting — first versions a person edits, never final output that ships unread

Worth resisting

Anything where being wrong is expensive and nobody is checking the output
Arithmetic and aggregation. A SQL query is correct; a language model is plausible
Replacing a rules engine that works. Deterministic beats probabilistic when the rules are known
A chatbot on the website because competitors have one

The pattern that separates the two columns: an LLM feature works when there is a cheap way to catch it being wrong. Design that check first. If you cannot describe how a bad output gets noticed, the feature is not ready regardless of how well it demos.

PRN/ — Principles

How we approach data work.

Pipelines that complain

Every job reports success or failure somewhere a human will see it. Silent partial failure is the defining data-engineering disaster, and it is entirely preventable.

One definition per metric

"Revenue" means one thing, defined once, in the transformation layer — not differently in four dashboards. Most reporting disputes are definition disputes wearing a technical costume.

Tests on the data, not just the code

Row counts, null rates, referential integrity and freshness checked on every run. The code being correct does not mean today's load was.

Start with the question

We build backwards from a decision somebody needs to make. A warehouse built forwards from "let's centralise all our data" produces a large, expensive, unused asset.

CTA/ — Data work

What decision are you trying to make?

Tell us the question you can't currently answer, and roughly where the data lives. That's usually enough for a straight assessment of what it would take.

Start a conversation →