The business caseThe problem this solves

A data governance analyst working a CDE exception report each quarter opens the profiling output for every critical data element, checks whether the measured failing rate breaches its declared threshold, then walks the lineage registry hop by hop and reads the steward's own investigation notes to decide which system is actually at fault -- and has to remember, unaided, whether a finding for this incident has already been raised so the same breach is not reported as new every quarter it stays open. The manual walk from a failing-rate dashboard to a lineage registry to a steward's notes, repeated every reporting period for every CDE, to decide whether this period is a new finding, a continuing one, a closed one, or nothing at all.

The inputThe actual CDE profiles

The corpus is 120 CDE profiles, 0.54 MB (json 1 · jsonl 1 · txt 120).

Synthetic Record
----------------------------------------------------------------
This is a SYNTHETIC data-governance monitoring record generated for the dq-lineage kit. No real bank, customer, system or person is represented.
CDE reference: CDE-0001   Reporting period: P1 of 4

Critical Data Element
----------------------------------------------------------------
CDE reference           : CDE-0001
Name                    : Days Past Due (Retail Loans)
Owning function         : Credit Risk
Quality dimension       : Accuracy
Definition              : The number of calendar days a retail loan's scheduled payment is overdue, as reported to the risk data mart at each reporting period.

Quality Rule
----------------------------------------------------------------
Failing definition      : A record fails where a record where Days Past Due as reported disagrees with the value recomputed from the servicing ledger by more than 1 day.
Declared threshold      : 0.75%

Rule DQ-1  A CDE is IN BREACH for a reporting period when its measured failing rate for that
          period is STRICTLY GREATER than its declared threshold. Equal to the threshold is
          within tolerance, not a breach.
Rule DQ-2  A finding is raised ONCE per incident, on the first reporting period at which the CDE
          is in breach with no incident already open. A later period that is still in breach
          reports the incident CONTINUING; it does not raise a second finding for the same
          incident (BREACH_ONGOING).
Rule DQ-3  The root cause identified when a finding is raised STANDS for every later period the
          same incident remains open, unless a new instrument in THIS period's Lineage Registry
          supersedes it. It is not re-derived from scratch each period.

The outcomeWhat a good result looks like

Every CDE in breach carries exactly one open finding, its affected segment matches what the profiling shows, and its named root cause matches what the steward would go on to confirm -- including the undocumented cases, whenever the evidence for them exists anywhere in the file.

Where it fitsWhat did work

Every line below is a measured result from this kit's own runs, with the figure that supports it. The headline above is not softened by any of them.

• Your lineage registry captures every hop system-to-system with no manual gaps — the free floor in this repo, or an equivalent rules engine over your own registry
  It ties the model exactly on all three structured fields and on the 11 documented-origin root causes in this run -- 100.00 pct, $0.00, no key.
• Your registry has known or suspected undocumented manual steps, and stewards write investigation notes when they find one — the model, with the carried state
  It traced the true root cause on 5 of 5 undocumented findings that carried a clue in this run -- the free floor gets 0 of 7 by construction, every time.
• You need alerting across reporting periods without re-raising the same open incident — the model WITH the carried state -- never the stateless variant
  Duplicate findings go from 0 of 102 quiet periods to 30 of 102 the moment the carried-state sentence is removed, at no reduction in cost per reading.

At a glanceHow the whole thing runs

Run once, for real, on 2026-08-24. Every figure on these pages was captured from that run — nothing is written from intent.

14 steps, grouped by the question that sends you to them rather than by build order. Each tile carries the one figure that step is about, and opens the page behind it.

Should you use this?What you bring, where it stops, and when not to use it

Before you commit an afternoon to this, these are the answers that decide it. Each one is rendered from the record it lives in — and links the page that holds it in full.

Not asked of this kit — 2 questions: clone (a fresh clone of this kit runs with nothing fetched); judge (nothing here is graded by a model).

Last verified 2026-08-24 — r001-dq-lineage. Every figure on these pages was captured from that run.

Run itHow this reaches your data

Every result on this page was produced by pure code over checked-in files, with no API key — which is why you can read the numbers before anyone spends anything.

Checked before this shipped — A fresh clone with no API_KEY renders the full UI (python3 -m src.app), the committed corpus, the answer key and the free floor's verdict on every reading -- all computed locally. It reproduces r001-dq-lineage's committed results via the 'Show what run r001 recorded' replay button, but cannot make a new live call: the read button returns a plain sentence saying nothing was called, rather than an error.

Step 01 of 14Business case

Written for: product manager · Measured during the eval run. Never estimated, never quoted from a vendor page.

In brief

What the clock covers. END-TO-END per reading: one HTTP request carrying the assembled prompt -- the five quality/lineage rules, the carried-state sentence, and this period's CDE definition, profile, lineage registry, reporting position and steward notes -- and the reply parsed to a status, an affected segment, a root-cause system and a new-finding call. Parsing the extract into sections, dropping the withheld Escalation Contact section, and advancing the carried state all happen outside this measurement and cost no network at all.

Current processWhat it replaces

The manual walk from a failing-rate dashboard to a lineage registry to a steward's notes, repeated every reporting period for every CDE, to decide whether this period is a new finding, a continuing one, a closed one, or nothing at all.

Step 02 of 14Architecture

Written for: solutions architect · Component map derived from the real code, not drawn from intent.

In brief

CorpusCorpusArchitectureArchitectureArchitectureArchitectureEvalsEvalsEvalsEvalsPromptPromptPromptPromptApp UIApp UIEvalsEvalsBusiness caseUnit cost

• 1stations numbered in run order
• txt
• jsonl
• json
• 3 of 10 stations carry a recorded failure

scroll → 10 stations

One question, end to end. Colour on the fan-in is the corpus format; a red hook marks every station with a recorded failure, and the words — every sub line, failure and report field — are in the ledger beneath. Every station is a link — click one to jump to its row, and each row links to the lens that explains it.

The swap seams

Components

Step 03 of 14App UI

Written for: anyone, in 5 seconds · Screenshots of the running app taken during the run.

SuccessesWhen it works

LimitsWhen it does not

A report showing only wins is an advert. This one is required, and the validator now refuses a kit that omits it.

Step 04 of 14Corpus

Written for: "can I point this at mine?" · Measured off the corpus the run actually used.

In brief

How it is cutWhat one CDE reporting-period extract is

30 CDEs x 4 fixed quarterly reporting periods each (2025-03-31 / 06-30 / 09-30 / 12-31) -- no train/test split; every reading is scored against the generator's own answer key

SetupWhat the setup figure measured

There is no index to build -- every reading re-profiles the CDE's own extract whole, with no retrieval step. build_seconds/build_cost_usd measure tools/build_corpus.py generating all 120 extracts plus data/gold.jsonl and data/corpus-stats.json from the fixed seed, not an embedding or retrieval index.

LicenceLicence

MIT, same as the rest of adhana-ai/adhana-foundry-kits

Bring your ownBring your own CDE profiles

Keep the eight section headings in src/segment.py::SECTIONS and supply your own data/gold.jsonl with one row per reading. evals/check_labels.py re-derives every status from src/dqstep.step and refuses to let a run spend if the hand-written key disagrees with the arithmetic. tools/build_corpus.py is the reference generator to adapt: CDE_DEFS is the registry, make_lineage() the declared-hop pool, and breach_pattern() the per-CDE status plan.

⚠︎ And what stops being true when you do: The undocumented-upstream rate measured here (7 of 30 CDEs, about 23 pct, split 5-with-a-clue/2-without) is a property of THIS corpus, not a measured property of data governance in general. A real institution's own coverage gap between what its lineage tooling captures and where its data quality issues actually originate is unknown until someone goes and looks for it.

Step 05 of 14Prompt

Written for: engineer · Logged from the run, verbatim.

In brief

The assembled prompt in full, and its real decomposition. Every part below occurs in the prompt that was actually sent. The split is in characters, because that is what this run recorded — the billed totals are measured, but nothing apportioned them across the parts, and dividing a measured total by character share would produce three numbers nobody counted.

AssemblyHow the prompt is assembled

This is the cost lesson as arithmetic: of the 8,058 characters assembled, 4,478 are contexts — 56% of the prompt, the largest single part. A per-request bill follows whichever part is biggest, and on this kit that is the one named here.

The exact prompt sent for CDE-0001-P1, reconstructed by replaying src/prompt.build() with this reading's own recorded carried-state input (data/gold.jsonl's carried_in) -- trustworthy because the reconstructed length (7,868 characters) and section list match what evals/run.py's harness logged for the run's first completed call.

Full promptThe prompt in full

You are a scheduled data-quality and lineage watch for one bank's critical-data-element registry. You read one CDE at one reporting period, and you answer with one JSON object and no other text.

You are the scheduled data-quality and lineage watch for one bank's critical-data-element (CDE)
registry. It runs every reporting period and re-profiles EVERY CDE against its declared quality
rule. You are reading ONE CDE at ONE reporting period.

The CDE's definition, its quality rule, this period's profiling results, its declared lineage
registry and the steward's notes are reproduced in the extract below. You cannot see the earlier
reporting periods; what is known about them is stated under "Carried state" and is the only history
available to you. Do not assume anything about earlier periods beyond it.

How to work it out:
 - FIRST decide the STATUS for this period, applying Rule DQ-1 (breach = measured rate strictly
   over threshold) and the carried state:
     CLEAN            not in breach, and no incident was already open
     BREACH_NEW       in breach, and no incident was already open -- this is a NEW finding
     BREACH_ONGOING   in breach (or not yet remediated), and an incident was ALREADY open
     REMEDIATED       not in breach this period AND a remediation is recorded for the open
                      incident (Rule DQ-4) -- being within threshold alone is not remediation
 - THEN, only for BREACH_NEW: name the AFFECTED SEGMENT the Reporting Period Profile identifies as
   carrying the concentration of failing records. For CLEAN and REMEDIATED, this is "none".
   For BREACH_ONGOING, restate the segment named when the incident was first raised, from the
   carried state or this period's profile if it repeats it.
 - THEN, only for BREACH_NEW: trace the ROOT CAUSE. Read the Lineage Registry: it lists hops from
   the most upstream system to the report, each with a per-hop reconciliation exception count for
   this period. Rule DQ-5: the root cause is the EARLIEST (most upstream) hop with a non-zero
   exception count. BUT the Lineage Registry only records what is captured system-to-system --
   check the Steward Notes for any mention of a step BEFORE the first declared hop (an undocumented,
   manual, analyst-only step). If the notes name such a step and say the exceptions originate
   there, THAT step is the true root cause, even though it is not in the Lineage Registry table.
   Naming the first declared hop when the notes point further upstream has stopped one hop short.
   For BREACH_ONGOING, restate the root cause already identified (carried state) unless this
   period's Lineage Registry or Steward Notes name a superseding instrument (Rule DQ-3). For CLEAN
   and REMEDIATED, this is "n/a".
 - THEN decide "new_alert": YES only when status is BREACH_NEW -- a finding is raised once per
   incident (Rule DQ-2). NO for CLEAN, BREACH_ONGOING and REMEDIATED.

Answer with a single JSON object and nothing else:

{"status": "CLEAN|BREACH_NEW|BREACH_ONGOING|REMEDIATED",
 "affected_segment": "<segment name, or 'none'>",
 "root_cause_system": "<system or step name, or 'n/a'>",
 "new_alert": "YES|NO",
 "rationale": "one sentence, naming the measured rate against the threshold and, where a root "
              "cause was traced, which hop and why"}

Carried state
----------------------------------------------------------------
No earlier reporting period has been recorded for this critical data element. This is its first appearance on the watch: no incident is open and no root cause has been identified for it before today.

CDE reporting-period extract
----------------------------------------------------------------
Synthetic Record
----------------------------------------------------------------
This is a SYNTHETIC data-governance monitoring record generated for the dq-lineage kit. No real bank, customer, system or person is represented.
CDE reference: CDE-0001   Reporting period: P1 of 4

Critical Data Element
----------------------------------------------------------------
CDE reference           : CDE-0001
Name                    : Days Past Due (Retail Loans)
Owning function         : Credit Risk
Quality dimension       : Accuracy
Definition              : The number of calendar days a retail loan's scheduled payment is overdue, as reported to the risk data mart at each reporting period.

Quality Rule
----------------------------------------------------------------
Failing definition      : A record fails where a record where Days Past Due as reported disagrees with the value recomputed from the servicing ledger by more than 1 day.
Declared threshold      : 0.75%

Rule DQ-1  A CDE is IN BREACH for a reporting period when its measured failing rate for that
          period is STRICTLY GREATER than its declared threshold. Equal to the threshold is
          within tolerance, not a breach.
Rule DQ-2  A finding is raised ONCE per incident, on the first reporting period at which the CDE
          is in breach with no incident already open. A later period that is still in breach
          reports the incident CONTINUING; it does not raise a second finding for the same
          incident (BREACH_ONGOING).
Rule DQ-3  The root cause identified when a finding is raised STANDS for every later period the
          same incident remains open, unless a new instrument in THIS period's Lineage Registry
          supersedes it. It is not re-derived from scratch each period.
Rule DQ-4  An incident is REMEDIATED only on the period at which BOTH conditions hold: the
          measured rate is back within threshold, AND a remediation is recorded in this period's
          Prior Period Status carry-forward or this period's own record. Passing the threshold
          with no remediation recorded is not evidence the issue was fixed -- it is evidence the
          sample happened to be clean this period, and Rule DQ-2's incident stays open.
Rule DQ-5  Root cause is traced from the DECLARED lineage registry: the earliest (most upstream)
          hop at which this period's per-hop reconciliation exceptions are non-zero. Where the
          Steward Notes name an earlier step not carried in the Lineage Registry -- an
          undocumented, manual, system-to-system gap -- and that step is where the exceptions
          actually originate, THAT step is the true root cause, not the first declared hop
          downstream of it. A trace that stops at the first declared hop when the notes say the
          gap sits before it has stopped one hop short.

Reporting Period Profile
----------------------------------------------------------------
Reporting period        : P1 of 4
Snapshot date           : 2025-03-31
Previous period         : --
Next period             : 2025-06-30
Total records profiled  : 47,837
Failing records         : 182
Measured failing rate   : 0.38%
Declared threshold      : 0.75%
Segment breakdown (failing records): no material concentration this period
Concentration segment    : none

Lineage Registry
----------------------------------------------------------------
Declared hops, most upstream first. Exceptions are this period's per-hop reconciliation count against the prior hop.
  Hop 1  Deposit Servicing System         (owner: Business Ops            ) exceptions: 0
  Hop 2  Data Quality Firewall            (owner: Data Engineering        ) exceptions: 0
  Hop 3  Finance Data Mart                (owner: Data Engineering        ) exceptions: 0
  Hop 4  Regulatory Reporting Mart        (owner: Reporting & Analytics   ) exceptions: 0

No remediation instrument recorded against this CDE's lineage this period.

Reporting Position
----------------------------------------------------------------
Reporting period        : P1 of 4
Watch cadence           : quarterly, on the last calendar day of the quarter
Snapshot date           : 2025-03-31
Previous period         : --
Next period             : 2025-06-30

Steward Notes
----------------------------------------------------------------
No open findings for this CDE this period.

Raw responseThe raw response

{"status": "CLEAN", "affected_segment": "none", "root_cause_system": "n/a", "new_alert": "NO", "rationale": "Measured failing rate of 0.38% is not strictly greater than the 0.75% threshold, and no incident was previously open, so the CDE is clean."}

Step 06 of 14Evals

Written for: the skeptic · The harness output, with as_of / model version / dataset version / verified_by.

In brief

Trace a bank's bad data back to its source — 120 CDE profiles. One model answered, and every answer was then graded Two different ways — because the grade is a measurement too, and most of what went wrong on this kit went wrong in the ruler rather than the model.

The rulerHow it was graded

Every gold value is computed by tools/build_corpus.py's planted breach plan and re-derived independently by src/dqstep.step in evals/check_labels.py before any run may spend. There is no LLM judge anywhere in this kit's grading path: status, affected segment and new-finding alert are exact string matches against a closed list, and root cause is a normalised token-overlap or keyword-recognition match implemented in pure Python (evals/scoring.py).

MeasurementsWhat was measured

Two words carry this page: Counted is deterministic and nobody's opinion and Not yet known is printed blank rather than filled with something plausible. There is no Judged row here and that is the point: nothing on this page is a model's opinion about another model. The row most worth having is currently the empty one.

Grading costWhat it costs

Every dollar on these pages is a MEASURED token count multiplied by a named vendor's PUBLISHED rate -- a projection onto a rate card, not a bill anyone paid.

Rates checked 2026-08-18. The provider that actually ran all 241 calls for this kit's build is kept out of these tables per this estate's naming rule, so nothing here is what was paid. The real spend is on the shared call ledger, not on this page.

The gradersTwo ways to grade

The free floor ties the model exactly on every structured field (status, affected segment, new-finding alert, all 100.00 pct) and on the 11 documented-origin root causes (100.00 pct each). It is not a strawman -- it reads the same Reporting Period Profile and Lineage Registry the model does, in pure Python, and carries the same three-scalar state between periods. The entire measured difference is on the 7 undocumented-origin root causes: the floor is 0.00 pct, stopping one hop short every time by construction, because it never reads Steward Notes; the model is 71.43 pct, splitting cleanly into 5 of 5 correct where the notes carry a clue and 0 of 2 where they do not.

Every row opens its own page: how the test was run, the input on one real row, the prompt or formula with every iteration of it, and the analysis.

Choosing oneWhich one to use

The comparison is only useful if it ends in a choice. The answer is conditional — and it is not the grader with the best agreement score.

This pipeline was also attacked, which is a different question from whether its answers are right: see Threat model for the injection experiment, its two gates and what it does not prove.

Failure causesHow it fails

Step 07 of 14Unit cost

Written for: whoever signs off on the bill · Measured over the eval run, per model. Never quoted from a vendor page.

In brief

The token counts are measured on a real run and belong to this pipeline — which sections are selected, the field schema, the prompt — so they hold wherever you run it. The dollars are those counts multiplied by each vendor's published rate, checked 2026-08-18. Nobody paid these particular bills; they are what the same work would cost you on a card you can sign up to today.

Identical work in both rows — the same reading (one CDE, at one reporting period), the same tokens. Only the price list changed. Which is why the token count is the measurement and the dollar is arithmetic you can redo on your own card.

Answering vs gradingAnswering and grading are two separate bills

241 live calls were attempted for this kit's build and 240 returned something: 120 scored (r001), 120 stateless control (s001, of which 1 was cut off at the 4,000-token ceiling and returned nothing), and 1 live UI screenshot call outside either eval run. THE ONE THAT RETURNED NOTHING WAS BILLED IN FULL -- it ran to exactly 4,000 output tokens and was cut off, which is why discarded_usd is not zero (input tokens for that specific call were not separately logged; this figure uses the run's own average input length). The free floor and the wiring-proof stub made no call at all and cost $0.00.

Cost driversWhat actually moves the bill

• PROVIDER-SIDE REASONING, LEFT AT THE DEFAULT. 75.2 pct of r001's output tokens (31,318 of 41,647) were reasoning that never reaches the parsed answer and still counts against the bill -- thinking was never sent on any published run, and whether disabling it holds accuracy is unmeasured (Eval.could_not_verify).
• THE FIVE FIXED QUALITY/LINEAGE RULES, REPRINTED ON EVERY EXTRACT. About 473 of the 1,860 average input tokens per reading (roughly a quarter) is Rules DQ-1 through DQ-5, reproduced in full on every page so a forker can replace them without touching the prompt.
• THE CADENCE, WHICH MULTIPLIES EVERYTHING. One call per open CDE per reporting period. A registry of 2,000 CDEs on this kit's quarterly cadence is 8,000 calls a year; the same registry monitored monthly is 24,000.
• THE STEWARD NOTES, WHICH VARY IN LENGTH BUT NOT IN WHETHER THEY ARE SENT. Every reading pays for this section whether or not a root cause is actually being traced that period -- it cannot be selectively withheld without also hiding the one channel this kit has for an undocumented step.

Your volumeWhat it costs at your volume

LINEAR IN CDEs x REPORTING PERIODS, AND THAT IS THE WHOLE WARNING. Ten times the CDEs on the registry is ten times the calls at the same per-reading cost; nothing here amortises, because there is no index and each reading is independent of every other CDE's own history.

Model choiceWhy this model

The same tier every other kit in this build lap is measured on, so the figures compare across use cases rather than across price lists -- see Eval.scores and the naming note above.

Other modelsOn other models

This is arithmetic, not a run. No model below was executed against the labelled set, and no accuracy is claimed for any of them. What transfers is the input volume: retrieval is model-independent, so every model would receive the same passages.

The exact work behind every stateful number on these pages: 120 readings, one completion call each, one tier.

The codeEvery file, and what it is for

11 modules, no framework, and almost no dependencies. The pipeline is stdlib Python, because a kit is meant to be read and changed by someone who cloned it ten minutes ago — every dependency is a thing they have to understand before they can touch the part they came for.

Four of these are swap seams: the points you edit to make the kit yours. Each is marked, and each block below is the module’s real shape, read out of the file rather than written here.

The files on this page are not in the public GitHub catalog.

tools/build_corpus.pythe corpus generator — a swap seam

Generates 30 CDEs x 4 quarterly reporting periods = 120 extracts from a fixed seed (SEED = 20260824). The 7 undocumented-upstream CDEs are drawn from across three breach-pattern groups rather than concentrated in one, so the property is not separable by owning function or breach shape. The gold labels are src/dqstep.step's output over the planted breach plan, never typed.

You change it to: The 30 CDE definitions, their thresholds, their declared lineage chains and which are flagged undocumented-upstream. A forker points this at their own registry by keeping the eight section headings and supplying their own data/gold.jsonl.

# Generate the corpus and the answer key. Deterministic: one seed, one corpus, forever.

HERE = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))
CORPUS = os.path.join(HERE, "data", "corpus")
GOLD = os.path.join(HERE, "data", "gold.jsonl")
STATS = os.path.join(HERE, "data", "corpus-stats.json")
SEED = 20260824
RULE = "-" * 64
PERIOD_DATES = ["2025-03-31", "2025-06-30", "2025-09-30", "2025-12-31"]
PERIODS = len(PERIOD_DATES)
SEGMENTS = ["Retail Banking", "Commercial Banking", "Wealth Management",

src/dqstep.pythe quality/lineage arithmetic

The four-stage rule as pure code: breach-vs-threshold, the once-per-incident finding rule, and root-cause carry-forward while an incident stays open. No model, no judgement.

# The critical-data-element (CDE) quality/lineage rule as arithmetic. Pure code, no model.

CLEAN = "CLEAN"
BREACH_NEW = "BREACH_NEW"
BREACH_ONGOING = "BREACH_ONGOING"
REMEDIATED = "REMEDIATED"
STAGES = (CLEAN, BREACH_NEW, BREACH_ONGOING, REMEDIATED)
YES = "YES"
NO = "NO"
RULE_TEXT = """\
def initial_state():

src/state.pythe carried state — a swap seam

SEAM -- the thing that makes this a monitor. Three scalars per CDE (incident_open, the root_cause_system last identified, the previous status), written from the arithmetic and never from the model's reply, rendered into one or two English sentences for the prompt.

You change it to: What is carried between reporting periods, and how it is worded to the model. Three scalars today, rendered as English rather than JSON -- a design choice, not a measurement.

# The carried state -- the thing that makes this a monitor and not a one-shot profiler.

def describe(state):

src/segment.pythe section splitter

Splits an extract into its eight named sections. Pure code; evals/check_labels.py asserts all eight are present in all 120 documents before a run may spend.

# Split a CDE reporting-period extract into its named sections. Pure code, no model.

SECTIONS = ("Synthetic Record", "Critical Data Element", "Quality Rule",
RULE = "-" * 64
def split(text):
def render(secs):

src/select.pythe section selector

Decides which sections reach the model. Escalation Contact -- the data steward's name, mobile and email -- is mapped by no field and is subtracted unconditionally. Steward Notes ARE sent deliberately: they are the kit's only channel for an undocumented lineage step.

# Pick which sections of an extract are sent. Pure code -- the last deterministic step before

BANNER = "Synthetic Record"
CDE = "Critical Data Element"
RULE = "Quality Rule"
PROFILE = "Reporting Period Profile"
LINEAGE = "Lineage Registry"
POSITION = "Reporting Position"
NOTES = "Steward Notes"
CONTACT = "Escalation Contact"
NEVER_SENT = (CONTACT,)

src/prompt.pythe prompt

Three parts: the fixed instruction, the carried-state sentence, and the selected sections in document order. The stateless build replaces the sentence with a line saying no history is available.

# Assemble the one prompt this kit sends. No template engine, no framework -- string

INSTRUCTION = """\
def build(text, carried, stateless=False):

src/adapters/__init__.pythe model adapter — a swap seam

SEAM -- the model. Raw HTTP for every provider, standard library only, shared unmodified with every sibling kit in this repo.

You change it to: PROVIDER, BASE_URL, API_KEY and MODEL in .env. Adding a provider is one function and one entry in PROVIDERS; it must return token counts, because lens 05 publishes them and lens 07 prices them.

# SEAM 1 — the model. Swapping provider or model is .env plus the same run again.

class AdapterError(RuntimeError):
TRANSIENT = {408, 429, 500, 502, 503, 504}
RETRIES = 4
def _post(url, headers, payload, timeout=120):
def openai_compatible(cfg, system, user, max_tokens, thinking=None):
def anthropic(cfg, system, user, max_tokens):
PROVIDERS = {"openai-compatible": openai_compatible, "anthropic": anthropic}
THINKING_OFF = {"type": "disabled"}
def complete(cfg, system, user, max_tokens=1024, thinking=None):

src/watch.pythe watch

One CDE, one reporting period, one call. Parses the measured rate, threshold and structured profile fields off the page with a regex and parses NOTHING from the Lineage Registry or Steward Notes -- deciding the root cause from those is the entire task.

# One CDE, one reporting period, one model call. The runtime half of the kit.

HERE = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))
CORPUS = os.path.join(HERE, "data", "corpus")
SYSTEM = ("You are a scheduled data-quality and lineage watch for one bank's critical-data-element "
MAX_TOKENS = 4000
FIELDS = ("status", "affected_segment", "root_cause_system", "new_alert")
def documents():
def cdes():
def load_doc(doc_id):
def position_of(text):

src/app.pythe local UI

One CDE, one reporting period, its carried state and its verdict, on 127.0.0.1:8203. Shows the model's answer beside the free floor's, and an undocumented-step banner explaining what agreement or disagreement between the two columns means.

# The minimal local UI. Standard library only -- python3 -m src.app, then open the printed URL.

HERE = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))
UI = os.path.join(HERE, "ui")
GOLD = os.path.join(HERE, "data", "gold.jsonl")
PORT = int(os.environ.get("PORT", "8203"))
RECORDED_RUN = os.environ.get("RECORDED_RUN", "r001-dq-lineage")
GOLD_ROWS = {r["doc_id"]: r for r in
def carried_for(doc_id):
class H(BaseHTTPRequestHandler):
def main():

evals/baseline.pythe free floor — a swap seam

Rule-based lineage matching against DECLARED, system-to-system metadata only -- $0.00, no model. Reads the Reporting Period Profile and Lineage Registry with regex, independently of src/dqstep.py, and NEVER reads Steward Notes.

You change it to: How aggressively the declared registry is read. This floor is the STRONGEST free reading of structured metadata alone; a forker with richer lineage tooling could raise this floor's ceiling on the documented cases.

# THE FREE FLOOR. Rule-based lineage matching against DECLARED, system-to-system metadata only.

def _section(text, name, nxt):
def _num(pat, text, cast=float):
def parse_profile(text):
HOP_RE = re.compile(r"^\s*Hop (\d+)\s+(.+?)\s+\(owner: .+?\)\s+exceptions: ([\d,]+)", re.M)
def parse_lineage(text):
def parse_remediation(text):
def root_cause_from_registry(hops):
def review(text, carried=None):

evals/scoring.pythe scorer

Exact match on status, affected segment and new-finding alert; a normalised token-overlap match on the free-text root cause, split into three outcomes. Documents a real grading bug it caught on its own first pass before publishing.

# Score a run against the answer key. Pure code, exact match on the categorical fields, a

STATUSES = ("CLEAN", "BREACH_NEW", "BREACH_ONGOING", "REMEDIATED")
UNDOCUMENTED_KEYWORDS = ("manual", "undocumented", "analyst", "spreadsheet", "workbook", "re-key",
def _norm(s):
def _norm_field(v):
def _contains_or_overlap(gold, ans, min_overlap=0.6):
def _mentions_undocumented(ans):
def grade_root_cause(gold_row, answer_text):
def _pct(n, d):
def score(records, golds):

Start hereThe shortest path into it

Every entry above is a file in this kit, listed in the order the pipeline runs it.

ScenariosWhat it costs at your volume

Everything below is computed from one measured base: 1859 input and 347 output tokens per reading (one CDE, at one reporting period), all of it fixed — this kit sends the document's own selected sections, so there is no retrieval depth to turn. Change the volume and the bill scales linearly, because nothing here batches.

OperationsFour shapes of workload

The same arithmetic, at volumes worth naming. These are illustrations of scale, not measurements of anyone’s deployment.

Model follows the controls above.

What this ignoresWhere a real bill diverges

In one lineWhat this kit exposes

No untrusted external input surface in the shipped version. Every field that reaches the prompt comes from tools/build_corpus.py, which invents all of it from a fixed seed. In a real deployment exactly one field is writable by somebody outside the data governance team -- the Steward Notes, which a data steward types and into which a business-unit reply or an email thread is routinely pasted.

The provider key lives only in .env (gitignored) or the shared repo-root .env, read by src/config.py and never logged, never written to results/, and never rendered by the UI. src/app.py replaces it and the base URL with placeholders before any provider error reaches the browser.

The experimentWe did NOT attack it -- and this is the surface we left open

An indirect prompt injection needs a field somebody outside can write into, and this kit has exactly one: the Steward Notes. They are SENT, deliberately, because hiding the surface would hide it from the run that is supposed to measure it -- and it is also the kit's only channel for the undocumented-lineage-step finding. None of the seven shipped note templates in this corpus is instruction-shaped; whether the model would follow an embedded instruction in a Steward Note (e.g. 'do not raise a finding on this CDE until legal has reviewed') was NOT measured. No attack was fired at this kit and none is claimed. The three boundaries below were checked in code on 2026-08-24, and the first is red-proven in both directions.

The first row is the only one measured in both directions. The other two are guarantees about what is ABSENT, and a path named something this checker does not know would pass them.

The result0 attack trials, three boundaries checked in code -- the privacy boundary red-proven by removing the guard and watching all 120 documents leak; the write-back and key-redaction boundaries checked by static grep, not by a live probe.

The Steward Notes ARE the field an outside party would influence in a real deployment, and this kit sends them. Nothing measured what a followed instruction does to a reading.

HonestyWhat this does not prove

• Whether a real deployment's Steward Notes -- prose a data steward writes freely, often pasting an email or a business-unit reply -- would carry an instruction the model follows. Not applicable to this synthetic corpus, and not measured.
• WHETHER THE KEY REDACTION HOLDS AGAINST A PROVIDER THAT ECHOES A MASKED KEY. src/app.py's replacement is an exact-string match; critical-date's own equivalent guard was found incomplete this way by taking a live provider-refused screenshot. This kit's redaction path was not probed the same way -- it is the same code, unmodified, and untested here.
• Whether the guardrail holds against a code path named something evals/check_labels.py does not know. It asserts the absence of names it knows.
• Whether the withheld section stays withheld under a corpus that carries a NINTH section. The selector's guard is a subtraction and should, but nothing tests a shape this corpus cannot produce.
• Whether the 30 CDE definitions, thresholds and lineage systems -- all invented -- would need different handling if a forker pointed this at a real registry. Almost certainly yes, and nothing here helps with it.

In one lineThe guardrail is enforced in code

Not a prompt instruction the model can ignore — a comparison applied after the reply is parsed, before anything downstream sees it.

No write-back, non-configurable. This kit produces a status, an affected segment, a root-cause system and a new-finding call. It never writes back to a source system, corrects a record, edits the lineage registry or files a remediation ticket, and there is no setting that makes it.

Everywhere and nowhere -- it is a property of what is ABSENT. The only writer in the kit is evals/run.py (results/*.json). There is no outbound path of any kind except the one completion call in src/adapters.

EvidenceDoes it hold?

The limitWhat a guardrail is not

• IT IS NOT A CHECK ON WHETHER THE ANSWER IS RIGHT. The arithmetic is correct whatever the model says, which means a wrong reading is a wrong finding and not a blocked action. The guardrail stops the kit acting; it does not stop it being wrong.
• IT IS NOT A SCHEDULER. This is the half of a monitor the kit does not ship. evals/run.py is INVOKED, not woken, and nothing here detects a missed reporting period.
• IT IS NOT A LINEAGE DISCOVERY TOOL. It reads a declared registry and a steward's own notes; it does not crawl pipelines, parse ETL code or infer lineage automatically. Where nobody has written the true origin down anywhere, this kit cannot find it -- see Business.not_good_enough.

WatchedWhat is watched, and why that one

The kit measures 23 watched figures plus 8 comparability guards and 5 reference constants — three duties, not one list. 0 of the watched are grader rates, each on its own grader page; this board watches the ones that decide when to look again. Each square is one watched figure; filled means the latest run measured it.

17 measured by the latest run 6 need the model half

GuardsBefore any comparison

Preconditions, not alarms. If one moves, the runs were not measuring the same system and nothing else on this board may be differenced.

all shared guards held between the recorded runs (cadence quarterly, cdes 30, documented_cells 11, documents 120, new_alert_cells 18, quiet_cells 102, readings_scored 120, root_cause_cells 18, stateless False, undocumented_cells 7) — which is why the history below is allowed to mean anything.

The reference constants — the null-grader baseline, the adjudication matrix, the negative count — are the third duty. They are never re-measured per run: a baseline that moves with the thing it measures is not a baseline.

BandsThe alarm bands

Derived from evidence, never picked: exact-match where two runs reproduced a metric to the digit, wider than the measured same-input drift for latency, one row of the negative class for any rate — denominator printed beside it.

HistoryRun history

4 recorded runs. A dash is a metric that run did not measure, and a dash is never differenced: not measured is a third state, neither a value nor a zero, and reading it as zero is how a board reports an improvement on a run that never looked. They are split into 3 blocks because a free floor is a baseline rather than a peer, and a run of another kind measures another thing; a column in one block is never differenced against a column in another.

triage · no model in the path — a baseline, not a peer column — 1 run. A floor is what the kit scores with no model in the path; it is the line the model runs have to beat, and it is never differenced against them.

one run A verdict is a comparison and one run has nothing to compare with, so the Verdict column is left off rather than filled with 17 chips that all say so.

triage · with the model in the path — 2 runs. Columns here are only ever compared with each other.

not a time series No two of these 2 runs measured the same system — they differ on documents, stateless — so nothing here may be differenced and the Verdict column is left off. Read this block DOWN a column, as a comparison between those runs, not along a row as a history.

stub · no model in the path — a baseline, not a peer column — 1 run. A floor is what the kit scores with no model in the path; it is the line the model runs have to beat, and it is never differenced against them.

one run A verdict is a comparison and one run has nothing to compare with, so the Verdict column is left off rather than filled with 17 chips that all say so.

DeviationsWhat deviated

0 breaches across 4 runs

The day a band breaks, a row renders here carrying the metric, the two runs, the band it crossed and what changed between them — model, prompt, chunker or top_k, read off the run records’ guards. A deviation with no diff beside it is an alarm nobody can act on.

RippleThe ripple map

Which figures move together, so one alarm reads as a system. Every edge carries its basis: measured names the run that showed it; reasoning admits nothing has varied it yet.

FiresWhat fires when a band breaks

Where evals stop sitting beside the guardrail and start feeding it. Where the answer is nothing automatic, the row says so — hiding it would undo “What a guardrail is not” above.

NextThe three you would add first

None of these is built here. They are named against the seam they sit on so they can be argued with.

CadenceWhen to re-run, and what it costs

Re-run evals/check_labels.py (free, seconds) on any change to tools/build_corpus.py, src/dqstep.py, src/segment.py, src/select.py or src/prompt.py -- it is the gate that asserts the corpus still carries both a clued and an unclued undocumented case. Re-run the scored eval AND its stateless control together (paid, 240 calls) on any change to src/prompt.py or src/state.py, since the headline is a difference between the two.

In one lineNo framework, deliberately

No framework and no dependencies at all -- json, os, re, random, http.server and concurrent.futures, all standard library. There is not even a date library, and the whole need is a fixed set of quarter-end strings compared with plain string equality, which is a judgement this kit states on the page rather than inheriting from somebody's default.

The mappingSeam by seam, who owns what

The seams are the ones this kit already publishes, so the mapping cannot drift from the code.

GraphsWhere LangGraph changes the answer

Nothing here is a graph, and the one place it looks like one is a straight line. Each CDE is a chain of four reporting periods and the only edge between them is three scalars. CDEs are independent of each other and run 30-wide.

The other sideWhat a framework costs you

• No scheduler. This is a watch that carries state and is still INVOKED rather than woken, and this kit has no cadence-risk analysis of its own -- whether a missed reporting period costs anything is untested (Eval.could_not_verify).
• No persistence layer beyond the run's own in-memory state, scoped to one eval run at a time (see src/state.py's module docstring pattern).
• No lineage discovery. This kit assumes a registry already exists and is declared; building or maintaining that registry is entirely out of scope.

In one lineWhat one run of this kit actually cost, in time and tokens

Measured on r001-dq-lineage on the same tier, memory removed (the control), 2026-08-24. This kit records telemetry measured per run — 4 of the 6 readings on this axis, 4 of them with a band the guardrail board can judge against.

The readingWhat the last run measured

No movement column. Not one of the 2 earlier runs on record is comparable with this one — a different model tier, or a changed guard — and differencing across that measures two systems rather than one. Said once here rather than as a dash on every row.

Retrieval not shown. No run of this kit has ever recorded a retrieval timing, because the pipeline has no such stage. Those readings are left out rather than dashed: a dash says “this run did not measure it”, which promises a later run could.

DriftMedian call, run over run

Hatched bars are runs that are not comparable with the latest — a different model tier or a changed guard. They are drawn because hiding them would make the history look shorter than it is, and greyed because differencing across them would be measuring two systems.

1 run not plotted. b000-dq-lineage-floor recorded no call latency at all — a rules-only floor run makes no model call, and the 0 its record stores is an absence, not a zero-millisecond answer. Plotting it would put a bar on this chart claiming the fastest run in the kit’s history.

The other sideWhat this does not tell you

The first of those is the one worth doing something about, and it is a solved problem: instrumenting a pipeline so each step reports its own duration is a couple of lines. Observability / tracing has the code, and what the result looks like once it is running.

In one lineWhat you provision, honestly

Everything measured on this page says where it was measured; everything not measured says that — the same contract as the other thirteen pages. Where a retrieval index would be on other kits, this one has: no index — the population is re-read whole on each scheduled run, and the prior run's carried state is what makes a reading a CHANGE.

The machineWhat this needs

Enumerated from the kit’s own source by build/facts/envscan.py, committed, and drift-checked — never typed into this page.

Your dataWhere everything sits

The wireWhat crosses it, and when

Zero-egress topology: point BASE_URL at a local OpenAI-compatible server and nothing leaves the machine — statically true of the shipped adapter, whose only credential travels in the Authorization header.

The shapeHow it ships, and what you add

The ladderEach decision, and what you provision past its ceiling

Every threshold is a measurement with its provenance beside it, or says is_measured:false. A ceiling with no seam says so — it is the point the kit is outgrown, never a forced join.

When it failsFailure signatures

The knobsThe config surface, enumerated

Environment variables: API_KEY, BASE_URL, EMBED_MODEL, EVAL_WORKERS, MAX_CALLS_PER_DAY, MODEL, PORT, PROVIDER, RECORDED_RUN.

The other sideWhat this page does not claim

The corpus licence, from the Data lens: MIT, same as the rest of adhana-ai/adhana-foundry-kits Your corpus’s licence is yours to verify, and the labels you write are about your documents.

In one lineStatus, affected segment and new-finding alert, per reading, exact match against the computed answer key

For each of the 120 readings, did the reply's status, affected_segment and new_alert equal the computed answer key? All three are words from a closed list (or 'none'/'n/a'), compared exactly.

MethodHow the test was run

evals/scoring.py::score, in-process, no key and no model. The same function scores the model, the stateless control and the free floor.

Every grader on these pages scored the same 120 already-recorded answers. Nothing was re-generated, so this compares rulers and not models.

The inputOne real row, seen by every grader

The formulaWhat it computes

accuracy = hits / 120 per field. A reading whose reply did not parse counts as a MISS in every field, never as an exclusion -- coverage is published beside every accuracy (answered_pct).

The analysisWhat it actually did

In operationWhat to monitor

Reference standard: data/gold.jsonl, computed by tools/build_corpus.py over the planted breach plan at generation time and re-derived from src/dqstep.step by evals/check_labels.py before any run may spend. This grader IS the reference, so its own TPR/TNR are not measured -- scoring it against itself would be circular.

How tight can the band be? No tuned threshold anywhere on the model path -- the reply decides. new_alert has a denominator of 18 (readings where a NEW finding is due) against 102 quiet periods, so one row moves missed/duplicate rates by 5.6 or 1.0 points respectively.

Cadence: Re-run evals/check_labels.py (free) on any change to tools/build_corpus.py, src/dqstep.py, src/segment.py, src/select.py or src/prompt.py. Re-run the scored eval AND its stateless control together (paid, 240 calls) on any change to src/prompt.py or src/state.py.

The decisionWhen to reach for it

In one lineRoot cause traced on BREACH_NEW findings, normalised text match against the answer key, split correct / one hop short / other miss

For each of the 18 BREACH_NEW findings, does the free-text root_cause_system answer name the TRUE root cause? Scored in three outcomes rather than a binary: 'correct' (names the true system or recognises the undocumented step in its own words), 'one hop short' (names exactly the first declared hop when the true origin sits before it), 'other miss' (anything else).

MethodHow the test was run

evals/scoring.py::grade_root_cause, in-process, no key and no model. The same function scores all three arms.

Every grader on these pages scored the same 120 already-recorded answers. Nothing was re-generated, so this compares rulers and not models.

The inputOne real row, seen by every grader

The formulaWhat it computes

A normalised token-overlap/containment match against the gold system name for the 11 documented-origin findings; a keyword recognition test (evals/scoring.py::_mentions_undocumented) against the 7 undocumented-origin findings, because the undocumented step has no fixed proper name to match exactly.

The analysisWhat it actually did

In operationWhat to monitor

Reference standard: The same data/gold.jsonl, carrying the TRUE root_cause_system planted by the generator (a declared hop for 11 findings, an invented undocumented-step label for 7) and, for the 7, the first declared hop's name as the specific 'one hop short' answer.

How tight can the band be? Small denominators throughout: 7 undocumented cells split 5 clued / 2 unclued. One cell moving changes the undocumented rate by 14.3 points -- read the count, not just the percentage.

Cadence: Re-run with the scored eval. Re-run evals/check_labels.py's 'both a clued and an unclued arm' assertion on any change to tools/build_corpus.py's CLUE_IDX / UNDOCUMENTED_IDX.

The decisionWhen to reach for it