Say what good looks like before anyone builds on it.
Meridian drafts the business rules and data quality rules that govern the data behind your dashboard, every one tied to an attribute you defined in Conform. You confirm each rule, and your own team implements the finished library.
Everybody knows the rule. Nobody wrote it down.
Somebody on the team knows a closed order should never carry an empty shipping date, and that region only ever holds four values. It is not in a ticket, not in the warehouse, and not in the handover. It is in their head, and it leaves when they do. The dashboard keeps rendering, quietly, on data that broke a rule nobody had written.
When the rules do get written, they get written twice: once as a check inside a quality engine, once as an assumption inside a report. The two drift apart, and neither names the definition it depends on. So a rule survives an edit that made it untrue, and the first anyone hears of it is a number in a board pack that cannot be explained.
Rules your team can implement, written against your own definitions
Write down the rules the data behind your dashboard has to obey, against the attributes you already defined, so your own team can implement them in your own tooling.
Rules about attributes you defined
Every rule names one attribute from the data dictionary you agreed in Conform. A rule reaching for something you never defined, or contradicting what you agreed there, is flagged rather than quietly shipped, and it cannot be confirmed while the flag stands.
Two kinds of rule, kept apart
A quality rule is checkable, so it carries a dimension and a threshold. A business rule is a declaration about how your organisation works, and it belongs in the library even when no engine can enforce it. Collapsing the two is how the unenforceable ones get dropped.
Thresholds from your own profiling report
Bring the aggregate output of whatever profiling tool you already run, and the numbers rest on evidence rather than a Meridian default. It is a summary of your data, never your data: anything resembling a row of real values is refused, and the file is never stored. Skip it and the step still works.
A score that admits what it is
The Rule Coverage Score says how much of your data product the library speaks about, and how much of that rests on evidence rather than a Meridian default. It tells you nothing about whether your data is any good, because no rule here has been run against it.
Meridian drafts the rules, you decide which ones stand
Every rule arrives as a proposal naming one attribute you already defined, with the reason it matters written in business terms. You accept it, reword it, or throw it out. A rule that no longer matches the dictionary is flagged, and it cannot be confirmed until you resolve it.
Meridian reads the data dictionary you confirmed in Conform, because a rule is a statement about an attribute you have already defined.
Import the aggregate profiling report your own tooling produced, if you have one, so thresholds come from your data rather than from a convention.
Ask Meridian to draft the library, then work through it with the mentor, confirming, rewording or throwing out each rule.
Clear anything flagged. A rule naming an attribute the dictionary no longer has, or contradicting what it says, has to be resolved before the library can be finished.
Download the specification as Markdown or Excel and hand it to the team who runs your data quality engine.
What you walk away with
The rule library
Every rule with its statement in plain English, why it matters in business terms, the attribute it governs, and how serious a breach is. Meridian drafts; you confirm each one.
Coverage across eight dimensions
Accuracy, completeness, conformity, consistency, coverage, timeliness, validity and uniqueness. Cover fewer than four and Meridian says so before you finish. It warns you; it never stops you.
The specification
One document in Markdown or Excel, carrying only the rules you confirmed that still bind cleanly to the dictionary as it stands today. Your engineers implement it in your own data quality engine.
Meridian is an external mentor, not another pipeline
Meridian never connects to your systems and never sees a row of your data, so it cannot tell you whether your data is any good. It writes the rules; your team runs them. The library says so on its own first page: "These rules are declarations of intent. Your engineering team must validate and baseline them against live data before they have governance standing."
Write the rules down once
A rule that lives in one person’s head is not a control. Put the library beside the definitions it depends on, and give your engineers something they can build.
Request access