docs(verification): profile floors are specification choices, not regulatory derivations - #310
Conversation
… correct the Annex IV attribution Annex IV is the technical documentation schedule referred to in Article 11(1) rather than a classification annex, so "Annex IV high-risk" names no category a reader can look up. High-risk classification runs through Article 6 with Annexes I and III. No provision of the Regulation requires a verification depth, so the floor is stated as a choice this specification makes rather than a derivation from any regime. The regulatory detail moves into an informative section recording what each instrument requires and nothing beyond it. Documentation only. No normative delta, no schema change, no conformance test IDs. Signed-off-by: Ioana Valea <ioana.valea02@gmail.com>
lywinged
left a comment
lywinged
left a comment
There was a problem hiding this comment.
Approved.
The correction is right, and for the reason that matters: Annex IV is the technical documentation schedule Article 11(1) points at, so "Annex IV high-risk" named nothing a reader could look up, while classification runs through Article 6 with Annexes I and III.
I checked the new section's citations rather than taking them, since this is the kind of text that gets quoted back at us. They hold, including the two that rest on the amended Regulation:
- Annex IV is titled "Technical Documentation Referred to in Article 11(1)" and is a documentation schedule, not a classification annex.
- Article 6(1) classifies safety components under the Annex I harmonisation legislation and Article 6(2) classifies the Annex III uses, so the substituted label names something a reader can check.
- Article 15(5) is outcome-framed, and its list is the one you give.
- Articles 11 and 15 sit in Chapter III Section 2 and Article 25 in Section 3.
- Regulation (EU) 2026/1744 entered into force on 27 July 2026, it does amend both Article 25(4) and Article 111(2), and the new Article 113 dates are 2 December 2027 for Article 6(2) and Annex III and 2 August 2028 for Article 6(1) and Annex I. That is what you wrote, mapping included.
- The Cyber Resilience Act dates are right as well: Annex I obligations from 11 December 2027, Article 14 reporting from 11 September 2026, which is in two days.
One suggestion, not a condition. The section leaves out Article 12, which is the provision this repository leans on everywhere else: spec/trace-v0.2.md cites it for tamper-evident logging and LIMITATIONS.md maps it to Level 1. It supports your thesis rather than complicating it, since Article 12 requires that a system technically allow the automatic recording of events over its lifetime and says nothing about provenance or supply-chain depth. A reader who knows this repository will look for it in a section that promises what the Regulation actually requires.
Two notes for whoever reads this next, neither of them yours to act on.
spec/trace-v0.2.md still describes the Article 12 timeline as "the current provisional timeline" with obligations "from around December 2027". After 2026/1744 that is stale, and the date is now split by classification. It deserves its own issue: it is normative-adjacent and correctly out of scope for a documentation-only change.
The same file's comparison table reads "EU AI Act Annex IV / Article 12" in a row about mandating documentation. That use of Annex IV is correct and should not be swept by analogy with this fix.
Checked on the branch: 1319 passed and 1 skipped, with check_dashes.py, ruff and mypy clean. Nothing in the package or the vectors depends on the profile names and no test parses this table, which is also why nothing caught the original wording.
imran-siddique
left a comment
imran-siddique
left a comment
There was a problem hiding this comment.
Approving. The table correction is right and the informative section is the more useful half.
On the table. Annex IV was the wrong citation for what that row meant. Annex IV is the technical-documentation schedule whose elements Article 11(1) requires the documentation to contain; classification runs through Article 6 with Annexes I and III. A reader configuring a floor from the old row would have been reading a documentation annex as a classification test.
What I verified, against the primary texts rather than the PR body.
- Regulation (EU) 2026/1744 exists, and EUR-Lex confirms it amends Article 25(4) to exactly the list quoted here: "AI system, AI model, tools, services, components, or processes". The addition of
AI modelto that list is the amendment, and it is stated correctly. - The two application dates are exact: 2 December 2027 for systems high-risk under Article 6(2) and Annex III, 2 August 2028 for Article 6(1) and Annex I.
- Article 15(5)'s outcome framing, data poisoning, model poisoning, adversarial examples, confidentiality attacks and model flaws, matches the published wording, and the point that it states an outcome rather than a supply-chain verification depth is the right reading.
- Regulation (EU) 2024/2847 Annex I obligations from 11 December 2027 and the Article 14 reporting obligations from 11 September 2026 both match.
What I did not verify, so it is on the record rather than implied. The free-and-open-source carve-out wording inside the amended 25(4): the EUR-Lex text truncated at that sentence, and I read the carve-out forward from the original rather than from the amended text. And the characterisation of the Article 111(2) grace period as covering units of a type and model already placed on the market. Neither changes a floor in the table.
Why this is worth having beyond accuracy. The section says a floor that is met is not evidence of compliance with either regulation, and that neither requires a verification depth at all. That makes our own claim weaker and it is correct. A profile floor is a choice this specification makes for deployments that describe themselves as operating under a regime, and saying so in the document stops the table being cited as though the Regulation produced it.
CI: the runs were held pending first-time-contributor approval and reported 2 checks. Released, and the rollup came back at 6 with everything green apart from the maintainer-hold gate, which this approval clears.
|
Merged, and thank you both for reading it against the sources rather than against the PR body. Two things you left open, @imran-siddique, and one correction to my own text. Article 111(2). It is amended, by Article 1 point (39)(a), and the replacement reads: "Without prejudice to the application of Article 5 as referred to in Article 113, third par agraph, point (a), this Regulation shall apply to operators of high-risk AI systems, other than the systems referred to in paragraph 1 of this Article, that have been placed on the market or put into service before the date of application of Chapter III referred to in Article 113, only if, as from that date, those systems are subject to significant changes in their designs." Point (39)(a) also carries a second sentence requiring providers and deployers of high-risk systems intended to be used by public authorities to comply by 2 August 2030. What the replaced paragraph does not contain is the type-and-model language. That sits in recital (39), which states that the grace period should apply where the type and model of AI system has already been placed on the market, and that one lawfully placed unit carries the other units of the same type and model. So the sentence I wrote, "subject to the Article 111(2) grace period for units of a type and model already placed on the market", presents a recital as though it were operative text. The reading is right and the attribution is not, and I would rather correct that than leave it standing in The free-and-open-source carve-out. The sentence appears inside the Article 25 amendment as published, so the exclusion holds under the amended text rather than only by carry-forward from the original. What I have not separately confirmed is whether it sits within the replaced first subparagraph or as the subparagraph following it, which does not change the effect either way. @lywinged, on Article 12. Agreed, and for the reason you give: it is the provision this repository leans on elsewhere, and it requires only that a system technically allow the automatic recording of events over its lifetime, so it supports the section's argument rather than complicating it. Since this has merged, I will bring it as a small follow-up together with the Article 111(2) attribution fix above, unless you would rather they were separate. On The comparison table's use of Annex IV is correct and I will not touch it. Source verification for this comment was AI-assisted. Article 1 point (39)(a) and recital (39) of Regulation (EU) 2026/1744 were read against the Official Journal text before being quoted. |
|
Thank you so much for the view @ioanavalea ! Both follow-ups are yours, and I will not file anything on either, so nothing collides. Together is better for the first one: both edits land in the same informative section of On that sentence, the record should say where the correction came from. My approval said the citations hold, and on Article 111(2) it checked that the paragraph is amended and that the dates are right; it did not separate recital (39) from the replacement text in point (39)(a). The other review put the sentence on the record as unverified. You went back to the Official Journal after merge and corrected your own text, so the correction is yours and so is the credit. The distinction you drew is the one worth keeping: the reading is right and the attribution is not, and a citation that gets that distinction right stays checkable by the next reader. I read point (39)(a) and recital (39) against the Official Journal text as well, from the Publications Office copy, and it is as you say. The replacement paragraph 2 is the text you quote, the 2 August 2030 sentence for systems intended to be used by public authorities sits in the same point, and "type and model" occurs three times in the Regulation, all of them in recital (39) and none in the operative articles. On the free and open-source carve-out, the thing you had not separately confirmed: it is inside the replaced first subparagraph. Article 1 point (12)(b) reads "in paragraph 4, the first subparagraph is replaced by the following", and the quoted replacement ends with the sentence "This paragraph shall not apply to third parties making accessible to the public tools, services, processes, or components, other than general-purpose AI models, under a free and open-source licence." So the exclusion is operative under the amended text rather than only by carry-forward from the original, and it is not a following subparagraph. The Agreed on the comparison table. That row's Annex IV is the documentation schedule doing documentation work, and it stays. |
…ribution Article 12 requires that a high-risk system technically allow the automatic recording of events over its lifetime, and imposes no verification depth, so it belongs beside Article 11 and Annex IV in the informative section. Suggested by @lywinged in review of agentrust-io#310. The list of provisions sitting in Sections 2 and 3 of Chapter III is extended to match. The Article 111(2) sentence presented recital 39 as operative text. Article 1 point (39)(a) of Regulation (EU) 2026/1744 replaces Article 111(2), and the replacement carries the significant-changes test and a 2 August 2030 compliance date for providers and deployers of high-risk systems intended to be used by public authorities. The type-and-model reading is recital 39. Documentation only. No normative delta, no schema change, no conformance test IDs. Signed-off-by: Ioana Valea <ioana.valea02@gmail.com>
|
Both are up as #313, in one diff as you preferred, and the list of provisions sitting in Sections 2 and 3 is extended to One more thing came out of re-reading the Regulation for this, and it is beyond what you asked for, so it is deliberately not in the PR. Regulation (EU) 2026/1744 Article 1 point (18) inserted Article 42(3): "Where high-risk AI systems fall within the scope of Regulation (EU) 2024/2847 and the conditions laid down in Article 12(1) of that Regulation are fulfilled, such systems shall be deemed to comply with the cybersecurity requirements set out in Article 15 of this Regulation." Two things about it are worth stating precisely, because both are easy to get wrong and I got the first one wrong before checking. It is not a new route. Regulation (EU) 2024/2847 Article 12, titled "High-risk AI systems", has said the same thing from the other side since adoption, deeming products with digital elements within its scope that are classified as high-risk pursuant to Article 6 to comply with the Article 15 cybersecurity requirements where the product meets the essential requirements in Annex I Part I, the manufacturer's processes meet those in Annex I Part II, and the level of protection is demonstrated in the EU declaration of conformity. What the 2026 Regulation did is write that existing rule into Regulation (EU) 2024/1689. And it reaches less far than the article number suggests. Article 12(1) opens "Without prejudice to the requirements relating to accuracy and robustness set out in Article 15 of Regulation (EU) 2024/1689", so the deeming covers the cybersecurity half of Article 15 and not the accuracy and robustness half. The reason it is relevant to this section rather than merely adjacent: condition (b) is the manufacturer's processes under Annex I Part II, and Part II point 1 is the software bill of materials covering at the very least the top-level dependencies, which is the obligation the section already cites. So the nearest thing either instrument has to a supply-chain obligation reaches Article 15 by way of a component inventory rather than by verifying provenance, which is this section's own point made by the two instruments together. Your call on whether that belongs here, in a separate PR, or nowhere. I have it drafted as three sentences at the end of the Regulation (EU) 2024/2847 paragraph and will add it on a word from you rather than assume. Source verification for this comment was AI-assisted. Article 42(3) as inserted by Article 1 point (18) of Regulation (EU) 2026/1744, and Article 12 and Annex I Part II point 1 of Regulation (EU) 2024/2847, were read against the Official Journal text before being quoted. |
3 participants
What this changes
docs/verification.mdpresents thetransitiveprofile floor as following from "EU AI Act Annex IV high-risk". This corrects that attribution, keeps every profile and every floor exactly as it stands, and adds an informative section recording what the cited instruments actually require.The line being corrected:
Type of change
The added subsection is informative and sits in
docs/rather than in the specification, so it carries no normative effect and no conformance test IDs.Spec section
None. The change is confined to
docs/verification.md. Section 3.3.1 ofspec/trace-v0.2.md, which this document is the implementation guide to, is unchanged, and no schema file is touched.Why
Two separate problems sit in the same phrase.
Annex IV is the technical documentation schedule whose elements Article 11(1) requires the technical documentation to contain at a minimum. It is not a classification annex, so "Annex IV high-risk" names no category a reader can look up, since high-risk classification runs through Article 6 with Annexes I and III. The row now reads "EU AI Act Article 6 high-risk".
Separately, no provision of the Regulation requires a verification depth, so a floor cannot be derived from it. The floor is still the right requirement for that profile, and it is a requirement this specification makes rather than one the Regulation imposes. The lead-in now says so for every row.
No other instrument is put in Annex IV's place. A floor that rests on a citation is only as stable as the reading of that citation, and the security argument already in this document carries the floor without one. The regulatory material therefore moves into an informative section that records what each instrument requires and stops there, which also keeps the table clear of anything a reader could take as a compliance claim. @safal207's refinement is carried in that section: the software bill of materials obligation in the CRA is a component inventory, and an inventory of top-level dependencies does not by itself establish
builderortransitiveverification, which are claims about provenance rather than about composition.FIPS and HIPAA are unchanged and are not spoken to here, as in my comment on #66.
Not changed, deliberately
The depth vocabulary is untouched. #66 gives the same supply-chain ladder two names,
surface | builder_chain | dependency_chainforverification.depthandsurface | builder | transitiveforbuild_provenance.provenance_depth, and reconciling the two was asked for on that thread.docs/verification.mduses the short names throughout, so this PR uses them too. Which vocabulary survives is a maintainer decision worth settling before v1.0, and this PR does not make it.No new conformance claim and no legal-compliance claim are introduced, and the informative section states explicitly that verification at any depth is not evidence of compliance with either instrument.
Context
The profile-floor correction was directed on #66 to be a separate docs-only contribution with source verification and no new conformance or legal-compliance claim: #66 (comment). #66 has since been closed via #306, whose description states that it does not close #66, so this is filed as the separate contribution that was asked for rather than as a change to that issue's scope.
Checklist
git commit -s)CHANGELOG.mdupdated (for any normative change): not applicable, no normative changeAI assistance
Drafting and source verification were AI-assisted. Article 6, Article 11(1), Article 15(5), Article 25(4), Article 111(2), Article 113 and Annex IV were read against Regulation (EU) 2024/1689 as amended; Article 1 points (10) and (12) and the Article 113 replacement against Regulation (EU) 2026/1744; and Annex I Part II point 1 and Article 71 against Regulation (EU) 2024/2847, before being cited.