Platform · Data Products

Data Products.scaleData Products & Engineering Factory

This module owns the whole journey, not just the shop window. It discovers and maps the sources, generates the models and the transformations, migrates the layers, validates and reconciles at every one, then publishes the result as a product with an owner, a contract and a service level. Consumers get data they can rely on; producers get credit for keeping it that way.

The product, at a glance

What Data Products is made of.

6 capabilities, and the part of the mechanism this product carries. Every box opens right here, with its full story one tap deeper.

tap any box, or any circle in the mechanism, and it answers right herecontrol what changes

What changes

What changes when this is running.

Not promises of speed, but mechanisms: each of these happens because of how the product works, not because we say so.

Consumers stop discovering breakage in production, because contract status is checked continuously and shown live before they build on it.

Trust travels with the data, because certification is derived from live evidence and rides along wherever a product is consumed.

Investment debates get honest, because usage telemetry shows who consumes each product and where it actually lands.

The build stops being archaeology, because mapping, models and transformation code are generated from what the sources actually contain rather than from what a document says they do.

who lives herePlatform teamsDomains

The product

Build. Govern. Deliver. Trust at scale.

The end-to-end journey of building trusted data products, from legacy sources to production. An AI-powered factory that automates and governs the whole lifecycle, so regulatory and business outcomes arrive faster and with the evidence attached.

Trust and Scale

Business outcomes

Faster time to value

Lower cost of rework

Higher data quality

Stronger regulatory readiness

Trusted decisions and analytics

AI-ready data products

At a glance

An AI-powered data product factory that automates and governs the entire lifecycle, from finding the data to certifying what was built from it.

Discover

Find and profile data across all sources.

Map

AI-driven source-to-target mapping, with a confidence you can see.

Model

Generate canonical, logical and physical models.

Transform

Auto-generate and refactor transformations and code.

Migrate

Plan and execute layer-to-layer modernisation and migrations.

Validate

Built-in QA and QC, reconciliation and testing at every layer.

Certify

Steward approvals, controls and data product certification.

Publish

Deliver trusted products by marketplace, API, file and stream.

Trigger events

When an institution reaches for this.

A regulatory build that takes two quarters and cannot be traced back to the ruleMappings maintained in spreadsheets that nobody can reconcile to the codeA legacy platform nobody will touch because nothing documents what it doesReports that disagree because each was built from a different copyAn examiner asking which source a number came from, and how it was transformed

What it does

Ten stages from a source system nobody has documented to a certified product something else depends on.

01 · Discover and profileDiscover, profile and understand data assets and their quality.

Hover, click or use the arrow keys to walk the lifecycle.

The data transformation architecture

Five layers, and the discipline is what each one is forbidden to do. A business calculation does not happen in the landing zone. A raw feed does not reach a regulatory report. The layers exist to make shortcuts impossible rather than merely discouraged.

L0 · Source systemsBatch, CDC, streaming, APIs

Core banking
Deposits and loans
Securities and treasury
Collateral and payments
General ledger and finance
Reference data
External feeds
Files and APIs

Where the data starts, and the only layer nobody governs.

Every layer captures its own lineage, so a field in a regulatory report resolves back through the transformation, the conformed record and the raw landing to the source system it arrived from.

The golden thread of data trust

Every field in a report resolves back to the rule that required it. The colour says who does the work at each link, which is the part that matters: most of this is machine work, and you can see exactly where a person still signs.

01 · RegulationAI-assisted

The rule itself, ingested and versioned.

A chain is a conjunction. Take one link out and see what is left.

Automated
AI-assisted
Human approval

The thread runs forwards, and it also runs back: what quality and control observe in production feeds the policy and the concept, so the definition is corrected rather than merely disputed.

One regulatory report, end to end

A worked FR 2052a build, from reading the rule to answering the examiner. This is the journey the factory compresses, and every stage leaves the artefact the next one needs.

01 · Regulation interpretationAI-assisted

Read the rule and extract what it actually asks for.

A chain is a conjunction. Take one link out and see what is left.

Automated
AI-assisted
Human approval

Every field is traceable from regulation to obligation to concept to critical data element to source to transformation to report to evidence. That traceability is not a report you run afterwards; it is a by-product of having been built this way.

Key capabilities

Source discovery and profiling

Auto inventory
Profiling and statistics
Data quality assessment
Relationship discovery
Anomaly detection

Smart mapping workbench

Semantic matching
Field and datatype mapping
Code and value mapping
Mapping confidence
AI recommendations

Modelling studio

Conceptual modelling
Logical modelling
Canonical models
Dimensional and data vault
Physical model and DDL

Transformation studio

Visual mapping designer
SQL, dbt, Spark and Python
Reusable components
Rule and logic library
Version and lineage capture

Refactoring studio

Legacy code ingestion
Logic extraction
Duplicate detection
Optimisation
Auto-refactor and convert

Migration factory

Migration assessment
Dependency analysis
Cutover planning
Parallel run and validation
Rollback and recovery

QA, QC and reconciliation

Auto test generation
Data quality rules
Reconciliation rules
Balance and totals checks
Exception management

Certification workbench

Steward approvals
Control mapping
Evidence collection
Attestations
Certification status

Deployment and operations

CI/CD and orchestration
Scheduling and pipelines
Monitoring and alerts
Lineage at runtime
Rollback and versioning

Marketplace and access

Product catalog
APIs, SQL, files and streams
Contracts and SLAs
Usage analytics
Self-service access

AI and automation across every workbench

AI-powered, and every one of them a recommendation rather than a decision.

AI discovery

Smart mapping

Model generation

Code generation

Test generation

Anomaly detection

Reconciliation AI

Explain and recommend

Manual and AI-assisted

The same work, split. Everything on the left is something a person does; everything on the right is something the platform proposes, with evidence, for a person to accept. Nothing crosses the line on its own.

Manual

A person does this.

Interpret the regulation and set what is required
Own the concepts, the model and the definitions
Review and accept a proposed mapping
Approve a release and certify the product
Decide a cutover and accept the risk
Attest to the evidence

AI-assisted

The platform proposes. A person accepts.

Discover and profile sources, and find the relationships
Propose source-to-target mappings with a confidence score
Generate conceptual, logical and physical models
Generate and refactor transformation code
Generate tests and reconciliation rules
Detect anomalies and explain what changed

Common use cases

Where institutions start

Build and publish governed data products
Accelerate regulatory report builds, such as FR 2052a
Layer-to-layer modernisation, L1 to L2 to L3
Legacy system migrations and refactoring
AI-powered source-to-target mapping
Automated QA, QC and test generation
A centralised data product marketplace
Reducing manual mapping and engineering effort
Data product certification and audit readiness

End-to-end workflow

01Discover and profile
02Map
03Model
04Transform
05Migrate
06Validate
07Certify
08Deploy
09Publish
10Consume

What gets measured

Against your own baseline.

Data products certifiedMapping coverage and confidenceAutomated test coverageReconciliation break rateTime from source to certified productManual engineering effort avoidedRegulatory build cycle time

Who it is for

Data owners and stewardsData engineers and architectsETL and ELT developersAnalytics and BI teamsRisk, finance and regulatory teamsData governance and quality teamsPlatform and operations teams

Integrations

OntaVera CatalogOntaVera LineageOntaVera QualityOntaVera GovernanceOntaVera RegulatoryOntaVera Reference DataOntaVera Trust IntelligenceDatabricks, Snowflakedbt, Spark, AirflowInformatica, DataStageAWS, Azure, GCPKafka, ConfluentTableau, Power BI, LookerServiceNow, Jira

Built on the OntaVera platform

Shared by every product in the suite.

Financial ontology and knowledge graph

Metadata fabric and connectors

Policy and rules engine

Workflow and approvals

Security and evidence, immutable and encrypted

Audit and events: REST, GraphQL

AI and ML services, and GenAI copilots

Why OntaVera

AI-native automation for mapping, engineering and testing
End-to-end lineage and impact across all layers
Built-in quality, controls and reconciliation
Accelerates migrations and reduces manual effort substantially
Designed for enterprise scale, security and compliance

Build trusted data products.Faster. Smarter.From source to decisions.

Try it yourself

See Data Products do real work.

setting the stage…

Inside Data Products6 sub-modules

A data product is governed data with a name, an owner, and a certification status you can check. The registry holds every product your teams publish: what it contains, who stands behind it, and whether the evidence behind it is current. When an examiner asks who owns the data feeding a report, you answer from the registry entry and the sealed history behind it.

What you get

Every product carries a named owner, a steward, and a stated purpose, tied to the same governed knowledge graph the rest of the platform runs on.

Certification status is derived from live evidence, including contract health, lineage, and data quality, with no manual override to make it look better than it is.

Lineage runs from each product back through the systems that feed it, federated through the connector library without copying data out of your environment.

Records imported from an existing catalog land as claims, and they stay marked as claims until checks against evidence verify them.

Versioning and deprecation live in the registry, so consumers see when a product is retiring and what replaces it.

Filters cover domain, certification state, and regulatory scope, so you can pull every product carrying BCBS 239 CDEs in one view.

How it works

Federate

Connectors read metadata from your source systems and warehouses, and nothing copies out of your environment.

Publish

An owner names the product, binds it to governed datasets, and declares what it is for.

Derive

Certification computes from the product's evidence and updates itself when the evidence changes.

Seal

Every change to the entry, including ownership, status, and contents, lands on the hash-chained ledger.

Questions buyers ask

Asked about Data Products

5 questions

A catalog tells you what exists. A data product carries a commitment: a named owner, a contract that is checked continuously, and a certification status derived from live evidence instead of typed into a field. Entries imported from your existing catalog land as claims, and they stay marked as claims until checks against evidence verify them.

See the product registry →

Connectors read metadata from your warehouses and source systems, and the data itself stays where it lives. Nothing copies out of your environment, so standing this up is a connector conversation, not a migration project. The deployment model, including how metadata is held under your keys and air-gapped support, is laid out on the architecture page.

How deployment works →

The people who already own the data operate it. A producer publishes the product, declares its contract, and works the issues that open when checks fail, while agents assemble drafts and evidence packs to keep the manual load small. The platform does the continuous checking, so a central team is not a precondition for starting.

An examiner gets a sealed trail. Every publication decision, access grant, contract revision, and certification change lands on the hash-chained ledger, so questions like who approved this feed or how this product got certified become lookups instead of reconstruction exercises. For BCBS 239 work, you can pull every product carrying BCBS 239 critical data elements with its live certification state in one view.

Agents do the assembly work: they draft product entries, propose contracts, build evidence packs, and flag unusual consumption to owners. They do not certify products, approve access, or close issues, because certification is derived from the checks, approvals run under maker-checker, and a failed check clears only when the evidence passes again. The agents shorten the work, and the decisions stay human.

The publishing workflow →

Stronger together

One shared record, so products compound.

Every product you add makes this one smarter, because they read and write the same governed record. Start where it hurts most; nothing you adopt later starts from zero.

Data Products + Quality

Add quality and product contracts are enforced by continuous checks instead of producer promises.

Data Products + Catalog

Add the catalog and consumers discover products by business meaning, with trust signals in the results.

Getting started

Start small, and prove it on your own systems.

Most banks start with one priority report and five source systems, live in 90 days, then bring in more of the platform behind exit gates they approve. Data Products is part of that first conversation.

Keep exploring

← Regulatoryavailable now AI Governance →available now The engines underneatharchitecture How decisions workframework

The next step

Start with proof, not a promise.

There are three ways in, and each one earns the next. You approve the exit criteria before we spend any more of your time or budget.

A 60-minute working session

Bring one report that is expensive to prove. We walk the mechanism against it. Nothing is required from your side.

A two-week guided sandbox

Your team works hands-on against a synthetic sample bank. It requires zero access to your systems and zero procurement.

A six-week proof on your systems

We use read-only metadata across five systems and one priority report, scored against criteria both sides sign first. The decision it produces is yours.

Book a working session See the adoption path