// architecture

Everything runs inside your boundary.

Sprinkle is installed in your cloud account or data centre and operated by your team. Your warehouse holds the data, your data team defines who sees what, and the LLM you have approved does the thinking.

// 01 — where the data lives

In your warehouse. Sprinkle keeps no copy.

Ingestion lands data in your warehouse. Sprinkle then pushes SQL down to it and reads results back — it does not maintain a parallel store of your data.

This is the property that makes the rest of the page possible. There is no extract to secure, no second copy to reconcile, and no migration off the infrastructure you have already had audited.

// what Sprinkle holds
  • Your Domain Model — metrics, entities, joins
  • Access rules and roles
  • Dashboard and pipeline configuration
  • Audit logs
// what Sprinkle does not hold
  • A copy of your tables
  • Extracts or exports at rest
  • Anything outside your boundary
// 02 — where control lives

Access rules are defined in Sprinkle, by your team.

Warehouse permissions are coarse — schema and table grants, managed by engineers. Business-level control lives in Sprinkle: your data team decides who sees what, without a warehouse change or an engineering ticket.

  • Roles — who can see which datasets, dashboards and pipelines
  • Row-level rules — a branch head sees their branch; a tenant sees only their own data
  • Applied everywhere — the same rule gates dashboards, exports, embedded views and every Analyst Agent answer
  • Audit log — who ran what, against which data, when
  • SSO / SAML — identity from the provider you already run
// 03 — where trust comes from

One Domain Model. SQL behind every answer.

Every answer comes from your Domain Model — the AI's map of your business: every metric defined once, every entity and join, every access rule. Each metric — GNPA, contribution margin, net revenue retention — is defined once with its joins, filters and logic (what data teams call a semantic layer), and every dashboard and every AI answer inherits that definition.

When the Analyst Agent answers a question, it shows the SQL it ran. Risk, finance and audit teams verify the number instead of trusting it, and lineage traces each metric back to its source tables.

// 04 — why not just a model and a database

The LLM is replaceable. Your Domain Model isn't.

An LLM with a database connection is a demo, not a deployment. It doesn't know that "active customer" means status = active and ordered in the last 90 days. It connects as whoever's credentials you gave it. It answers the same question differently on Tuesday than on Monday. And it leaves no trail.

Four things go missing without a Domain Model between the model and the data — and each one is a thing your team would otherwise build and own forever:

// consistency
  • The same question gets the same answer for everyone — one definition, not one SQL query per ask
// scope
  • A branch head sees their branch. Row-level rules apply to the AI exactly as they do to dashboards
// audit
  • Every answer shows its SQL and is logged — verifiable by risk and finance, not taken on trust
// portability
  • Swap the LLM, or the warehouse. The definitions, joins and rules stay — they're yours, not a vendor's

The LLM and the warehouse can be swapped. The Domain Model is what makes it safe to give the AI to everyone — and the agent builds the first draft from your warehouse, so it isn't a modelling project before it's useful.

// 05 — where intelligence runs

Bring your own LLM.

The Analyst Agent calls the model your organisation has approved — hosted in your cloud account or self-hosted on your infrastructure. Nothing goes to a model vendor you have not chosen.

// what the model receives
  • The question being asked
  • Domain Model context — metric definitions, entities, joins
  • Aggregated results needed to explain the answer
// what the model does not receive
  • Bulk raw tables
  • Data outside the asker's row-level scope
  • Anything that leaves your boundary

This is also what lets the agentic story and the residency story coexist: the AI investigates your data without your data going anywhere.

// 06 — deployment

Your cloud account or your data centre.

Sprinkle is installed in your environment and operated by your team, with our support through installation and beyond. Infrastructure costs stay with your provider; the licence covers the software.

  • Where — AWS, Azure or GCP account you own, or on-premises servers
  • Who operates it — your team, with Sprinkle support and upgrades
  • What crosses the boundary — a browser session over HTTPS. Nothing else.
  • Prerequisites — a warehouse, compute to run Sprinkle, and an approved LLM endpoint for the agent
// 07 — security practices

Plain controls, no adjectives.

Because Sprinkle runs inside your boundary, most of your existing security posture applies unchanged. What Sprinkle adds:

Encryption in transit (TLS)Encryption at restSSO / SAMLRBACRow-level securityAudit trailSecrets held in your environmentNetwork isolation in your VPC

We will walk your security team through this architecture, answer your questionnaire, and show the data flow live.

Book an architecture walkthrough