Who Is Covered Before Anyone Has to Report?
For H.R. 9477, the proposed AI Incident Reporting Act, the first operational question is not what a developer writes in a report. It is who falls inside the reporting perimeter in the first place. This chapter examines the Secretary of Commerce, covered models, covered model developers, and the rules that connect them. The practical judgment is straightforward: a reporting duty can be clear on paper and still fail if the coverage boundary is vague, too narrow, or impossible to apply consistently.
The Secretary is the owner of the boundary
The bill would give the Secretary of Commerce the central role in constructing the proposed system. Within 180 days after enactment, the Secretary would consult relevant agency heads, AI model developers, other private-sector entities, and a range of technical, cybersecurity, national-security, public-safety, academic, and other outside experts. After that process, the Secretary would promulgate regulations establishing “capability or other thresholds” for models and model developers that could pose significant risks to national security or public safety.
The Secretary would then designate the models and developers that meet those thresholds as covered. The same official would issue guidelines for compliance, coordinate with other agencies to identify reportable activity and receive or analyze reports, and take action on the information. This makes the Secretary more than the recipient of a form. The office would control the interface between a broad field of AI development and the narrower class of systems subject to the Act.
The timeline and consultation requirement reveal two features of the proposal. First, Congress would establish the authority and the broad purpose, but the operational perimeter would be made through later rulemaking. Second, the bill recognizes that deciding which capabilities present significant public-safety or national-security risk is not a task for a single definition copied into a form. It calls for input from people who would build, evaluate, secure, regulate, and respond to those systems.
That delegation is consequential. The bill does not specify a benchmark score, a compute level, a fixed model size, or a complete evaluation procedure that automatically makes a model covered. It does not settle how a capability should be measured when a model is fine-tuned, connected to tools, embedded in a product, or combined with another system. It directs the Secretary to establish thresholds later. Until those thresholds exist, the legal proposal identifies an authority and a process, not a finished coverage test.
The distinction is important for readers evaluating claims about the Act. It is accurate to say that H.R. 9477 would require the Secretary to designate covered models and developers. It is not accurate to say that the bill already tells every developer whether they are covered. That answer would come from regulations and guidance that the introduced text anticipates but does not provide.
Three components, three different relationships
The reporting perimeter has three components that are easy to collapse into one word: model, developer, and threshold.
A covered model is a model designated by the Secretary under the threshold-setting provision. The designation is about the model’s capabilities or other characteristics, not simply about the organization that owns it. A covered model developer is a person or entity that develops or trains a covered model, or substantially modifies one in a manner the Secretary determines causes it to meet an established threshold. The bill’s definition therefore reaches beyond an original training run.
The reference to substantial modification matters because models do not remain fixed when they move through the ecosystem. An organization might fine-tune a model, alter its weights, or make another change that materially changes what the system can do. H.R. 9477 defines model weights as the parameters, numerical values, or other internal artifacts sufficient to reproduce, substantially reproduce, or enable the operational use of a model. But the presence of that definition does not itself tell us which modification is substantial. The Secretary would have to decide when a change creates a new threshold-relevant model or brings a modifier into the class of covered developers.
This is an interface problem. The model is the object being assessed; the developer is the actor that may owe the reporting duty; the threshold is the rule connecting the two. If the threshold is attached only to original developers, a significant modified system could fall through. If it attaches to every minor adjustment, the regime could become burdensome and lose the ability to distinguish consequential changes from routine product work. The bill leaves that calibration to the Secretary rather than pretending that the statute can resolve every technical boundary in advance.
The architecture can be pictured as a chain of ownership and information flow:
The diagram is not a claim that the bill creates separate legal corporations called “model” or “threshold.” It is a way to keep the relationships distinct. The Secretary establishes the boundary. The covered model is the designated system. The covered developer is the actor connected to development, training, or substantial modification. Reports travel from the developer to the Secretary, while coordination and specified serious-risk notifications travel outward from the Secretary.
The congressional link is also conditional. The bill would require the Secretary to inform specified House and Senate leaders and committee chairs of reports presenting an imminent or ongoing risk of serious harm within 48 hours after receipt. Other reports would be communicated to those recipients within 30 days after receipt. This is a downstream consequence of coverage, not a reason that every AI developer reports directly to Congress. The Secretary remains the organizing node.
Why coverage is a policy choice, not an administrative preface
A threshold determines which risks can enter the rest of the system. That makes the coverage decision substantive even before anyone debates the content of a report.
Suppose the capability threshold is narrow and focuses only on models with a defined set of dangerous capabilities. A smaller or differently configured system may escape coverage even if it contributes to a serious incident when connected to tools or other systems. Suppose the threshold is broad but uses terms that developers cannot test reliably. The result may be inconsistent self-assessment, defensive over-reporting, or delayed reporting while an organization seeks advice about whether an ambiguous term applies. Neither outcome is fixed by adding more fields to the report.
The bill anticipates this problem by directing the Secretary, to the maximum extent practicable, to describe clearly the categories of information that must be reported, minimize unnecessary ambiguity and duplication, reduce undue reporting burden, and establish clear, secure, straightforward submission mechanisms. These instructions are best understood as design constraints on the whole perimeter. Clarity is not merely a benefit to the person filling out a form. It determines whether similar facts produce similar coverage and reporting decisions.
The research on escalation criteria sharpens the point. It compares broad legal categories that may be hard to translate into observable indicators with highly specific numerical thresholds that are easy to test but can miss real harms below the cutoff. H.R. 9477’s phrase “capability or other thresholds” gives the Secretary room to choose among such approaches, but it does not eliminate the trade-off. A threshold must be legally intelligible, technically observable, and connected to a response that is worth the burden of crossing it.
That is also why public-safety and national-security significance cannot be treated as a label that automatically solves the question. The label expresses the purpose of the regime. The threshold must still answer what evidence shows that a model or developer could pose the relevant risk, who can obtain that evidence, and how often the classification should be revisited. A model may change through modification. A tool-connected deployment may create capabilities not visible in the base model. A threshold that ignores those transitions can become stale while remaining formally precise.
The introduced bill does not resolve these questions, and the distinction should be preserved rather than filled with speculation. Its legal design is to assign the decision to a rulemaking process with consultation and guidelines. That process would be where the public could examine the actual measurements, exceptions, reassessment rules, and burdens. Until then, the strongest supported conclusion is narrower: H.R. 9477 makes capability-based designation the gateway to reporting and recognizes that the gateway requires more detail than the statute itself supplies.
Protections and enforcement determine whether the perimeter works
A coverage rule operates through human incentives. The actor with the best information about a model’s behavior may also worry that disclosure will expose trade secrets, trigger litigation, invite regulatory action, or reveal security-sensitive details. The bill therefore treats information protection as part of the reporting architecture.
It would require procedures to protect sensitive, classified, controlled, or security-relevant information. Information submitted under the Act would be exempt from specified federal disclosure requirements and could not be disclosed under state or local laws that require disclosure of records. Submission would not waive applicable trade-secret, attorney-client, work-product, or other legal protections. The proposal would also limit the use of a report and material created solely to prepare or submit it against the developer in civil, criminal, or administrative proceedings, and would restrict government use for regulation or enforcement, subject to exceptions for response, mitigation, prevention, compliance with the Act, and independently obtained evidence.
These protections do not make the reporting perimeter voluntary. The Secretary would retain authority to require records and audits, conduct investigations, issue subpoenas, require corrective action, and refer matters for civil action. A civil penalty could reach $2 million, and each day of a continuing violation would count as a separate offense. The design tries to hold two ideas together: reporting should be safe enough to encourage timely disclosure, but failure to comply should remain enforceable.
Whether that balance works cannot be determined from the bill alone. The practical effect would depend on implementing procedures, how protections interact with other laws, how agencies handle shared information, and how exceptions for independently obtained evidence are applied. A rule that promises confidentiality but leaves developers uncertain about its boundaries may not produce candid early reports. A rule that protects every submitted fact from meaningful use may weaken accountability. The threshold is therefore supported by an incentive structure, not just a definition.
The same is true of coordination. H.R. 9477 permits the Secretary to share submitted information with other agencies, including intelligence and law-enforcement agencies, when appropriate and consistent with law. Shared information remains subject to the Act’s protections for the receiving agency. This can expand the government’s ability to connect a model event with a broader threat, but it also makes the handling rules and agency interfaces part of the system’s credibility.
The boundary remains unfinished
H.R. 9477 specifies the decision-maker, the broad purpose, the timing for designation, the model and developer relationships, and several constraints on reporting and information use. It does not specify the numerical or technical tests that will determine coverage, the complete treatment of substantial modification, or the procedures by which a designation will be maintained, challenged, or revised. Those omissions are not necessarily drafting failures; some may be deliberate delegations to an agency with access to technical expertise. But they are unresolved parts of the threshold.
The right way to read the proposal is therefore neither “the law covers frontier AI” nor “the law says nothing until a form appears.” The text establishes a proposed institutional mechanism for deciding coverage and receiving reports. The crucial work will occur at the interface between the Secretary’s rulemaking, the developer’s technical evidence, the model’s changing capabilities, and the protections that make disclosure credible.
Once that perimeter is visible, the next problem becomes more precise: what behavior, capability, compromise, or narrowly prevented harm would activate the reporting duty inside it? That is where the Act’s categories and timing rules turn coverage into an actual reporting lifecycle.