Spec section
§3.5 (hitl_record, hitl_runtime) and §9.1 (EU AI Act mapping table) of spec/agent-manifest-spec-v0.2.md. Two problems: the first sits in both sections, the second in the §9.1 preamble alone. They need different routes, so both are recorded here and the PR that follows will carry only the first.
Problem
Problem 1: the Art. 14 mapping cites the wrong points and claims satisfaction
Art. 14(4) opens: "For the purpose of implementing paragraphs 1, 2 and 3, the high-risk AI system shall be provided to the deployer in such a way that natural persons to whom human oversight is assigned are enabled, as appropriate and proportionate:". Point (a) is understanding the system's capacities and limitations and monitoring its operation. Point (b) is remaining aware of automation bias. Point (c) is correctly interpreting the output. Point (d) is deciding not to use the system or to disregard, override or reverse its output. Point (e) is intervening in the operation or interrupting the system through a stop button or similar procedure.
Three consequences for the current text.
The automation_bias_disclosure field description in §3.5 cites the wrong point. It reads <URI to Art. 14(4)(c) automation bias disclosure document>. Automation bias is (b), whereas (c) governs correct interpretation of the output.
§3.5 and §9.1 both cite Art. 14(4)(a) for the stop and override capability. §3.5: "The hitl_runtime block separately addresses the runtime stop/override capability requirement (Art. 14(4)(a))." §9.1: "Art. 14(4)(a) requires the ability to stop or interrupt the system safely during operation." Stopping is (e) and overriding is (d).
§3.5 and §9.1 both describe Art. 14(4)(b)-(e) as pre-deployment documentation obligations. §3.5: "The hitl_record.approvals structure satisfies Art. 14 pre-deployment documentation obligations (Art. 14(4)(b)-(e))." Art. 14(4) imposes no documentation obligation, since its chapeau addresses how the system is provided to the deployer and its points state what the persons assigned to oversight must be enabled to do. The documentation duty nearest to this is Annex IV point 2(e) through Art. 11(1), which has a different addressee and a different trigger.
Both sections additionally state that the fields are "required for full Art. 14 compliance", and §9.1 says they "satisfy" the requirement. A manifest field records an event, whereas Art. 14 is met or not met by a deployer's oversight arrangements, which the manifest cannot observe. §9.1.2 already draws exactly this distinction for Art. 50, where the section warns that the manifest is not evidence of Article 50 compliance and that the runtime control it defers to produces none either.
I have already cited Art. 14(4)(e) for stop_authority in #348, so the spec currently contradicts an open issue in this repository.
Problem 2: the §9.1 applicability note predates the adopted Omnibus
The preamble to the §9.1 table currently reads, in part:
The high-risk obligations mapped in the table below (Arts. 12-15, 26) are deferred under the current provisional legislative timeline (the Digital Omnibus amendments): Annex III systems from around 2 December 2027, and Annex I systems (AI embedded in regulated products) from around August 2028. These dates remain subject to the legislative process; implementers MUST verify against the official implementation timeline before asserting a compliance deadline.
Regulation (EU) 2026/1744 was adopted on 8 July 2026, published in the Official Journal on 24 July 2026 and entered into force on 27 July 2026. §9.1.2, in the same section, now cites it as amending law following #376. The dates are exact rather than approximate: Art. 113 as replaced sets 2 December 2027 for systems high-risk under Art. 6(2) and Annex III, and 2 August 2028 for systems high-risk under Art. 6(1) and Annex I. So §9.1 currently tells a reader that a timeline is provisional in the paragraph above the subsection that treats it as settled law.
Proposed change
For Problem 1, four edits in spec/agent-manifest-spec-v0.2.md
§3.5, field description.
Current: "automation_bias_disclosure": "<URI to Art. 14(4)(c) automation bias disclosure document> -- OPTIONAL"
Proposed: "automation_bias_disclosure": "<URI to Art. 14(4)(b) automation bias disclosure document> -- OPTIONAL"
§3.5, paragraph. Current:
hitl_runtime block declares the runtime human oversight capabilities required by EU AI Act Art. 14(4) operational oversight obligations. The hitl_record.approvals structure satisfies Art. 14 pre-deployment documentation obligations (Art. 14(4)(b)-(e)). The hitl_runtime block separately addresses the runtime stop/override capability requirement (Art. 14(4)(a)). Both are required for full Art. 14 compliance. See section 9.1 for the regulatory mapping.
Proposed:
The hitl_runtime block declares runtime human oversight capabilities. Art. 14(4) imposes no documentation obligation, since it states what the persons assigned to human oversight must be enabled to do and is addressed to how the system is provided to the deployer. The hitl_record.approvals structure records an approval event, its approver and its scope, which is evidence a deployer can use when demonstrating oversight rather than satisfaction of Art. 14(4) itself. The hitl_runtime block carries the interrupt and override capability, which corresponds to Art. 14(4)(e) on intervening in the operation or interrupting through a stop button or similar procedure, and to Art. 14(4)(d) on deciding not to use the output or to disregard, override or reverse it. Neither block establishes Art. 14 compliance. See section 9.1 for the regulatory mapping.
§9.1 table, pre-deployment row. Requirement column becomes: "Art. 14(1) requires high-risk systems to be designed so they can be effectively overseen by natural persons. Art. 14(4) states what the persons assigned to oversight must be enabled to do." Satisfaction column becomes: "hitl_record.approvals records the approval event, its approver and its scope, which is evidence a deployer can use when demonstrating oversight. It does not by itself satisfy Art. 14(4). approval_signature by hardware key provides non-repudiation for the approval event."
§9.1 table, operational row. Requirement column becomes: "Art. 14(4)(e) concerns intervening in the operation or interrupting the system through a stop button or similar procedure. Art. 14(4)(d) concerns deciding not to use the output or to disregard, override or reverse it." Satisfaction column becomes: "hitl_record.hitl_runtime.interrupt_endpoint and override_mechanism carry the interrupt and override capability. Neither these fields nor the approvals establish Art. 14 compliance."
For Problem 2
I am not proposing to author this one. The sentence carrying the stale claim also carries implementers MUST verify, so under GOVERNANCE it is normative text and needs an organisational sponsor, or a Maintainer to carry it. Recording it here so that the two halves of §9.1 stop disagreeing, and leaving the route to you.
Impact
- Backward compatible: yes. No field, value or requirement level changes.
- Affects conformance level(s): none. The Level 2+ requirements on
hitl_runtime are untouched.
- Conformance tests that need updating: none. No existing vector changes behaviour and no new vector is required.
- Regulatory mapping impact: EU AI Act Art. 14, in §3.5 and the §9.1 table.
docs/compliance/eu-ai-act.md was checked and quotes only Art. 14(1), so it carries none of the lettering and needs no change. Regulation (EU) 2026/1744 does not amend Art. 14, so the lettering is stable and needs no "as amended" qualifier.
Normative delta for Problem 1: none. One caveat rather than a decision: the automation_bias_disclosure line ends with an uppercase OPTIONAL, so on a literal reading of the sponsor rule that line is normative text. The edit changes a citation inside the field description and alters no requirement level, but I would rather flag that than assume it.
Alternatives considered
Correcting the point letters only, leaving "satisfies" and "required for full Art. 14 compliance" in place. Smaller diff, and it leaves the half that actually misleads. A wrong letter sends a reader to the wrong provision, whereas a satisfaction claim tells them they have met an obligation the manifest cannot establish.
Correcting §3.5 alone. Rejected, because §3.5 directs the reader to §9.1 for the regulatory mapping and §9.1 states the same error more strongly, so a partial fix leaves the two sections contradicting each other.
Filing a PR directly, as with #355 and #376. Rejected, because Problem 2 needs a ruling rather than a patch, and holding both in one place gives the whole picture before anything is filed.
On the CHANGELOG: #355 and #376 both went in without an entry, on the basis that spec prose carrying no normative delta is not a recorded change. Happy to add one here if you would rather every spec-file edit be listed.
AI assistance
Drafting and source verification were AI-assisted. §3.5 and §9.1 were read against current main, and Art. 14(1), the Art. 14(4) chapeau and its points (a) to (e), and Art. 113 were read against Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744 before being cited.
Spec section
§3.5 (
hitl_record,hitl_runtime) and §9.1 (EU AI Act mapping table) ofspec/agent-manifest-spec-v0.2.md. Two problems: the first sits in both sections, the second in the §9.1 preamble alone. They need different routes, so both are recorded here and the PR that follows will carry only the first.Problem
Problem 1: the Art. 14 mapping cites the wrong points and claims satisfaction
Art. 14(4) opens: "For the purpose of implementing paragraphs 1, 2 and 3, the high-risk AI system shall be provided to the deployer in such a way that natural persons to whom human oversight is assigned are enabled, as appropriate and proportionate:". Point (a) is understanding the system's capacities and limitations and monitoring its operation. Point (b) is remaining aware of automation bias. Point (c) is correctly interpreting the output. Point (d) is deciding not to use the system or to disregard, override or reverse its output. Point (e) is intervening in the operation or interrupting the system through a stop button or similar procedure.
Three consequences for the current text.
The
automation_bias_disclosurefield description in §3.5 cites the wrong point. It reads<URI to Art. 14(4)(c) automation bias disclosure document>. Automation bias is (b), whereas (c) governs correct interpretation of the output.§3.5 and §9.1 both cite Art. 14(4)(a) for the stop and override capability. §3.5: "The
hitl_runtimeblock separately addresses the runtime stop/override capability requirement (Art. 14(4)(a))." §9.1: "Art. 14(4)(a) requires the ability to stop or interrupt the system safely during operation." Stopping is (e) and overriding is (d).§3.5 and §9.1 both describe Art. 14(4)(b)-(e) as pre-deployment documentation obligations. §3.5: "The
hitl_record.approvalsstructure satisfies Art. 14 pre-deployment documentation obligations (Art. 14(4)(b)-(e))." Art. 14(4) imposes no documentation obligation, since its chapeau addresses how the system is provided to the deployer and its points state what the persons assigned to oversight must be enabled to do. The documentation duty nearest to this is Annex IV point 2(e) through Art. 11(1), which has a different addressee and a different trigger.Both sections additionally state that the fields are "required for full Art. 14 compliance", and §9.1 says they "satisfy" the requirement. A manifest field records an event, whereas Art. 14 is met or not met by a deployer's oversight arrangements, which the manifest cannot observe. §9.1.2 already draws exactly this distinction for Art. 50, where the section warns that the manifest is not evidence of Article 50 compliance and that the runtime control it defers to produces none either.
I have already cited Art. 14(4)(e) for
stop_authorityin #348, so the spec currently contradicts an open issue in this repository.Problem 2: the §9.1 applicability note predates the adopted Omnibus
The preamble to the §9.1 table currently reads, in part:
Regulation (EU) 2026/1744 was adopted on 8 July 2026, published in the Official Journal on 24 July 2026 and entered into force on 27 July 2026. §9.1.2, in the same section, now cites it as amending law following #376. The dates are exact rather than approximate: Art. 113 as replaced sets 2 December 2027 for systems high-risk under Art. 6(2) and Annex III, and 2 August 2028 for systems high-risk under Art. 6(1) and Annex I. So §9.1 currently tells a reader that a timeline is provisional in the paragraph above the subsection that treats it as settled law.
Proposed change
For Problem 1, four edits in
spec/agent-manifest-spec-v0.2.md§3.5, field description.
Current:
"automation_bias_disclosure": "<URI to Art. 14(4)(c) automation bias disclosure document> -- OPTIONAL"Proposed:
"automation_bias_disclosure": "<URI to Art. 14(4)(b) automation bias disclosure document> -- OPTIONAL"§3.5, paragraph. Current:
Proposed:
§9.1 table, pre-deployment row. Requirement column becomes: "Art. 14(1) requires high-risk systems to be designed so they can be effectively overseen by natural persons. Art. 14(4) states what the persons assigned to oversight must be enabled to do." Satisfaction column becomes: "
hitl_record.approvalsrecords the approval event, its approver and its scope, which is evidence a deployer can use when demonstrating oversight. It does not by itself satisfy Art. 14(4).approval_signatureby hardware key provides non-repudiation for the approval event."§9.1 table, operational row. Requirement column becomes: "Art. 14(4)(e) concerns intervening in the operation or interrupting the system through a stop button or similar procedure. Art. 14(4)(d) concerns deciding not to use the output or to disregard, override or reverse it." Satisfaction column becomes: "
hitl_record.hitl_runtime.interrupt_endpointandoverride_mechanismcarry the interrupt and override capability. Neither these fields nor the approvals establish Art. 14 compliance."For Problem 2
I am not proposing to author this one. The sentence carrying the stale claim also carries
implementers MUST verify, so under GOVERNANCE it is normative text and needs an organisational sponsor, or a Maintainer to carry it. Recording it here so that the two halves of §9.1 stop disagreeing, and leaving the route to you.Impact
hitl_runtimeare untouched.docs/compliance/eu-ai-act.mdwas checked and quotes only Art. 14(1), so it carries none of the lettering and needs no change. Regulation (EU) 2026/1744 does not amend Art. 14, so the lettering is stable and needs no "as amended" qualifier.Normative delta for Problem 1: none. One caveat rather than a decision: the
automation_bias_disclosureline ends with an uppercaseOPTIONAL, so on a literal reading of the sponsor rule that line is normative text. The edit changes a citation inside the field description and alters no requirement level, but I would rather flag that than assume it.Alternatives considered
Correcting the point letters only, leaving "satisfies" and "required for full Art. 14 compliance" in place. Smaller diff, and it leaves the half that actually misleads. A wrong letter sends a reader to the wrong provision, whereas a satisfaction claim tells them they have met an obligation the manifest cannot establish.
Correcting §3.5 alone. Rejected, because §3.5 directs the reader to §9.1 for the regulatory mapping and §9.1 states the same error more strongly, so a partial fix leaves the two sections contradicting each other.
Filing a PR directly, as with #355 and #376. Rejected, because Problem 2 needs a ruling rather than a patch, and holding both in one place gives the whole picture before anything is filed.
On the CHANGELOG: #355 and #376 both went in without an entry, on the basis that spec prose carrying no normative delta is not a recorded change. Happy to add one here if you would rather every spec-file edit be listed.
AI assistance
Drafting and source verification were AI-assisted. §3.5 and §9.1 were read against current
main, and Art. 14(1), the Art. 14(4) chapeau and its points (a) to (e), and Art. 113 were read against Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744 before being cited.