Which regulation should the next pack cover?

[eduardstan]

Four packs ship today: Table 7, the EU AI Act, GDPR, and ECOA / Regulation B — eighteen requirements in total. Three of the four quote statute; the Table 7 pack restates a table from a paper.

Which regulation should the fifth pack cover, and why that one before the others?

This is the one item on ROADMAP.md (objective 5) that a stranger unblocks rather than waits on. It is not a poll — the useful answer names a specific duty, not a framework.

What makes an answer usable

A pack is a set of duties encoded as checkable properties, with the statutory text quoted character-for-character and re-verified against the live source every month by python -m reasonsmith.drift. So the parts of a proposal that actually do work are:

1. Which clause. An article, section or paragraph — not "the DSA" but "DSA Article 27(1)". A framework is a reading list; a clause is something a property can stand for.
2. Which official source. The document the quotes must match, in force, at a public URL. It gets recorded in docs/legal-sources.md and re-fetched monthly, so a source behind a paywall or without stable text is a source this project cannot hold itself to.
3. What a system would have to emit for the duty to be checkable at all. If no decision record could carry the evidence, the honest verdict is unattainable, and knowing that in advance is worth more than a pack that reports nothing.
4. What the formula would leave out. Every shipped requirement has a row in docs/refinement.md whose fourth column names what the refinement deliberately did not capture — meaningful, specific, suitable are adjectives no presence check can see. If you can already name the gap for your clause, say so; that is the hardest column to write and the most valuable.

Rough or partial answers are welcome. Even (1) and (2) alone are a real contribution — you do not need Python to do the part that matters here.

What would help most

Duties that would stretch the tool rather than repeat it, if there are any in your area:

• A duty that is not a presence check. Fifteen of the eighteen shipped requirements ask whether a field is non-empty. One is logical (proved by a solver) and two are temporal. A clause whose content is a genuine constraint rather than a checklist is the scarce thing.
• A duty that needs until or since. The temporal fragment deliberately excludes rtamt's infix operators because no shipped duty needs one, and the language will not be widened speculatively (ROADMAP.md §3). A clause that genuinely cannot be written without one would unblock that.
• A duty about discrimination. No requirement in any shipped pack checks a fairness property — that is stated plainly in docs/refinement.md and it is ROADMAP.md §4.

Answers this project already has

Not to shut anything down, only so the same ground is not re-covered:

• The scope problem is known. Twelve of eighteen requirements are not limited to a regulatory class, so an ECOA duty reaches a system that issues no credit and reports it satisfied. That is ROADMAP.md §1 and it is a gap in the tool, not a reason to avoid proposing a domain-specific pack.
• The refinement is editorial and says so. Which formula stands for a clause is a judgement made in this repository. Disagreeing with one of the shipped rows in docs/refinement.md is itself a welcome contribution, here or as an issue.

If a proposal firms up, the pack proposal issue template is where it becomes tracked work. The authoring rules a pack must satisfy are in docs/authoring-packs.md.

[eduardstan]

A candidate with an argument: EU AI Act GPAI obligations, Article 53 and Article 55. Work on it
started today, so this is a report on a decision rather than a proposal — but the reasoning is worth
putting on the record, including the part that argues against it.

1. Which clause. Article 53(1)(a)–(d) — technical documentation to Annex XI, information and
   documentation to downstream providers to Annex XII, a copyright policy, and a public summary of
   training content on the AI Office's template. Article 55(1)(a)–(d) for models with systemic risk
   — model evaluation including adversarial testing, systemic-risk assessment and mitigation,
   serious-incident tracking and reporting to the AI Office, and cybersecurity protection.
2. Which official source. Already recorded: CELEX 32024R1689, the same EUR-Lex document the
   existing EU AI Act pack quotes, so docs/legal-sources.md needs no new retrieval record and the
   monthly drift check already covers the source.
3. What the tool already has for it. general-purpose is a member of REGULATORY_CLASSES and is
   used by zero shipped requirements — the scope gate is wired and has never been exercised.
   domains would be []: a general-purpose model is not limited to a kind of decision.
4. The timing. Article 113 puts Chapter V in application from 2 August 2025 with the exception
   of Article 101, so Article 101 — the Commission's power to fine providers of general-purpose AI
   models up to 3 % of worldwide turnover or EUR 15 000 000 — falls under the general date of
   2 August 2026. That is today.

What a GPAI pack could not check, said plainly. Almost every Article 53 duty is a
document-production duty, so the property is a presence check and the presence check is the
correct refinement rather than a weak proxy — a duty to draw up documentation is discharged by the
documentation existing. But that ceiling is hard: nothing in it could see whether the technical
documentation contains what Annex XI asks, whether the training-content summary is sufficiently
detailed, whether the copyright policy is honoured in practice, or whether an Article 55
evaluation reflects the state of the art. Article 55(1)(c)'s reporting duty has a timing limb
that a temporal property could reach, and only if a system emits a timestamp for the incident and
one for the report. Every one of those gaps gets a row in docs/refinement.md rather than being
left for a reader to discover.

And the honest cost. This widens the pack in exactly the direction this discussion says is not
scarce. Thirteen of the current nineteen requirements are already presence checks; a GPAI pack makes
that ratio worse, not better. It is cheap, it is timely, it exercises a gate that has never been
exercised — and it does not stretch the tool. Those are the actual reasons, and none of them is
"this is deep work".

Against the candidates in #58:

• ISO/IEC 42001 fails on rule 2 before anything else. The standard is sold rather than
  published, so there is no public in-force text python -m reasonsmith.drift can re-fetch monthly
  and no quote this project could hold itself to.
• SR 11-7 is the one that would actually stretch the tool. Its model-validation expectations —
  outcomes analysis, benchmarking against alternatives, ongoing monitoring — are genuine constraints
  rather than checklists, which is the scarce thing named above. It is supervisory guidance rather
  than statute, so every requirement would be binding = false, and that is a fair trade for a
  non-presence duty.
• HIPAA is mostly organisational safeguard and disclosure duties rather than duties about a
  decision record, so it would produce presence checks too, from a larger and less decision-shaped
  surface. healthcare already exists in DECISION_DOMAINS if someone wants to try.

My order: GPAI for cheapness and the date, SR 11-7 next, because it is the thing this project
actually lacks. If anyone wants to take that one, the thread to name a clause in is this one.

One correction to my own opening post: it is now 19 requirements, not eighteen — 13 record,
3 logical, 3 temporal — after contains() and the reason-deletion certificate landed.

[eduardstan]

Current intake status: #177 proposes extending eu_ai_act with Article 86 — accepted, see the issue for the verified reasoning and the four refinement-row gaps it must carry. That makes Article 86 the active candidate; new proposals still land here first.

[eduardstan]

A lot has moved since this was opened. The repository now ships 7 packs with 39 requirements: Table 7, EU AI Act, GDPR, ECOA/Regulation B, GPAI, the Cyber Resilience Act, and the Seoul Frontier AI Safety Commitments. The newer packs add real breadth, but the project is explicit that breadth is not the same as depth: 28 of the 39 requirements are presence checks, and no shipped pack currently uses the statistical, undetermined, or graded machinery.

So I’m reopening the question on that ground: what should come next, and why should it come before deepening one of these packs? A useful proposal names a specific clause (not just a framework), an official stable source whose text can be rechecked, the evidence a system would need to emit, and what the formalisation would deliberately leave out. If the clause needs a property beyond presence, say what that property is; if it needs a legal interpretation we do not have, say that too.

The pack proposal form and docs/authoring-packs.md describe the intake. A concrete article/section and the decision records it would exercise would be much more useful than a general shortlist.

[eduardstan]

The right answer to this question changed in July, and not because of anything in this repository.

The Digital Omnibus on AI (Regulation 2026/1744, in force 27 July 2026) deferred the standalone
high-risk obligations to December 2027 and the product-embedded ones to August 2028. What stayed live
is the transparency layer: Article 50 — the duty to inform a person that they are interacting with
an AI system, and to mark synthetic content.

Set that against what ships. eu_ai_act carries Articles 12(1), 12(2), 13(1), 13(2) and 86(1);
gpai carries 53 and 55. Article 50 is in no pack. So the tree covers duties that do not bite for
another sixteen months and omits the one that bites today. That is the gap worth closing next, and it
is a stronger argument than any of the candidates weighed above — including the ones I argued for
myself.

It also happens to be the duty most likely to be checkable. Much of Article 50 is not: whether a
disclosure was "clear and distinguishable", whether the person understood it, and the
direct-interaction exceptions are all readings this tool must refuse. But one fragment is objectively
observable — the disclosure exists at or before the first interaction boundary — which is an
ordering property the temporal engine already evaluates.

I have opened #270 for it rather than leaving the proposal here, so the acceptance criteria
sit next to the work. The gates are the usual ones and none of them are waived: a retrieval record in
docs/legal-sources.md, character-exact verbatim_text held to the drift check, one
docs/refinement.md row per duty naming what was left out, and at least one duty above record.

The other candidates are not rejected, they are queued. HIPAA, SR 11-7, ISO/IEC 42001 and the
Colorado AI Act all remain open proposals, and this thread is still where they belong. What has
changed is the ordering argument: a duty currently in force outranks one that is not, and until July
that distinction did not separate these candidates.

If you disagree — in particular if you think a deferred high-risk duty is still the better target
because implementers are building against it now rather than in 2027 — that is a real argument and I
would rather hear it here than discover it after the pack is written.