Skip to main content

The CryspIQ® Data Model

Most data platforms store a source record roughly as it arrived, then add meaning on top with a semantic layer or a catalogue. CryspIQ® does the opposite. It takes the record apart on the way in, stores each element in a structure chosen for what that element is, and attaches the business meaning at that point.

This page describes that model: the dimensions, the seven typed fact stores, the fact type that carries the definition, and the link key that puts a record back together.

It is the CryspIQ® methodology made concrete — the part covered by the patent.

Is a fixed model a limitation?

The structure below is the same in every deployment, which reasonably prompts the question. The short answer is that the structure is fixed while the content — every fact type, entity and business definition — is entirely open, so the model is fixed where businesses are the same and open where they differ. The long answer, including what it genuinely costs you, is on the methodology page: is a fixed model a limitation?

Why decompose at all​

A source record carries two things: the facts of what happened, and the shape the application chose to record them in.

The second is the problem. Field names, table layouts and conventions belong to the system that produced them, and they change when that system changes or is replaced. Store records in that shape and every downstream report, pipeline and model inherits a dependency on an application's design decisions.

Decomposition separates the two. Transactional decomposition breaks a record into its individual elements, disassociating each from the structure and the source system it arrived with. Data of like type from every input then clusters into the same store — so the underlying structures stay static as sources come and go.

That is what makes the result an asset rather than a copy: it does not depend on the applications that fed it.

The two halves of the model​

Every piece of data lands in one of two places.

Dimensions describe the things your business is about — the master data. They answer who, what and where.

DimensionHolds
EntityA party. Every customer, supplier, worker or counterparty
ProductThings sold or produced
ServiceServices delivered
AssetEquipment, vehicles, plant
AccountFinancial or customer accounts
LocationSites, branches, addresses, regions

Each has a matching …Type dimension — EntityType, AssetType, LocationType, AccountType — that classifies its members.

Facts record what happened, as measurements and occurrences against those dimensions. They answer when, why and how much.

Everyone you deal with is an Entity​

Entity deserves particular attention, because it is where most of the value sits and it is not structured the way people expect.

There is no separate customer table, supplier table or employee table. A customer, a supplier and a worker are all Entities — the same kind of thing, distinguished by their EntityType. That is what makes a single instance of a party possible: an organisation that is both a customer and a supplier is one Entity, not two records in two tables that someone later has to match up.

An Entity then carries whichever detail suits what it is:

Attached to EntityHolds
PersonName, date of birth, identity documents — for an Entity that is an individual
CompanyRegistration number, trading name, tax code, GST registration — for an Entity that is an organisation

So a supplier company is an Entity, with its corporate detail in Company. A contractor is an Entity, with their personal detail in Person. The party and its attributes are separated, so the relationship between parties and everything that happens to them does not change depending on which kind of party it is.

Parties relate to each other, and those relationships have dates​

An employee works for a company. A contact acts for a supplier. A subsidiary belongs to a parent. These are relationships between two Entities, and CryspIQ® holds them in their own structure rather than as a field on either party.

Each relationship records a parent, a child, what kind of relationship it is, and — critically — the period it was true for.

That last part is what keeps a single instance of a person intact over time.

When someone changes employer, nothing about them is duplicated. Their existing relationship is closed with an end date and a new one opens against the new company. They remain one Entity, with one identity and one history, whose employment simply moved. The alternative — a person record per employer — is how organisations end up unable to answer whether the person they are dealing with now is the same one they dealt with three years ago.

The same structure covers supplier contacts. The individual you deal with at a supplier is an Entity in their own right, related to the supplier company for the period they held that role. When they move on, the relationship closes; when they turn up at a different supplier, a new relationship opens against the same person.

Two things follow that are hard to get any other way.

History follows the party, not the association. Everything recorded against that person stays attached to them across every role they have held, because the party never changed.

A relationship that has ended is still true of the past. Because relationships carry dates rather than being deleted, "who worked for us in 2024" and "who works for us now" are both answerable from the same data — one is not destroyed to answer the other.

It also means a question has to be specific about when. "Who works for this supplier" and "who has ever worked for this supplier" are different questions with different answers, and the model can tell them apart.

The seven fact stores​

An element goes to the store that matches what the element is, not where it came from.

Fact storeHolds
ReferenceAn identifier or code — an invoice number, an order reference, a registration
MonetaryMoney
QuantitativeA count or measure, with its unit
PercentileA rate, ratio or percentage
EventThat something happened
GISA position
UnstructuredA document, image or file

Two of these are worth dwelling on, because they are where the design shows.

An event has nothing to measure. The occurrence is the fact. A delivery arriving, a shift starting, a door opening — these have a subject, a time and a type, and no value. Forcing one onto them would invent data.

A document is referenced, not copied. The file stays where it lives; the model records that it exists, what it relates to and what kind of thing it is. That keeps the analytical footprint small — you are not paying to hold a copy of every PDF in a warehouse in order to know a contract exists.

What every fact carries​

Whatever its type, each fact row holds the same frame:

  • when it happened
  • what it means — its fact type (see below)
  • which organisation owns it (see below)
  • optional links to each dimension — the party, product, service, asset, location or account it concerns
  • which source record it came from (see below)

The dimension links are nullable on purpose. A fact links to the dimensions that are relevant to it and leaves the rest empty. A payment has an Entity and an Account but no Asset; a vehicle reading has an Asset and a Location but no Account. One structure serves both without a column being wasted or a fact being forced into a shape it does not fit.

The company link is the exception: it is always required. Every fact is stamped with the organisation that owns it, so a group can run several companies in one model and still report on each separately, on any combination, or on all of them — without physically separating the data or maintaining a model per company. It is also what makes the acquisition case work: the business you acquire becomes another owning company in the same model rather than a second system to consolidate later.

The fact type carries the definition​

Every fact points at a fact type, also known as its mapping type. This is the most important relationship in the model, and it is easy to mistake for a simple lookup.

The fact type holds the definition of what that data means for the entire business. Not what the source application called it. Not what one report assumes. Alongside the definition it carries:

  • a description — the business meaning, in business language
  • a security classification — how sensitive this kind of data is
  • effective dates — the period the definition is valid for, so definitions are versioned rather than silently rewritten
  • the originating system, for provenance

Three consequences follow, and they are the reason the model works.

Meaning is established once, not per report. Every consumer of a fact reads the same definition. There is no second place for a competing one to live.

Data from different systems converges. Two facts pointing at the same fact type mean the same thing even when they arrived from different applications. An invoice amount from Xero and an invoice amount from Pronto are both monetary values pointing at the same definition — so reporting across them needs no reconciliation step, because there is nothing to reconcile.

Sensitivity travels with the data. Because the classification is attached to the type rather than to a system or a reporting tool, it cannot be lost in transit. A field does not become less sensitive because someone reached it through a different application.

Decomposition raises an obvious question: if one invoice becomes three rows in three tables, how do you get the invoice back?

Every fact carries a link key, and facts decomposed from the same source record share its value.

Take an invoice arriving from an accounting system. The invoice number is an identifier, the amount is money, the line quantity is a measure — three different kinds of thing, so three different stores. The customer and the product are master data, so they resolve to existing dimensions. The date is carried on each fact.

Several rows across several tables, sharing one link key. The invoice can be reassembled whenever it is needed, without ever having been stored in the shape the accounting system used.

The link key does a second job that matters just as much: it is the link back to the originating source record. Any figure in any report can be traced to the row in the source system that produced it. Lineage is a property of the model rather than a separate capability someone has to build and maintain alongside it.

What this buys you​

The model's properties follow directly from the structure rather than from process or discipline.

A single instance of master data is enforced, not agreed. A customer is defined once because the structure provides exactly one place for one. Conventional master data management produces a golden record by agreement and then relies on discipline to hold it; discipline decays and exceptions accumulate. A constraint does not.

And it survives change. Because parties relate to each other through dated relationships rather than by being copied into each other's records, a person moving employer, a supplier being acquired or a company restructuring does not fragment the party. The relationships change; the parties do not.

New sources do not require new models. Because only specific elements are recorded rather than whole records, and because those elements cluster by type, the underlying structures stay static as systems are added.

Replacing an application does not break history. Nothing was stored in that application's shape, so its removal does not orphan the past — which also means AI models trained on that history do not face a discontinuity at the switchover and do not need retraining.

Storage stays small. Recording only the elements that matter, and pointing at documents rather than copying them, is where the reduction in storage and compute comes from.