From Statute to Spec

An engineer handed the EU AI Act reads it the way they would read an RFC: start at the top, proceed to the bottom, extract the requirements. This fails immediately, because they hit 180 numbered recitals before reaching a single binding word, and by the time the obligations arrive they have absorbed a great deal of text that does not bind and missed the definitions that decide whether any of it applies to them. A lawyer handed the same document does something different and equally incomplete: quotes the operative article that matters to the question asked, and never reads the annex that determines whether the article attaches at all.

Both failures come from the same missing model. A European regulation has an architecture, and each part carries a different kind of authority.

The practical consequence is a reading order. Start with the definitions, because they tell you whether the words in the obligation mean what you think. Then the annexes the operative provision points at, because those usually decide applicability. Then the operative article itself, decomposed. Recitals come in only when the article is genuinely ambiguous, and guidance comes in last, to answer the engineering questions the legislature deliberately left open.

An obligation is a conjunction of conditions. It attaches when every conjunctive element is satisfied and fails to attach when any one of them is not — which means the useful question is never "does GDPR apply to us" but "which element of Article 22(1) does our system fail, and what product change would satisfy it." That reframing is the whole skill. It converts a diffuse anxiety into a finite list of facts, each of which someone in the building can confirm or deny.

Take GDPR Article 22(1): the data subject has the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects concerning him or her or similarly significantly affects him or her. Three conjunctive elements — a decision; based solely on automated processing; producing legal or similarly significant effects — and each one is load-bearing in the literal sense that removing it collapses the obligation.

Notice what the diagram makes available that the prose does not. Once the provision is drawn as elements, the phase-2 launch stops being a compliance question and becomes a product question with a known shape: the element we currently fail is the one we are proposing to satisfy. That is a sentence a product manager can take to a roadmap review, and it is unavailable to anyone who has only read the article top to bottom.

Elements come in two flavors and the difference matters constantly. Conjunctive elements are joined by "and" — every one must hold. Disjunctive elements are joined by "or" — any one suffices. Article 22(1)'s three elements are conjunctive; Article 22(2)'s three exceptions are disjunctive. Misreading which is which produces the two most common errors in the field: treating an obligation as attached when a conjunctive element fails, and treating an exception as unavailable because you cannot satisfy all of its branches when you only needed one.

Nearly every misclassification in the field starts the same way: someone reads a defined term colloquially. The AI Act's Article 3 and GDPR's Article 4 are not glossaries for the reader's convenience; they are operative text that displaces ordinary meaning wherever the term appears. When Article 3(3) says provider means a natural or legal person that develops an AI system and places it on the market or puts it into service under its own name or trademark, whether for payment or free of charge, the ordinary sense of "provider" — the vendor you buy from — has been overwritten. An insurer that builds a drafting assistant for its own agents and turns it on has put a system into service under its own name and is a provider, with zero external customers and no product to sell.

This is where the AI Act catches almost every internal-tools team by surprise, and it is a pure defined-term failure. The team reasons: we are the customer, not the vendor, so we must be the deployer. The reasoning is impeccable and irrelevant, because the statute did not use the word in that sense.

The last row is the one that determines architecture. If retrieval is processing — and it plainly is, "retrieval" appears in the definition verbatim — then assembling a context window is a processing operation requiring a lawful basis and bounded by minimization. That single defined term is why module 3 can treat a field allowlist as a legal control rather than a nice-to-have.

Applicability analysis comes first, and it is a separate exercise from obligations analysis. Three scope triggers decide whether a regime attaches at all: territorial (does it reach you where you are and where your users are), material (is the activity within the subject matter), and personal (are you one of the actors it addresses). Only once all three hold do you begin decomposing obligations. Teams that skip this step do enormous work for nothing, and teams that assume it away without checking do the opposite.

GDPR's Article 3 reaches processing in the context of an EU establishment regardless of where the processing happens, and reaches non-EU controllers who offer goods or services to, or monitor the behavior of, people in the Union. The AI Act's Article 2 reaches providers placing systems on the Union market or putting them into service in the Union, deployers established in the Union, and — the provision people miss — providers and deployers outside the Union where the system's output is used in the Union. Meridian, a European insurer serving European policyholders, satisfies both trivially. The interesting cases are the ones where you have to think, and those are exactly the cases where an unexamined assumption costs a quarter.

Safe harbors — exemptions, derogations, exceptions — have to be established the way you would establish an affirmative defense: element by element, with facts, in writing, before you rely on them. The AI Act exempts systems developed and put into service for the sole purpose of scientific research and development (Art. 2(6)), and exempts research and development activity prior to placing on the market (Art. 2(8)). Both exemptions have real elements. "Sole purpose" means sole; a research prototype that is quietly serving real customer traffic has left the exemption, and the fact that the team still calls it a prototype does not restore it.

Note the symmetry: assuming a safe harbor applies and assuming it does not are the same error with different bills. One produces an unbounded gap you discover during an assessment; the other produces a control set that consumes engineering capacity forever. The discipline is identical in both directions — establish the elements, write down the facts.

A recital is numbered preamble text explaining why the legislature did what it did. It is not operative law and cannot create an obligation the articles do not create, but it is also not decoration: the Court of Justice uses recitals to resolve ambiguity in operative text, and so should you. The usable rule is that a recital can shade the reading of an ambiguous article and cannot override a clear one. When you cite a recital in an internal position, cite it as what it is — support for one reading of an article, with the article quoted alongside.

Below the statute sits a layer that matters more to engineers than the statute does, because it is where the actual specifications live. Delegated acts are secondary legislation the Commission is authorized to issue, and they bind. Harmonized standards developed by the European standardization bodies carry a presumption of conformity — build to the standard and you are presumed to satisfy the corresponding requirement, which is the single most valuable engineering shortcut the Act offers. Regulatory guidance from the EDPB and the AI Office is persuasive rather than binding, and is nonetheless what a supervisory authority will measure you against on a Tuesday.

That last sentence is the module's bridge to the rest of the course. A regulatory change is one of exactly three events that must reach your compliance matrix — module 5 names the other two — and the reason a program can be genuinely compliant in March and quietly non-compliant in September is almost never that the engineers changed something. It is that the law did, and nothing routed the change to the people holding the controls.

The Act sorts uses into four tiers by the risk the use presents, and layers a separate set of obligations on general-purpose models that sits across all of them. The tiers are not a spectrum you land somewhere on; they are defined categories with elements, and you establish membership the way module 1 taught.

Prohibited practices (Art. 5) are the floor: manipulative techniques exploiting vulnerabilities, social scoring by public authorities, untargeted facial-image scraping, emotion inference in workplaces and schools, and certain biometric categorization and real-time remote biometric identification uses. These are bans, not obligations — the answer to "what controls do we need?" is that you do not build the thing. High-risk AI systems (Art. 6) come in two families: systems that are safety components of products covered by the Annex I harmonization legislation, and systems in the Annex III use areas. This tier carries the Act's heavy machinery — risk management (Art. 9), data governance (Art. 10), technical documentation (Art. 11 and Annex IV), record-keeping (Art. 12), transparency to deployers (Art. 13), human oversight (Art. 14), accuracy and robustness (Art. 15), a quality management system (Art. 17), and conformity assessment (Art. 43). Transparency-risk uses (Art. 50) carry disclosure duties without the heavy machinery. Everything else is minimal risk and carries no system-specific obligations at all — though Art. 4's AI literacy duty applies to providers and deployers across the board.

Two structural facts about this picture are worth carrying. First, tier membership is decided by use, so the same model can sit in three tiers across three deployments in one company. Second, the GPAI layer is drawn sideways deliberately — it is the single most misattributed set of obligations in practice, and §4 returns to why.

Obligations attach to roles. The Act names several — provider, deployer, importer, distributor, authorized representative — and for most organizations building with AI, two matter. A provider (Art. 3(3)) develops an AI system or has one developed and places it on the market or puts it into service under its own name or trademark, for payment or free of charge. A deployer (Art. 3(4)) uses an AI system under its own authority in a professional capacity. Nothing prevents one organization from being both, and for in-house builds that is the normal case rather than an edge case.

Meridian is both. It developed Draftline, put it into service under its own name for its own agents, and uses it under its own authority. Every provider obligation that would attach at a given tier attaches to Meridian, and so does every deployer obligation. There is no vendor to point at and no contract to allocate the duty into — which is precisely the situation the internal-tools team assumed it was avoiding by building rather than buying.

The role can also move underneath you. Article 25 converts a deployer, distributor, or importer into a provider of a high-risk system in three situations: putting your name or trademark on a system already on the market, making a substantial modification to a high-risk system, or modifying the intended purpose of a system such that it becomes high-risk. This is the trap that catches teams who license a vendor system, fine-tune it on their own data, rebrand the interface, and continue to believe the vendor carries the compliance load. When Art. 25 fires, the full provider stack lands on you — including technical documentation for a system whose training data you may not have visibility into.

Read the table as a column-selection exercise. A pure deployer reads two rows; a pure provider reads six; Meridian reads all eight, and the two rows that would otherwise fall in a contractual gap — log retention against logging capability, oversight design against oversight operation — are the ones that most often go unowned when a company is both.

Now the walk. Draftline retrieves from Meridian's policy documents and customer records, drafts a response to an inbound customer-service contact, and presents it in the agent console. An agent reads it, edits it if needed, and sends it. Phase 2 will auto-resolve routine travel-delay claims below a value threshold with no agent in the loop.

Step one, is it an AI system under Art. 3(1)? Yes — machine-based, infers from inputs how to generate outputs, operates with a degree of autonomy. Step two, prohibited practice under Art. 5? No; nothing here manipulates, scores social behavior, or infers emotion in a workplace or educational setting. Note the near-miss worth recording: if a future release inferred customer emotional state to prioritize queues, the Art. 5(1)(f) analysis would concern workplace and educational emotion inference and would not directly attach, but a system inferring agents' emotional states would sit squarely inside it — a distinction worth writing down before someone proposes agent-sentiment monitoring.

Step three, Annex I? No — Draftline is not a safety component of a regulated product. Step four, Annex III? This is the real question, and it is answered area by area rather than by vibe. Annex III area 5 covers access to and enjoyment of essential private and public services: 5(a) public assistance benefits eligibility, 5(b) creditworthiness evaluation, 5(c) risk assessment and pricing in life and health insurance, 5(d) emergency call triage. Meridian sells health-and-travel insurance, so 5(c) is close — but 5(c) addresses risk assessment and pricing, and Draftline phase 1 does neither. It drafts prose for a human to review; it does not assess risk, price a policy, or decide a claim. No Annex III area is satisfied, so the Art. 6(3) derogation is not even reached — a point worth being precise about, since 6(3) is a rebuttal available to systems that are in an Annex III area but perform only narrow procedural, preparatory, or pattern-detection tasks without materially influencing the decision outcome.

So the honest answer for phase 1 is minimal risk, and the honest answer is worth writing down with its reasoning, because a defensible "not high-risk" finding is an asset. It is the document that stops a well-meaning colleague from opening an Art. 9 risk-management workstream next quarter.

The near-miss analysis is the more valuable half. Phase 2 auto-resolves travel-delay claims: the system now determines an outcome affecting a customer's access to an insurance benefit, at a health-and-travel insurer, without a human. Whether that lands inside Annex III 5(c) is genuinely arguable — 5(c) speaks to risk assessment and pricing rather than claims handling, and a serious analysis would work that boundary carefully and probably conclude claims adjudication sits outside its literal terms. But "arguable" is the operative word, and module 4 will show why Meridian decided not to spend the phase-2 launch window arguing it.

Classification exists to produce a list. Here is Draftline's, as of today, across both statutes — the raw material module 4 runs through the translation stack. Each is stated as an obligation sentence with its citation, because a list item without an article number is a preference.

1. AI literacy — AI Act Art. 4. Providers and deployers must take measures to ensure a sufficient level of AI literacy among staff dealing with the operation and use of their AI systems, considering their technical knowledge, experience, and the context of use. This binds Meridian for all 400 agents and it binds regardless of tier — it is the one AI Act obligation that attaches to a minimal-risk system.

2. Transparency analysis — AI Act Art. 50. Analyzed in module 1's worksheet: 50(1) does not attach in phase 1 because Draftline does not interact directly with natural persons, and 50(2)'s synthetic-content marking duty requires its own analysis. The obligation here is to maintain the analysis, since a customer-facing surface would attach 50(1) immediately.

3. Lawful basis, including special category — GDPR Arts. 6 and 9. Every processing operation in the pipeline needs a basis, and health data in travel-medical claims is Art. 9 special-category data requiring an additional condition. Module 3 works this.

4. Data minimization — GDPR Art. 5(1)(c). Binding on retrieval (which fields enter the context window) and on logs (what prompts and completions retain, for how long, under Art. 5(1)(e)). This becomes the field-allowlist requirement and the CI check in module 6.

5. Rights handling — GDPR Arts. 12–15. A one-month clock on access requests that must reach prompts, completions, logs, embeddings, and caches. Survivable only by design.

Now the misattribution this section exists to prevent. Draftline calls a third-party GPAI model API. Meridian's engineers, reading Arts. 51–55, might reasonably conclude those obligations are theirs — training-data summaries, copyright policy, technical documentation for the model, systemic-risk assessment. They are not. Those duties bind the provider of the model, the entity that placed it on the market. Meridian's relationship to them is as a purchaser: it should demand the Art. 53 documentation the model provider owes downstream providers, because that documentation is an input to Meridian's own obligations if Draftline ever becomes high-risk. Confusing "obligations I can read about" with "obligations that bind me" produces both wasted work and, occasionally, the reverse error — assuming the model provider's compliance discharges yours.

The Act entered into force on 1 August 2024 and applies in stages. Prohibited practices (Art. 5) and the AI literacy duty (Art. 4) applied from 2 February 2025. The GPAI-model obligations, the governance structures, and most of the penalty provisions applied from 2 August 2025. The general application date — including the Art. 50 transparency duties — is 2 August 2026, and the compliance deadline for GPAI models already on the market before August 2025 falls on 2 August 2027. The Annex III high-risk regime under Art. 6(2) was originally due on 2 August 2026, and high-risk systems that are safety components of Annex I products on 2 August 2027, but the digital-omnibus package (adopted June 2026, signed July 2026) deferred them to 2 December 2027 and 2 August 2028 respectively.

Penalties scale with the tier: up to €35 million or 7% of worldwide annual turnover for prohibited practices, up to €15 million or 3% for most other obligation breaches, and up to €7.5 million or 1% for supplying incorrect or misleading information to authorities (Art. 99), with the lower of the two figures applying to SMEs. The relevant point for a builder is not the number but its structure — the third tier means that a wrong answer given confidently to a regulator is itself a sanctioned act, which is an argument for the traceability discipline the next three modules build.

Finally, the myth. "It is internal-only, so the Act does not apply" is wrong twice over. Putting a system into service under your own name is an independent trigger alongside placing it on the market, so internal deployment makes you a provider (§2). And Annex III's use areas include several — employment, worker management, access to services — that describe systems most companies run purely internally. Internal deployment narrows your exposure to third-party claims. It does not narrow the statute.

Ninety-nine articles is a lot to hold, and you do not have to. GDPR has a small structure with a lot of elaboration hanging off it. Article 5 states seven principles, and every other substantive obligation in the regulation is either a specification of one of them or an enforcement mechanism for one of them. Chapter III grants eight data subject rights. Chapters IV and V allocate duties between controllers and processors and constrain international transfers. That is the whole shape.

The six Article 5(1) principles: lawfulness, fairness and transparency; purpose limitation; data minimization; accuracy; storage limitation; and integrity and confidentiality — plus, in 5(2), separately and importantly, accountability, the duty to be able to demonstrate compliance with the other six. That is seven principles in all, six of them in 5(1) and accountability standing apart in 5(2). Article 5(2) is the provision this entire course serves. It is the statutory basis for the claim that evidence you cannot produce is compliance you do not have.

Two role definitions decide who owes what. A controller determines the purposes and means of processing; a processor processes on the controller's behalf and on its instructions. Meridian is the controller for all Draftline processing. The GPAI model provider, called via API under a contract that forbids using Meridian's data for training, is a processor — which triggers Art. 28's requirement for a written contract with specific mandated terms, and, if the model runs outside the EEA, Chapter V transfer machinery. Note that this is a different allocation than the AI Act's: under the AI Act the model vendor is a GPAI-model provider and Meridian is the system provider; under GDPR the vendor is Meridian's processor. Same commercial relationship, two statutes, two role vocabularies, and no reason for them to line up. Keeping the two vocabularies distinct in your writing is a small discipline that prevents a large class of confusion.

Every processing operation needs a basis under Article 6, and the six bases are not interchangeable. Choosing one commits you to engineering work specific to that choice, which is why the decision belongs in a design review rather than in a privacy notice written afterward.

Consent (Art. 6(1)(a)) must be freely given, specific, informed, unambiguous, and as easy to withdraw as to give — which commits you to building a withdrawal mechanism, propagating withdrawal to every downstream store, and functioning correctly for users who refuse. Contract (Art. 6(1)(b)) covers processing necessary to perform a contract with the data subject, where "necessary" means necessary, not convenient. Legal obligation (Art. 6(1)(c)) requires a specific legal duty you can cite. Legitimate interests (Art. 6(1)(f)) is the most flexible and the most misused: it requires a documented three-part assessment — a legitimate interest identified, necessity established, and a balancing test against the data subject's interests and reasonable expectations — plus an Art. 21 objection path that actually stops the processing.

For Draftline, Meridian's analysis runs: processing customer records to answer that customer's own service contact is necessary for performance of the insurance contract, Art. 6(1)(b) — clean, and it survives the "necessary" test because responding to a policyholder's claim query is literally contract performance. Using the same corpus to evaluate model quality is not contract performance; that is a separate purpose resting on legitimate interests, with its own documented balancing test, and it is the operation most likely to be quietly conflated with the first.

Then the harder layer. Travel-medical claims contain health data, which is special-category data under Article 9(1) and prohibited from processing unless an Art. 9(2) condition applies — and Art. 9(2) is a closed list, not a balancing exercise. For insurance claims handling the workable conditions are 9(2)(a) explicit consent or 9(2)(f) establishment, exercise or defence of legal claims; several Member States also legislate insurance-specific conditions under 9(2)(g)'s substantial public interest gateway. The engineering consequence is direct and unpleasant: an Art. 9 condition established for claims handling does not extend to model evaluation, so the health data that may lawfully enter a claim response may not lawfully enter your eval set. That single sentence is a data-pipeline requirement, and it is the sort of requirement that gets discovered in an audit rather than in a design doc because nobody translated it.

Here is the course's secondary running example in full, because it is the cleanest demonstration that a principle is a spec. Article 5(1)(c) requires personal data to be adequate, relevant, and limited to what is necessary for the purposes. Most teams read this as a collection-time rule — ask for fewer fields at signup — and stop. But processing under Art. 4(2) expressly includes retrieval, consultation, and use. Assembling a context window is retrieval and use. Therefore every field your retrieval layer injects into a prompt is a processing operation that must independently satisfy minimization for the purpose at hand.

The convenient implementation is to fetch the customer object and let the model sort it out. The customer object at Meridian contains, among other things: name, address, date of birth, policy identifiers, coverage terms, claims history with diagnosis codes, payment method and partial card data, marketing preferences, a fraud-risk score, and free-text agent notes from prior contacts. Injecting all of it to answer "when does my travel cover start?" fails Art. 5(1)(c) on its face, and the fact that it is one line of code is not a defense. It also fails Art. 9, since diagnosis codes enter processing for a purpose no Art. 9(2) condition covers, and it creates a security consequence you already understand — every field in the context window is a field a prompt-injection attack can exfiltrate.

The corrective is a field allowlist: an explicit, version-controlled declaration of which customer fields may enter a context window, keyed by request intent. Meridian's coverage-query intent allows policy identifier, coverage terms, effective dates, and the current ticket text — and nothing else. The claims-status intent additionally allows claim identifier, status, and decision date, but not diagnosis codes, because the status answer does not require them. Everything else is denied by default, and adding a field is a reviewed change rather than a query modification.

That design has three properties worth naming. It is testable — you can assert the allowlist's contents in CI, which is exactly what module 6 does. It is evidence-producing — the config file's version history is itself the record that the control operated. And it is legible to a regulator, because "here is the declared set of fields, here is the check that enforces it, here is its change history" is a far better answer than "our engineers are careful."

Purpose limitation (Art. 5(1)(b)) then constrains the second life of the same data. Prompts and completions are extraordinarily useful for evaluation, debugging, and fine-tuning, and every one of those is a new purpose requiring its own compatibility analysis. Meridian's resolution: prompt and completion logs retain a redacted form — identifiers hashed, free-text customer content dropped, retrieved field names retained without values — for 90 days for operational debugging, with a separate, consented, opt-in corpus for evaluation. That is what a translated principle looks like: a retention number, a redaction rule, and a second corpus with a different legal basis.

Articles 12 to 15 give a data subject the right to know what you hold about them and to receive a copy, and give you one month to comply — extendable by two further months for complex or numerous requests, but only if you tell the requester within the first month. Whether that clock is survivable is decided entirely at design time. No amount of process discipline rescues a system whose personal data topology nobody mapped, because the work is not procedural, it is archaeological.

The awkward question for AI systems is where the personal data actually lives. The customer record store is obvious. The prompt logs contain the customer's own words and the retrieved fields. The completion logs contain statements about the customer, which are personal data and are also, uncomfortably, subject to the Article 16 rectification right if they are wrong. Embeddings derived from customer text are personal data where the individual remains identifiable. Caches hold copies with their own lifetimes. The analytics warehouse holds a copy someone made in 2024 for a quarterly report. A vendor holds another. Each of these is in scope, and each needs an export path that exists before the request arrives.

Return to Figure 1.2's elements: a decision, based solely on automated processing, producing legal or similarly significant effects. Draftline phase 1 fails the second element and Article 22 does not attach. Phase 2 satisfies all three — a claim outcome is a decision, auto-resolution is solely automated, and paying or refusing an insurance claim significantly affects the claimant. So the provision engages, and the question becomes what Article 22 actually demands.

Article 22(1) is drafted as a right not to be subject to such a decision, which functions in practice as a prohibition subject to the three disjunctive exceptions in 22(2): necessity for entering or performing a contract, authorization by Union or Member State law, or explicit consent. And critically, where 22(2)(a) or (c) applies, Article 22(3) requires suitable safeguards including at minimum the right to obtain human intervention, to express a point of view, and to contest the decision. Where special-category data is involved, Article 22(4) restricts the available routes further, permitting the processing only on explicit consent or substantial public interest grounds with suitable safeguards — which for a health insurer is a constraint that reshapes the product.

Which brings us to the element every deployment eventually leans on: "solely." A human in the loop defeats the trigger — but only a human whose involvement is meaningful. Regulatory guidance is consistent on this: token involvement does not remove a decision from Article 22's scope. Meaningful involvement means the reviewer has authority to change the outcome, competence to evaluate it, and the actual practical ability to do so — time, information, and an interface that supports disagreement.

Consider the two ends of the chain. At one end, Article 14(1): high-risk AI systems shall be designed and developed such that they can be effectively overseen by natural persons during the period in which they are in use. At the other end, a Jira ticket that a senior engineer can estimate, implement, and close. Everyone agrees these are related. Almost no one owns the path between them.

The gap is not a knowledge gap on either side. Counsel can tell you precisely what Article 14 requires as a matter of law and will decline, correctly, to tell you what to build — that is not a legal question. Engineering can build any specified behavior and will decline, correctly, to infer the specification from a statute — that is not an engineering question. Both refusals are professionally sound. The consequence is that the work in between gets done by whoever is standing closest, usually under deadline, usually once, and never gets written down as the reasoning that connects the two ends.

You see the result in artifacts. An obligation arrives at a sprint planning session as "be compliant with the AI Act." A policy document says "human oversight shall be effective" and is signed by someone senior. A control inventory lists "human review process" with no reference to a system behavior. An auditor asks how you know oversight is working and receives a training-completion report. Each of these is a layer that got skipped, and skipping a layer does not remove the work — it defers it to the moment when someone has to defend the position, at which point the reasoning has to be reconstructed by people who were not there.

The good news is that this is a tractable, specifiable, teachable process, and the person best positioned to run it is not a lawyer or an engineer but someone fluent enough in both to perform each transformation without distortion. If you can read a provision structurally and write a requirement that a skeptical engineer accepts as buildable, you can do this work, and very few people can.

Six layers. Each answers a different question, each is produced by a different transformation, and each adjacent pair has a characteristic failure.

1. Obligation. What the law demands, stated as a sentence with a citation and an addressee. Not a topic — "human oversight" is a topic; "as provider, Meridian must design Draftline so that natural persons can effectively oversee it while in use, AI Act Art. 14(1)" is an obligation. The test of a well-stated obligation is that it survives being read aloud to counsel without correction.

2. Control objective. The outcome that, if achieved, satisfies the obligation — stated system-agnostically. This layer exists because it is where legal judgment ends and design judgment begins, and collapsing it is how organizations end up unable to explain why they built what they built. A control objective for Art. 14 says what must be true of the world, not what software does.

3. Control. The mechanism your organization operates to achieve the objective. Controls can be technical, procedural, or organizational, and one objective routinely needs several of each. This is the layer GRC frameworks are made of and the layer engineers find least satisfying, because a control is still not a thing you can build.

4. Requirement. A testable, bounded, owned statement of specific system behavior. This is the transformation that most needs a product manager: it converts "the organization operates a review process" into "the system presents X to user role Y within Z seconds, and records W." Four quality criteria — testable (a disagreement about whether it passed is resolvable by observation), bounded (thresholds and scope are numeric or enumerable), owned (a named role, not a team name), evidenced (the artifact it will produce is specified in advance).

5. Test. How you would know. Automated where the property is machine-checkable, procedural where it is not. The test's output is not a boolean; it is a record.

6. Evidence. The artifact a skeptic accepts as proof the control operated during a stated period. Four properties, developed fully in module 6: provenance (what system produced it), timestamp (when, in a trustworthy clock), integrity (it has not been altered), and a link to the requirement ID it satisfies.

Notice who appears in four of five rows. The transformations are not owned by legal or by engineering; they are owned by the person sitting between them, and the reason organizations lack that person is usually that nobody has ever written the role down.

Before the trace, a necessary piece of honesty. Module 2 concluded that Draftline phase 1 is not high-risk, which means Article 14 does not bind it as a matter of statute. Running the full Art. 14 translation anyway is a deliberate decision, and the reasoning is itself teaching content.

Meridian adopted Article 14 as a binding internal standard for phase 2 on three grounds. First, phase-2 auto-resolution engages GDPR Article 22 cleanly (module 3), and Art. 22(3) requires human intervention as a safeguard without specifying what adequate intervention looks like — Article 14 is the most concrete available specification of meaningful human involvement, so adopting it discharges a GDPR duty using an AI Act blueprint. Second, phase 2 at a health insurer sits within arguable reach of Annex III 5(c), and retrofitting oversight into a shipped automation costs multiples of designing it in; the option value of already conforming exceeds the cost of conforming early. Third — the pedagogically important one — the stack works identically regardless of where the obligation comes from. Statute, contract, regulator undertaking, or adopted internal standard: the six layers and five transformations do not change. Module 5's worksheet proves this by running the same stack on a contractual and an internal-policy obligation.

So: obligation, adopted, cited to its source.

Two features of the trace deserve attention. The numbers appear for the first time at layer 4: four hours, 240 minutes, 60 cases. Nothing above layer 4 could be tested, and nothing below it could be argued about legally. That is the seam, and it is the reason the two professions cannot simply hand work to each other across it. And the evidence at layer 6 is a named file with a named format, decided at design time rather than discovered at audit time — which is what makes the difference between module 6's pipeline and module 8's scramble.

The obligation-to-requirement path is where most of the craft lives, and three specific errors account for most of the damage.

The "shall be effective" trap. Adjectives are not requirements. "Human oversight shall be effective," "access shall be appropriately restricted," "data shall be adequately protected" — each of these can be disagreed about indefinitely by reasonable people, which is the definition of untestable. The tell is that you cannot describe an observation that would settle the disagreement. The fix is not to add more adjectives but to ask the question that produces layer 4: what would we observe if this were true, and what would we observe if it were not?

The one-to-one fallacy. Teams assume one obligation yields one control, so Article 14 becomes "we have a human review step" and the translation stops. But Figure 4.1's objective decomposes into four controls of three different kinds: an interface control (the intervention window), an interaction control (override with reason codes), an organizational control (competence), and a detective control (sampling audit). Drop any one and the objective fails in a specific way — without C-3 the reviewer lacks competence, without C-4 nobody notices when C-1 and C-2 degrade into a rubber stamp. The count is not arbitrary; it comes from reading Art. 14(4)'s measures as a list of distinct capacities the human must have.

Control objective / control confusion. "Every claim outcome can be overridden by a competent human before it affects the claimant" is an objective — it describes the world. "A four-hour intervention window in the resolution queue" is a control — it is a mechanism you operate. The confusion matters because objectives are stable and controls are not: Meridian could replace the four-hour window with an eight-hour window, or with synchronous review for high-value claims, and the objective would be unchanged. When you record only the control, you lose the ability to change implementation without re-litigating the obligation, and every re-implementation becomes a compliance question rather than an engineering decision.

A method shown once on a carefully chosen example proves very little. So here is the same stack, compressed, on a different obligation with a different shape: AI Act Article 12, record-keeping. Article 12(1) requires that high-risk systems technically allow for the automatic recording of events over the system's lifetime, and 12(2) requires logging capabilities appropriate to identifying situations that may present a risk or lead to a substantial modification, and to facilitating post-market monitoring. Where Art. 14 was about human capacity, Art. 12 is about system capability — a different kind of duty, run through identical machinery.

Now compare the two traces against a third case: doing it badly. The bad version is not a strawman — it is what every one of these translations looks like when the layers are skipped, and it passes internal review more often than the good version does, because it is shorter and contains no numbers to argue about.

Two traces, one counter-example. If you can run this on Art. 12 having only watched it run on Art. 14, you have the method, and the method is the deliverable — not the Draftline answers, which are specific to a system you do not own. The worksheet below asks you to prove that on a provision from your own work.

A traceability matrix maps obligations to the controls that satisfy them, the requirements that implement those controls, the tests that verify them, and the evidence that proves they operated — with a named owner attached to each row. It is the artifact that answers "show me," which as module 3 established is not an audit courtesy but the substance of GDPR Article 5(2) and the working assumption behind AI Act Article 43.

Most organizations that have one treat it as reporting. It is not reporting; it is the operational data structure of the compliance program, and the difference shows in how it is used. A reporting matrix is written before an audit and read by the auditor. An operational matrix is queried when a deploy touches a controlled surface, when an owner leaves, when guidance changes, and when someone asks whether a proposed feature is already covered. If nobody queries your matrix between audits, you have a report.

The owner column carries more weight than it looks like it does. A control with a test, evidence, and no named owner is not a control that is slightly incomplete; it is a control whose next failure has no addressee. Owners must be roles held by people, not teams — "Platform Engineering" cannot notice that its evidence went stale, but the Platform Engineering Manager, Claims Systems can.

Here is an excerpt from Meridian's matrix, five rows covering obligations from both statutes, with one row shown in the state it is actually in rather than the state its owner would like to report.

Now the granularity question, which is where most matrices fail before they are ever maintained. A matrix with the single row "GDPR compliance" is untraceable — no control implements it, no test verifies it, and the owner is the general counsel by default and nobody in practice. A matrix with a row per code commit is unmaintainable and will be abandoned in six weeks. The right grain is the one module 1 already gave you: the obligation as decomposed by elements analysis. "GDPR Article 15 access requests" is a row because it has identifiable elements, a determinate scope, and a control set that can be built and tested. "GDPR" is a statute; "the export job's retry logic" is an implementation detail.

A useful heuristic: if two obligations in the same row could plausibly have different owners, split the row. If two rows would always have the same owner, the same control, and the same evidence, merge them. Meridian's matrix has 34 rows across both statutes and three contractual sources — small enough to read in one sitting, large enough that each row means something.

Controls are not booleans. Treating a control as either "in place" or "not in place" is the modeling error underneath most compliance surprises, because it has no vocabulary for the state a control is actually in most of the time: implemented, believed to be working, and not verified recently enough for anyone to be sure.

Two consequences follow, and both are counterintuitive to people who think of compliance as a binary.

First, control drift is normal. Systems change, contexts change, evidence ages. A program in which no control is ever drifted is not a program with perfect controls; it is a program that is not looking. Meridian's matrix typically shows three to five drifted rows out of 34 at any moment, and that number being zero would be a stronger signal of trouble than that number being six.

Second, the failure is non-detection. The Art. 15 row in Figure 5.1 did not become dangerous when the tabletop stopped running; it became dangerous when it stopped running and nothing noticed for seven months. Detection latency, not drift frequency, is the metric that describes the health of a compliance program — and it is a metric almost nobody tracks, because a program that thinks of drift as failure has no vocabulary for measuring how quickly it finds it.

Three classes of change must reach the matrix, and each needs a route that does not depend on someone remembering.

Regulatory change. New guidance, an adopted delegated act, an amendment, a supervisory authority decision that shifts how a provision is read. The route: a named owner monitors the sources module 1 named (EUR-Lex consolidated texts, the AI Office, EDPB publications), on a schedule, and the output of that monitoring is a re-verification of the affected rows' first two columns — obligation and control objective. This is the class most likely to have no route at all, because it originates outside the company and therefore triggers no internal workflow.

System change. A deploy touches a controlled surface. The route should be automatic and is the subject of module 6: policy checks that identify when a change affects a requirement and move the row's state accordingly. Until that exists, the manual version is a checklist item on changes to a named list of components, which works about as well as manual checklists ever do.

Organizational change. An owner leaves, a team reorganizes, a control's operation transfers. This is the trigger that killed Figure 5.1's row 4, and it is the one with the clearest fix: owners are roles, transitions of role holders are already a tracked HR event, and the matrix should be a system of record consulted when someone changes roles. Meridian's rule after the row-4 incident: no role change completes until every matrix row owned by that role has a named successor, checked as part of offboarding rather than remembered afterward.

Two organizations, identical controls, identical systems. In the first, an assessment date is set and six weeks of archaeology begin: engineers reconstruct what configuration was live last March, someone assembles screenshots, a spreadsheet is filled in the week before, and the assessment passes. In the second, the assessment date is set and the compliance lead runs a query.

The difference is not diligence. It is whether evidence is produced by the system as a consequence of operating, or produced by people as a consequence of being asked. And the difference in quality is larger than the difference in effort, because retrospectively assembled evidence has a structural problem: it demonstrates the state of the world on the day it was assembled, which is precisely the day the organization was most motivated to look good.

So what makes an artifact evidence rather than a file? Four properties, and a skeptical assessor — or opposing counsel — checks them in roughly this order.

Provenance. What system produced this, and can that be established independently of the person handing it over? A JSON document emitted by a named CI job with its commit SHA has provenance; a spreadsheet has none. Timestamp. When was it produced, on a clock nobody involved controls? Integrity. Can it be shown not to have been altered since — object lock, write-once storage, or a signature? Linkage. Which requirement does it evidence? An artifact that cannot be connected to a specific requirement ID is a file that proves something happened, without establishing what obligation that something discharges.

Sort your controls into two classes, honestly, because the cost of misfiling in either direction is high.

The automatable class covers controls whose satisfaction is a fact about configuration or system state that a program can read and assert. Retention settings on a bucket or table. Access policies and role bindings. Model and prompt version pinning. The presence and schema-conformance of required log events. Encryption and transport settings. Field-allowlist conformance — REQ-MIN-005C-02's check is nothing more than reading retrieval_allowlist.yaml and asserting it equals the approved set, which is a fifteen-line check enforcing a statutory principle. Dependency and model provenance. The defining feature is that a disagreement about whether the control holds is resolvable by reading state, which is exactly the requirement-quality criterion from module 4 — a well-written requirement is often already a specification for its own check.

The judgment class covers controls whose satisfaction is a human assessment. Whether a legitimate-interests balancing test was reasonable. Whether a risk assessment considered the right foreseeable misuses. Whether oversight is meaningful in module 3's substantive sense. Whether a documentation set genuinely describes the system as built. No amount of tooling converts these into assertions, and the attempt is corrosive: a CI check that claims to verify a balancing test verifies only that a file exists at a path, while producing a green signal that reads as though something was validated.

The two classes are not equal in prestige and this causes a specific distortion: teams automate what is automatable, then quietly treat the un-automated remainder as less real. Resist that. The judgment-class controls are usually the ones carrying the most regulatory weight — meaningfulness of oversight is the whole Article 22 position — and what they need is not automation but a designed cadence: a named attester, a defined interval, a specified artifact with the same four properties, and an alert when the interval lapses. The cadence lapse is itself machine-detectable even when the judgment is not, which is the automation that actually helps.

The architecture is four stages, and it is deliberately unglamorous — the whole point is that it is built from components you already run.

Producers emit evidence: CI policy checks on merge and deploy, runtime probes on a schedule, periodic jobs (retention sweeps, access reconciliation), and human attestations for the judgment class. Every producer emits the same envelope — requirement ID, producer identity, commit or job run ID, UTC timestamp, result, and payload — because a heterogeneous evidence store is a store nobody can query.

The evidence store is object storage with versioning and object lock in compliance mode, retention set to exceed the longest applicable obligation. Immutability is the property that converts a file into something an adversarial reader will accept, and it is a bucket setting.

The index is keyed by requirement ID. This is the piece that is usually missing, and its absence is why organizations with excellent evidence still fail assessments: artifacts landing in a bucket with timestamp-based paths are unfindable at the moment they are needed. The index maps requirement ID to its artifacts over time, and its schema comes directly from module 5's matrix — the matrix is the index's schema source, which is what finally makes the matrix an operational artifact rather than a document.

The audit view answers the query the whole system exists to serve: show me current evidence for REQ-OVS-014-03, and its sibling, show me every requirement whose evidence is older than its cadence allows. The second query is the drift detector.

Built on Meridian's stack, this is: a scheduled EventBridge rule invoking Lambda probes, checks running as pipeline steps, an S3 bucket with Object Lock in compliance mode and a 24-month default retention, a DynamoDB table as the requirement-ID index, and a small internal page over it. The unglamorousness is the point — every component is one your team already operates, and the entire novelty is the discipline of the common envelope and the requirement-ID key.

Now wire module 5's state machine to the pipeline, so that lifecycle states are set by events rather than by meetings.

A CI policy check that fails on a merge affecting a controlled surface moves its requirement's row to drifted automatically and notifies the row's owner — the transition that Figure 5.2 draws as "change without re-test" becomes an actual message to an actual person. Evidence expiry is a scheduled query: any requirement whose most recent artifact is older than its declared cadence moves to drifted without anyone noticing it should have. And the silent path — the dashed edge where a control ships and is never tested — becomes detectable by inverting the index: any requirement in the matrix with zero artifacts ever is a control that has never been evidenced, which is a report you can run today and which is, in most organizations, uncomfortably long the first time.

That dashed path deserves the last word of this module, because it is the failure that survives good tooling. A pipeline can tell you that the checks it ran passed. It cannot tell you about a check that was quietly disabled to unblock a release, or a control that was never encoded. Only the matrix knows what should exist, which is why the two artifacts are load-bearing together and neither is sufficient alone: the matrix without the pipeline is a document that goes stale, and the pipeline without the matrix is a dashboard that is green about an unknown subset of your obligations.

"Conformity assessment" sounds like it requires an external body with a certificate, and for most systems it does not. Article 43 routes high-risk systems to one of two procedures. For Annex III point 1 — biometrics — a notified body is involved where harmonized standards have not been applied. For Annex III points 2 through 8, which is where nearly every business system lives, the route is the internal control procedure of Annex VI: the provider verifies its own quality management system, checks the technical documentation against the Chapter 2 requirements, and confirms the design and post-market monitoring are consistent with them.

Reframed for a builder, Article 43 is a release gate your own quality management system must be able to pass on demand. The provider then draws up a written EU declaration of conformity (Art. 47) in which a named legal person states that the system meets the requirements, keeps it for 10 years, affixes CE marking (Art. 48), and registers the system in the EU database before putting it into service (Art. 49). The declaration is the sharp end: it is a document with a signature on it, which is why it concentrates attention in a way that a control inventory does not.

Draftline phase 2, if classified high-risk, traces to the internal-control path. The practical consequence is that the assessment is not the hard part; the quality management system behind it is. Article 17 requires a documented QMS covering regulatory compliance strategy, design and development controls, verification and testing procedures, technical specifications, data management, risk management, post-market monitoring, incident reporting, record-keeping, and accountability. If your engineering organization has a design review process, a test strategy, a change-management practice, and an incident process, you have most of a QMS already and the work is documenting it as one rather than inventing it.

As deployer, Meridian's parallel duty is verification: Art. 26 requires deployers to use high-risk systems in accordance with the provider's instructions, assign human oversight to competent people with authority and support, ensure input data is relevant and sufficiently representative, monitor operation, retain logs for at least six months, and inform affected persons. When you are both provider and deployer, both columns are yours — and it is worth checking that they are separately owned in the matrix, because a single owner tends to satisfy one and quietly assume the other.

Annex IV specifies what a high-risk system's technical documentation must contain, and reading it as an engineer produces a pleasant surprise: most of it is documentation a functioning engineering organization already produces, under different names, for different reasons.

That mapping is the whole method: do not write a technical file, assemble one, and scope the actual work to the gaps. The two gaps here are typical. Foreseeable-misuse analysis has no home in normal engineering practice — it asks what users will do with the system that you did not intend and could reasonably have predicted, which for Draftline includes agents pasting draft output into channels the tool was never scoped for, and using the assistant for complaint responses where regulatory language matters. Post-market monitoring (Art. 72) is likewise not the same thing as ops dashboards: it requires a plan — what is monitored, against what thresholds, by whom, with what escalation — and the plan is the deliverable, not the graphs.

One more Annex IV property that changes how you schedule the work: technical documentation must be kept up to date. A file that is accurate at release and stale six months later is not compliant, and "we will refresh it annually" is a scheduling decision that guarantees eleven months of non-conformity each year. The practical answer is to bind documentation updates to the same trigger as everything else in module 5 — a change that touches a documented surface updates the documentation in the same change, reviewed in the same pull request.

Module 4 traced Article 12 to REQ-LOG-012-01, and this section builds the spec behind it — specifically the part that makes it interesting, which is that logging sits in a genuine tension between two obligations that both bind.

Article 12 requires automatic recording of events over the system's lifetime, appropriate to identifying risk situations and substantial modifications and to facilitating post-market monitoring; Article 26(6) requires deployers to keep those logs for at least six months. GDPR Article 5(1)(c) requires that the personal data in those logs be limited to what is necessary, and 5(1)(e) requires it be kept no longer than necessary. A naive reading produces a contradiction and then a bad resolution: teams log everything for a long time (satisfying Art. 12, breaching minimization) or log almost nothing (satisfying minimization, failing reconstruction).

The resolution is that the two obligations constrain different dimensions, and seeing that is the whole trick. Article 12 constrains what must be reconstructable. GDPR constrains what personal data may be retained. These are separable, because reconstruction does not require retaining content — it requires retaining enough to establish what happened, and identifiers plus references do that where raw text does not.

The two bottom rows are where the design earns its keep. Not logging raw prompts and completions removes the single largest personal-data exposure in the system — module 3's Lane B discovered its prompt store on day 19 of a DSAR — while losing nothing Article 12 requires, because the prompt is deterministically reconstructable from the template version, the allowlist version, the source document IDs at their recorded hashes, and the customer record as it then stood. Reconstruction becomes a procedure rather than a lookup, which is a small operational cost against a large standing liability.

Note also that the six-month deployer retention in Art. 26(6) and the 90-day figure here are in tension, and the tension is deliberate on Meridian's part: 90 days applies to Draftline's operational resolution log, while claim decision records — which carry the reconstruction fields copied at closure, per module 5's row 2 — are retained on the claims system's own schedule. If Draftline phase 2 is classified high-risk, the resolution log retention moves to at least six months to meet Art. 26(6), and the fact that this is a config value rather than an architecture change is exactly the payoff of having designed retention as a parameter.

Article 14(4) enumerates what the human must be able to do, and reading it as a UX specification rather than a policy statement is the move that makes it buildable. The measures: properly understand the system's capacities and limitations and monitor its operation, including detecting anomalies and dysfunctions; remain aware of automation bias; correctly interpret the output; decide not to use the system or otherwise disregard, override, or reverse the output; and intervene or interrupt the system, including via a stop button.

Each of those is an affordance, and each affordance produces a log event that is itself the evidence the control operated. That correspondence — measure, affordance, log event, metric — is the whole design.

Two design decisions in that picture do disproportionate work. The sources panel is what converts review from a plausibility judgment into a verification: an agent shown a fluent paragraph can only assess whether it reads correctly, while an agent shown the paragraph beside the three policy clauses it drew on can assess whether it is right. And the reason code on override turns a corrective action into a dataset — override reasons aggregated over a quarter tell you which failure modes the model actually exhibits, which feeds the risk management system and the post-market monitoring plan that Figure 7.1 flagged as net-new.

Finally, the countermeasure against the module 3 rubber stamp. Automation bias is a documented human tendency, not a failure of diligence, so it must be designed against rather than trained away. Meridian's three measures: dwell-time monitoring with an alert when the seven-day median review time on auto-resolutions falls below 45 seconds; a mandatory blind re-review of 60 sampled cases quarterly, with the reviewer seeing the inputs but not the proposed outcome; and an override-rate floor alert at 2%, on the reasoning that a model whose outputs are never overridden is either perfect or unexamined, and only one of those is likely.

The flagship anti-pattern, and the one that consumes the most resources. Compliance theater is a program that produces documents but cannot trace any of them to controls, requirements, or evidence. Policies exist and are well written. Training is assigned and completed. An annual attestation is signed. And no artifact in the entire apparatus connects to a system behavior that could be verified.

The symptom, and how to elicit it. Take any sentence from any policy — "access to customer data is restricted on a need-to-know basis" — and ask: which requirement ID does this land on, and what evidence shows it operated last quarter? In a healthy program you get an ID and an artifact within a minute. In theater you get a description of the policy's approval process, a reference to the annual audit, or an offer to introduce you to someone else. The pause is diagnostic, and so is the redirection to process about the document rather than to the document's consequences.

The layer that failed: everything below the obligation. Theater is the state of a program in which layer 1 exists in abundance and layers 2 through 6 were never built, which is why it produces so much output — writing policies is the only activity available.

The corrective: run module 4's stack backward against your own program as an audit. Sample five policy statements at random and attempt to trace each to a requirement ID and a current evidence artifact. The trace failure rate is your theater score, and it is the most useful number you can produce about a compliance program in an afternoon. Then fix in the direction of the highest-risk obligations rather than the easiest traces.

Two anti-patterns that look unrelated and share a root cause: both treat compliance as an event rather than a property.

Legal review as a launch gate. Symptom: counsel first sees the system at 90% built, in a review scheduled two weeks before launch, and the meeting is titled "legal sign-off." The tell is in the calendar, not in the outcome — a gate can produce a "yes" and still be the wrong structure. Layer that failed: obligation, which never entered as a design input, so the entire translation ran on assumptions nobody checked. Consequence: the review's only available outcomes are rubber-stamp or expensive, because at 90% built the architecture is set and the only levers are ship-with-risk or delay. This is why gate-thinking makes counsel look obstructive: they are asked to evaluate decisions at the one moment when nothing can cheaply change. Corrective: obligations enter at the requirements stage, which is precisely what modules 2 and 3's obligation lists exist to produce. The structural version: an obligations list is a required section of the design doc, and its absence blocks design review the way a missing test plan does.

The annual-audit scramble. Symptom: plot the creation dates of your evidence artifacts on a twelve-month axis. If they cluster in the weeks before an audit, you have the scramble regardless of whether the audit passed. This is Figure 6.1's top band, and it is a genuinely measurable diagnostic — most organizations have never looked. Layer that failed: evidence, treated as a reporting output rather than a system byproduct. Consequence: beyond the six weeks of diverted engineering, the evidence is weak in a specific way that a skilled assessor probes — it attests to the assembly period rather than the assessed period, and reconstruction under deadline is exactly the condition under which people record what they believe was true. Corrective: module 6's pipeline, starting with the three highest-risk controls rather than all of them.

The shared root is worth stating plainly, because it explains why organizations that fix one often still have the other. Both anti-patterns model compliance as something you do at a moment — sign-off, audit — rather than something a system continuously is. An organization holding the event model will accept an eleven-month gap between compliance activities as normal, and will experience the suggestion that evidence should be generated on Tuesdays as strange.

The under-discussed failure, and the one your peer group is least equipped to argue against, because arguing against it sounds like arguing for less compliance.

Symptom: read your control inventory and try to cite an obligation for each control. The controls with no citable obligation are the over-compliance population — and they are usually defended not with an argument but with a posture: "it seemed safer," "we didn't want to take the risk," "the auditors like it." Related symptoms: a minimal-risk system carrying a quality management system, consent collected where legitimate interests plainly holds (which is worse than useless, since a withdrawn consent now blocks processing you were entitled to perform), and a classification exercise that reaches "high-risk" without walking Annex III area by area.

The layer that failed is the earliest one: applicability. Module 1's scope-trigger analysis was skipped or performed as a formality, so obligations were assumed rather than established.

The cost argument, made concretely. This is the part that has to be rehearsed, because the instinctive framing — over-compliance is cautious, under-compliance is reckless — treats one failure as a virtue. Three costs, all real:

Direct. Meridian's over-classification scenario from module 2 would have added an Art. 17 QMS workstream, an Annex IV documentation set, a conformity assessment, and EU database registration for a sentiment dashboard. Call it two engineer-quarters and a director's attention for a system the Act does not reach.

Displacement. The same reviewers, risk committee slots, and legal hours are finite. Every hour spent assessing the dashboard is an hour not spent on Draftline phase 2, which is the system that actually sits near a classification boundary and carries special-category data. Over-compliance is not extra safety; it is safety relocated to where it is not needed, from where it is.

Credibility. The most expensive and the least visible. An organization that experiences compliance requirements as uncalibrated learns to discount all of them, so the next genuine requirement arrives pre-discounted. You can watch this happen: it is why teams route around review rather than through it, and the routing is rational behavior in response to a function that has stopped distinguishing important from unimportant.

The corrective is module 1 run honestly, and the demonstration is module 2's Draftline classification — where the finding was "not high-risk," written down with the three facts that decide it. That document is a compliance deliverable, not the absence of one, and treating a well-reasoned negative finding as valuable output is the cultural change that makes the corrective stick.

Here is the whole field guide, arranged as what it is: six failures of specific layers of one stack.

Programs rarely exhibit one of these. They exhibit clusters, and the clusters have a geography, which the next figure makes usable.

That trajectory answers the sequencing question. If a program exhibits both theater and the scramble, fix traceability first — automating evidence for controls that trace to nothing produces the dashboard illusion, which is harder to correct than theater because it now has a confident green report defending it. Layer failures also cascade downward: a broken applicability analysis corrupts every layer beneath it, so an over-compliance finding is always more urgent than it feels.

The operating model. All of this reduces to a role that most organizations do not have. Someone must own the mapping from obligation to evidence: maintaining the matrix, running the translation for new obligations and new systems, routing the three change classes, and holding the evidence pipeline's requirements. Their artifacts are module 5's matrix and module 6's pipeline, and their authority is narrow but real — a design doc without an obligations section does not pass design review.

The role is not a lawyer's, because it specifies systems. It is not an engineer's, because it interprets provisions. It is not a traditional GRC role either, because GRC frameworks typically start at the control layer and inherit obligations from somewhere upstream. It sits precisely where a technical product manager sits, and requires exactly the two fluencies that are rarely found together: reading a provision structurally, and writing a requirement a skeptical engineer accepts as buildable.