Control
Frontier model deployed without a public transparency report
When a frontier model (new or substantially modified) is deployed, its developer publishes a transparency report (identity and contact route, release date, languages, output modalities, intended uses, use restrictions) and, for large developers, summaries of catastrophic-risk assessments, their results and third-party evaluator involvement.
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.
Reach
enacted, not yet applying in Illinois (US-IL), New York (US-NY); next date 2027-01-01.
The guard to add
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 reviewers look for: for each frontier-model release, a published report or system card carrying every listed field and that version's release date; for large developers, risk-assessment summaries with results and third-party evaluator involvement; and a release checklist or pipeline step that fails when the report is not live or a field is missing, rather than a report written after launch.
Organizational control: the evidence is a kept record, its owner and its upkeep, not code.
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"Engineering guidance, not legal advice. Each provision below may add its own details (a cadence, a deadline, a required notice element): open it for those.
Upcoming dates
- : Frontier developers must publish a transparency report at deployment, with machine-readable risk summaries (Illinois SB 315) (Illinois (US-IL); first application)
- : Frontier developers must publish a transparency report when deploying a new or substantially modified frontier model (New York RAISE Act) (New York (US-NY); first application)
Every rule this guard addresses
Binding law — not yet in force or stayed (2)
- Illinois (US-IL)
- Frontier developers must publish a transparency report at deployment, with machine-readable risk summaries (Illinois SB 315) IL PA 104-0538, Sec. 10(c)(1) · applies from 2027-01-01
- New York (US-NY)
- 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) · applies from 2027-01-01