Library · Data Practice OS
From data to decisions
Reference guide · Published · Source reviewed
The purpose of the practice is to be the backbone of knowledge and decisions for your organisation. The data platform, pipelines and AI are the engine. What the business needs from that engine is decisions it can make faster, explain later and improve over time: can this licence be renewed?, which defects are fixed first?, does this heavy-vehicle route need a permit?
A dashboard, a model or a chatbot is useful only when it supports one of those decisions. So the practice starts from the decision and works back to the data, a discipline often called Decision intelligence. This page sets out the seven layers every decision stands on, what the practice already covers at each one, and the gaps that are new work.
Status. This framing is a proposed practice, agreed as the direction for this guide. It is not an agreed decision, and it changes no ADR.
The stack
Each layer answers one question. None is a product. A layer can be a table, a document set, a decision table or a person with a delegation, as long as it answers its question reliably.
| # | Layer | The question it answers | Already covered | Gaps (new work) |
|---|---|---|---|---|
| 1 | Facts | What is true now, and what was true then? | Medallion layers and modelling, Data contracts, Data quality and observability, Effective dating | Point-in-time ("as known at") views on every product that feeds a decision |
| 2 | Meaning | What do these words and identifiers mean, and is this the same thing? | The semantic layer, Catalog, Master data management | Shared vocabularies and entity resolution across systems (Ontology, vocabularies and entity resolution); a graph only where it earns it (When a knowledge graph earns its place) |
| 3 | Knowledge | What do policy, legislation and procedure say, in which version, from which source? | RAG and enterprise search | Knowledge sources with an owner, version, effective date and applicability, not just an index of documents |
| 4 | Rules | What logic is approved, and which version applied on the day? | Extracting business rules, Where business rules run after migration, Rule authority | Decision models and tables as projections of the rule of record (Decision modelling with DMN) |
| 5 | Context assembly | What does this decision need, under this user's permissions? | Agents and MCP, Identity propagation, AI readiness assessment (context sufficiency gate) | A per-decision context specification (Context engineering for decisions) |
| 6 | Decision and action | Who may decide, with what review, and is AI reading, recommending, approving or executing? | Governance, security and trust, Human in the loop, AI-permission record | A Decision inventory with authority and AI fit (Decision inventory) |
| 7 | Outcome and learning | What happened, was the decision right, and what changes? | Evaluating AI systems | Decision records (Decision records and provenance, Decision record schema) and outcome capture (Outcome feedback loops) |
Across every layer: governance and classification (Governance, security and trust), identity (Identity propagation), evaluation (Evaluating AI systems), lifecycle and re-scoring (AI readiness assessment), and cost (FinOps).
The full set of new pages is the Knowledge and decisions handbook.
Three principles
1. A knowledge graph is a technique, not the centre
Use a Knowledge graph where relationships are the point of the question: legislation that cross-references other legislation, vehicle make and model lineage, a road network where a closure here diverts traffic there. Most decisions do not need one. A maintained glossary, a Semantic layer and a decision table answer most questions with less to build and run. The readiness assessment already says this: a graph database is not a prerequisite. See When a knowledge graph earns its place for when it earns its place.
2. Decisions are data too
The organisation keeps careful records of vehicles, licences and assets, and few records of the decisions made about them. Two artefacts fix that:
- A Decision inventory: the important decisions, each with an owner, volume, consequence of error, authority and the data, knowledge and rules it needs. It is how you choose what to build (Decision inventory).
- A Decision record for each decision made with system support: the facts used, the rule version, the context sources, the authority, the reviewer and, later, the outcome (Decision record schema). It is Decision provenance made concrete, and it is what an appeal, an audit or an evaluation set needs.
3. Controls live at the source, not only in the app
Permissions, masking, effective dates and rule approval belong in the governed layers: the catalog, the policy-as-code and the rule of record. An assistant, an agent or a report then inherits them. If a control exists only in the application, the next application will not have it, and the agent that calls the data directly will skip it. This is the reference architecture's fifth principle, "AI reads the same governed interfaces as people", applied to decisions.
Worked example: "Which road defects are fixed first?"
Illustrative. Written to show the layers. It is not an assessed use case, and the sources and rules named are placeholders to confirm with the maintenance business.
A district works planner sees a ranked list of open road defects and approves the next fortnight's work. An assistant recommends the ranking; the planner approves; the work management system executes by issuing work orders. The AI never issues a work order.
| Layer | What this decision needs |
|---|---|
| Facts | Open defects with location, type, size and report date; asset condition and inspection history; traffic volume; crash history near the defect, all as at the planning date |
| Meaning | One road and chainage identifier across the defect, asset and crash systems; a defect-type vocabulary; duplicate public and inspector reports resolved to one defect (Entity resolution) |
| Knowledge | The maintenance standard that sets intervention levels and response times, with its version and owner |
| Rules | The risk-rating matrix (likelihood x consequence → priority and response time) as an approved, effective-dated decision table (Decision modelling with DMN) |
| Context assembly | Only this planner's district; crash records summarised, without personal details of the people involved |
| Decision and action | The planner approves within their delegation. Overriding the ranking needs a reason code. Budget above the district limit goes to the regional manager |
| Outcome and learning | A decision record per approved programme; the repair date and whether the defect recurred within six months; overrides and recurrences feed the evaluation set and the annual review of the matrix (Outcome feedback loops) |
None of these layers needs a new platform. Most need ownership: someone who maintains the vocabulary, the matrix and the reason codes. For a decision about a person, see the licence renewal example in AI readiness assessment.
How the reference architecture serves the stack
The Target reference architecture describes how the engine is built. The stack describes what it is for. Each decision layer draws on these architecture layers:
| Decision layer | Architecture layers |
|---|---|
| 1 Facts | 1 Ingest, 2 Store, 3 Process, 4 Model and transform |
| 2 Meaning | 5 Semantic, with the catalog in 8 |
| 3 Knowledge | 1 Ingest (documents), 7 AI (search and retrieval) |
| 4 Rules | 4 Model and transform (effective-dated parameters), plus a rule repository outside the platform |
| 5 Context assembly | 6 Serve (governed SQL, APIs, MCP), 7 AI |
| 6 Decision and action | 6 Serve (apps), 7 AI, plus the business workflow that holds authority |
| 7 Outcome and learning | 1 Ingest (outcomes flow back), 4 Model (decision records as a product), 8 Govern and operate (evaluation) |
Two things sit outside the data platform and must still be designed: the workflow where authority lives, and the rule repository. The platform holds their data, not their authority.
Not when
- Do not build all seven layers for a report. A descriptive dashboard with no decision attached needs facts and meaning, and that is enough.
- Do not start with the technology layer that looks most interesting. Start from a decision in the inventory and build only the layers it is missing.
- Do not turn every rule into a model. If a decision table gives the answer, an LLM should cite it, not re-derive it.
Next: Target reference architecture shows how the engine is built.
Source links: Data Practice reading list.