A changed sentence is not yet a change programme
A regulator publishes a revised document. The organisation must determine what changed, which provisions apply, which obligations are new or altered, which policies and controls are affected, who owns the response and what evidence will demonstrate implementation. Most of that work happens after document comparison.
An unsafe system jumps from a highlighted sentence to an automatically assigned control update. Legal text contains scope, definitions, cross-references, exceptions, transition dates and supervisory context. A deletion can narrow an obligation, remove a duplication or move text elsewhere. A new recital or example may influence interpretation without creating a direct requirement.
Preserve the publication object
Regulatory change begins with source integrity. The intake service records publisher, document identifier, jurisdiction, legal status, publication date, effective date, consultation or final status, language, retrieved file, checksum and source URL. It should not rely on an email attachment or an unversioned webpage as the master object.
| Source field | Why it matters | Example failure |
|---|---|---|
| Publisher and authority | Distinguishes regulator, legislature, industry body and commentary | Consultancy summary treated as binding text |
| Document status | Separates consultation, final rule, guidance and speech | Proposal enters mandatory implementation queue |
| Version relation | Identifies amendment, replacement, correction or consolidation | Corrected text compared with the wrong baseline |
| Effective and transition dates | Drives implementation timing and historical applicability | Publication date used as compliance date |
| Jurisdiction and entity scope | Limits applicability assessment | Group-wide task created from local guidance |
| Language and translation | Preserves authoritative text and transformation | Machine translation treated as legal source |
| Checksum and retrieval time | Makes the source replayable | Later webpage change cannot be detected |
The system should retain both native and rendered structures. Numbered provisions, schedules, tables and footnotes carry meaning that plain-text extraction can lose. The W3C PROV-O recommendation can represent derivation between source, extraction, comparison and candidate obligations, while legal meaning remains governed by the organisation.
Compare structure before meaning
Line-by-line diff is useful only when document structure is stable. Regulatory documents renumber clauses, move sections and consolidate amendments. The comparison engine should first align document hierarchy and cross-references, then compute textual change within aligned units.
Each change object should state whether text was added, removed, edited, moved or renumbered. It links both versions and shows surrounding definitions and referenced clauses. A semantic model can propose that two moved passages are equivalent, but the view must expose the exact text and confidence.
The unit of review is a change object with context, not a generated summary of the whole publication. Reviewers need to see what changed and what did not.
| Change class | Machine contribution | Required human question |
|---|---|---|
| Addition | Locate and classify candidate requirement-bearing language | Does it create, clarify or illustrate an obligation? |
| Deletion | Show removed text and dependencies | Is the obligation removed, relocated or retained elsewhere? |
| Modification | Highlight semantic and deontic changes | Does “should” become “must,” or does scope change? |
| Move or renumber | Align old and new structure | Is meaning preserved after cross-reference changes? |
| Definition change | Identify every dependent provision | Which existing interpretations and controls are affected? |
| Date change | Recompute implementation milestones | Which products, entities or historical cases fall in transition? |
Extract candidate obligations with a typed taxonomy
The extraction stage should not emit a flat list of “requirements.” A useful taxonomy separates mandates, sub-mandates, obligations, permissions, prohibitions, conditions, exceptions, evidence expectations, reporting duties and definitions. Each candidate remains linked to the exact source span.
Research is moving toward these structured tasks. De Jure evaluates iterative extraction of machine-readable regulatory rules. From Regulation to Requirements studies traceable derivation of software requirements from regulatory text. ComplianceNLP combines obligation extraction, cross-reference resolution and graph-supported gap analysis. These are useful technical signals, not proof that an institution can delegate legal interpretation.
Every candidate carries an extraction version, type, source span, actor, action, object, conditions, exceptions, timing and uncertainty. The model must be able to abstain when a clause depends on an unresolved definition or external instrument.
Applicability is an authorised decision
Applicability depends on legal entity, regulated activity, product, customer, jurisdiction, threshold, date and transitional arrangement. The system can assemble these attributes and retrieve prior decisions, but an authorised role accepts the determination.
The decision record should explain the basis, evidence and approver. A group policy may choose broader application than the minimum local rule. That is a policy decision and should be distinguished from the legal applicability conclusion.
The FCA's June 2026 statement on AI says the regulator will rely on existing frameworks including the Consumer Duty, SM&CR and governance expectations rather than create a separate AI rulebook. For regulatory-change architecture, this means an “AI regulation” keyword feed is inadequate. Existing obligations can change how an agentic system must be governed even when the publication does not use the word agent.
| Applicability state | Meaning | Required record |
|---|---|---|
| Applicable | Obligation binds the named scope | Basis, scope, effective date and owner |
| Partially applicable | Only stated entities, activities or provisions apply | Inclusion and exclusion rationale |
| Policy adopted | Institution voluntarily applies a rule or standard | Policy owner and chosen scope |
| Not applicable | Authorised analysis concludes it does not bind | Reason, evidence and review trigger |
| Pending | Missing fact, interpretation or external decision | Owner, dependency and due date |
| Superseded | Later source replaces the treatment | New obligation link and historical validity |
Map obligations through capabilities, processes and controls
Directly matching a regulatory sentence to a control produces brittle many-to-many links. A better graph moves through institutional concepts: obligation, policy statement, business capability, process, data object, system, risk, control, test and evidence. Each edge has an owner, confidence and review state.
The graph supports impact analysis in both directions. A changed definition can identify dependent obligations and policies. A failed control can show which obligations it supports. A system migration can reveal affected regulatory evidence. The graph should not create an illusion of certainty: proposed edges remain separate from approved mappings.
| Mapping evidence | Strength | Limitation |
|---|---|---|
| Existing approved obligation-control mapping | High for unchanged scope and versions | May be stale after process or policy change |
| Shared controlled vocabulary | Useful candidate generation | Similar labels do not prove coverage |
| Process and system lineage | Shows operational dependency | Does not establish policy interpretation |
| Control objective and test | Indicates how outcome is evidenced | One control may only partly cover obligation |
| Model similarity | Finds non-obvious candidates | Must not auto-approve mapping |
| Reviewer confirmation | Establishes accountable institutional mapping | Needs periodic challenge and versioning |
Coverage is not the number of edges. A mapped obligation can still be under-controlled if the control objective is incomplete, the population is wrong or the evidence is weak.
Turn change objects into owned work
Once applicability and impact are approved, the system creates implementation candidates. Each task names the obligation, affected policy or control, accountable owner, required artefact, dependency, due date and closure evidence. It should not assign work solely by the owner of a similar historical task.
Implementation state must remain distinct from regulatory interpretation. A task can be complete while the control test has not yet produced evidence. A policy can be published while system changes remain open. Closure therefore requires the stated evidence for each work package and a final owner decision on residual gaps.
The system should also retain withdrawn and rejected proposals. They explain why one source change did not create action and protect against repeated analysis when the same interpretation question returns.
Evaluate the whole chain
Regulatory-change evaluation should include source integrity, structural alignment, candidate extraction, cross-reference resolution, applicability support, mapping usefulness, work-package correctness and closure evidence. Gold labels should be created by authorised domain experts and include legitimate disagreement.
| Layer | Useful measure | Dangerous shortcut |
|---|---|---|
| Source | Correct publication identity and version relation | Counting downloaded documents |
| Diff | Clause alignment and material-change recall | Raw character-diff volume |
| Extraction | Span accuracy, type accuracy and exception capture | Plausible obligation paraphrase |
| Applicability | Evidence completeness and correct routing | Model agreement with one reviewer |
| Mapping | Recall of affected policies and controls with low false expansion | Similarity score alone |
| Delivery | On-time evidence-backed closure and reopened gaps | Task marked complete |
Adversarial cases should include renumbered clauses, corrected publications, identical text with new scope, changed definitions, conflicting translations, consultation material, indirect cross-references and prompt injection in external commentary. The agent must treat publications as data, not instructions to change its task.
Production monitoring should track intake delay, source corrections, unresolved interpretations, mapping overrides, orphan obligations, ageing tasks, evidence rejection and reopened change records. A low number of changes can indicate missed sources rather than stability.
Govern the graph as a record of institutional judgement
Legal or compliance owns interpretation. Business owners accept process impact. Control owners maintain mappings and evidence. Architecture and engineering own system change. The platform team owns source ingestion, graph services, workflow, access and evaluation. Internal audit may use the chain as evidence but retains independent scope and conclusion.
The EBA's June 2026 risk assessment emphasises risk-sensitive and transparent AI governance alongside DORA obligations. The Bank of England's February 2026 AI roundtable summary records industry concern that traditional validation and generic “human in the loop” controls may not scale for agentic systems. A regulatory-change service should therefore expose system outcomes, guardrails and evidence rather than rely on a reviewer clicking through model output.
The business case should measure time from publication to verified impact, duplicate analysis removed, mapping reuse, missed-change rate, review effort, task ageing and closure-evidence quality. It should not claim value from the number of generated obligations.
Follow a publication from intake to verified closure
Consider a final regulatory publication that changes customer due-diligence expectations, introduces a phased effective date and replaces part of an earlier instrument while retaining several definitions by reference. It arrives after consultation material and a supervisory speech on the same topic. A conventional keyword monitor creates three overlapping alerts and routes them to different teams.
The source registry classifies each item by authority, jurisdiction, instrument type and lifecycle. The final publication becomes the operative source. Consultation and speech remain contextual evidence but cannot create obligations. Structural comparison aligns the final clauses to the previous instrument, identifies changed definitions and preserves cross-references and exceptions.
An authorised compliance reviewer confirms that the institution is in scope and records the applicable entities, products and dates. The graph connects each accepted obligation to policies, onboarding processes, customer-data attributes, decision rules, training and controls. Owners receive bounded work packages with acceptance evidence rather than the whole publication.
Closure requires more than an attestation that a document was updated. The system verifies the approved policy version, deployed rule, completed control test and relevant population treatment. Any residual interpretation or transitional dependency remains open. The completion unit is an evidenced operating change, not a circulated regulatory summary.
Define a stable obligation graph schema
The graph should distinguish what the authority published, what the institution interpreted and what the institution changed. Mixing these layers makes it difficult to revisit a judgement without implying that the source text changed.
| Node type | Owned facts | Example relation |
|---|---|---|
| Publication | Authority, identifier, status, dates, language, digest | supersedes publication |
| Provision | Source span, numbering, definitions, exceptions | amends provision |
| Candidate obligation | Extracted actor, action, object, condition, time | derived from provision |
| Applicability decision | Entities, products, rationale, approver | accepts candidate obligation |
| Capability | Customer due diligence, reporting, monitoring | fulfils obligation |
| Process or journey | Operating steps and owner | realises capability |
| Policy or control | Version, effectivity and evidence | governs process |
| Change package | Scope, owner, due date, dependencies | implements obligation |
| Closure receipt | Tests, approvals and deployed state | verifies change package |
Every edge records source, owner, valid interval and decision status. A similarity model may propose a mapping, but accepted edges require the authority appropriate to the object. A process owner cannot decide legal applicability. A compliance reviewer cannot attest that a technology control was deployed without operating evidence.
The graph permits one-to-many and many-to-one relations. One obligation can affect many controls. Several obligations can be implemented through one platform change. This avoids duplicate programmes while retaining traceability. Graph reuse is valuable only when every reused edge remains reviewable and time-bounded.
Monitor authoritative sources and their corrections
Source acquisition needs more than a web crawler. The registry should use official feeds, publication pages and named repositories with permitted retrieval. It records HTTP metadata, document digest, language, annexes, status and observed time. A missing expected feed is an operational alert.
Corrections and consolidated versions require explicit treatment. A file with the same title and a different digest is quarantined until the relationship is known. The platform does not overwrite the earlier copy. It creates a new publication version, re-runs structural alignment and identifies affected institutional decisions.
Machine translation can assist routing, but the source language and official translations remain authoritative according to policy. Conflicting versions are surfaced. The system preserves tables, footnotes and annexes because material requirements often reside outside body paragraphs.
External commentary can help discovery and interpretation research, but it is stored as commentary, never as an authority source. Sponsored summaries, search snippets and model memory cannot establish operative text. This distinction reduces the risk that a well-ranked secondary article becomes the basis of institutional change.
Make interpretation disagreement visible and governed
Regulatory language can support several defensible readings. The platform should represent alternatives with cited spans, assumptions, affected scope and proponent. It should not ask a model to merge them into a smooth compromise.
The comparison separates source meaning, applicability assumption, business impact and confidence. Reviewers can request external counsel or supervisory clarification. Pending questions have owners and dates. Downstream work may proceed on an explicitly conservative assumption when authorised, but that assumption remains linked and revisable.
Challenge does not disappear after acceptance. A policy owner can contest a mapping. A delivery team can show that an existing control already satisfies the intended outcome. A later clarification can reopen the decision. The graph preserves the prior rationale and determines which work packages and closure receipts need review.
Models can produce candidate structures and retrieve similar precedents. Precedents are evidence of institutional history, not binding interpretation. They must be filtered for jurisdiction, instrument, entity and time. A prior answer is useful context only when the system can show why it is comparable.
Govern delivery dependencies and closure evidence
Regulatory change often crosses policy, data, technology, operations, training and assurance. The change graph should express dependencies and critical path rather than create a flat task list. A policy may be approved before a system rule is ready. Training may depend on the final procedure. Control testing needs a deployed environment and representative data.
Each package declares acceptance evidence, responsible owner, approver, due date, predecessor and rollback plan. Status is derived from verified receipts where possible. A ticket marked done does not prove a rule is deployed. A policy document in draft does not prove approval. A completed training file does not prove the intended population received it.
Closure review checks that every material obligation has an accepted applicability decision, mapped implementation, operating evidence and residual-risk treatment. It also checks effective dates and transitional populations. Where a staged rollout is authorised, the open population remains visible.
Architecture review should ask whether authoritative and contextual sources are separated, whether source corrections invalidate dependent decisions, whether graph layers preserve authority, whether alternative interpretations remain visible, whether dependencies drive a credible critical path. Whether closure uses operating evidence rather than task status.
Measure the operating system, not document volume
Useful measures follow the chain from source to operating effect. Intake latency measures how quickly an authoritative item is verified. Interpretation lead time measures accepted decisions, not summaries produced. Mapping reuse measures reviewed edges. Delivery measures ageing, dependencies and evidence rejection. Assurance measures missed changes, reopened obligations and defects found after closure.
| Measure | Why it matters | Control against gaming |
|---|---|---|
| Verified intake latency | Detects monitoring gaps | Denominator is expected source universe |
| Material-change recall | Tests structural comparison | Expert sample includes renumbering and exceptions |
| Decision turnaround | Shows interpretation bottlenecks | Stop clock only on accepted or formally pending decision |
| Mapping acceptance | Measures useful reuse | Count owner-reviewed mappings, not suggestions |
| Evidence-first closure | Tests operating implementation | Sample receipts against authoritative systems |
| Reopen and defect rate | Reveals premature completion | Preserve source and causal classification |
The service should also report unknowns: inaccessible sources, unresolved cross-references, missing owners, contested mappings and unverifiable closures. A low alert count or fast average closure can indicate suppressed complexity. Metrics are reviewed by risk and business owners together.
Treat security, privacy and resilience as design inputs
The service ingests untrusted external documents and can influence enterprise change. It needs a strict boundary between source content, agent instructions and authorised actions. Publications may contain links, scripts, hidden text or malformed structures. Parsers run in isolated environments. Retrieved content cannot select tools, change system policy or request data from internal repositories.
Internal retrieval is purpose-bound. A regulatory mapping task may access policy and control metadata without receiving customer records. Workload identity, user role, legal entity, jurisdiction and change record travel to enforcement points. Sensitive implementation evidence is disclosed only to authorised reviewers.
Side effects use proposed, approved, submitted, verified and unknown states. If a task-creation request times out, the controller reconciles by idempotency key before retry. If a policy publication system reports ambiguous state, closure remains open. The service never marks implementation complete from a drafted message or attempted API call.
Resilience design includes source-feed failure, authority-site change, parser failure, graph corruption, workflow outage and model-provider disruption. The system can continue deterministic inventory and workflow functions when drafting is unavailable. It can operate from a verified last-known source only under explicit freshness policy and shows that limitation.
| Dependency failure | Safe degradation |
|---|---|
| Official feed unavailable | Alert expected-source gap; do not claim no change |
| Parser rejects document | Preserve original and route manual intake |
| Model service unavailable | Continue source, graph and task operations without synthesis |
| Mapping index stale | Disable suggestions; retain accepted graph |
| Workflow API ambiguous | Reconcile external state before retry |
| Evidence store unavailable | Block closure and disclosure |
The NIST AI RMF provides a useful governance frame. The NIST guidance on secure software development informs protected build and release. The Basel Committee's principles for operational resilience are relevant to the service's ability to support critical regulatory response through disruption. These references inform controls; the applicable institutional obligations still require authorised interpretation.
Use architecture review to bound authority
Before release, the design authority should be able to answer:
- Which official sources are expected, and how is a missing feed detected?
- How are consultation, guidance, speech, final rule, correction and consolidated text distinguished?
- Which publication version and clause support each candidate obligation?
- Who can accept applicability for an entity, product and effective date?
- Can process and control mappings be challenged without changing source interpretation?
- Which operating evidence proves policy, system, data, training and control changes?
- What happens when a source correction or legal clarification arrives after closure?
- Can external text alter tools, internal scope or task creation?
- How are ambiguous external actions reconciled and duplicate tasks prevented?
- Which signals force rollback, reopening or narrower automation?
Authority should narrow as consequence increases. Models can monitor, compare, extract and propose. Authorised experts interpret. Business and control owners accept impact. Delivery owners implement. Independent functions challenge and assure. The graph connects those acts without merging their accountabilities.
The release plan should reflect that boundary. Begin with source integrity and clause comparison. Add candidate obligations under mandatory review. Add mapping suggestions only where the institutional inventory is mature. Introduce task creation after idempotency and verification work. Closure remains human-approved and evidence-backed. Each expansion uses observed error, correction effort and operational incidents from the prior stage.
Keep a decision ledger for audit and reuse
The graph stores current relations, while the decision ledger records how they were accepted. Each entry names the question, source evidence, alternatives, authority, rationale, effective interval and downstream objects. This makes reuse safer because a team can inspect the basis before adopting an earlier mapping.
A reused decision carries its jurisdiction, legal entities, products, source version and time. If those dimensions differ, the system presents it as a candidate precedent rather than an answer. Reviewers can accept, adapt or reject it. The new decision points back to the earlier one without overwriting either rationale.
The ledger is also the basis for impact analysis. A corrected clause can identify every applicability decision that cited it. A retired control can identify obligations whose implementation mapping may be incomplete. A changed product perimeter can identify decisions with an outdated scope assumption.
Audit views should expose the chain without granting unrestricted access to privileged advice or security-sensitive implementation. The ledger can retain protected evidence references and provide role-specific renderings. Record retention follows the governing change, legal and assurance policies.
Institutional memory becomes useful when it preserves context and dissent, not when it turns yesterday's answer into a global default. This is the practical advantage of a decision ledger over a folder of summaries.
The operating model should include horizon scanning, formal change intake, interpretation, impact, delivery and assurance as distinct services. They can share the publication and obligation graph, but each has different owners and evidence. A horizon signal may justify attention; it does not enter delivery as an accepted obligation until the authority and lifecycle are established.
Capacity planning should reflect publication bursts and correlated deadlines. The service can prioritise by authority, materiality, effective date, scope uncertainty and dependency depth. A language model may help assemble the queue, but the priority rule and overrides are visible. Low-ranked items remain in the expected-source inventory so they cannot disappear.
Post-implementation review samples closed changes against operating evidence and customer or control outcomes. Defects feed mapping, delivery and source-process improvement. They do not automatically rewrite the legal interpretation. The causal layer must be identified before the graph is corrected.
This federated model creates a common trace while preserving professional boundaries. It is also portable: replacing a retrieval or model component should not erase the institution's publication inventory, accepted decisions or closure evidence.
The goal is not to automate regulatory judgement. It is to make every judgement easier to locate, challenge, update and connect to operating evidence. A traceable obligation graph turns change management from document circulation into an accountable system of record for interpretation and response.