Products
Data that carries its own governance
Publish a dataset once as a governed product. Consumers find it by meaning, reach it through one standard API, and every request is checked, logged and traced back to source.
Semantic discovery
Describe data by meaning, not by table name
A dataset nobody can find is not an asset. Every data product is described by a shared semantic model — the entities, the relationships and the definitions that give the data meaning across teams. Consumers search for the concept they need, such as a customer or a settlement, and reach the right product without knowing which system it physically lives in or what the columns were called.
Business entities
Data is organised around the concepts your business uses, so discovery matches how people actually ask questions.
Shared definitions
A single agreed definition for each term removes the arguments about whose number is correct.
Relationships
Links between entities are described explicitly, so related products surface together instead of in isolation.
Unified access
One REST API, whatever the source
A data product might sit on a warehouse, a transactional database, object storage or a SaaS system. Consumers should not have to care. Every product is reached through the same standard REST interface, with a consistent request and response shape, so an application written against one product works against the next without a new connector or a new dialect of query.
Source-agnostic
The same interface fronts a warehouse, a database, a bucket or an API, so the backing store can change without breaking consumers.
Consistent contracts
Each product exposes a stable schema and versioning, so integrations do not shatter when the data behind them evolves.
Policy at the edge
Row and column rules are applied at the API, so every consumer sees exactly what they are entitled to and nothing more.
Secure delivery
Reach data from private and air-gapped environments
Some data can never leave the perimeter, and some consumers sit inside networks with no route to the public internet. Data Products run where the data is allowed to live and serve consumers inside the same boundary. The governance, discovery and API surface are identical whether the deployment is multi-cloud, on-premise or fully disconnected.
In-region and on-premise
Keep data resident where regulation or policy requires while still publishing it as a governed product.
Air-gapped
Serve consumers inside fully disconnected networks with no dependency on outside services.
No functionality fork
The isolated deployment behaves exactly like the shared one, so nothing is lost by choosing stricter isolation.
AI-driven operations
Let AI run the routine data work
The maintenance around data products — classifying fields, suggesting joins, catching quality drift — is repetitive and never finished. AI handles the routine part so your engineers spend their time on the judgement calls.
Automatic classification
Fields are tagged by type and sensitivity as they arrive, so policies attach without a manual pass.
Suggested modelling
Likely relationships and joins are proposed from the data itself, giving your team a head start on the semantic model.
Drift detection
Changes in shape, volume or distribution are surfaced early, before a downstream consumer is affected.
No-code pipelines
Build the pipeline without writing the plumbing
Getting data into a product means ingestion, transformation and scheduling. The pipeline builder lets a data team assemble that flow visually — pick a source, shape the data, set a cadence — and produces a governed, observable pipeline rather than a script that only its author understands. Engineers can still drop to code where a step genuinely needs it.
Visual assembly
Compose ingestion and transformation steps on a canvas, with each step documented and re-runnable.
Scheduled or streaming
Run on a cadence or continuously, with backfill handled as a first-class operation.
Governed by default
Every pipeline inherits the platform's access rules and lineage, so nothing built this way sits outside governance.
Observability
Know the state of every product
A data product is only trustworthy if its health is visible. Freshness, volume and quality are tracked continuously, and consumers can see the state of what they depend on.
Freshness
See when each product last updated and whether it is keeping to its expected cadence.
Quality checks
Rules for completeness, ranges and uniqueness run on every load, with failures raised as alerts.
Volume and drift
Unexpected changes in row counts or distributions are flagged before they mislead a report.
Metadata and lineage
Trace any value back to where it came from
When a number looks wrong, the first question is where it came from. Every data product carries end-to-end lineage: the sources it draws on, the transformations applied, and the products downstream that depend on it. Metadata is managed alongside the data, so definitions, owners and sensitivity travel with the product rather than living in a spreadsheet.
End-to-end lineage
Follow a value from source system through every transformation to the products and reports that use it.
Ownership and definitions
Each product has a named owner and a clear definition, so questions have somewhere to go.
Impact analysis
Before a change, see everything downstream that depends on it, so nothing breaks by surprise.
Auditing and compliance
Built for the regulations you answer to
Access, masking and retention map onto the frameworks your auditors care about, with the evidence produced as a by-product of normal operation.
GDPR
- Purpose-bound access
- Enforced
- Field-level masking
- Yes
- Right to erasure support
- Yes
- Access logging
- Complete
- Data residency controls
- Yes
HIPAA
- Purpose-bound access
- Enforced
- Field-level masking
- Yes
- Right to erasure support
- Where applicable
- Access logging
- Complete
- Data residency controls
- Yes
CCPA
- Purpose-bound access
- Enforced
- Field-level masking
- Yes
- Right to erasure support
- Yes
- Access logging
- Complete
- Data residency controls
- Yes
Questions
Frequently asked
- Does publishing a data product mean copying the data?
- Not by default. A product can serve directly from the source through the unified API, so you avoid an extra copy unless you deliberately choose to materialise one for performance.
- How is access decided?
- By policy, at the API. Rules defined in the platform's policy engine determine which rows and columns each consumer sees, and the decision is logged with every request.
- Can non-engineers build products?
- Data teams can assemble pipelines and publish products through the no-code builder. Engineers can drop to code for any step that needs it, so neither group is blocked by the other.
- What does lineage actually capture?
- The sources a product draws on, every transformation applied along the way, and the downstream products and reports that consume it — enough to answer where any value came from and what a change would affect.
Publish your first governed product
Point us at a dataset your teams keep re-deriving and we will publish it as a governed product with discovery, access and lineage in place.