Stewardship, scaled to part-time.
A request queue that surfaces priority. An approval flow that scales down to a domain expert's spare hour. And the five metrics that show whether the system is working.
What it is.
Every dimension that matters has a named steward. The steward is one person, not a committee, holding decision rights for additions, definitional changes, deprecations, and contested decisions within their dimension. CleanDims provides the workflow that lets stewardship operate part-time, layered onto an existing role rather than constituted as a new full-time function.
This is not a governance platform, which provides policy management at the organisational level. CleanDims provides the operational tooling that lets a steward make decisions about specific dimensional values without leaving their domain expertise.
Requests, queues, and thresholds.
Every change to the canonical reference flows through one primitive: the request. A request is the durable artifact capturing a proposed change, who proposed it, the reasoning, the discussion among reviewers, and the resolution. Requests originate automatically when the system observes a new value below the auto-mapping confidence threshold, or manually when anyone in the organisation proposes a change.
The auto-mapping confidence threshold is configurable per dimension. A higher threshold opens more requests and silently resolves fewer values; a lower threshold opens fewer requests and silently resolves more. The threshold is the principal control the steward has over the trade-off between automation and review.
The queue surfaces priority based on present consumer impact. A request whose unresolved value is currently affecting consumers, an analyst seeing warnings, an agent producing flagged output, downstream models receiving low-confidence inputs, is high-priority. A request whose unresolved value is not currently being consumed is low-priority. The steward sees the priority and works the queue accordingly; there is no service-level commitment that forces unsustainable response time.
The five metrics.
CleanDims tracks five metrics, each measuring a different aspect of system health. Coverage measures the breadth of dimension management adoption: what percentage of the organisation's dimensions have an active canonical reference. Drift measures the input rate of new variants per dimension, surfacing upstream changes that the reference has not absorbed. Resolution latency measures steward throughput. Resolution coverage measures the structural reach: what percentage of records arrive at consumers with a canonical value attached, regardless of confidence. Confidence depth measures the quality of those resolutions: the distribution of confidence levels across resolved records.
The metrics are observable from the system itself. None is aspirational. Together they form a complete operational picture: how broadly the discipline is adopted, how fast the input is changing, how quickly stewards are keeping up, how much of the data the system is touching, and how well it is touching it.
A steward's queue, fifteen minutes on Monday.
A vendor name steward in procurement sees three new requests at the start of their week. The first is high-priority: an unresolved supplier name is appearing on invoices that finance has flagged. The steward reviews the request, sees the system's suggested alias mapping to an existing canonical, accepts it, and the resolution propagates to all consumers within the configured sync interval. The second request is medium-priority: a genuine new vendor with no existing canonical. The steward creates a new entry, writes a one-line definition, and accepts. The third is low-priority: a value that appeared once on a single document six weeks ago and has not been seen since. The steward defers it. Total time: under fifteen minutes. The system is async-by-default; nothing in the production flow was waiting for the steward's response.