Intelligence and data work is the disciplined conversion of observations into decisions, actions and measurable outcomes. It includes data capture, ownership, quality, modeling, analysis, privacy, communication and feedback. A company can own a modern platform and still make weak decisions if nobody can explain which source is authoritative, what a metric means, how current it is or who may act. Conversely, a modest stack can be dependable when a small number of critical data products have explicit purpose, service expectations and accountable owners.
Start with one consequential decision rather than an enterprise-wide inventory. Name the person accountable, the population affected, the available actions, the decision deadline and the result that will show whether the action helped. Edilec's intelligence and data implementation checklist turns that framing into delivery controls, while the intelligence and data FAQ covers architecture and governance choices. This guide explains how the parts fit together.
Define the decision contract before the data estate
A decision contract is a concise agreement about purpose. It records the question, eligible cases, owner, action options, timing, constraints, review route and success measure. For inventory replenishment, for example, the question is not simply how much stock exists. It may be which product-location pairs should be reordered today, within supplier, cash, shelf-life and storage constraints. That statement exposes the data required and prevents a dashboard from becoming the project goal.
Separate descriptive, diagnostic, predictive and prescriptive uses. A historical report may tolerate a corrected monthly refresh; an intervention that stops a payment or schedules care may need near-real-time data, a reason code and human challenge. Identify the cost of false positives, false negatives and delay. Establish a baseline using the current process so improvement can be compared with something real. The data and AI services checklist is useful when the decision will include a model.
| Decision element | Question to settle | Evidence before launch | Named owner |
|---|---|---|---|
| Purpose | What choice will improve? | Approved decision statement | Business owner |
| Population | Which cases are eligible or excluded? | Test cohort and coverage report | Process owner |
| Action | What may a person or system do? | Authority and exception matrix | Operational lead |
| Timing | When does information lose value? | Freshness objective and late-data behavior | Data product owner |
| Outcome | How will benefit and harm be measured? | Baseline, target and review cadence | Business and risk owners |
Treat critical datasets as operated products
A critical data product has users, a declared purpose, an interface, an owner and service expectations. Document the authoritative source, identifiers, schema, refresh, retention, access, quality thresholds, lineage and support route. Publish known limitations beside the data, not in a forgotten project document. The UK Government's Data Maturity Assessment uses evidence across connected organizational capabilities; that is a useful reminder that a catalog entry alone does not create maturity.
Assign ownership at the level where a correction can be made. A warehouse team can detect that delivery status is missing, but the source process owner may need to repair a scanner workflow or partner contract. A steward can maintain definitions and coordinate issues; the accountable owner decides acceptable use and investment. Set an escalation path for missed freshness, changed semantics and access incidents. Retire feeds and reports whose approved use has ended so the estate does not accumulate unsupported authority.
Define data quality as fitness for the decision
Quality is contextual. Evaluate completeness, validity, uniqueness, consistency, timeliness and accuracy where each can change the decision. The UK Government's Data Quality Framework emphasizes knowing users, assessing quality through the lifecycle, communicating it and anticipating change. Translate those principles into measurable rules by segment. Ninety-nine percent completeness may still be unacceptable if the missing one percent contains every new customer.
Run checks at capture, transformation and publication. Preserve rejected records with safe diagnostic context; silently discarding them can make a clean dashboard from an incomplete population. Every rule needs severity, response, owner and exception behavior. Communicate current confidence to users with measurement time, affected scope and operational advice. Prioritize root-cause changes at source when they prevent recurring cleansing. A quality score with no decision threshold or action is decoration, not a control.
| Quality dimension | Example rule | Failure response | Decision risk |
|---|---|---|---|
| Completeness | All eligible orders have location and promised date | Quarantine affected cohort | Demand is understated |
| Validity | Quantity and currency use approved domains | Reject or map under review | Measures cannot be compared |
| Uniqueness | One current record per business key | Resolve duplicate authority | Counts and actions repeat |
| Timeliness | Source arrives before decision cutoff | Label stale or use fallback | Action uses obsolete state |
| Accuracy | Sample reconciles to source evidence | Investigate process and restate | Decision is confidently wrong |
Preserve provenance and semantic history
Technical lineage shows sources, transformations, joins, filters and outputs. Business lineage explains why a field or metric represents the concept users expect. W3C PROV-DM models entities, activities and responsible agents, a durable foundation for expressing derivation across tools. Capture deployed code and schema versions, run identifiers and effective times at the level required to reproduce an important output and assess consumers when a source changes.
Definitions need versioning too. Revenue recognized, active customer and on-time delivery may all change when policy changes. Record effective dates and preserve historical interpretation. A semantic layer can centralize approved calculations, but it still needs an owner, tests and change notice. The data and AI services FAQ discusses the boundary between governed data and operated models. When two definitions legitimately serve different decisions, name both instead of manufacturing false consensus.
Protect people and make analysis reproducible
Classify data, state purpose, minimize fields, restrict effective access and set retention before broad analytical use. Derived attributes and joins can create sensitivity that no source field had alone. The NIST Privacy Framework connects privacy risk with enterprise risk management; apply it to analyst workspaces, exports and downstream copies, not only operational databases. Log material access, review privileged and dormant accounts, and test correction or deletion across the decision chain where obligations apply.
Reproducible analysis retains code, parameters, environment, input references and output revision. State assumptions, missingness, uncertainty and causal limits in terms a decision owner can use. A correlation can prioritize investigation without proving that an intervention caused an outcome. For AI-supported intelligence, NIST's AI Risk Management Framework organizes continuous work around govern, map, measure and manage. Define evaluation populations, error costs, fallback and human authority before deployment.
Operate intelligence as a feedback loop
Monitor source capture, pipeline runs, freshness, rule results, schema changes, access, report use, recommendations, overrides and outcomes. Set incident severity from decision impact. A failed overnight pipeline for an annual report differs from stale fraud signals during live payments. Give users a visible correction route and status. After repair, reconcile missed or incorrect actions instead of declaring success when the pipeline turns green.
Hold a regular review with the business owner, producer, analyst, operations, privacy and security representatives appropriate to the use. Examine changed assumptions, unresolved exceptions, recurring repairs, override reasons, cost and outcome evidence. Remove measures that do not inform action. Expand only after the first decision chain is explainable and operable by its permanent owners. This creates reusable governance without imposing an abstract enterprise program before value is visible.
Control semantic and decision change
Treat a material data or policy change as a change to the decision system. Assess affected products, metrics, reports, models, users and automated actions before deployment. Compare old and new results on a representative period, explain expected differences and decide whether history should be restated or remain under its original definition. Publish the effective date, approver, migration path and contact. Where both definitions must coexist, give them distinct names and prevent an unqualified metric from silently switching meaning.
Maintain a decision record for consequential releases: problem, options considered, chosen rule, evidence, owner, effective revision and review trigger. Link it to source contracts, transformation code, model or analysis revision and communication. Exercise a correction by identifying affected decisions, pausing unsafe automation, recomputing outputs and notifying operators. The ability to repair and explain a wrong result is part of intelligence quality. It also reveals whether lineage and ownership are operational or merely documented.
Intelligence and data FAQ
Do we need a new platform first?
Usually not. Prove the decision, ownership, source and quality gaps with current systems. Invest where repeated constraints prevent reliability, scale, security or timely action. A platform can automate movement and policy; it cannot decide what a business concept means.
Can one dashboard be the single source of truth?
A dashboard can be an approved presentation of governed products and definitions. Authority normally remains distributed across operational sources, controlled transformations and decision policy. Publish lineage, effective definitions and limitations rather than promising one universal truth.
How should return on intelligence be measured?
Measure the change in the target outcome, decision cycle time, avoidable errors, adoption and operating cost against a baseline. Include harms, exceptions and manual work. Usage is useful diagnostic evidence, but a frequently opened report is not proof of a better decision.
Key takeaways
- Begin with an accountable decision, authorized action and measurable outcome.
- Operate critical datasets as products with purpose, owners and service expectations.
- Measure quality relative to affected populations and decision consequences.
- Version lineage, definitions, analysis and access so results remain explainable.
- Review outcomes and overrides, then improve or retire the decision chain.
Conclusion: build trust one decision at a time
Intelligence and data become trusted when a business decision can be traced through governed products, quality evidence, provenance, analysis and accountable action. Build that complete chain for one material use, protect people and uncertainty, observe the result and use the feedback to improve. Repeating that practice creates durable, auditable, repeatable business capability far more reliably than accumulating unowned dashboards.