Skip to content

Conformance

Conformance

Conformance is what lets a rule written in Taipei run unchanged on an engine in Seattle. Three levels define what it means to claim a system implements ATR — so that any conforming engine evaluates the same rule the same way. Each level has a test suite published as YAML fixtures in the repository; conformance is demonstrated, not asserted.

Working Draft·version 3.5.6·updated 16 June 2026·canonical /spec·editor Adam Lin

L1 Engine Conformance Normative

An L1 engine is what makes the format portable. It MUST parse every rule that validates against spec/atr-schema.yaml, MUST evaluate detection.conditions with the semantics defined in §3.5, and MUST honor scan_target and status semantics — so that the same rule yields the same verdict regardless of who wrote the engine. L1 engines MAY refuse rules outside their declared scan_target.

L2 Publisher Conformance Normative

An L2 publisher publishes rules in a vendor-prefixed sub-range (e.g., ACME-YYYY-NNNNN) that follow all ATR semantics. L2 publishers MUST honor the deprecation policy in §3.7 and SHOULD include test_cases for every published rule.

L3 Sub-range Authority Normative

An L3 sub-range authority is a national or organizational body that mints rules under a sovereign prefix (e.g., ATR-TW-2026-NNNNN). Authority is granted following the procedure in /charter §5; the TSC grants it once seated — until then the lead maintainer (BDFL) acts in this role.

The TSC is not yet seated. Authority is granted once the TSC is seated; until then the lead maintainer (BDFL) acts in this role.

Test Suite

The L1 engine test suite consists of YAML fixtures stored under spec/conformance/ in the main repository. Each fixture pairs a rule with its expected evaluation outcome on a fixed event — the contract is in the fixture, not in any one implementation. An implementation passes if every fixture evaluates as declared. Two engines that both pass agree, by construction, on every rule the suite covers.

spec/
└── conformance/
    ├── L1/
    │   ├── 001-basic-match.yaml
    │   ├── 002-scan-target-mismatch.yaml
    │   ├── 003-status-draft-skip.yaml
    │   └── …
    ├── L2/
    │   └── …
    └── README.md

Each fixture is a YAML file with three blocks: the target rule, the input event, and the expected evaluation outcome. Engine implementers clone the repo, run the test suite locally, and produce a pass/fail report.

Self-Certification

Implementations self-certify by running the test suite locally and opening a pull request against ADOPTERS.md with the integration metadata. The maintainers (the TSC once seated) may verify a self-certification at any time by re-running the suite against a published artifact.

The TSC is not yet seated. This verification role is exercised by the TSC once it is seated; until then the lead maintainer (BDFL) acts in this role.

After passing the test suite, implementers open a pull request against ADOPTERS.md ↗, including organization name, spec version, integration date (ISO 8601), a verifiable public evidence link, and a self-declared conformance level. Maintainers aim to validate and merge within seven days. The full procedure and the list of merged implementers live at /implementers.

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