Skip to content
Architecture

Built to pass your security review.

This page shows what runs where, what crosses the boundary, and what never leaves. It answers the questions your architects and your CISO will ask, before they ask them.

The operating model

The whole platform on one screen.

Solutions on top, ten products beneath them, the semantic plane they all share, and your estate at the base, with the control plane running through everything. Click around: this is how the pieces actually fit.

What institutions buy it for · click one
Ten products · one record · click one
The semantic control plane · every product reads and writes it
Shared services · not sold separately
metadata fabricconnector frameworkpolicy & rulesworkflow & casesissues & remediationidentity & dutiesclassificationaudit & versioningAI runtimesearch & queryAPIs & eventsmonitoring
Your estate · connected once, never copied
core banking & paymentsfinance & ledgerrisk & capitaltreasury & liquiditycustomer & CRMregulatory reportingwarehouses & lakesETL & orchestrationBI & reportingmainframe & schedulersdocuments & policiesthird-party data

This is the whole platform on one screen. Click a solution to see which products serve it, a product to see what is inside it and what it trades with the record, or a plane layer to see what it holds.

The core01 / 06

One graph under everything.

Systems, datasets, columns, business terms, rules, controls, owners, and reports live in one connected record, updated continuously as your systems change. Ask any number where it came from, and the answer traces back through this graph.

Three semantic layers
Industry ontologyversioned regulatory packs: BCBS 239 and liquidity reporting today, more arriving
Your institution's ontologyyour terms, your hierarchies, your report structures
Operational graphthe live picture: what exists, what feeds what, what changed
Go deeper: ontology & knowledge graph →
One shared record02 / 06

Every product writes here, and every product reads it back.

Every product writes to this plane and reads from it. Pick a layer to see what it holds, then trace the loop: contributions flow in as labeled assertions, and the graph hands back obligations, contracts, context, and derived trust.

every product contributes
assets & metadata
CDEs & decisions
flows & transformations
rules & run results
classifications & purposes

Business knowledge graph · Meaning as facts. Every binding is a labeled assertion with provenance and a validation state, and conflicting claims coexist with their history. The graph is a rebuildable projection; the authoritative record is the assertion log plus sealed decisions.

the graph enriches every product
obligations → controls → evidence
contracts, SLOs & usage
governed context for models & agents
golden records & hierarchies
trust scores, decomposed

one record, ten lenses · nothing copied, everything traceable

TWO WAYS IN, ONE TRUTH, MANY VIEWS

machines contribute claims, people make decisions, and only the sealed record is ever the truth

One consequence worth naming: the graph you query is a projection. The record is the append-only assertion log and the sealed decisions behind it, and every projection, graph, search, or score, can be rebuilt from that record, provably identical.

The engines03 / 06

Nine engines do the work.

The ten products are what your teams see. These are the engines underneath them. Here is what each one does and what it hands the rest of the platform.

01

Knowledge graph

It holds every system, dataset, column, term, rule, control, owner, and report as one connected, continuously updated record.

→ the single record every product reads and writes

02

Connectors & sync

It ships connectors for warehouses, databases, ETL, BI, files, and streams, push and pull, incremental and event-driven. There are no per-connector fees, so coverage is an engineering decision, not a budget one.

→ fresh metadata from your systems, on schedule or on event

03

Lineage parser

It reads your actual SQL, ETL, and BI code, reconstructs column-level lineage, and reconciles it against what teams declared.

→ impact and blast-radius answers in seconds

04

Rule & quality engine

It profiles data, runs rules, and checks freshness, volume, schema, and drift. Everything executes inside your systems, and only pass/fail counts come back.

→ quality results and SLO breaches, caught upstream

05

Anomaly detection

It watches the numbers between rule runs and flags breaks nobody wrote a rule for, before a report consumes them.

→ early warnings with the evidence attached

06

Policy & workflow engine

It handles approvals, attestations, maker-checker, separation of duties, and RBAC/ABAC. These are the controls your audit team already expects, enforced in software.

→ governed change with the sign-off trail built in

07

Evidence ledger

It seals every governed decision onto a hash-chained, append-only ledger. If it can't seal, it refuses the write.

→ exam-ready evidence packs and point-in-time reconstruction

08

Trust derivation

It recomputes certification and regulatory posture from live evidence every time someone looks. Nobody can hand-set a badge.

→ trust states you can defend in front of an examiner

09

AI & agent runtime

It runs retrieval and agents with confidence scores and human checkpoints. Every AI action is logged, attributed, and reversible. AI cannot approve.

→ drafts and rankings for humans to decide on

The stackread it top down

People on top, one platform beneath.

Read it the way the platform runs: the people it serves, the ten products they use, and the shared services every product stands on. Click one to open it, and see the full seven-layer stack on the home page.

built for
ExecutivesData ownersData stewardsData engineersRisk & compliancePrivacy officersAnalystsAI & ML teams

Financial-industry ontology packs, led by BCBS 239 with Basel, LCR, IFRS, GAAP, SOX, and CCAR arriving, sit beneath your institution's ontology and an operational knowledge graph reconciled on every governed write.

Financial ontology packs, BCBS 239 first
The governed knowledge graph
Metadata fabric, technical through process
Semantic reasoning over one record
one platform · every product reads and writes the same governed graph · your data stays where it lives
How they work together04 / 06

From observation to proof, in five steps.

Every engine feeds the same loop. This is the path a governed change takes from first observation to evidence an examiner can verify.

Observe. Connectors parse code, profile datasets, and run checks where your data lives. Metadata flows up; rows never leave your systems.

The trust boundary05 / 06

Your rows never leave.

Your rows never leaving is architecture, not a promise in a contract clause. Watch what crosses the boundary, and flip the deployment toggle to see the whole platform move inside your perimeter.

The trust boundary · what crosses, what never does
YOUR PERIMETERcore bankingtreasury ledgerwarehouse & ETLBI & reportsRULES EXECUTE IN HEREmetadata · results · pass/failflows uprows never crossONTAVERA PLATFORMgovernedgraphenginespolicy & workflowsealed ledgerevidenceexam-ready

As managed SaaS, only metadata, results, and pass/fail counts cross the boundary, encrypted and held under your keys; your rows never do. Flip the toggle to see the other deployment.

Metadata flows up
schemas, lineage, results, decisions. Rows stay in your systems.
Pushdown execution
quality rules run inside your databases; only pass/fail counts return
Samples off by default
when enabled, masked in the connector before anything moves
Your keys
BYOK with a customer-held crypto kill switch
No phone-home
signed images, published bill of materials, no telemetry callbacks
Audit everything
full access and action trail, exportable to your SIEM
Deployment06 / 06

Same product on either side of your perimeter.

Managed SaaS
metadata only · your rows never leave · your region · your keys
Your VPC
the full product inside your own cloud tenancy
On-premises
air-gapped supported · no phone-home

Single sign-on and directory sync · security questionnaires returned in five business days · exit terms in the contract: your graph, rules, and evidence export in open formats, with 90 days of transition help.

Where our certifications stand.

SOC 2 Type II and ISO 27001 are in progress, not claimed. Available today under NDA, before any engagement: our latest penetration test summary, a shared responsibility matrix, our subprocessor list, and the connector access and egress model. Security questionnaires are answered within five business days.

How the seal works: every decision is hashed and chained to the one before it. Checkpoints are exportable to anchors you hold, so the chain verifies against a reference outside our control, and verification runs offline against the exported pack with no access to us. No role, ours or yours, can rewrite sealed history; a correction is a new sealed decision that points at the old one. And because the graph and every index are projections of that record, any of them can be burned down and rebuilt from it, provably identical: losing a view never loses the truth.

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.