diff --git a/assistant-workflows/eu-gdpr-pack/contract-clause-checklist/SKILL.md b/assistant-workflows/eu-gdpr-pack/contract-clause-checklist/SKILL.md new file mode 100644 index 00000000..049caaca --- /dev/null +++ b/assistant-workflows/eu-gdpr-pack/contract-clause-checklist/SKILL.md @@ -0,0 +1,66 @@ +--- +name: "contract-clause-checklist" +description: "Walk a single contract against 41 clause categories from the CUAD taxonomy: first assess which categories this deal needs, then mark each applicable one present, absent, or risky, quoting the clause when present, so that a safeguard the deal needs does not slip through by omission. Extractive: findings come from the contract text, not paraphrase. Use before signing, in negotiation, or in due diligence of one agreement, when the question is what is missing from this contract and which clauses bite. Jurisdiction-neutral framing with common-law roots; the assessment and the recommendation stay with the lawyer." +license: "MIT" +metadata: + version: "1.0.0" + author: "Wieslaw Mazur / MateMatic Solutions" + language: "English" + mike-display-name: "Contract Clause Checklist" + mike-type: "assistant" + mike-availability: "add-on" + practice: "General Transactions" + jurisdictions: "General" +--- +# Contract Clause Checklist + +The most expensive clauses are the ones that are not in the contract. Reviewing a contract is not only reading what is written - it is checking that no safeguard the deal needs is absent. This workflow walks the contract against a fixed list of 41 clause categories and, for each, says: present, absent, or present-but-risky, quoting the clause when present. + +It is extractive - what it shows comes from the contract, not from paraphrase. It flags presence and risk; the assessment and the call stay with the lawyer. + +One caution built into the method: CUAD is an extraction taxonomy, not a list of safeguards every agreement must contain. Several categories are deal-specific, and some are mutually exclusive pairs - uncapped liability versus a cap on liability, unlimited versus limited licence grants. Treating every absence as a red flag would bury the real gaps in false positives. + +## The 41 categories (CUAD taxonomy) + +Each category is assessed in two steps. First, applicability: does this deal need the clause at all, given the contract type, the parties, and the subject matter? Then, for applicable categories only: present / absent / risky, plus a quote when present. Mutually exclusive pairs count as one decision - record which side the contract takes, not the "absence" of the other side. + +### Contract metadata +- Document name, Parties (verify authority to sign), Governing law. + +### Group 1 - term and dates +- Agreement date, Effective date, Expiration date, Renewal term (auto-renew?), Notice period to terminate renewal. + +### Group 2 - competition restrictions +- Non-compete, Exclusivity, No-solicit of customers, Competitive restriction exception (carve-outs). + +### Group 3 - control and assignment +- Change of control (consent or termination on M&A?), Anti-assignment. + +### Group 4 - licences +- License grant, Non-transferable license, Affiliate license (licensor), Affiliate license (licensee), Unlimited license, Irrevocable or perpetual license. + +### Group 5 - post-term and audit +- Post-termination services, Audit rights. + +### Group 6 - liability +- Uncapped liability, Cap on liability. + +### Ungrouped +- Most favored nation, No-solicit of employees, Non-disparagement, Termination for convenience, ROFR/ROFO/ROFN, Revenue/profit sharing, Price restrictions, Minimum commitment, Volume restriction, IP ownership assignment, Joint IP ownership, Source code escrow, Covenant not to sue, Liquidated damages, Warranty duration, Insurance, Third-party beneficiary. + +## Output format + +Start with the red flags, then the full table: + +- RED FLAGS: each category that is applicable and absent, with why this deal needs it, and each risky category with how it is one-sided. A category marked not applicable never becomes a red flag. +- 41-CATEGORY TABLE with columns: Category, Applicable (yes/no + why), Status, Note, Quote (if present). + +## Limits + +- This is a presence-and-risk checklist, not an interpretation of clause wording. Whether a clause is effective, and the recommendation, are the lawyer's. +- The taxonomy is common-law-oriented at source; for a specific jurisdiction, add local-law anchors. +- Descriptive references without a clause ("the parties intend to cooperate") have nothing to match - mark them as "no clause, manual check". + +## Attribution + +The 41-category clause taxonomy is based on CUAD (Contract Understanding Atticus Dataset), The Atticus Project, licensed CC BY 4.0 (https://www.atticusprojectai.org/cuad). Category descriptions and the risk framing are the author's own. diff --git a/assistant-workflows/eu-gdpr-pack/gdpr-breach-notification/SKILL.md b/assistant-workflows/eu-gdpr-pack/gdpr-breach-notification/SKILL.md new file mode 100644 index 00000000..e41a4d44 --- /dev/null +++ b/assistant-workflows/eu-gdpr-pack/gdpr-breach-notification/SKILL.md @@ -0,0 +1,44 @@ +--- +name: "gdpr-breach-notification" +description: "Run the personal data breach decision tree under GDPR Articles 33-34 and EDPB Guidelines 9/2022: classify the breach, assess risk to rights and freedoms, track the 72-hour notification deadline from awareness, decide on communication to data subjects, and draft the supervisory authority notification, the data subject communication, and the internal register entry. Use when a data leak, ransomware incident, misdirected email, or lost device raises the question of whether and whom to notify. The workflow drafts; the controller or DPO decides and sends." +license: "MIT" +metadata: + version: "1.0.0" + author: "Wieslaw Mazur / MateMatic Solutions" + language: "English" + mike-display-name: "GDPR Breach Notification" + mike-type: "assistant" + mike-availability: "add-on" + practice: "Data Protection" + jurisdictions: "European Union" +--- +# GDPR Breach Notification + +In a breach, the clock and the documented reasoning are what matter. This workflow runs a documented decision tree and produces drafts; the decision to notify and the act of sending belong to the controller or DPO. Do not guess - flag missing inputs for the risk assessment as gaps. + +## Step 1 - Is it a breach, and which type + +A personal data breach is a breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data (Article 4(12)). Classify it as a confidentiality breach (disclosure or access), an integrity breach (alteration), or an availability breach (loss or destruction). Breaches are often combined - record every type that applies. + +## Step 2 - Risk assessment to rights and freedoms + +Assess against the factors in EDPB Guidelines 9/2022 (formerly WP250): type of breach; nature, sensitivity, and volume of the data; ease of identifying individuals; severity of consequences (identity theft, financial loss, discrimination, reputational harm); special characteristics of the individuals (children, patients); and the number of individuals affected. Record the outcome as one of three levels: no risk, risk, or high risk. + +## Step 3 - Notify the supervisory authority (Article 33) within 72 hours + +- The clock starts when the controller becomes aware of the breach, not when the incident occurred. The deadline is 72 hours from awareness. Compute the exact deadline date and time and state it in the draft and the register - do not estimate it. +- Notification is required unless the breach is unlikely to result in a risk to rights and freedoms (Article 33(1)). If not notifying, justify and document the decision. +- If the deadline has passed, notify anyway and state the reasons for the delay (Article 33(1), second sentence). +- Draft the notification to the content required by Article 33(3): nature of the breach with categories and approximate numbers of data subjects and records, DPO contact details, likely consequences, and measures taken or proposed. Notification in phases is allowed (Article 33(4)). + +## Step 4 - Communicate to data subjects (Article 34) + +If the risk is high, the controller must communicate the breach to the affected individuals without undue delay, in clear and plain language, covering the elements of Article 34(2): description of the breach, DPO contact, likely consequences, and measures. Check the exemptions in Article 34(3): safeguards that render the data unintelligible (such as encryption), subsequent measures that eliminate the high risk, or disproportionate effort - in which case draft a public communication instead. + +## Step 5 - Breach register (Article 33(5)) + +Record every breach in the internal register, including breaches that were not notified: facts, effects, and remedial action. The register is the accountability evidence the supervisory authority will ask for. + +## Governance boundary + +The workflow runs the decision tree, tracks the 72-hour deadline, and drafts the notification, the data subject communication, and the register entry. A human approves the risk assessment and sends the notification and communications. Sending is never automatic. diff --git a/assistant-workflows/eu-gdpr-pack/gdpr-data-subject-requests/SKILL.md b/assistant-workflows/eu-gdpr-pack/gdpr-data-subject-requests/SKILL.md new file mode 100644 index 00000000..f0945ac8 --- /dev/null +++ b/assistant-workflows/eu-gdpr-pack/gdpr-data-subject-requests/SKILL.md @@ -0,0 +1,49 @@ +--- +name: "gdpr-data-subject-requests" +description: "Handle a data subject rights request under GDPR Articles 12 and 15-22: identify the right invoked (access, rectification, erasure, restriction, portability, objection, automated decisions), verify identity, track the one-month deadline and the two-month extension, check exemptions and refusal grounds, and draft the response plus a request register entry. Use when a subject access request, erasure request, objection, or portability request arrives and the deadline and legal gates must be worked through. The workflow drafts; a human decides, performs the erasure or export, and sends the response." +license: "MIT" +metadata: + version: "1.0.0" + author: "Wieslaw Mazur / MateMatic Solutions" + language: "English" + mike-display-name: "GDPR Data Subject Requests" + mike-type: "assistant" + mike-availability: "add-on" + practice: "Data Protection" + jurisdictions: "European Union" +--- +# GDPR Data Subject Requests + +A rights request is a clock plus a legal assessment, not an automation. The workflow classifies the request, tracks the deadline, and produces a draft; the fulfil-or-refuse decision and the act of sending belong to the controller. Erasure and export are irreversible or outward acts, so they always stay with a human. + +## Step 0 - Identity and deadline + +- Identity verification (Article 12(6)): where reasonable doubt exists, request further information. This does not pause the clock unconditionally. Per EDPB Guidelines 01/2022, the deadline may be suspended only where the additional information is necessary to confirm identity and the controller asked for it without undue delay. Always preserve the original receipt date in the register - a late or disproportionate identity request does not extend the deadline, and verification must not be used to obstruct the request. +- Deadline: one month from receipt (Article 12(3)), extendable by up to two further months for complexity or number of requests - the data subject must be informed of the extension and its reasons within the first month. Compute the exact deadline dates and state them in the draft and register. Month arithmetic has traps: under Regulation (EEC) No 1182/71, a request received on 31 January runs to the last day of February. +- Free of charge by default (Article 12(5)). A fee or refusal is allowed only where the request is manifestly unfounded or excessive, and the burden of proof is on the controller. + +## Step 1 - Classify the right + +| Article | Right | Key points | +|---|---|---| +| 15 | Access and copy | scope of information, copy of the data, third-party rights | +| 16 | Rectification | inaccurate or incomplete data | +| 17 | Erasure ("right to be forgotten") | grounds in 17(1) against the exemptions in 17(3): legal obligation, legal claims, freedom of expression | +| 18 | Restriction | a freeze instead of erasure | +| 20 | Portability | consent or contract basis plus automated processing only; structured, machine-readable format | +| 21 | Objection | legitimate interest or direct marketing - the marketing objection is absolute | +| 22 | Automated decisions | the primary right is not to be subject to a solely automated decision producing legal or similarly significant effects; exceptions in 22(2) (contract, authorising law, explicit consent) trigger safeguards - at minimum human intervention, expressing one's view, and contesting the decision (22(3)) | + +A request can be informal - interpret its substance, not its heading. + +## Step 2 - Gates and refusal grounds + +Check the exemptions specific to the right invoked (especially Article 17(3) and national restrictions). Every refusal must be legally justified and must inform the data subject of the right to lodge a complaint with the supervisory authority and to seek a judicial remedy (Article 12(4)). + +## Step 3 - Draft the response and the register entry + +Draft the response in clear and plain language (Article 12(1)), tailored to the right invoked. For an Article 15 request that means a copy of the personal data undergoing processing, retrieved from the operational systems that actually hold it, plus any available information on the data's source (Article 15(1)(g)). The records of processing supply only the general processing information - purposes, categories, recipients, retention - not the person's data or necessarily its sources; a response drafted from the RoPA alone is incomplete. Close with a register entry recording receipt date, request type, deadline, and outcome. + +## Governance boundary + +The workflow classifies, computes deadlines, drafts, and maintains the register. A human verifies identity, decides whether to fulfil or refuse, performs the erasure or export, and sends the response. Irreversible and outward acts are never automatic. diff --git a/assistant-workflows/eu-gdpr-pack/gdpr-dpia/SKILL.md b/assistant-workflows/eu-gdpr-pack/gdpr-dpia/SKILL.md new file mode 100644 index 00000000..6f9a281d --- /dev/null +++ b/assistant-workflows/eu-gdpr-pack/gdpr-dpia/SKILL.md @@ -0,0 +1,46 @@ +--- +name: "gdpr-dpia" +description: "Assess whether a Data Protection Impact Assessment is required under GDPR Article 35 and draft it to the Article 35(7) structure: run the threshold test against the EDPB WP248 criteria, the Article 35(3) mandatory cases, and the national supervisory authority blacklist, then build the systematic description, the necessity and proportionality assessment, the risk assessment, and the mitigating measures, and decide whether Article 36 prior consultation applies. Use for profiling, CCTV, AI systems, large-scale monitoring, or any processing that may be high risk. The workflow drafts; the controller accepts residual risk and files." +license: "MIT" +metadata: + version: "1.0.0" + author: "Wieslaw Mazur / MateMatic Solutions" + language: "English" + mike-display-name: "GDPR DPIA" + mike-type: "assistant" + mike-availability: "add-on" + practice: "Data Protection" + jurisdictions: "European Union" +--- +# GDPR DPIA + +A DPIA is not a checkbox - it is a process for managing risk to the rights and freedoms of natural persons. This workflow runs the process and produces a draft; the residual-risk acceptance and the go/no-go decision belong to the controller. + +## Step 1 - Is a DPIA required (Article 35(1) threshold) + +A DPIA is mandatory where processing is likely to result in a high risk. Check three routes: + +1. The supervisory authority's mandatory list (Article 35(4)) - each EU supervisory authority publishes a list of operations that always require a DPIA. Check the relevant national list. +2. The nine EDPB criteria (WP248 rev.01), with the rule of thumb that meeting two or more criteria means a DPIA is required: evaluation or scoring; automated decisions with significant effect (Article 22); systematic monitoring; sensitive or highly personal data; large-scale processing; matching or combining datasets; vulnerable data subjects (children, employees); innovative technology (AI, IoT); and processing that prevents exercising a right or using a service. +3. The explicit cases in Article 35(3): systematic and extensive evaluation including profiling, large-scale processing of special-category or criminal data, and large-scale systematic monitoring of publicly accessible areas. + +Record the verdict as required, recommended, or not required, with a per-criterion justification. This is a screening, not a clearance - the controller documents the decision. + +## Step 2 - DPIA structure (Article 35(7) minimum) + +Draft the four pillars: + +- (a) A systematic description of the processing and its purposes, including the legitimate interest where relied on. +- (b) An assessment of necessity and proportionality against the purposes: minimisation, legal basis, purpose limitation, retention, data subject rights, transfers. +- (c) A risk assessment to rights and freedoms: risk sources, confidentiality, integrity, and availability scenarios, likelihood times severity. +- (d) The measures envisaged to address the risks and demonstrate compliance, plus the residual risk. + +Record the DPO's advice (Article 35(2)) and any consultation with data subjects (Article 35(9)). + +## Step 3 - Prior consultation (Article 36) + +If the residual risk remains high despite the measures, the controller must consult the supervisory authority before processing. Draft the consultation request to the scope of Article 36(3) - a human files it. + +## Governance boundary + +The workflow classifies the criteria, drafts the DPIA, and prepares the consultation request. A human approves the risk assessment, decides on deployment, signs, and files. The outward act of filing with the supervisory authority is never automatic. diff --git a/assistant-workflows/eu-gdpr-pack/gdpr-records-of-processing/SKILL.md b/assistant-workflows/eu-gdpr-pack/gdpr-records-of-processing/SKILL.md new file mode 100644 index 00000000..69ee33a9 --- /dev/null +++ b/assistant-workflows/eu-gdpr-pack/gdpr-records-of-processing/SKILL.md @@ -0,0 +1,56 @@ +--- +name: "gdpr-records-of-processing" +description: "Build and validate the records of processing activities (RoPA) required by GDPR Article 30: the controller register under Article 30(1) and the processor register under Article 30(2), enforcing every mandatory field - purposes, categories of data subjects and data, recipients, third-country transfers and safeguards, erasure time limits, and security measures. Flags activities that trigger a DPIA and tests the narrow Article 30(5) exemption. Use when creating a RoPA from scratch, auditing an existing register for gaps, or preparing accountability evidence for a supervisory authority. Complements the DPA review workflows, which cover the processor contract itself." +license: "MIT" +metadata: + version: "1.0.0" + author: "Wieslaw Mazur / MateMatic Solutions" + language: "English" + mike-display-name: "GDPR Records of Processing" + mike-type: "assistant" + mike-availability: "add-on" + practice: "Data Protection" + jurisdictions: "European Union" +--- +# GDPR Records of Processing + +The RoPA is a living accountability document, and its required content can be checked mechanically against Article 30. This workflow builds or validates the register and reports gaps; ownership of the register and every filing decision stay with the controller. + +## Controller register (Article 30(1)) + +For each processing activity, the register must record: + +- the name and contact details of the controller, any joint controller, the representative, and the DPO, +- the purposes of the processing, +- the categories of data subjects and the categories of personal data, +- the categories of recipients, including recipients in third countries or international organisations, +- transfers to third countries with the identification of the country and the documentation of safeguards (Chapter V), +- the envisaged erasure time limits for each category of data, +- a general description of the technical and organisational security measures (Article 32). + +Validate completeness field by field. A missing field is a gap to report, not a value to guess. + +## Processor register (Article 30(2)) + +The processor's register has its own mandatory field list, validated field by field like the controller's: + +- the name and contact details of the processor or processors and of each controller on behalf of which the processor is acting, and, where applicable, of the controller's or the processor's representative and the DPO (Article 30(2)(a)), +- the categories of processing carried out on behalf of each controller, +- transfers to third countries or international organisations, with the identification of the country and, for transfers under the second subparagraph of Article 49(1), the documentation of suitable safeguards, +- a general description of the technical and organisational security measures (Article 32(1)). + +A register that lists controllers and sub-processors but omits contact details, the representative, or the DPO is incomplete - report the gap, do not mark the activity complete. + +## Cross-checks + +- Flag every activity whose description meets a DPIA trigger (profiling, large-scale special-category data, systematic monitoring) so it can be taken through a DPIA. +- Test the Article 30(5) exemption honestly, disqualifier by disqualifier - any one of them removes it. The exemption is unavailable if the organisation employs 250 persons or more; and regardless of size, if the processing is likely to result in a risk to rights and freedoms, is not occasional, includes special categories of data under Article 9(1), or includes personal data relating to criminal convictions and offences under Article 10. In practice it rarely applies - most organisations process employee or customer data regularly. +- Where the register reveals a processor without a compliant processing contract, note it and route the contract itself to a DPA review workflow. + +## Output + +A draft register (or a gap report against an existing one) with each activity marked complete or listing its missing fields, plus the DPIA flags and contract flags. + +## Governance boundary + +The workflow builds and validates the register and maps gaps to the article. A human approves the content and owns the register. Nothing is filed or signed automatically. diff --git a/assistant-workflows/eu-gdpr-pack/legal-citation-extraction/SKILL.md b/assistant-workflows/eu-gdpr-pack/legal-citation-extraction/SKILL.md new file mode 100644 index 00000000..c8c1513d --- /dev/null +++ b/assistant-workflows/eu-gdpr-pack/legal-citation-extraction/SKILL.md @@ -0,0 +1,64 @@ +--- +name: "legal-citation-extraction" +description: "Extract every legal citation from an English-language text by pattern rather than judgement: ECLI identifiers (CJEU and national), EU act identifiers (CELEX, Official Journal references, Regulation and Directive numbers), case names and numbers, and cited provisions, then normalise, deduplicate, and resolve short references (ibid., id., supra, op. cit., the above-cited judgment) to their antecedents. The front-end to citation verification: find every citation first, then check it. Use before verifying authorities, before sending a brief or opinion, or when asked what a text cites." +license: "MIT" +metadata: + version: "1.0.0" + author: "Wieslaw Mazur / MateMatic Solutions" + language: "English" + mike-display-name: "Legal Citation Extraction" + mike-type: "assistant" + mike-availability: "add-on" + practice: "Legal Research" + jurisdictions: "European Union, General" +--- +# Legal Citation Extraction + +You can only verify what you first find. Grounding a citation checks whether it exists in the source - but it runs on a list that someone has to assemble first. This workflow is that front-end: it walks the text and lists every authority, so none slips past verification. A missed citation is an unverified one. + +Extraction is mechanical - by patterns and rules, not by judgement - on purpose: an unconstrained reading might miss a citation or invent one. + +## Three steps + +1. Extraction - recognise and capture every reference by the patterns below. +2. Aggregation - resolve short references (ibid., id., supra, op. cit., "the above-cited judgment") to their antecedents by the pointer-aware rules below, so they count as one citation, not several. +3. Hand-off - pass the structured list to verification: does each cited authority exist, and does it say what the text claims. + +## Citation patterns + +### Case law +- ECLI (EU): `ECLI:EU:C:2020:559` (Court of Justice), `ECLI:EU:T:2019:...` (General Court). +- ECLI (national): `ECLI:NL:HR:2021:...`, `ECLI:DE:BGH:...`, `ECLI:PL:SN:...`. +- Case names and numbers: `Party v Party`; CJEU case numbers `C-123/20`, `C-123/20 P` (appeal), joined cases `C-123/20 and C-124/20`; General Court `T-456/19`. + +### EU legislation +- CELEX: `32016R0679`, `32019L0790` (sector + year + type + number). +- Named acts: `Regulation (EU) 2016/679`, `Directive 2019/790`, `Regulation (EC) No 1/2003`. +- Official Journal: `OJ L 119`, `OJ C 326`. + +### Provisions +- `Article 5(1)(a) GDPR`, `Art. 263 TFEU`, `section 12`, `ยง 3(2)`. + +## Aggregation - short references + +Short reference forms carry different resolution rules - they cannot all be sent to the nearest antecedent: + +- `ibid.`, `id.`, `loc. cit.` - refer to the immediately preceding authority. +- `supra`, `op. cit.` - often carry a pointer that overrides proximity: an author name, a title fragment, or a note number ("Kranenborg, op. cit., p. 12"; "supra note 14"). Resolve by the pointer first; fall back to proximity only when the reference is bare. +- Descriptive forms (`the cited judgment`, `the above-cited`) - match by the described attributes (court, party, subject), not by position alone. + +Where more than one antecedent matches, or none does, mark the reference **unresolved - manual review** instead of guessing: a wrong merge silently fuses two distinct authorities into one. Count each resolved reference as the same citation as its antecedent, but record where it occurs. + +## Output format + +A numbered table with columns: Type, Citation (normalised), Occurrences (page or offset), Antecedent (if a short reference). Close with the list of citations to verify. + +## Limits + +- Extraction catches references in a known format. A descriptive reference with no identifier ("the Court's data-protection case law") has nothing to match - mark it "no identifier, manual check". +- This is not existence verification - it says what is cited, not whether the citation is real. +- The patterns cover the common EU and ECLI formats; an unusual citation style may slip through. At high stakes, review by hand as well. + +## Attribution + +The extraction, aggregation, and annotation architecture follows eyecite (Free Law Project), BSD-2-Clause (https://github.com/freelawproject/eyecite), as a design pattern only - no eyecite code is used. US reporter patterns are dropped; the ECLI, CELEX, OJ, and EU citation patterns and the antecedent rules are the author's own. diff --git a/assistant-workflows/eu-gdpr-pack/legal-syllogism/SKILL.md b/assistant-workflows/eu-gdpr-pack/legal-syllogism/SKILL.md new file mode 100644 index 00000000..5b2fde70 --- /dev/null +++ b/assistant-workflows/eu-gdpr-pack/legal-syllogism/SKILL.md @@ -0,0 +1,57 @@ +--- +name: "legal-syllogism" +description: "Build the explicit legal syllogism for an issue: state the major premise (the rule and its interpretation), the minor premise (the material facts), the application subsuming each fact under each element of the rule, and the conclusion, then flag the weak links - unstated assumptions, contested facts, debatable interpretation. Forces every step of the reasoning to be said out loud and checkable instead of jumping from facts to a holding. Maps to civil-law subsumption and common-law IRAC/CREAC. Use when drafting an opinion, brief, or memo and the reasoning needs to be laid out element by element." +license: "MIT" +metadata: + version: "1.0.0" + author: "Wieslaw Mazur / MateMatic Solutions" + language: "English" + mike-display-name: "Legal Syllogism" + mike-type: "assistant" + mike-availability: "add-on" + practice: "Legal Analysis" + jurisdictions: "General" +--- +# Legal Syllogism + +A flawed opinion rarely fails at the conclusion - it fails at the premise nobody stated. Legal reasoning is a syllogism: the rule (major premise), the facts (minor premise), the application, and the conclusion. When a step is left unsaid because it seems obvious, that is where the gap hides, and that is where the other side, or the court, will strike. This workflow forces each step to be stated and marks what is settled and what is contested. + +It structures the reasoning; it does not decide the case. Judgement and the decision stay with the lawyer. + +## Method (subsumption / IRAC) + +1. Major premise (rule and interpretation) - identify the governing rule, then its reading: how each element of the rule is construed (text, structure, purpose). Note where authority or commentary splits. +2. Minor premise (material facts) - list the facts that matter to the rule's elements. Separate undisputed facts from contested ones, and facts from characterisations. +3. Application (subsumption) - for each element of the rule, show which fact satisfies it or does not. This is the real work: matching fact to element. +4. Conclusion - the legal consequence that follows from the application. +5. Weak-link test - mark which elements are contested in interpretation, which facts are contested on the evidence, and which assumptions were made silently. This is the map for any adversarial review that follows. + +## Output format + +``` +ISSUE: + +MAJOR PREMISE (rule): - "" + Interpretation: + +MINOR PREMISE (material facts): + - undisputed: <...> + - contested (evidence): <...> + +APPLICATION (element -> fact): + - : satisfied by | NOT satisfied | contested + - : ... + +CONCLUSION: + +WEAK LINKS: + - interpretation: + - facts: + - silent assumptions: <...> +``` + +## Limits + +- The syllogism orders reasoning - it does not perform interpretation or fact-finding. Whether the rule, its reading, and the facts are right is for the lawyer. +- It does not weigh competing arguments - it arranges them so attack and verification have something to work on. +- Subsumption assumes a rule with elements. For open-textured standards and the balancing of principles, a pure syllogism is not enough - mark it as balancing, not subsumption. diff --git a/assistant-workflows/eu-gdpr-pack/pack.yaml b/assistant-workflows/eu-gdpr-pack/pack.yaml new file mode 100644 index 00000000..e5847f68 --- /dev/null +++ b/assistant-workflows/eu-gdpr-pack/pack.yaml @@ -0,0 +1,21 @@ +$schema: "../../workflow-schema/pack.schema.yaml" +id: "eu-gdpr" +title: "EU GDPR Pack" +description: "English-language GDPR compliance workflows for EU practice: breach notification under Articles 33-34 with the 72-hour clock, DPIA threshold screening and drafting under Articles 35-36, data subject request handling under Articles 12 and 15-22, and records of processing under Article 30. The pack also carries three method workflows: a 41-category contract clause checklist, an explicit legal syllogism scaffold, and mechanical extraction of ECLI, CELEX, and EU citations. Every workflow produces drafts for human review; notification, filing, signing, and sending stay with the lawyer." +publisher: + name: "MateMatic Solutions" + url: "https://matematicsolutions.com" +license: "MIT" +version: "1.0.0" +jurisdiction: "European Union" +source: + repo: "https://github.com/matematicsolutions/awesome-matematic-skills-en" + url: "https://matematicsolutions.com" +workflows: + - "gdpr-breach-notification" + - "gdpr-dpia" + - "gdpr-data-subject-requests" + - "gdpr-records-of-processing" + - "contract-clause-checklist" + - "legal-syllogism" + - "legal-citation-extraction" diff --git a/workflow-schema/__pycache__/workflow_validation.cpython-313.pyc b/workflow-schema/__pycache__/workflow_validation.cpython-313.pyc new file mode 100644 index 00000000..edbbcce5 Binary files /dev/null and b/workflow-schema/__pycache__/workflow_validation.cpython-313.pyc differ