The workpaper is a compiled claim

A regulation is written for a class of situations. A workpaper speaks about one institution, one scope, one period and one conclusion. Between those endpoints sit several decisions that are often flattened into a row called “control mapping”. The row creates an appearance of traceability while concealing the mechanism that would make the conclusion true.

Consider a source statement that requires a firm to monitor whether customers receive good outcomes. It does not itself identify the bank’s legal entities, products, journey stages, authoritative systems, measures, thresholds, exceptions or reviewers. Those facts arise from legal interpretation, business design, risk decisions and operational knowledge. A useful compiler therefore narrows meaning in stages instead of translating prose directly into code.

The eight objects in the lineage

The first object is the source version: the exact provision, its authority, status, amendments, commencement and applicability dates, definitions and cross-references. Machine-readable legal-document standards such as Akoma Ntoso can preserve document structure. A representation standard improves addressability; it does not decide which interpretation a bank must adopt.

The second object is a candidate norm. It records whether the source appears to create an obligation, prohibition, permission, reporting duty, governance expectation or evidential requirement. LegalRuleML is relevant because it can represent deontic and temporal features that simple if-then rules discard. The candidate remains a proposal until an authorised role accepts its meaning and scope.

The third object is the applicability decision. It binds the candidate norm to legal entity, jurisdiction, product, customer class, activity, role, materiality condition and effective period. Applicability is where generic law becomes an institution-specific claim. It requires an accountable decision, supporting facts and visible unresolved questions.

The fourth is the institutional obligation: a concise statement of what the bank must do, prevent, evidence or decide. It should name the intended outcome and the responsible function. Copying a paragraph from the source is insufficient because the source often contains several norms and conditions.

The fifth is the control contract. It explains the mechanism expected to discharge the obligation. A control contract names the risk, objective, complete population, unit of assessment, predicate or assessment method, frequency, tolerance, unknown-state policy, owner, evidence requirements and human judgement points. This is where “monitor outcomes” becomes a specified monitoring design rather than a dashboard aspiration.

The sixth object is the test execution. It records the approved test version, runner identity, authoritative inputs, cut-off, population manifest, observations, errors and deterministic classifications. Tests can be queries, samples, reconciliations, walkthroughs, model validations or mixed methods. The compiler does not assume that every control is reducible to code.

The seventh is the exception and response set. Each exception has scope, rationale, approving role, compensating control, effective period, expiry, residual risk and remediation. A failed predicate and an accepted exception are different facts. An exception cannot rewrite the underlying observation to “pass”.

The eighth object is the workpaper conclusion. It states scope, period, method, observations, limitations, exceptions, unresolved items and the accountable conclusion. A model may draft readable prose, but protected values and relationships must come from the signed evidence graph and be validated after generation.

Here, W is the workpaper at assessment time t. For every lineage link i, A means the decision has the required authority, V means its version is valid at that time, P means provenance is present, and C means the relevant scope is complete. J is the accountable human conclusion where judgement is required.

The conjunction matters more than the notation. These are hard gates, not scores to average. An excellent test cannot compensate for the wrong legal entity. A signed workpaper cannot compensate for missing evidence. A current source cannot compensate for an expired exception. Defensibility is limited by the weakest required link because each link supplies a different kind of warrant.

flowchart LR
  A["The green workpaper that<br/>proved nothing"] --> B["The workpaper is a compiled claim"]
  B --> C["Authorise meaning before code"]
  C --> D["Make evidence fail honestly"]
  D -. "re-test" .-> A
  classDef first fill:#0a1424,stroke:#7B4CD8,stroke-width:2px,color:#e6f3ff
  classDef step fill:#0a1424,stroke:#3f7da0,stroke-width:1px,color:#e6f3ff
  class A first
  class B,C,D step

Authorise meaning before code

The temptation in regulatory technology is to place a language model at the front of the pipeline, generate rules, and celebrate the disappearance of manual mapping. That design accelerates the easiest visible activity while leaving the consequential decisions implicit. The important question is not whether a model can produce syntactically valid logic. It is whether the logic represents an authorised institutional obligation under the correct facts and dates.

Thought experiment one: hold the words constant, change only the entity

Imagine one provision and two subsidiaries. Subsidiary North manufactures a retail product and controls its communications. Subsidiary South only provides an unregulated technical service to North. Keep the source text, customer journey, model output and monitoring query identical. Change only the legal entity whose workpaper is being compiled.

If the system converts text directly into a universal control, both subsidiaries receive the same obligation and the same red or green status. A competent lawyer may instead conclude that the provision applies directly to North, while South carries contractual and operational responsibilities that support North’s compliance but do not arise from the same rule. The technical query can still be useful for both. Its legal meaning, owner, escalation route and conclusion differ.

Applicability is therefore an input to execution, not an output inferred from execution. The compiler must bind an accepted scope decision to the source digest and the relevant institutional facts. When those facts change, the compiler reopens applicability. It does not let yesterday’s answer propagate as a global default.

A minimal worked example: customer understanding

Take a deliberately small scenario. A bank has accepted an obligation to monitor whether a specified group of retail customers understands a revised current-account fee communication. The obligation applies to one legal entity, one product and one communication version for a defined period. The control owner approves a test contract before any result is calculated.

The contract defines the population as every customer who received version C of the communication during the period. The unit is a customer communication event. The method combines delivery confirmation, a short comprehension check and a targeted review of vulnerable-customer cases. The contract forbids the monitoring service from dropping records with unavailable comprehension data. Those records become unknown. It also states that one aggregate percentage cannot override a material subgroup failure.

Suppose the expected population is 1,000 events. The evidence service receives 940 complete observations, 35 failed comprehension checks and 25 unavailable outcomes. A naive dashboard divides 905 favourable observations by the 940 it received and reports 96.3 per cent. The contract instead preserves the expected denominator: 905 pass, 35 fail and 60 unknown, because the missing 25 must be added to the 35 unavailable cases already observed. The control owner cannot conclude effective operation until the unknown scope is resolved or an authorised limitation is accepted.

This design aligns with the direction of the FCA’s published Consumer Duty monitoring material. The FCA describes stronger approaches as structured and evidence-based, with clear definitions of outcomes, monitoring across journey stages, data-led decisions, governance and action. Its reviews also identify weaknesses where high-level indicators are not tied to concrete outcomes, thresholds lack evidence, or reporting gives limited insight into actual customer experience. See the outcomes-monitoring review and the multi-firm review.

The example does not claim that the FCA prescribes this exact data model or threshold. It shows how an institution can make its own monitoring logic reviewable. The legal source and official guidance shape the obligation. Authorised roles choose the institution-specific outcome definition and control design. Deterministic services then preserve the population, apply the accepted method and report uncertainty without editorial improvement.

The four authority gates

Four decisions should remain visibly human-accountable even when models assist. First, an authorised legal or compliance role accepts the interpretation and applicability record. Second, a control owner accepts that the proposed mechanism is reasonably connected to the obligation. Third, the appropriate risk owner decides whether an exception and compensating control are acceptable. Fourth, a reviewer or governing body makes the conclusion required by its mandate.

These gates need not imply paper signatures or slow serial committees. They can be typed approvals with role validation, purpose, evidence viewed, expiry and delegation. The design goal is to prevent ambient authority. A model that drafted the obligation cannot approve it. A test runner that observed a failure cannot accept the risk. A control owner cannot inherit independent assurance simply because the same platform renders both views.

Machine assistance remains valuable between the gates. Models can identify candidate provisions, propose mappings, compare versions, draft test specifications, summarise exceptions and explain evidence to different reviewers. Each proposal retains the model, prompt, source set and uncertainty needed for challenge. Acceptance creates a new institutional object; it does not retroactively turn the model’s suggestion into legal fact.

The reporting experiment that should restrain us

Digital regulatory reporting is the strongest competing case because some reporting rules are genuinely close to executable. Regulators and firms can agree data definitions, formalise calculations, publish validation rules and compare generated reports with known outputs. The FCA’s Digital Regulatory Reporting work explored this possibility, and the Bank of England later reviewed several machine-readable and executable reporting initiatives.

The review supplies a useful negative result. In Project Ellipse, a narrow mortgage-reporting proof of concept considered about 120 data points, while definitions for only about 32 were mutually agreed. A separate proof of concept for EMIR reporting concluded that its then-current implementation was not fit for purpose because the available data models lacked necessary fields or equivalents and did not support some requirements. These findings do not disprove machine-executable regulation. They reveal the precondition it cannot manufacture: shared semantics and sufficient data models.

The correct inference is bounded. Where terms, scope, data and calculations are authoritative, a regulator or institution can publish executable artefacts beside legal text. That can reduce divergent implementation and improve change response. Where a requirement depends on purpose, proportionality, materiality, reasonable steps, customer outcomes or contested facts, full compilation is unavailable. The system should emit an assessment plan and explicit questions rather than synthetic certainty.

The compiler’s most important output may be a refusal to compile. A refusal can name the unresolved definition, missing population source, disputed applicability fact or unapproved exception rule. That turns ambiguity into owned work. Automatic code generation that guesses past those gaps merely relocates legal and operational risk into a less visible layer.

Make evidence fail honestly

Once the control contract is accepted, deterministic execution becomes more useful. The execution service should know what it may read, which population it expects, which version of the test it runs, what constitutes pass or fail, and which conditions create an unknown result. It should not have authority to change the target system or to edit an accepted observation after the fact.

The distinction among pass, fail and unknown is foundational. Pass means the admitted predicate is satisfied for the in-scope subject under the recorded evidence. Fail means it is not satisfied. Unknown means the service cannot support either conclusion because scope, access, evidence, parsing or execution is incomplete. Treating unknown as pass rewards outages and permission loss. Treating unknown as fail confuses evidence-system reliability with control failure. Both distort management action.

Thought experiment two: hold the estate constant, remove one evidence feed

Imagine a control that reconciles every critical ICT service to a current owner, recovery objective and test record. On Monday, all 300 services are observed and 294 satisfy the predicate. On Tuesday, the actual estate is unchanged, but the provider inventory API denies access to 40 records after a role change. Keep the control, threshold and underlying services constant. Vary only evidence availability.

A system that divides by observed records may report an improved pass rate because difficult cases disappeared. A system that repeats Monday’s result may conceal the age and the altered evidence condition. A defensible system reports 260 observed subjects and 40 unknowns, blocks a completeness conclusion, and preserves Monday’s accepted result as a distinct historical object. The missing API permission is an incident in the evidence chain, not proof that 40 controls failed or passed.

This is why the workpaper needs both an expected population manifest and an observed population manifest. Their difference is evidence. It also needs collection errors, runner identity, source timestamps and test version. A screenshot of a green dashboard cannot reconstruct those facts.

Two clocks and one semantic fingerprint

A workpaper needs at least two clocks. Valid time records when a source, applicability decision, control or exception is meant to apply in the world. Transaction time records when the institution learned or recorded it. The distinction matters when a correction arrives late, an amendment has a future application date, or an exception is approved after a control run.

Suppose a rule amendment applies from 1 October, but the bank records it on 12 October. A workpaper for 8 October cannot be reconstructed by asking only what the database contained at the time. It needs the rule’s legal validity and the institution’s contemporaneous knowledge. The difference may produce an incident, a retrospective assessment or a limitation. Erasing the late arrival would erase the very fact an assurance reviewer needs.

A semantic fingerprint helps detect change. It can hash the source version, applicability decision, control contract, population manifest, test version, exception set, evidence cut-off and approval record. The hash is not legal proof and cannot establish that the inputs were correct. It answers a narrower question: are these exactly the inputs previously reviewed? If one changes, the old workpaper cannot masquerade as the current one.

χ(W) is the workpaper fingerprint, H is a cryptographic hash, and ∥ means canonical concatenation. A change in any listed input produces a different fingerprint. Canonicalisation, secure storage, identity and signing remain separate engineering requirements.

A production-shaped DORA case

Consider a composite bank operating across several European entities. The institution has accepted obligations under the Digital Operational Resilience Act relating to ICT risk management, incidents, resilience testing and third-party risk. DORA has applied since 17 January 2025 and is supported by regulatory and implementing technical standards. The official EIOPA overview summarises these areas, while the regulation itself remains the authoritative legal source.

The bank’s obligation graph separates the Level 1 regulation, relevant technical standards, supervisory interpretations and internal decisions. Applicability records bind each requirement to financial entity, critical or important function, ICT service, provider relationship and effective period. A “DORA compliant” flag would be meaningless because no single predicate spans that structure.

One control family concerns the register of ICT third-party arrangements. The control objective is that every in-scope arrangement supporting a financial function is present, correctly classified, owned and maintained with the required information. Its population is not “contracts found in procurement”. It is the reconciled set of provider arrangements derived from service inventories, accounts payable, contract repositories, architecture records and business ownership. Disagreements among sources become reconciliation items, not silent exclusions.

The test contract contains several methods. Deterministic checks validate required fields, identifiers, dates and cross-references. Reconciliation checks compare independent source populations. A reviewer assesses disputed criticality and materiality decisions. Sampling verifies that registered arrangements correspond to executed contracts and actual service use. The control can therefore produce machine observations, human findings and unresolved questions in one evidence model without pretending they are the same thing.

An approved exception might cover a newly acquired entity whose contract metadata is being migrated. The exception identifies the affected arrangements, rationale, approving role, compensating inventory, expiry and remediation milestones. Each subsequent run confirms that the scope has not expanded unnoticed, the compensating inventory still operates and the exception remains valid. Expiry converts unresolved subjects to failure or unknown according to the accepted policy; it does not extend itself.

The workpaper for the quarter reports the expected and observed populations, control versions, test coverage, results, unknowns, exceptions, source limitations and remediation. The control owner concludes on operation within the accepted scope. A second-line reviewer challenges applicability and exception treatment. Internal audit may reuse the evidence but retains authority over its own scope, procedures and conclusion.

This division of labour is compatible with broader regulatory practice. PRA model-risk expectations, for example, call for model inventories, risk-based tiering, governance, validation, monitoring, documented exceptions and recurring self-assessment, while leaving institutions to implement proportionately. The PRA supervisory statement SS1/23 does not prescribe this compiler. It demonstrates why inventories, ownership, testing, exceptions and board-visible remediation must remain connected rather than reported as unrelated activities.

W3C PROV-O offers a useful vocabulary for this evidence chain: entities such as source versions and manifests, activities such as tests and reviews, agents such as systems and accountable people, and derivation or delegation relations. NIST OSCAL assessment results similarly model scope, activities, observations, findings, risks, evidence and attestation in machine-readable form. Neither standard decides legal meaning or certifies a bank’s conclusion. Their value is that they make provenance and assessment structure portable.

Recompile through change

A workpaper is not finished when it is signed. It remains a claim tied to versions and time. Regulatory amendments, corrected source documents, new guidance, business changes, data-model changes, test defects, exception expiry and evidence incidents can each invalidate some part of its warrant. The operating system needs dependency-aware invalidation rather than calendar-based regeneration alone.

Source change is the obvious trigger. The graph should compare structure before meaning, record supersession and identify every accepted obligation derived from affected provisions. A language model can propose an impact set. An authorised reviewer decides whether the institutional obligation changes. Unaffected mappings remain linked to the new source through an explicit “reviewed, no change” decision rather than silent inheritance.

Institutional facts also change. A new legal entity, product, distribution arrangement, customer class, technology provider or AI use can reopen applicability even when regulation is unchanged. This is especially important under regimes with role and classification dependencies. The EU AI Act’s application timetable and actor-specific obligations illustrate why effective dates, intended purpose, provider or deployer role, and system classification need separate records. The European Commission’s current AI Act page should be treated as an official overview, with exact duties verified in the legal text and implementing material.

Control meaning changes when an owner changes the objective, population, method, threshold, frequency, tolerance or unknown-state policy. Even a seemingly modest threshold adjustment can change the conclusion for every prior run. The release record should state whether historical workpapers are untouched, restated, replayed or withdrawn. A new renderer need not rerun the test if it changes only presentation, but its output still receives a new version and claim-to-evidence validation.

Evidence infrastructure creates its own invalidation events. A source schema change may alter normalisation. A lost permission may create false completeness. A runner compromise may quarantine every receipt created with that identity. A defect in population logic may require historical replay. Recovery must preserve the incident interval rather than overwriting it with a clean rerun.

Continuous does not mean permanently assured

Some evidence can be refreshed continuously, but assurance remains periodic and purpose-bound. A control runner may evaluate a technical predicate every hour. A governing body may review an annual report. A regulator may request a self-assessment. Each conclusion has a period, mandate and evidence cut-off. The platform should make newer observations available without silently rewriting a signed historical conclusion.

This distinction is visible in official expectations. The FCA’s Consumer Duty board-report material describes annual governing-body reporting, approval, confirmation and action. The Bank of England’s operational-resilience material expects firms to identify important business services, set impact tolerances, map and test dependencies, remediate vulnerabilities and maintain a written self-assessment. PRA SS1/23 expects at least annual model-risk self-assessment and board-visible remediation. These sources require accountable review and evidence. They do not turn a live dashboard into a standing assurance opinion.

A useful operating rhythm has four loops. The source loop monitors authoritative publications and corrections. The obligation loop governs interpretation, applicability and institutional mapping. The control loop versions objectives, tests, exceptions and evidence. The assurance loop decides what conclusion a specific role can make for a specific purpose and period. Shared identifiers connect the loops; ownership remains distinct.

Metrics should describe the chain rather than document volume. Useful measures include unreviewed source changes, ageing applicability questions, obligations without control coverage, controls without complete populations, unknown observation rates, expired exceptions, evidence latency, replay failures, withdrawn workpapers and time from material change to recompiled conclusion. A high pass rate with rising unknowns is a warning, not improvement.

"""Synthetic validator for a regulation-to-workpaper evidence pack.

The validator does not interpret law. It checks whether an already-authorised
obligation/control mapping has a complete, time-valid and reproducible evidence
chain. It deliberately treats missing scope as UNKNOWN rather than PASS.
"""

from __future__ import annotations

from dataclasses import dataclass, asdict
from datetime import date
from hashlib import sha256
import json
from typing import Literal, Optional

ObservationState = Literal["PASS", "FAIL", "UNKNOWN"]


@dataclass(frozen=True)
class SourceVersion:
    source_id: str
    version: str
    digest: str
    valid_from: date
    valid_to: Optional[date] = None


@dataclass(frozen=True)
class ApplicabilityDecision:
    decision_id: str
    source_digest: str
    legal_entity: str
    product_scope: str
    accepted_by: str


@dataclass(frozen=True)
class ControlContract:
    control_id: str
    version: str
    population_ids: tuple[str, ...]
    minimum_effective_rate: float
    owner: str


@dataclass(frozen=True)
class Observation:
    subject_id: str
    state: ObservationState
    evidence_digest: str


@dataclass(frozen=True)
class ExceptionRecord:
    subject_id: str
    approved_by: str
    expires_on: date
    compensating_control_ok: bool


@dataclass(frozen=True)
class Review:
    prepared_by: str
    reviewed_by: str


@dataclass(frozen=True)
class WorkpaperPack:
    source: SourceVersion
    applicability: ApplicabilityDecision
    control: ControlContract
    observations: tuple[Observation, ...]
    exceptions: tuple[ExceptionRecord, ...]
    review: Review


def active_on(source: SourceVersion, as_of: date) -> bool:
    return source.valid_from <= as_of and (
        source.valid_to is None or as_of <= source.valid_to
    )


def compile_workpaper(pack: WorkpaperPack, as_of: date) -> dict[str, object]:
    """Return a deterministic conclusion and a semantic fingerprint."""

    blockers: list[str] = []

    if not active_on(pack.source, as_of):
        blockers.append("source version is not valid at the assessment date")

    if pack.applicability.source_digest != pack.source.digest:
        blockers.append("applicability decision points to a different source digest")

    if pack.review.prepared_by == pack.review.reviewed_by:
        blockers.append("preparer and reviewer must be different people")

    expected = set(pack.control.population_ids)
    by_subject = {item.subject_id: item for item in pack.observations}
    missing = sorted(expected - set(by_subject))
    unexpected = sorted(set(by_subject) - expected)

    if missing:
        blockers.append(f"population has no observation for: {', '.join(missing)}")
    if unexpected:
        blockers.append(f"observations contain out-of-scope subjects: {', '.join(unexpected)}")

    exception_by_subject = {item.subject_id: item for item in pack.exceptions}
    counts = {"pass": 0, "fail": 0, "unknown": 0, "excepted": 0}

    for subject_id in sorted(expected):
        observation = by_subject.get(subject_id)
        if observation is None or observation.state == "UNKNOWN":
            counts["unknown"] += 1
            continue
        if observation.state == "PASS":
            counts["pass"] += 1
            continue

        exception = exception_by_subject.get(subject_id)
        if (
            exception is not None
            and as_of <= exception.expires_on
            and exception.compensating_control_ok
        ):
            counts["excepted"] += 1
        else:
            counts["fail"] += 1

    denominator = len(expected)
    effective_rate = (
        (counts["pass"] + counts["excepted"]) / denominator if denominator else 0.0
    )

    if denominator == 0:
        blockers.append("control population is empty")
    if counts["unknown"]:
        blockers.append("one or more in-scope subjects have an unknown outcome")

    if blockers:
        conclusion = "BLOCKED_UNKNOWN"
    elif counts["fail"] or effective_rate < pack.control.minimum_effective_rate:
        conclusion = "NOT_SUPPORTED"
    else:
        conclusion = "SUPPORTED"

    semantic_inputs = {
        "source": asdict(pack.source),
        "applicability": asdict(pack.applicability),
        "control": asdict(pack.control),
        "observations": [asdict(item) for item in pack.observations],
        "exceptions": [asdict(item) for item in pack.exceptions],
        "review": asdict(pack.review),
        "as_of": as_of,
    }
    canonical = json.dumps(semantic_inputs, sort_keys=True, default=str).encode("utf-8")

    return {
        "conclusion": conclusion,
        "counts": counts,
        "effective_rate": round(effective_rate, 3),
        "blockers": blockers,
        "semantic_fingerprint": sha256(canonical).hexdigest()[:16],
    }


def demo() -> None:
    as_of = date(2026, 8, 30)
    source = SourceVersion(
        source_id="SYNTHETIC-RULE-17",
        version="3",
        digest="sha256:rule-v3",
        valid_from=date(2026, 8, 1),
    )
    applicability = ApplicabilityDecision(
        decision_id="APP-44",
        source_digest="sha256:rule-v3",
        legal_entity="Example Bank plc",
        product_scope="Retail current accounts",
        accepted_by="Head of Compliance",
    )
    control = ControlContract(
        control_id="CTRL-COMMS-09",
        version="2.1",
        population_ids=("case-1", "case-2", "case-3", "case-4"),
        minimum_effective_rate=1.0,
        owner="Customer Communications Director",
    )
    review = Review(prepared_by="Control Analyst", reviewed_by="Risk Reviewer")

    positive = WorkpaperPack(
        source=source,
        applicability=applicability,
        control=control,
        observations=(
            Observation("case-1", "PASS", "sha256:e1"),
            Observation("case-2", "PASS", "sha256:e2"),
            Observation("case-3", "PASS", "sha256:e3"),
            Observation("case-4", "FAIL", "sha256:e4"),
        ),
        exceptions=(
            ExceptionRecord(
                "case-4",
                approved_by="Risk Acceptance Committee",
                expires_on=date(2026, 9, 15),
                compensating_control_ok=True,
            ),
        ),
        review=review,
    )

    negative = WorkpaperPack(
        source=source,
        applicability=applicability,
        control=control,
        observations=positive.observations[:-1],  # case-4 is missing
        exceptions=positive.exceptions,
        review=review,
    )

    print("positive", json.dumps(compile_workpaper(positive, as_of), indent=2))
    print("negative", json.dumps(compile_workpaper(negative, as_of), indent=2))


if __name__ == "__main__":
    demo()

The compilation-readiness decision

Not every obligation deserves the same automation path. The decision should depend on two causal properties: how much authorised interpretation remains open, and how directly the required state can be observed. Consequence and reversibility then determine how much independent review is needed. This produces a placement decision, not a maturity score.

The explicit failure boundary

The mechanism stops helping when its inputs cannot be responsibly stabilised. Open-textured standards such as fairness, reasonable steps or good outcomes may support structured evidence and assessment rubrics, but a compiler cannot remove the judgement embedded in them. Causal claims about customer outcomes may require research designs beyond operational monitoring. Conflicting instruments, live litigation, privileged advice and rapidly changing facts may prevent a single accepted obligation. Weak enterprise data may make the complete population unknowable.

At this boundary, the platform should preserve source, questions, evidence, dissent, authority and deadlines. It may propose analyses and collect facts. It should not emit executable certainty. A controlled unknown is a stronger compliance state than an unsupported green.

stateDiagram-v2
  [*] --> Claim
  state "The eight objects in the lineage" as Claim
  state "Thought experiment one: hold<br/>the words constant, change<br/>only the entity" as Test
  state "A minimal worked example:<br/>customer understanding" as Revision
  Claim --> Test: expose mechanism
  Test --> Decision: evidence survives
  Test --> Revision: rival survives
  Revision --> Claim: narrow or rebuild
  Decision --> [*]

Compact glossary

Candidate norm

A machine- or analyst-proposed obligation, prohibition, permission or evidential duty extracted from a source, awaiting authorised acceptance.

Applicability decision

The accepted binding of a norm to institutional facts such as entity, role, product, jurisdiction, customer class and effective period.

Control contract

A versioned specification of objective, population, method, frequency, tolerance, unknown state, evidence, owner and judgement points.

Evidence receipt

A protected record of what was observed, by which identity and artefact, from which source, at what time and with what result.

Semantic fingerprint

A digest of the exact source, decisions, control, test, evidence and review inputs used to support a workpaper.

Executable workpaper

A workpaper assembled and validated from typed evidence objects, while leaving interpretation and assurance authority with accountable roles.