What we build | Octelion

Data platforms that stay trustworthy as they grow

What you get

One governed place where every source lands as it arrived, is cleaned by written rules, and is served as tables shaped around the questions your people ask.

Every row carries where it came from and when.
Every rule reports how many rows it rejected, on every run.
Rejected rows sit in a table where they can be counted, not deleted.
A cost ceiling and an auto-shutdown, set on day one, not after the first surprising bill.

The problems it solves

Two reports show two different revenue numbers and nobody can say which is right.
The nightly load fails silently and the team finds out from a customer.
A new column in a source file breaks the pipeline at 3 am.
The cloud bill grew faster than the data did.

The stack, named plainly

Databricks on Azure. Delta Lake tables. Lakeflow pipelines with expectations for the rules. Unity Catalog for who can read what. Auto Loader for files that arrive on their own schedule. DuckDB and Python for the jobs that do not need a cluster. Microsoft Fabric when your company is already in it.

Read the lakehouse walkthrough on public data

Reports people open every morning and believe

What you get

A Power BI semantic model built as a star, so reports open in a few seconds and every number has one definition.

Measures instead of stored columns, incremental refresh with a real range, summary tables for the pages everyone opens.
One definition of each number, written down, used everywhere.
A reconciliation page that proves the report agrees with the source system.

The problems it solves

Typical of the models we are asked to fix, not a measurement: the report takes 40 seconds to open and a slicer click takes eight.
The refresh takes three hours to pick up one day of orders.
Margin is defined four different ways in four different reports.
People export to Excel because they do not trust the dashboard.

The stack, named plainly

Power BI and Fabric. DAX for measures, Power Query for shaping at refresh. Aggregation tables and incremental refresh policies. Performance Analyzer, DAX Studio and VertiPaq Analyzer to prove the result rather than describe it. The gold layer of a lakehouse, or your existing warehouse, underneath.

Read the five fixes, shown on public data

AI assistants and agents that do real work safely

What you get

An assistant or agent with one defined job, built so you can say afterwards exactly what it did: answer questions over your documents, triage a queue, draft the weekly report, file a ticket, reconcile two lists. The model is the easy part.

A safety classifier in front, and a human approval step for anything that changes a system.
A fixed set of tools, one permission per tool, a cost ceiling per day and per request.
Every request, tool call and answer traced and kept for as long as you decide.
Evals, a written set of cases, run before launch and on every change; the results are part of the handover.

The problems it solves

The prototype impressed everyone and nobody will put it in front of a customer.
Nobody can say what the assistant did last Tuesday, or why.
One bad prompt and the agent emails the wrong list.
The model bill is a line item nobody owns.

The stack, named plainly

Claude and other frontier models, chosen per task. A classifier in front of every request. MCP tools where a standard interface helps, with permissions per tool. Human review queues for the actions that need a person. Evals as code, run in CI. Traces and retention in your own storage. Rate limits and spend ceilings enforced in code, not in a policy document.

We do not ship an agent we cannot replay.

Have one of these problems? Send the one sentence that describes it.

Workflows that run themselves

What you get

Scheduled jobs that pull, check, transform and deliver without a person in the loop, and that stop and tell someone when a check fails.

Data quality gates between steps.
Approval steps where money, customers or compliance are involved, each one leaving a record of who approved what and when.
A log of every run with its inputs and outputs, readable on Monday morning without opening a terminal.

The problems it solves

Someone spends Monday morning assembling the same report by hand.
The export went out with last week's numbers because the upstream job had failed.
An approval lives in a chat thread nobody can find three months later.

The stack, named plainly

Python, scheduled on Databricks Jobs, Azure Functions or GitHub Actions. Power Automate where the workflow lives in Microsoft 365. Written quality gates between steps. Approval steps that record who approved what, and when. Cron where cron is enough.

Have one of these problems? Send the one sentence that describes it.

Monitoring that reaches a person

What you get

An alert that names the failing run and links to it.

A dashboard for cost, usage and freshness that someone actually opens.
Drift and quality checks on the data and on the model outputs, with thresholds you set.
A runbook for each alert that says what to try first and who to call.
Before launch, we break things on purpose to confirm the alert fires and the runbook works.

The problems it solves

The job failed on Friday and the dashboard was stale until Tuesday.
Alerts go to a channel with 400 unread messages.
The person who knew how to restart the pipeline left.
Cost went up 30% and nobody noticed for a quarter.

The stack, named plainly

Azure Monitor and Databricks system tables for cost and runs. Alerts to email, Teams or Slack with the run link in the message. Quality and drift checks written as queries that run on a schedule. Runbooks as plain documents in your repository.

Have one of these problems? Send the one sentence that describes it.

The product around it all

What you get

The web app your team or your customers log into. If the data and the agent are the engine, this is the car.

Real authentication, with row-level permissions enforced in the database.
Deployment that repeats.
Documentation that a new engineer can follow.

The problems it solves

The analysis lives in a notebook only one person can run.
Customers should see only their own rows and the app trusts the front end to hide the rest.
The demo worked on a laptop and there is no way to deploy it.

The stack, named plainly

Next.js on Vercel or Azure Static Web Apps. Supabase or Azure for auth and data, with row-level security in the database. GitHub for code, reviews and deployment. A README, an architecture note and a runbook in the same repository.

Have one of these problems? Send the one sentence that describes it.

How it is built

The diagram is the shape of most systems we build, and the same shape runs a sales lakehouse, a support agent and a sensor feed. The names on the boxes change; the shape does not. Click a node, or tab to it, to read what it does and why it is there. Without JavaScript the notes are listed below the diagram.

Data moves left to right and fans out into the three things people use. Monitoring and audit sit on the dotted line underneath and see every node. On a small screen the diagram scrolls sideways.

Selected node

Agents

Claude or another frontier model behind a safety classifier. A fixed set of tools, MCP where a standard interface helps, with a permission per tool. A human approval step for anything that changes a system. A cost ceiling per day. Evals run before launch and on every change.

All nine notes as a list

Sources: Your systems as they are: ERP, CRM, a warehouse, spreadsheets, APIs, event streams. Nothing changes here. We read; we do not write back.
Landing (bronze): Every file and every event lands exactly as it arrived, with the time it arrived and the file or stream it came from. Auto Loader into Delta tables on Databricks, schema evolution on, so a new column is added rather than a failed run.
Cleaning (silver): Rules with three outcomes: fix, drop, quarantine. Written as expectations in Lakeflow pipelines, so each run reports how many rows failed each rule. Rejected rows go to a quarantine table with the reason attached. Nothing is deleted silently.
Governance: Unity Catalog. Grants by group, read-only for people, writes only by service principals. Lineage from source to report. An audit log of who read what. Row-level filters where the business needs them.
Models (gold and semantic): One table per question, clustered by the column people filter on first. On top, a Power BI semantic model built as a star: measures, incremental refresh, aggregation tables, one written definition per number.
Agents: Claude or another frontier model behind a safety classifier. A fixed set of tools, MCP where a standard interface helps, with a permission per tool. A human approval step for anything that changes a system. A cost ceiling per day. Evals run before launch and on every change.
App: Next.js on Vercel or Azure. Supabase or Azure for authentication and data, with row-level security enforced in the database rather than the interface. The thing people log into.
Monitoring: Alerts that carry a link to the failing run. Dashboards for cost, usage and freshness. Quality and drift checks as scheduled queries. A runbook per alert. Tested by breaking things on purpose before launch.
Audit: Every agent request, every pipeline run, every grant change, retained for a period you choose, in storage you own. The answer to "what happened" is a query, not a meeting.

To see the data layers of this shape on real data, read the lakehouse walkthrough, which computed its figures on 4.3 million public taxi rows

Not sure which of these you need?

Describe what is slow, missing or risky and we will tell you which two or three apply, in writing, before anyone talks about an engagement.

hello@octelion.dev