It understands · Knowledge Graph
Knowledge graph and data lineage, discovered automatically
Every relationship, discovered
Behind every warehouse there is a web of relationships: which tables share a customer, which report depends on which column, which metric rolls up from which fact. Veracy discovers that web from the data and keeps it live, so lineage and impact are answers, not projects.
Today
Lineage is reconstructed after the fact, usually by reading code, and it is out of date the moment it is drawn. Impact analysis is a Slack thread: "does anyone know what uses this column?" Changes are made carefully, slowly, and still break things.
What Veracy does
- 01
Relationships are discovered from keys, values and usage during profiling, then confirmed and named in the contract.
- 02
Every generated artefact — layer, table, column, rule, metric — is linked to what it was built from, giving end-to-end lineage as a by-product of the build.
- 03
Before a change is applied, the graph is walked: what depends on this, what would break, who owns it. The answer arrives before the change, not after.
What you get
Lineage that is always true
recorded by the engine that built the thing, in W3C PROV terms, not documented by hand afterwards.
Impact before the change
a proposed schema or contract change comes with its blast radius attached.
Context for people and agents
the same graph that powers impact analysis powers plain-language questions and the semantic layer.
Questions
- Is the lineage column-level?
- Yes. Because every artefact is generated from the contract, Veracy knows which source column feeds which warehouse column, which metric, and which report — without parsing SQL after the fact.
- How are relationships discovered?
- From declared keys where they exist, and from value overlap and usage patterns where they do not. Discovered relationships are proposed in the contract for a person to confirm, never assumed silently.
- Can I see what breaks before I change something?
- That is the point of the graph. A change proposal is evaluated against everything downstream — tables, rules, metrics, dashboards, agents — and the affected owners are named before anything is applied.
In the same job · it understands
Stop building your data platform. Just sign what matters.