Regulatory obligation libraries and change-mapping records for regulatory-change AI

What the public record already gives you, and what it does not

Public sources cover the citation layer well and the judgment layer barely at all. Federal Register rules are available in bulk from govinfo, and researchers have linked more than two decades of Federal Register rules (2000 to 2022) to regulations.gov comments using Federal Register document numbers, docket IDs and Regulation Identifier Numbers (RINs) [1]. Those identifiers, plus CFR part and section citations, are the natural primary keys for any obligation dataset you license.

What is missing is obligation-level structure. Breaking a rule into individual "shall" and "must" duties is still largely research work, for example an obligation-level audit of EPA rulemaking, rather than a maintained, licensable corpus linked to controls [2]. The same work notes that regulations.gov bulk data blanks organization names for PII redaction, a reminder that even public regulatory data arrives pre-processed [2].

So the gap a buyer fills is specific: who the obligation applies to, which internal control satisfies it, and how a change to the rule alters that answer. Raw Federal Register NLP corpora and regulatory text for retrieval are covered elsewhere in our industry-specific operational data hub; this page is about the labels built on top.

The record types inside an obligation library

An obligation library is a set of linked tables, not one file. Consultancies and GRC teams typically maintain four record types, and a training set needs all four joined to be useful for an agent that goes from new rule text to a control gap.

• Obligation inventory rows. One row per atomic duty: citation (for example 16 CFR 312.5(c)), the exact text span with character offsets, a normalized obligation statement, and a type such as prohibition, affirmative duty, disclosure, recordkeeping, reporting or notice.
• Applicability assessments. A decision per obligation per entity profile (applies, does not apply, partially applies, needs legal review) with the rationale and the scoping facts used, such as charter type, state footprint, data categories handled or revenue thresholds.
• Regulation-to-control mappings. Links from each obligation to policy sections and control IDs in the firm's framework, which may be a proprietary library or a public catalog such as NIST SP 800-53, ISO/IEC 27001 Annex A or the HITRUST CSF. HITRUST's draft AI security certification requirements, for example, expect organizations to identify and evaluate their legal, regulatory and contractual obligations [4].
• Change-impact assessments. For each amended rule, a diff against the prior version, the obligations added, modified or retired, an impact rating, the controls needing update, and the remediation owner and due date.

Horizon-scanning logs (proposed rules, RIN entries in the Unified Agenda, comment deadlines) are a fifth, optional table. They teach early triage but carry far noisier labels, because many proposals change, or are withdrawn, before finalization.

Illustrative record: one obligation, mapped and versioned

The most reusable unit is a single obligation row that carries its own version history and mapping. The record below uses a real rule as its anchor: the FTC's COPPA amendments were published in the Federal Register on April 22, 2025 as document 2025-05904, took effect June 23, 2025, and had a compliance date of April 22, 2026, with certain paragraphs carved out of that date [5].

Illustrative example: invented to show structure; it does not describe an available dataset.

{
  "obligation_id": "OBL-16CFR312-0042",
  "source": {
    "cfr_citation": "16 CFR 312.x (illustrative paragraph)",
    "fr_document_number": "2025-05904",
    "fr_citation": "90 FR 16918",
    "rin": null,
    "text_span": {"start": 10432, "end": 10711},
    "rule_effective_date": "2025-06-23",
    "compliance_date": "2026-04-22",
    "carve_out": false
  },
  "obligation_type": "affirmative_duty",
  "actor": "operator",
  "normalized_statement": "Obtain separate verifiable parental consent before disclosing a child's personal information to third parties.",
  "applicability": {
    "entity_profile": "edtech_app_us_under13_users",
    "decision": "applies",
    "rationale": "Service directed to children; discloses data to analytics vendor.",
    "reviewer_role": "senior_analyst",
    "second_review": "agreed"
  },
  "mappings": [
    {"framework": "client_policy", "ref": "PRIV-POL-4.2", "relation": "satisfies_partially"},
    {"framework": "NIST SP 800-53 Rev. 5", "ref": "PT-4", "relation": "related"}
  ],
  "change_impact": {
    "prior_version_id": "OBL-16CFR312-0042@2013",
    "change_class": "modified",
    "impact_rating": "high",
    "controls_to_update": ["PRIV-POL-4.2", "VENDOR-ONB-07"]
  },
  "valid_from": "2026-04-22",
  "valid_to": null
}

Three fields do most of the training work: the text span (so extraction models learn boundaries), the applicability rationale (so agents learn reasoning, not just labels), and valid_from/valid_to (so nothing leaks across rule versions).

Version every label to the effective date, or the dataset lies

A mapping is only correct as of a specific rule version, so every label needs bitemporal dates. A rule has a publication date, an effective date and sometimes a separate compliance date with paragraph-level carve-outs, as the COPPA amendments show [5]. An analyst's applicability call made in 2024 against the 2013 rule text is a correct label for that text and a wrong label for the amended one.

Ask for two time axes on every row: when the rule text was valid, and when the analyst made the decision. Without them, a change-impact classifier trains on future knowledge, and an evaluation set silently rewards models for memorizing current answers. The same as-of discipline is covered in depth in point-in-time correct training data.

Also ask how superseded mappings were stored. Some GRC tools overwrite the mapping table in place, keeping only an audit log, which means the historical label has to be reconstructed rather than exported.

Label quality: where obligation datasets usually fail

Obligation datasets fail in predictable, testable places, and most of them come from segmentation and inconsistent taxonomies rather than wrong legal conclusions. Check these before you sign.

• Segmentation drift. One analyst splits a paragraph into four obligations, another into one. Ask for the segmentation guideline and inter-annotator agreement on a shared sample.
• Taxonomy churn. Obligation types and control IDs get renamed when the consultancy upgrades its framework. Require a crosswalk file and the framework version on each mapping.
• Silent "not applicable." Missing rows are often unassessed, not out of scope. Insist on an explicit decision value for every obligation-entity pair in the sample.
• Template rationales. Rationales copied from a dropdown teach nothing. Sample twenty and read them.
• Single-reviewer labels. Prefer records with second review or partner sign-off, flagged per row.

Model-generated labels are not a substitute for adjudicated ones. Research on LLM evaluation for public comment analysis finds that models can disagree when analyzing regulatory public comments, which makes evaluation sets without human adjudication hard to trust [3]. For a shared vocabulary on completeness, accuracy and consistency measures, ISO/IEC 5259-2 is a reasonable reference to write into acceptance criteria [7].

Rights: public text, proprietary analysis, client-owned conclusions

Regulation text is public, but the obligation library built on it may be protected, and client-specific mappings may belong to the client. As of October 2026, the Third Circuit has affirmed that Westlaw headnotes at issue in Thomson Reuters v. ROSS were original enough to be copyrightable [6]. Normalized obligation statements and analyst summaries written by a consultancy are analogous original analysis, so treat them as licensed content rather than free metadata.

The harder question is ownership of client work product. A consultancy's applicability decisions for a named client often fall under that engagement's confidentiality and deliverable-ownership terms, and the client's internal policy IDs and control descriptions are the client's information. Ask the supplier to separate three layers: the firm's generic library, client-specific assessments, and client-authored policy text, with the rights basis for each.

Strip or pseudonymize client names, entity profiles that would identify a client, and personal data in reviewer and owner fields. For assignability if the supplier is acquired, see assignment and change of control in AI data licenses.

This page is general information, not legal advice. Confirm requirements with counsel for your jurisdiction and use case.

Matching record types to model tasks

Different model tasks need different slices, and a buyer who asks for "the whole library" usually overpays for tables they will not use. Use this table to scope the request.

Illustrative example: invented to show structure; it does not describe an available dataset.

Mapping obligations to controls resembles the schema-mapping problem in data integration; the evaluation patterns in schema matching and source-to-target mapping data carry over. Downstream evidence that controls actually operate lives in testing workpapers, covered in SOX and internal control testing workpapers.

A request template for obligation-mapping data

A good request describes jurisdictions, rule families, record types and label provenance, not a supplier name. Adapt this to your scope.

Illustrative example: invented to show structure; it does not describe an available dataset.

• Jurisdictions and rule families: US federal privacy and consumer-finance rules (for example 16 CFR Part 312, Regulation E, Regulation Z), plus state privacy statutes in named states.
• Record types: obligation inventory, applicability assessments, control mappings, change-impact assessments; horizon-scanning logs optional.
• Time window: decisions made across at least two amendment cycles per rule family, with valid-from and decided-at dates.
• Keys: CFR citation, FR document number, docket ID, RIN where present [1].
• Frameworks: name and version of each control catalog; crosswalk if the library changed frameworks.
• Label provenance: reviewer role, second-review flag, guideline version; no model-generated labels without a flag.
• De-identification: client names, entity identifiers and personal data in reviewer fields removed or replaced, method documented.
• Intended use: fine-tuning an extraction and mapping agent, plus a held-out evaluation set.

How SourceX handles obligation-mapping requests

SourceX sources operational datasets from US companies on request, including documents and legal workflows; nothing is held in stock, and a request does not guarantee a match. You describe the obligation records you need, not the firms, and SourceX looks for US businesses that hold them; every release is approved by the supplying company. Each dataset is rights-reviewed for ownership and consents, personal details such as names and emails are removed or replaced before delivery with the method recorded and a sample checked, and delivery runs under a license that defines records, uses, term and delivery. You can describe your obligation-mapping data request once your scope is clear.

For context on the supplier side, see the compliance consulting buyers page, the compliance records overview, how compliance remediation records are used and SOP and knowledge base datasets. For de-identification background, start with the privacy guide for AI training data.

Source obligation-mapping records for your regulatory-change AI

SourceX looks for US companies that hold the operational records you describe, assesses data and licensing permissions, and manages the license and ongoing purchases; nothing is contracted until a supplier agrees. Prices are not published and terms are agreed per deal. Start your request at sourcex.si/buyers.