How Backbone worksWhat you provide, what we provide

You tell us three things: what your business is made of, the jobs you need the data to do, and where the data lives. Backbone then builds a governed, tested data warehouse in your own Snowflake account, with code stored in your GitHub repo, one use case at a time. We start from your business, not your systems: a shared model of common business processes, tailored to you. A short end-to-end check proves the plumbing first: a few hours once your data is landed. After that, every use case is checked against a number you already trust before anyone relies on it, and each one reuses what the earlier ones built. A first use case is usually live in 3–4 weeks. Nothing leaves your account, and nothing reaches production without approval, including yours.

Who provides what

You bring knowledge of the business and the authority to decide; we bring the model, the automation and the engineering.

How it comes together

Every engagement starts with an end-to-end check, then runs the same loop for each use case. Each pass adds only what that use case needs, so the warehouse grows in small, proven steps.

1. 1

   An end-to-end check first. Before any real use case, we take one critical figure (say, yesterday's orders and their value) from one source all the way through. That covers connection, build, tests, publishing, the production schedule and the approval route. Once your data is landed, the check takes a few hours. It proves everything works in your account with real data, so problems surface straight away, not halfway through a use case.

2. 2

   We start with the part of the ontology you need. Every client begins with a copy of our core ontology: the entities and relationships that recur across businesses (a party, an order, a product, a payment, an invoice), organised around common business processes. We tailor what the current use case touches (your entity names, your roles (a party can be a customer, a supplier, a store), your exceptions) and later use cases extend it. Moving into purchasing, for example, adds suppliers and bills. The copy is yours; changes to it never leak into anyone else's.

3. 3

   Connect your sources. If you already have your source systems loaded into their own Snowflake schema, we run a setup script we generate, which grants us read-only access and creates two Backbone-controlled databases (development and production). We scan every in-scope table, so nothing is skipped by sampling. We can set up the extraction if you don't already have them. A source joins when a use case first needs it; the databases and access are set up once, with the end-to-end check.

4. 4

   You write a brief per use case. A few paragraphs in plain language: the question to answer, who uses it, how often, and anything you already know is tricky. You do not need to know which tables hold the answer. A use case can ship in slices (one store or region first, the rest after), and a brief can leave a decision open until the data shows what it is.

5. 5

   You name a trusted source. The figure the business already believes — a trial balance, a platform's own report, last month's spreadsheet. We prove our numbers against this.

6. 6

   We compile a plan. The brief becomes a structured plan: which entities and sources the use case needs, and which metrics, rules and outputs it produces. Most of the model usually exists already, so the plan reuses it and lists only what is new, with each new assumption for you to confirm.

7. 7

   We build. Backbone generates the warehouse code from the plan — a Data Vault model that keeps full history and lineage, then the business rules and outputs on top — and runs it in your development database. Changes are additive: earlier outputs keep working, and every version of the warehouse is recorded.

8. 8

   We test and reconcile, on every load. Generated tests check keys, relationships and completeness. Reconciliation tests compare our output to your trusted source. Where that source is a system we load (your ledger, a platform report, the bank), the comparison repeats on every load. Where it is a file the use case replaces, we run in parallel for a closed month or two until every difference is explained, and then retire the file. Consistency tests keep running regardless: balances roll forward, every payout meets the bank, closed months don't move. Differences are explained or traced to a source, never hidden, and open ones go on a differences register that carries across use cases. Sometimes a use case shows the model needs adjusting; we go back and adjust it, which is expected, not a failure.

9. 9

   We publish. The use case is published as governed semantic views with business definitions, plus the outputs it needs (a monthly pack, a report). Your team can ask questions through a read-only Claude connector (or similar) that answers only from these definitions. By default we provide monthly packs and similar outputs via Claude Artifacts.

10. 10

    You approve; we promote. Each change is approved on its own: a named member of the engagement team approves the DEV evidence, and your administrator gives the second approval by merging into production. There is no big-bang go-live; your production schedule simply runs the latest approved code every day.

How the warehouse grows: a worked example

Each use case reuses what came before, so later ones need less new work. Here is a typical sequence for an online retailer, starting with sales and moving towards cash and the balance sheet.

By step 4 most of the model already exists, so the work is mainly new rules and a new reconciliation. Every other control in this sequence is data we load, so those reconciliations repeat on every load with nothing for you to maintain.

Where we need you

The system scans, infers and generates; you confirm, correct and decide. Expect to be asked at these points, and nowhere else:

Rulings are dated and recorded, so the reasoning behind every number survives staff changes. A later ruling can revise an earlier use case; its tests then follow the new rule.

The operating rhythm

Once the first use case is live, the work settles into a steady cadence rather than a project with an end date.

What you end up with

Value arrives with each use case, not at the end. Everything lives in your Snowflake account and your git repository, so it stays yours if the engagement ends.

Frequently asked questions

Glossary