Skip to content
Platform · Lineage

Reconciliation to source

Your BCBS 239 documentation says data moves one way, and the code may say another. OntaVera treats declared lineage as a claim, checks each claim against the lineage parsed from production code, and flags every difference for a human to resolve.

What you get01 / 03
01

You can import declared lineage from spreadsheets, prior program documentation, or an earlier tool, and it lands as claims rather than as established truth.

02

Every claimed edge is matched against parsed lineage, and a confirmed match carries the evidence that confirmed it.

03

Differences flag in both directions: declared edges the code does not support, and real flows that were never declared.

04

Each discrepancy opens as a tracked issue with an owner, and closure is verified against fresh evidence, so a failed reconciliation can never simply be marked closed.

05

Results seal to the hash-chained ledger, giving your second line and examiners a defensible record of what matched and what did not.

06

The comparison re-runs on every scan, so drift between documentation and code surfaces as it happens rather than at the next exam.

How it works02 / 03
1

Import

Declared lineage loads onto the graph as claims, and it is checked against evidence from the start.

2

Compare

Each claim is matched against the parsed, evidence-backed edges.

3

Flag

Unsupported claims and undeclared flows open as issues with named owners.

4

Verify closure

An issue closes only when fresh evidence shows the difference is resolved.

Questions it answers03 / 03

“Does our documented lineage match what the code actually does?”

OntaVera answers that continuously. Declared lineage loads as claims, each claim is matched against lineage parsed from production code, and differences flag in both directions: declared edges the code does not support, and real flows that were never declared.

“How do I know these discrepancies were really fixed and not just marked closed?”

Closure is verified against fresh evidence. Each discrepancy opens as a tracked issue with a named owner, and it closes only when a new scan shows the difference is actually resolved.

“How much of the lineage documentation we inherited from earlier programs still holds?”

Import it and find out. It lands on the graph as claims, every claimed edge is matched against parsed lineage, and the results seal to the hash-chained ledger so you have a defensible record of what matched and what did not.

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.