Building auditable regulatory reference data: from legal text to versioned CSV

Regulatory information becomes hard to use the moment it is reduced to an isolated answer. A date, threshold, or obligation may be technically correct today, yet unusable tomorrow if nobody can see its source, scope, or update rule.

A more reliable approach is to treat regulatory guidance as small, maintained reference data. The goal is not to automate legal judgment. It is to make the underlying rules inspectable, versioned, and easy to reuse.

Start with a decision, not a document

The first useful question is rarely “what does the law say?” It is usually “what action must happen, for whom, and when?”

That leads to a compact table with fields such as scope or company size, triggering event, required action, practical deadline, legal reference, source URL, version, and last verification date.

For example, the DUERP obligation matrix separates the duty to maintain a risk-assessment document from the distinct events that require an update. That distinction matters: an annual rule and an event-driven rule must not collapse into one vague reminder.

Preserve the source trail

Every row should point to the most precise primary source available. A generic “French labour law” reference is not enough when a reader needs to verify a threshold or an exception.

Useful source metadata is deliberately boring: source_url, version, and last_verified. This makes changes reviewable and gives downstream users a way to assess currency without guessing from a page’s publication date.

Model timing explicitly

Many regulatory calendars are not a single date. They depend on organisation size, transaction type, or an obligation that starts before another one.

The electronic invoicing calendar is a good example of why a reusable dataset needs separate rows for each company category and obligation. A reader can then filter or integrate the information instead of interpreting a paragraph.

The same principle applies to financial or tax comparisons. A LMNP tax-regime reference should expose thresholds, conditions, and source dates separately from an editorial explanation of the choices involved.

Entity-level tax choices need the same treatment. The SCI IR vs IS comparison separates the taxpayer, the relevant forms, and the mechanics of a distribution so that the regimes are not reduced to a headline tax rate.

Version the data, not only the page

A polished article can explain a rule, but a small CSV makes its operational structure reusable. Publishing both is valuable:

1. A human-oriented page explains context and limitations.
2. A CSV exposes the fields needed for filtering or integration.
3. A public dataset page makes the file discoverable and gives it a stable, citable home.

The CSV does not replace the explanatory page. It makes the claims inside that page testable.

Define maintenance before publishing

A dataset is durable only if someone knows when to revisit it. The maintenance trigger can be simple: a fixed review cadence, a legal text change, an official FAQ or implementation update, or a correction reported by a user.

For each revision, update the affected rows, increment the version, and record a new verification date. Avoid silently changing a table while leaving the old claims visible in screenshots, articles, or documentation.

Keep the boundary clear

This workflow produces a useful operational reference, not legal advice. The data should state its scope, cite the primary sources, and point readers to the fuller explanation when interpretation depends on an organisation’s facts.

That is the practical payoff of treating regulatory content as reference data: less ambiguity for users, clearer maintenance for publishers, and a trail that remains useful after the next rule change.