“Show Me Where This Number Comes From”: Lex in Daily Compliance Work

The Question Every Audit Ends With

An auditor, a works council or a client’s finance team points at a payslip line and asks: where does this number come from? The calculation is rarely the problem — it is covered by integration tests. The hard part is the statutory value behind it: the allowance, the ceiling, the rate. Without a record, the answer is a search through old e-mails, bookmarks and spreadsheets, and the honest version of it is often “someone typed it in last December.”

Payroll Engine keeps statutory values in data satellites. Lex adds the record to each satellite: a manifest that traces every documented value to its source, stores the source documents as frozen evidence, and states how each value was verified. The technical side — manifest, commands, pipeline gates — is described in Source-Traced Compliance. This article is about what a compliance owner does with it.

Scenario: Tracing a Value to Its Source

Take a fictitious basic tax allowance of 12,000 EUR. The wage type that computes the withholding reads it from the lookup TaxParameter, key BasicAllowance, of the 2026 tax satellite. Its lex entry answers the auditor’s question in one place:

{
  "key": "TaxParameter.BasicAllowance",
  "content": "12000",
  "unit": "EUR",
  "sourceUrls": ["https://example.org/tax-guide-2026.pdf"],
  "sourceLocation": "Employer tax guide 2026, page 4, section 2.1",
  "legalReference": "Income Tax Act s. 12(1)",
  "documentRef": "tax-guide-2026.pdf",
  "verification": {
    "mode": "manual",
    "verifiedOn": "2026-11-03",
    "verifiedBy": "Jane Doe",
    "evidence": "tax-guide-2026.pdf",
    "reviewedBy": "John Doe",
    "reviewedOn": "2026-11-04"
  }
}

Read from top to bottom, the entry says: this is the value, this is the document and the exact place in it, this is the legal norm, this is the copy of the document we used, and these two people confirmed the value against it on these dates. The copy is not a link that may break — it is stored in the satellite’s .lex folder, and its SHA-256 hash is recorded in snapshot.json. If anyone replaces the file or edits the value afterwards, LexVerify reports it.

Scenario: Assembling the Audit Pack

For a formal audit, the evidence of one satellite is a handful of files, each with a clear purpose:

LexVerify lex.json /recursive
LexCheck lex.json /recursive /release Report:Audit/LexRelease.md

With /release the report is the release gate of the satellite: every value has a precise location and a verification record, every main source is an official publication, no value rests on a weak automatic match, every value can be verified again against readable evidence, every zero value is justified, and every evidence file backs a value. The CSV opens in a spreadsheet, which is usually where an auditor wants it. The report also states its limits honestly: documented exclusions are listed with their reason, and the verification count shows how many entries carry an automatic record, a manual record, no record, or are still open. An audit pack built this way does not claim more than the records show.

Scenario: The Annual Update

The riskiest moment of the year is the update to the next cycle. The annual clock leaves little time, and the classic error is a value copied forward unchanged because nobody noticed that it changed. Lex turns the update into a work list:

1. Rollover. LexRollover creates next year’s satellite from the payroll calendar. The previous satellite stays untouched. Every entry in the new one is open — its value is still last year’s, and its verification record is removed.
2. Work list. LexCheck lists the open entries. Each one must be looked at; none is “probably unchanged.”
3. New evidence. The new publications are fetched into the .lex folder with LexFetch.
4. Values and verification. Changed values are updated, and every entry is verified again — automatically where the source is readable, by a person (and a reviewer, where required) otherwise.
5. Freeze, apply, check. LexSnapshot, LexApply, LexCheck. Open entries are skipped by LexApply, so a value that was not verified again cannot reach the regulation through the lex.
6. Regression tests. Only then do the integration tests run against the new values.

What the reviewer checks

• Does every changed value point to a source of the new cycle — not last year’s document?
• Is the sourceLocation precise enough to find the value in under a minute?
• Are values that stayed the same verified against the new source, not just carried over?
• Are new exclusions justified, and are old ones still valid?
• Is the LexCheck report free of open entries and value differences?

Scenario: Four Eyes Where It Matters

Not every source needs the same rigor. A single rate on a clearly structured web page is easy to confirm; a dense tariff table in a scanned circular is not. Lex sets the review rule per source: SingleAuthor by default, or FourEyes. For values from a four-eyes source, a manual verification is only complete with a second person and date. The reviewer records the review with one command over the affected entries:

LexAttest TaxParameter.* "ReviewedBy:John Doe"

LexCheck reports manual records of four-eyes sources that lack the review. Which sources deserve four eyes is a policy decision — typically the ones with the highest financial impact or the highest risk of misreading. Lex makes the decision visible in the manifest and enforces it in the check.

Scenario: The Source Changed Without Notice

Authorities correct publications. A web page is updated mid-year, a table gets a footnote, a document moves. Nobody sends a notification. LexCheck /checkurls loads every source URL and compares it with the snapshot:

• Source gone — 404/410 or an unknown host. The evidence copy in the .lex folder still documents what was used; the source reference needs updating.
• Source text changed — the hash of the normalized text differs from the one recorded at the snapshot. Check whether the value is affected and verify it again.
• Host blocks automated access — reported as a note, not as a pass.

Run as a scheduled job, this turns silent source changes into a finding with a date. One limitation matters in practice: change detection works on readable sources — web pages, spreadsheets, text documents and PDFs with a text layer. A scanned PDF is stored and hashed as evidence, but a change to its published version cannot be detected this way. Where an authority publishes the same values in a readable form, adding that document to the entry's sources makes both automatic verification and change detection possible.

Reading a Verification Record

A verification record is only as useful as the reader’s understanding of it. The two modes mean different things:

Weak matches never become an automatic record. A rate like 22% appears on almost every page, and a table listing 2025 and 2026 side by side holds both years’ values; such matches are reported as ambiguous and need either the exact passage of the source (sourceQuote) or a person. An automatic record never replaces a manual one. For a compliance owner, the useful reading is therefore simple: auto is a strong consistency check against the source, manual is a personal confirmation, and none or open is work still to do. The LexCheck report counts all of them per satellite, and /verificationrequired turns an entry without record into a finding.

Hard Cases, Documented Instead of Hidden

Real statutory sources are not always clean. The value of a manifest is that the difficult cases are written down where the next person will look:

• Two official sources disagree. Record the source that the implementation follows — typically the document addressed to employers for the computation — and keep the other source in sources with a description of the difference. A written clarification from the authority, once received, becomes evidence.
• No official default exists. When the regulation needs a default that no authority publishes, the entry’s description says so and states the rationale. An auditor should be able to tell an official value from a convention at a glance.
• The last published value is still valid. Some values are published once and stay in force until replaced. The entry cites the original publication and its location — it does not invent a successor document for the new year.
• Values keyed by earlier years. A satellite may need values of previous years, for example as reference amounts. Each one gets its own entry with its own source, inside the current satellite.
• A rule implemented in code. If a statutory rule lives in a script instead of a lookup, the lex entry has no regulation value to match. A documented orphan exclusion with a reason makes this visible instead of a silent gap; the same applies to technical lookup values that are not statutory (coverage exclusion).
• A value computed from others. Some figures are in no source because the law defines them as a formula — a reduced levy as a share of the full rate, a monthly threshold as a twelfth of the annual one. A derived exclusion records the formula and the legal reference; the other numbers of the entry are still verified against the source.
• A rule that does not apply. A region without disability insurance has a rate of 0. A notApplicable exclusion says why; a zero without such a reason is reported, so a rate set to 0 by mistake is caught.
• A value of another year. A surcharge published for 2025 may be needed in the 2026 satellite. The entry declares its referenceYear, so it is checked against the right year and listed as such in the report.
• A source that blocks tools. Bot protection, script-only pages and scanned documents cannot be read automatically. A readable copy of the official text in the .lex folder — or a manual verification — keeps the value verifiable; the release gate reports values that have neither.
• A secondary source. A tax calculator or an association summary can help to find a value, but it is marked official: false and must not be the main source of a released value.

One rule applies to all of these cases: the statutory or official rule is the specification. A difference found against the source is a defect to fix — not a known deviation to document, and never a reason to mark a value as derived just to silence a check.

Retro Corrections and Period Boundaries

An audit question often concerns a period that is long closed. Because each cycle is its own satellite with its own validFrom, a retro correction of an earlier period resolves the earlier satellite’s values. The lex follows the same structure: each satellite carries its own manifest, evidence and snapshot, and the rollover creates a new satellite instead of changing the previous one.

The practical consequence: as long as the satellites are kept in the repository, the question “which value did you apply in that period, and where did it come from?” is answered from the satellite of that period — with the evidence as it was frozen then, not with today’s version of the source.

Values Written by People, Scripts or AI Agents

More and more regulation work is assisted by tools and AI agents. That raises a fair question: who guarantees that an AI-proposed value is right? Lex does not need to know who wrote a value. LexCheck compares the regulation with the lex regardless of origin: a lookup value without lex entry is a finding, and a value that differs from its lex entry is a finding. With LexApply as the path into the regulation, a value enters with its source, location and verification state — or it shows up in the report.

This is the same principle that AI Compliance Intelligence describes for reading compliance data: AI is an access layer on top of the compliance record, not a replacement for it. Responsibility for a value stays with the person who verifies it.

Checklist

Annual update

• Rollover run; every entry open; previous satellite unchanged.
• New evidence fetched for every source of the new cycle.
• Every entry verified again — auto where readable, manual otherwise, four eyes where the source requires it.
• Snapshot regenerated, values applied, LexVerify and LexCheck /release without findings.
• Regression tests run against the new satellite.

Audit pack

• lex.json, snapshot.json and the evidence files of the satellite in question.
• LexVerify result and LexCheck /release report (Markdown + CSV).
• The wage type and lookup that produce the payslip line.

Reviewer questions

• Can I find each value in its source from the sourceLocation alone?
• Does each legal reference name the norm that defines the value?
• Which entries rely on automatic verification only, and is that enough for their source?
• Is every derived value backed by a formula and a legal reference, and every zero by a reason?
• Is every exclusion justified in a way an outsider understands?

The commands and the manifest format are part of the open-source Payroll Engine; the full reference is on the Lex page on payrollengine.org. For the developer view — how manifests are built, verified and gated in a pipeline — see Source-Traced Compliance: Lex as Part of the Regulation.