Data Democratisation
Data Democratisation
The idea that broad access to data improves decisions. The user's working definition (refined against Prukalpa's context-layer essay): democratising data means democratising the meaning of data — definitions, allowed slices, caveats, and the playbooks for using it — not just access to dashboards or self-service queries. Access without shared semantics democratises confusion.
The two readings
| Reading | What gets democratised | Predictable failure mode |
|---|---|---|
| Dashboard-access reading (common) | Read permissions, BI seats, self-service query tools | Different teams compute "revenue" / "active customer" / "win rate" differently. QBRs become arguments about whose number is right. Trust erodes. |
| Governed-meaning reading (Prukalpa / user POV) | Definitions, ontology, reusable playbooks, learning loops — exposed through the access layer | Slower to roll out; needs owned metrics, a glossary, and a learning council; pays back in decision speed and AI-readiness. |
The dashboard-access reading is the Cobra Effect of analytics programs: a measure ("dashboards rolled out", "self-service queries answered") becomes the target, and the actual goal (better decisions from shared facts) is abandoned.
What the governed-meaning version requires
Three primitives, all of which need named owners, not just artefacts:
- A Business Glossary + Metric Contract. One owner per metric, approved definition, source system, refresh cadence, allowed slices, known caveats, example questions it can answer. This is the semantics substrate from Prukalpa's context-layer framing.
- Reusable playbooks (skills). Tribal know-how converted into versioned procedures with trigger, steps, exception handling, approval rules, and an owner. This is the skills substrate — the same idea as Skills (Claude Code) at the org level instead of the agent level.
- A learning loop. Every question, correction, override, manual workaround, and "this number is wrong" complaint is context-mining input, not noise. Promote resolved learnings back into the glossary / semantic layer / playbooks / permissions. This is the compounding learning loops capability from Prukalpa's five.
Without all three, the access layer is a dashboard programme with a slogan.
Applied to sales
The first concrete instance the user worked through is Data Democratisation in Sales — Governed Context Layer, Not Dashboard Access: pick one high-value workflow (e.g. weekly pipeline health review), build the context layer only for that workflow (≈10 metrics, 5 entities, 3 playbooks, named owners, correction log), then scale by workflow rather than by dumping more data into more hands.
Cross-links
- What an Enterprise Context Layer Is (Prukalpa) — the source the meaning-not-access reading sits on
- Context Engineering · Context Development Lifecycle — the technical and procedural disciplines that make this practical
- Skills (Claude Code) — the agent-layer twin of the org-layer playbooks idea
- Knowledge Work Factory Redesign — the demand side; democratised meaning is what makes the "finding inputs" friction tractable
- Cobra Effect — the failure mode the access-only version walks into
- Hallucination Laundering — a sibling failure mode: confident-looking output without ownership of the underlying claims, applied to humans and dashboards rather than to LLMs
See also
- Data Democratisation in Sales — Governed Context Layer, Not Dashboard Access — the user's first applied POV (sales domain, 30-day pilot)