Components
Data Portrait
An optional layer on one Fact Base that measures the real data and writes down its business meaning, so everything built on it is better informed.
Written for
- Everyone
- Technical
Last reviewed
A Data Portrait sits on top of one Fact Base and answers two questions about it: what the data actually looks like today, and what it means to your organisation. It is optional, and each Fact Base can have at most one. When it exists, the Builder uses it to build better apps, queries and dashboards.
Note
In one sentence: a Data Portrait measures a Fact Base (the profile) and then describes it in business terms (the ontology), and you review and sign off both.
Why it matters
- Fewer wrong assumptions. The profile measures the data as it is, so a dashboard is not built on a column that turns out to be half empty.
- The definition gets corrected. Where the data and the description disagree, you accept the findings and the Fact Base definition is fixed.
- Shared business language. The ontology names your domain, concepts, lifecycles and metrics in one place people can read.
- Private by design. Profiling uses only aggregate measurements. It never reads individual rows.
Key concepts
| Term | What it means |
|---|---|
| Profile (Stage 2) | Measured facts about the live data: distributions, ranges, how often values are missing, how many distinct values, outliers. |
| Discrepancy | A place where the Fact Base definition and the measured data disagree. |
| Reconcile | Accepting discrepancies so the Fact Base definition is patched to match reality. |
| Ontology (Stage 3) | The business reading of the data: domain, concepts, lifecycles, metrics and assumptions. |
| Sign-off | Your review of the ontology. It creates the published version everything downstream trusts. |
| Built against | The Fact Base version a profile or ontology was produced from, so you can tell when it is out of date. |
How it works
- Fact Base. Start from a Fact Base that is provisioned and loaded. A profile of an empty schema has nothing to measure.
- Stage 2, Profile. A background job measures the data with aggregate queries only. It must cover every declared table before it can finish, so a partial profile is never saved. When it finishes you get a profile per table and a list of discrepancies.
- Reconcile. You accept the findings you agree with, and the Fact Base definition is patched. The live schema then needs a migration or a re-provision to catch up.
- Stage 3, Ontology. A second job synthesises the business meaning from the definition and the profile. It does not read data at all. You review it one lens at a time (Domain, Concepts, Lifecycles, Metrics and Assumptions) and sign it off.
- Richer context. The Builder reads the richest tier available: the definition alone, then the definition with the profile, then all three.
States
| Stage | Applied state |
|---|---|
| Profile finished | Profiled: a version is recorded |
| Ontology signed off | Published: the Portrait becomes trusted context |
Both stages run as background jobs you can watch and stop from the Profile and Ontology views.
Works with
- Fact Base: the dataset it describes. One Portrait per Fact Base at most.
- Builder: reads the Portrait tier when it plans apps, queries and dashboards.
- Template: a Template can carry Fact Bases with their Portraits, and a Template has its own Portrait workspace.
Governance and limits
| Area | What applies |
|---|---|
| Boundary | Owned by whichever Solution or Template owns its Fact Base. |
| Access | Anyone who may edit the owner may run and review it. |
| Versions | Each finished profile and each sign-off records a version, pinned to the Fact Base version it was built against. |
| Safety | Profiling reads aggregates only, never rows, and its queries are capped. The ontology stage has no data access. |
| Limits | Needs a provisioned and loaded Fact Base. A profile must cover every table before it is accepted. |