Informational data, not legal advice. Summaries are TwinEthos's own words and rules have not been reviewed by a lawyer: check the official text before relying on any of it. A guard addresses an item; adding it is not a statement that your code meets any law.
Binding law — not yet in force or stayed
Frontier developers must report critical safety incidents within 72 hours, or 24 hours if lives are at imminent risk (New York RAISE Act)
N.Y. Gen. Bus. Law 1422(3)(a)-(b) · official text · Enacted, not yet applying: applies from 1 Jan 2027 · New York (US-NY)
GBL 1422(3) requires a frontier developer to notify the DFS office of any critical safety incident involving its frontier models within 72 hours of determining that one occurred or of learning facts that support a reasonable belief that one did. The statute defines these incidents narrowly: unauthorized access to or tampering with model weights that causes death or bodily injury, harm from a catastrophic risk materializing, loss of control that causes death or injury, or a model deceiving its developer to get around controls or monitoring outside an evaluation in a way that shows materially higher catastrophic risk. When an incident poses an imminent risk of death or serious physical injury, the developer must tell an appropriate authority, such as law enforcement or a public safety agency, within 24 hours. A developer may instead meet a federal standard the office designates after declaring that intent. Detect a frontier developer with no incident procedure that classifies these incidents and meets the 72-hour and 24-hour clocks.
Who it applies to
- Duty falls on: developer
- All frontier developers (any revenue) whose frontier models are developed, deployed, or operating in New York. Applies from 2027-01-01.
- Whether it applies depends on facts outside the code; a person has to decide.
The guard to add
Organizational artifact to keep (not verifiable from code); the guard is the record, its owner and its upkeep.
Keep a critical safety incident runbook that classifies the defined incident classes and runs the 72-hour report and 24-hour imminent-risk escalation clocks.
An incident-response runbook section, owned by the frontier safety or security lead and reviewed whenever models, monitoring or the governing statutes change, that defines the critical-safety-incident classes as the statutes word them (model-weight theft or tampering causing death or injury, harm from a catastrophic risk materialising, loss of control causing death or injury, a model deceptively subverting the developer's controls outside testing), names who decides that an event qualifies, and starts the clock when facts support a reasonable belief one occurred. It lists the recipient authority per jurisdiction, the report fields, the 24-hour path to law enforcement or a public-safety agency for imminent risk of death or serious physical injury, and keeps a record of every report and amendment. In code, the severity taxonomy and monitoring that feed it (weight-access alerts, model-behaviour monitors) route a candidate incident to that runbook with the timers attached.
Where it goes: 12 repository artifacts, 10 logs and telemetry.
What this provision adds:
- Notify the DFS office within 72 hours of determining that an incident occurred or of learning facts that support a reasonable belief that one did.
- The deception class covers a model deceiving its developer to get around controls or monitoring outside an evaluation in a way that shows materially higher catastrophic risk.
- A developer may instead meet a federal standard the office designates after declaring that intent, with federal reports copied to the office.
Example (Incident severity taxonomy), before:
severities:
sev1: {page: oncall, examples: [outage, data_breach]}
sev2: {page: oncall}
After:
severities:
sev1: {page: oncall, examples: [outage, data_breach]}
critical_safety_incident:
classes: [weight_theft_or_tampering_with_harm, catastrophic_risk_harm,
loss_of_control_with_harm, deceptive_control_subversion_outside_testing]
page: [frontier-safety-lead, legal]
timers: {regulator_report: 72h, imminent_risk_authority: 24h}
runbook: docs/incident-response/critical-safety-incidents.md
Control: Frontier developer without a critical safety incident reporting process. The same guard addresses 2 items with binding law in 2 jurisdictions. Engineering guidance, not legal advice.
Rule id ny-raise-act.critical-safety-incident-reporting · review status: primary source derived
Binding law — not yet in force or stayed
Large frontier developers must publish and follow a frontier AI framework (New York RAISE Act)
N.Y. Gen. Bus. Law 1421(1) · official text · Enacted, not yet applying: applies from 1 Jan 2027 · New York (US-NY)
New York's RAISE Act, as rewritten by chapter 96 of 2026, requires a large frontier developer (one training models with more than 10^26 operations whose group revenue exceeded $500 million the prior year) to write, put into practice, abide by, and conspicuously post on its website a frontier AI framework explaining in detail how it handles ten topics: adopting recognized standards, capability thresholds for catastrophic risk, mitigations, deployment and internal-use review, third-party assessment, framework updates and what counts as a substantial modification, security of unreleased weights, critical safety incident response, internal governance, and internal-use risk including models evading oversight. It must revisit the framework yearly, repost any material change with its reasons within thirty days, and send the DFS office summaries of internal-use catastrophic-risk assessments every three months or on an agreed schedule. Detect a covered developer with no current published framework covering those topics or no record of the internal-use summaries.
Who it applies to
- Duty falls on: developer
- Large frontier developers whose frontier models are developed, deployed, or operating in whole or in part in New York. Binds model developers, not applications that call a hosted model. Applies from 2027-01-01.
- Whether it applies depends on facts outside the code; a person has to decide.
The guard to add
Organizational artifact to keep (not verifiable from code); the guard is the record, its owner and its upkeep.
Publish a frontier AI framework covering capability thresholds, mitigations, incident response, and internal-use risk, and gate model releases on it.
A public framework page, linked from the developer's website and owned by the frontier-safety lead, that maps each covered topic to the policy implementing it: standards adopted, catastrophic-capability thresholds and the evaluations that test them, mitigations applied when thresholds are reached, critical safety incident identification and response, and assessment of catastrophic risk from internal use. Show that it is implemented: release checklists cite the threshold evaluation results, a versioned changelog records changes with reasons and dates, and internal-use risk summaries sent to regulators are tracked with receipts. A CI or release gate refuses to promote a frontier model whose release record lacks the evaluations the framework calls for.
Where it goes: 12 repository artifacts, 14 user-facing text, 11 CI/CD pipeline.
What this provision adds:
- Cover all ten topics: recognized standards, capability thresholds, mitigations, deployment and internal-use review, third-party assessment, updates and substantial modification, unreleased-weight security, incident response, internal governance, and internal-use risk including oversight evasion.
- Revisit the framework yearly and repost any material change with its reasons within thirty days.
- Send the DFS office summaries of internal-use catastrophic-risk assessments every three months or on an agreed schedule.
Example (Model release record + CI gate), before:
# releases/model-x.yaml
model: model-x
approved_by: research-lead
After:
# releases/model-x.yaml (CI fails if a required field is missing)
model: model-x
framework_version: 2.3 # https://example.ai/frontier-framework
threshold_evals:
bio_uplift: evals/results/model-x/bio.json
cyber_offense: evals/results/model-x/cyber.json
autonomy: evals/results/model-x/autonomy.json
thresholds_crossed: [cyber_offense]
mitigations: [classifier-gating, staged-access]
incident_runbook: docs/safety/critical-incident-response.md
approved_by: frontier-safety-lead
Control: Frontier AI developer without a published catastrophic-risk framework. The same guard addresses 3 items with binding law in 3 jurisdictions. Engineering guidance, not legal advice.
Rule id ny-raise-act.frontier-ai-framework · review status: primary source derived
Binding law — not yet in force or stayed
Frontier developers must publish a transparency report when deploying a new or substantially modified frontier model (New York RAISE Act)
N.Y. Gen. Bus. Law 1421(3)(a) · official text · Enacted, not yet applying: applies from 1 Jan 2027 · New York (US-NY)
Before or at the time a frontier developer deploys a new frontier model, or a substantially modified one, GBL 1421(3) requires it to post a transparency report on its website giving its website, a way for a person to contact it, the model's release date, supported languages and output modalities, intended uses, and any general use restrictions. Large frontier developers must add summaries of the catastrophic-risk assessments run under their framework, the results, how far third-party evaluators were involved, and other framework steps taken for that model. Publishing the information inside a system card or model card satisfies the duty. Detect a frontier-model release process with no transparency report or model card carrying these fields.
Who it applies to
- Duty falls on: developer
- All frontier developers deploying a new or substantially modified frontier model that is developed, deployed, or operating in New York; the risk-assessment summaries apply only to large frontier developers (revenue above $500 million). Applies from 2027-01-01.
- Whether it applies depends on facts outside the code; a person has to decide.
The guard to add
Organizational artifact to keep (not verifiable from code); the guard is the record, its owner and its upkeep.
Publish a transparency report or system card on the developer's website before or at each new or substantially modified frontier-model deployment, and gate release on it.
A transparency report the frontier developer publishes on its website before or when each new or substantially modified frontier model is deployed; a model card or system card can carry it. It lists the developer's website, a contact channel for individuals, the release date, supported languages and output modalities, intended uses, and general use restrictions; for large developers it adds summaries of the catastrophic-risk assessments run under the developer's framework, their results, how far third-party evaluators were involved, and other framework steps taken for that model. The release or safety-policy owner maintains it and revises it for every new or substantially modified model, and the deployment pipeline carries a release gate that blocks rollout until the report is live with its fields present (for example a transparency-report.json validated against a schema in CI).
Where it goes: 12 repository artifacts, 14 user-facing text, 11 CI/CD pipeline.
What this provision adds:
- The risk-assessment summaries apply only to large frontier developers (revenue above $500 million); the base report covers models developed, deployed, or operating in New York.
Example (GitHub Actions release gate), before:
deploy-model:
runs-on: ubuntu-latest
steps:
- run: ./deploy.sh "$MODEL_VERSION"
After:
deploy-model:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: pipx run check-jsonschema --schemafile schemas/transparency-report.schema.json "reports/$MODEL_VERSION/transparency-report.json"
- run: curl -fsS "https://example.com/models/$MODEL_VERSION/transparency" > /dev/null # report is live
- run: ./deploy.sh "$MODEL_VERSION"
Control: Frontier model deployed without a public transparency report. The same guard addresses 2 items with binding law in 2 jurisdictions. Engineering guidance, not legal advice.
Rule id ny-raise-act.transparency-report · review status: primary source derived