03a Every capability

The pipelines are the visible part.

Around them sits the tooling that keeps your platform documented, explainable, reviewed and safe to change. Here is each capability in detail.

04.1Core feature

Local development, built in

The whole platform runs on a laptop. Any engineer can clone the repo, run the stack and test it end to end with no accounts and no spend. This is a core part of how we build, and it is yours to use after we leave.

  • Identity, warehouse, reports, source APIs and the AI provider are emulated with small local servers, issuing real signed tokens so the real code paths run
  • Test tiers you can run on their own: fast unit tests, end-to-end against the emulated services, and an opt-in tier against a locally hosted model
  • A local model is just another provider, so the AI part can run fully offline
  • Configuration can point a client at an emulated service only for known hosts or loopback, so a credential can never be sent to an arbitrary address
  • Docker is optional; everything also runs without it
  • Infrastructure changes are planned and reviewed by a person before anything is applied to your cloud
  • Where something has only been exercised against emulation, we say so

Why it matters

Engineers, ours or yours, get a fast, safe loop. Surprises happen on a laptop, not in your production account.

04.2

Documentation that writes itself and stays true

Every column carries its description and where it came from: a source catalog, inherited from upstream, or written by a person.

  • A person's wording always beats a machine's; nothing is overwritten silently
  • Descriptions cascade downstream wherever lineage is exact; computed or multi-source columns are raised as questions, never guessed
  • A browsable explorer scoped to the columns people actually use, with direct edits
  • Descriptions sync into your reports as a reviewed pull request

Why it matters

Documentation stops being a project that rots and becomes a property of the code.

04.3

Full lineage and blast radius

Column-level lineage from source to report in one graph, joined to your tickets, plans and deployments.

  • Before a change, see exactly which models, reports and apps it touches
  • Tickets, plans and deployments are nodes in the same graph, so the reason for a change is one click away
  • Plain Markdown notes in your repo, so people and agents can edit them like any other file

Why it matters

You know who to warn before you ship, not after something breaks.

04.4

A production line for data work

Different kinds of work get different treatment, declared in one reviewed file.

  • A documentation fix needs no model time; a new mart runs assess, plan, implement; an access request goes straight to a person
  • Routing is deterministic, with no model involved
  • Every change passes the same automated gates: secrets, conventions, contracts, reconciliation, sensitive data and controls
  • The line stops for a human where a human belongs, and the process itself changes through reviewed diffs

Why it matters

Speed where it is safe, a person where it matters, and evidence the process is improving.

04.5

Point it at a source. Get the integration.

Point it at an API or at tables already in your warehouse. It probes and profiles the source automatically, then the engineer and the AI build the integration together while you steer.

  • Probing is read-only: structure and types are sampled; values are not kept
  • Auto-profiling finds fields, types and key candidates; uniqueness is verified when the catalog allows, and the brief says when a key was guessed by name
  • The brief marks each item new, already a source, or already modelled, with the reports that read it
  • From the brief the AI drafts the pipeline, tests, documentation and run order; you approve the plan and review the pull request
  • Outbound calls are restricted: no credentials in URLs, private ranges only by allow-list

Why it matters

A new source goes from "we should ingest that" to a reviewed pull request quickly, and you decide with the facts in front of you.

04.6

Bring your own AI

Your provider, your account, your key. Nothing is tied to one vendor.

  • Route different jobs to different models, or run a local one
  • Every request is capped and counted against a per-run budget
  • Usage is logged without storing prompts or replies
  • Keys are references to your secret store, never values in code
  • Switching provider is a configuration change

Why it matters

You control the cost, the data boundary and the vendor relationship.

04.7

An independent review agent, with separated concerns

Each pull request is reviewed by narrow reviewers that own certain files, carry only their own rules, and are told what is out of scope.

  • A data-model reviewer, an infrastructure and security reviewer, a report reviewer
  • Merging is decided by scanners, code owners and required checks, never by a model's comment
  • The bundle is generated into your repo for a person to adopt through a reviewed change

Why it matters

A second, independent pair of eyes on every change, without letting a model be the gatekeeper.

04.8

Guardrails you control

The controls that make a team comfortable letting an AI near their data: who can do what, how much it can spend, what can leave the building, and which optional capabilities are on.

  • Roles come from your identity provider's groups or roles, recorded at sign-in; leavers lose access when they leave the directory, and an account can also be disabled immediately
  • Per-role budgets and monthly allowances with per-person overrides, and a kill switch that pauses everything that spends tokens
  • Administrative changes (people, settings, secret writes) are audited with who, when and what, never secret values
  • Outbound calls go only to known hosts or loopback, with private ranges only by allow-list
  • The AI reads only declared repositories, writes only after an approved plan and only to allowed paths, and has no shell or network access
  • Optional capabilities (code review, report descriptions, the dictionary explorer, plain-language Ask, vendor AI integrations) are feature switches, off per deployment
  • Questions run as the person asking, so their data permissions apply

Why it matters

Adoption at the pace your organisation is comfortable with, with limits you can see and change.

Want this on your data?