Regulatory Deal Card Generator Patrick Munro

Regulatory Deal Card Generator

Purpose

Produces a single self-contained HTML file that presents a regulation as an interactive "deal card" for use in negotiation, advisory, or training settings. The output clearly separates what the law compels from what it leaves open to the parties. This matters because most regulatory guides collapse the two together, which wastes negotiation capital on obligations that are not negotiable and leaves genuine flexibility on the table.

When to use

• Preparing for a contract negotiation where a specific regulation drives material clauses
• Briefing a commercial counterparty or client on what a regulation actually requires of them
• Building internal training material that needs to outlast a single briefing session
• Producing a client-facing deliverable that survives being emailed around without losing its structure
• Any situation where the question "must we, or may we?" needs to be answered clause-by-clause

Output format

A single HTML file, inline CSS and JS, no external dependencies beyond optional web fonts. Offline-capable. Print-friendly. Designed to be opened in a browser and used as a working tool, not a static reference.

Core visible components:

• Sticky navigation across regulation sections
• Per-requirement rows showing: the requirement with its article reference, the required response, the negotiable aspects, and a worked example
• Collapsible detail blocks for secondary material
• Hover tooltips for defined terms
• Risk badges (high / medium / low) per requirement
• Optional bilingual toggle where applicable

Core structural rule

Every row in the deal card answers three questions, in this order:

1. What does the regulation mandate? (with article citation)
2. What is fixed about how it must be done? (the non-negotiable floor)
3. What is open to negotiation? (implementation mechanism, timing, allocation between parties, documentation format, etc.)

A row that cannot distinguish (2) from (3) is a row that has not been thought through. Force the distinction even when it is uncomfortable, and flag genuine ambiguity explicitly rather than hiding it in neutral prose.

Workflow

1. Identify the regulation. Confirm official citation, current consolidated version, and date of last amendment.
2. Verify the text. Cross-check against the primary source (EUR-Lex for EU instruments, official gazette or equivalent for national law). Do not rely on secondary summaries. If the regulation is recent or amended, check for corrigenda.
3. Structure by business logic, not article order. Users read deal cards by topic (data access, incident reporting, third-party risk) rather than by article number. Group accordingly and cite articles within each topic.
4. Classify each requirement. For each provision, write down the mandatory minimum, then separately write down what the parties can decide for themselves. Resist the temptation to collapse them.
5. Add a worked example per requirement. A concrete scenario showing what compliance looks like in practice, and where relevant a counter-example showing what non-compliance looks like.
6. Build the HTML. Use the pattern in references/html-template.md. Keep the file self-contained.
7. Test interactivity. Every collapsible, tooltip, and filter should work in a cold browser with no dev tools open.
8. Add version metadata. Regulation citation, date verified, and a visible note that the user should re-verify before relying on the output for any binding decision.

Design principles

Negotiation-focused framing

Translate legal language into three registers:

• Legal: "The data holder shall make data available to the user without undue delay."
• Business: "You must provide user access promptly; what counts as promptly, and in what format, is yours to negotiate."
• Risk: "Failure to provide access exposes you to administrative fines and a private right of action by users."

Article-level precision

Always cite specific articles. Be precise about whether a provision sits in the main text, an annex, or an implementing act. Where the provision depends on a delegated act that has not yet been adopted, say so.