← DecisionOS

DecisionOS — Build · module

Data Foundation

Whether the data this initiative needs can be reached, is right enough, is permitted, and is fresh enough for the decision it feeds.

When you reach for it

After an initiative has been approved in principle and before anyone commits to a date — the exact point at which most AI programmes discover the problem that delays them by two quarters. Often run after a slip, to explain one.

What it asks you

3 blocks, in this order. Each one exists for a stated reason, and the run tells you that reason as you answer it.

  1. 01

    The data this initiative needs

    Named objects, in your own vocabulary — not systems, and not "the data lake". Data readiness is a property of an object and a use, not of an organisation.

  2. 02

    Each object

    Seven facts. Every one is a fact about the world rather than a rating, and every one may be answered "don't know" — which is recorded as not known rather than scored as poor.

  3. 03

    The decision this data feeds

    How good is good enough depends on what the data is for. These two answers are what make a latency mismatch detectable at all.

The method

How the result is produced

Each object is classified by an ordered rule set, first match wins, and the rule that matched is printed on the row: Blocked, Latency mismatch, Unverified, Fragmented, Unknown, Usable with work, Usable. The initiative is then gated by its worst object rather than by the average of its objects — if one of six is blocked, the initiative is blocked. Latency is arithmetic: the refresh interval and the staleness tolerance are asked in the same bands and compared directly, and how often the object changes is compared against how often the copy refreshes as a separate check. Provenance depth is derived from where an object lives and how it would be read rather than asked, because every fact it needs is already on the object; it is what caps the Verifiability dimension of Cognitive Coverage for anything built on these objects. An object with 3 or more of the seven facts unanswered is classified Unknown, which is a statement that it has not been assessed and not a statement that it is poor. Nothing is averaged and nothing is scored.

What this is not
Nothing here was profiled, sampled, connected to or read. Every attribute is what a person told us about a dataset, and this is the module most likely to be mistaken for one that inspected something.
A measured error rate that was reported to us is not a measured error rate we verified. We did not see the measurement.
This is not a data strategy. It is a readiness check for one initiative against the objects that initiative named.
It is not a completeness check. An object the initiative uses but nobody listed does not appear anywhere in this report.
Where it stops
Everything here is what you told us. Nothing was read, inspected, profiled or connected to.
There is no peer comparison behind any statement in this report, and none is implied. We will not show one until there is enough real data to state an n.
The object set is self-declared, and an object listed that the initiative does not actually use is undetectable here. The mitigation is procedural: review the list with whoever will build it.
Refresh intervals are commonly reported as the intended schedule rather than the observed one. A pipeline that is supposed to run nightly and fails twice a week reads as "daily" in this report.
No duration is offered for any task. The same data task takes a day in one organisation and a quarter in another, and an invented number would be the least reliable thing here.
This run reflects the answers of whoever completed it. A second respondent answering the same questions frequently disagrees, and that disagreement is usually the finding.

What it connects to

Answers established elsewhere are carried in with their age shown, so a stale answer reads as stale rather than being silently reused.