Skip to content
Platform · Catalog

Data dictionary & reference data

Column definitions, formats, and permitted values are kept current from the sources themselves. Reference data lives here too, including code lists, product hierarchies, and GL mappings, held as governed assets with owners, versions, and a sealed change history. Banks care because reporting breaks quietly when two teams run on two versions of the same code list.

What you get01 / 03
01

The column-level dictionary is built from scans, covering type, format, nullability, and observed values, and it refreshes on every rescan.

02

Stewards write business definitions and permitted-value lists, and each one is held as a claim that scans confirm or contest against the actual data.

03

Drift is flagged for review: a new code in a source list or a changed column shape raises a difference instead of silently updating the record.

04

Reference lists are governed with a named owner, explicit versions, and maker-checker on every change.

05

Everything stays federated in place: OntaVera points at your reference sources and never becomes another copy you have to reconcile.

06

The full change history is sealed on the ledger, so you can show which version of a hierarchy was in force on any reporting date.

How it works02 / 03
1

Scan

Connectors read structure and value profiles from source, working with metadata only and retaining nothing.

2

Define

Stewards add definitions and permitted values, each landing as a claim.

3

Check

Rescans test claims against reality and flag mismatches for review.

4

Govern

Reference data changes move through maker-checker and are sealed on the ledger.

Questions it answers03 / 03

“What are the valid values for this field, and who says so?”

The dictionary holds the steward-written permitted values alongside the values actually observed in scans, so you see both the rule and the reality. Each definition is a claim with a named steward behind it, and any mismatch is flagged for review.

“When did the product hierarchy last change, and who approved it?”

Every reference data change moves through maker-checker and is sealed on the ledger with explicit versions. You can show which version of the hierarchy was in force on any reporting date and who approved each change.

“Is this definition still true of the data as it exists today?”

Rescans continuously test each definition as a claim against the actual data. If a new code appears or a column's shape changes, the difference is raised for review rather than left to diverge quietly.

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.

01

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.

02

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.

03

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.