Skip to content

Project Charter

Project Charter

The charter defines what ATR is, what it is not, how decisions are made, and how the Technical Steering Committee is seated.

Working Draft·version 3.0.0-alpha.1·updated 25 May 2026·canonical /spec·editor Adam Lin

Mission

ATR exists to give the AI-agent security community a single shared format for declaring, exchanging, and evaluating detection rules — so that defenders working in different organizations and countries can compose their work without re-inventing the rule format each time.

Scope

In scope

In scope: the rule format, the reference engine, the rule schema, conformance levels, and the cross-framework mappings (OWASP, MITRE ATLAS, NIST AI RMF, SAFE-MCP).

Out of scope

Out of scope: vendor-specific tooling, commercial integrations, runtime enforcement policy, and incident response coordination — these belong to downstream implementers, not to the standard itself.

Governance

ATR is governed by a single maintainer (BDFL) transitioning to a Technical Steering Committee. The transition criteria and the TSC seating process are defined in GOVERNANCE.md and docs/BDFL-charter.md.

The full governance charter, maintainer role definitions, decision-escalation flow, and the BDFL → TSC transition timeline are normatively defined in GOVERNANCE.md ↗.

Intellectual Property

ATR is released under the MIT License. All contributions are MIT-licensed by submission. There is no CLA. The DOI for citation is 10.5281/zenodo.19178002.

Decision-Making

Spec-level changes go through the RFC process: anyone may open an RFC issue or PR describing the proposal, the maintainer labels it as RFC, and a public discussion window opens — typically fourteen days, extended to thirty for complex proposals. After discussion closes, decisions are reached by consensus where possible and by maintainer call where not. Engine-level fixes, documentation edits, and new rule submissions do not require the RFC process and follow the standard PR flow.

The threshold for adoption is rough consensus from active contributors — no sustained, unresolved objections from substantive contributors (definition in GOVERNANCE.md) within the public discussion window. Until the TSC is seated, the BDFL retains final call on every RFC and commits to publicly recording the rationale for each call inline on the RFC thread.

Full procedure: GOVERNANCE.md ↗.

TSC Seating Criteria

All four criteria below MUST be satisfied to be eligible for nomination to the ATR Technical Steering Committee. Nominations are made via pull request to GOVERNANCE.md and are subject to public review under the RFC process.

  1. Criterion 1. Demonstrated technical contribution to ATR — rules merged, engine work, benchmark work, or schema work — within the past twelve months.
  2. Criterion 2. Public maintainer of an ATR implementer organization or a downstream library that ships ATR in production.
  3. Criterion 3. Endorsement from the current maintainer plus one external implementer (the implementer MUST come from a different organization than the candidate).
  4. Criterion 4. Commitment to attend bi-monthly TSC calls and to respond to charter-level decisions within seven days.

TSC seating does not require the candidate's organization to be an implementer. Academic affiliates, independent researchers, and government researchers are eligible if the four criteria are met.

Editor: Adam Lin <[email protected]> — DOI 10.5281/zenodo.19178002 — MIT License — ISO 8601 2026-05-25