Conformance to ECL-1

The four levels

ECL-1 has four conformance levels, and each includes the requirements of the levels below it. The level a system needs is the highest of three scores: one for its autonomy, one for the sensitivity of its data, and one for the consequence of its actions. A score that cannot be given for lack of information takes the next higher level until the evidence is provided.

The independence classes

Class A is separation under the same operator, which a public claim must disclose. Class B places control approval and evidence verification in a separately administered trust domain that the AI system and its ordinary operators cannot change on their own. Class C adds a named, externally independent authority that holds both functions. Section 7.5 of the standard sets the minimum class for each level.

Kinds of claim

Each claim declares one of three boundary classes, and a level stated without one is incomplete.

Full-system mediation

full-system-mediation. The claim covers every reachable consequential action of the system of interest.

Bounded action-class mediation

bounded-action-class-mediation. The claim covers only the classes of action that it names.

Component or profile implementation

component-or-profile-implementation. The claim covers one component or one profile. It does not provide the guarantee of ECL-1.

Each claim also has a status. Full conformance means that every applicable control passes with the required evidence and that the assessment the level requires has taken place. Conditional conformance, allowed only at L2 and L3, means no critical findings, a remediation plan of at most 180 days, and the required negative-testing evidence. An assessment-only claim has technical evidence, but the required assessment or the certainty of its boundary is not yet established.

The anatomy of a claim

Under Section 7.7 of the standard, any public, procurement-facing, or regulator-facing claim states at least the system of interest, the claimed level, the claim status, the claim boundary class, the achieved independence class, the core version and the versions of the companions, any deployment or sector profile with its version, the date of the latest assessment or evidence refresh, any material limitation, and, where support for an external framework is asserted, the mapping packet with its statement of residual gaps. The standard’s own example, read part by part:

Not valid

“ECL-1 certified.” No certification program or certification mark is authorized.

Not valid

“ECL-1 compliant,” with nothing more. It omits the system, the level, the status, the boundary class, the version set, and the limitations.

Not valid

“ECL-1 ensures compliance with [a law].” Conformance must not be represented as legal compliance or sector certification.

The name ECL-1 may be used to describe what an implementation does. A conformance claim names the version, the level, and the claim boundary, as Section 7.7 requires.

Section 7.7 of the standardClaiming conformance, current version on GitHub (coming soon)The rules for marks, current version (coming soon)

The checklist

Section 11 of the standard is the conformance checklist. It turns the requirements and the claim rules into acceptance criteria that a buyer or an assessor can check, and a supplier that claims conformance submits it with links to the evidence for every applicable item.

• The items fall into six domains: boundary and claim, identity and authority, enforcement and action, provenance and evidence, verification and fleet, and procurement and reporting.
• Each item is marked Pass, Fail, or Not Applicable. An item is Not Applicable only when its applicability predicate is false for the system or the claimed level is below the item’s minimum level.
• The submission includes the boundary of the system of interest, the claim boundary class, and the Negative Boundary Annex, with a matrix that maps each functional requirement to the checklist items.
• An assessor records as critical any bypassable enforcement of an action in scope, fail-open behavior on missing proof, a missing evidence chain, a broken emergency halt, an undisclosed effect path outside the claim boundary, and, from L2, missing negative-testing evidence.

Section 11.5 lists the package that a supplier hands over with the checklist, from the claim statement and the Consequential Action Register to sample DCMP-2 messages, EBMP-2 evidence bundles, and drill records. Section 11 of the standard

The conformance tests

The conformance tests are a shared corpus of 953 vectors in the repository’s conformance folder. Each vector names an artifact, the stage at which an implementation checks it, and the expected result. A passing vector expects no finding, and a failing vector expects the rule or error code that the implementation must report first. The stages run from strict JSON parsing and canonical form, through the schemas and semantic rules of DCMP-2 and EBMP-2 objects, to envelopes, trust policies, signed evidence bundles, and offline packages.

Each measured unit of the published coverage denominator, meaning each branch of the wire, claim, and assessment schemas and each active semantic rule, has a passing and a failing vector. The incident replay suite adds 10 scenarios built from entries of the record, each with the outcome that every step must have.

An implementation runs the corpus and writes its results in the report format that the conformance folder defines. A schema-valid object is not necessarily conformant, and passing the tests is evidence for a claim, not the claim itself.

The conformance tests on GitHub (coming soon)The report template (coming soon)

The verifier

The verifier checks a signed evidence bundle, or an offline package that carries one, against a trust policy that the checking party chooses. The keys and policies inside a package count as evidence, never as trust. The browser version on this site reads the files you choose in your browser and makes no network request; the command line, ecl-verify-ts, gives the same verdicts and writes the report as JSON, and Version 1.0 also publishes command-line verifiers in Python (ecl-verify) and Go (ecl-verify-go), checked against the same conformance tests.

Verified

Every envelope verified under the trust policy, every pairing and binding rule held, and the record of each action is complete.

Invalid

At least one check failed. Each finding names the rule the bundle breaks.

Incomplete

The available record does not establish a complete history: a predecessor is missing, or a request has no final state.

Current trust failed

The evidence would otherwise verify, but at least one signing key, including a time authority’s key, is not acceptable under the current trust policy.

Beside every verdict the verifier lists the checks that held and what it did not establish. A verified verdict can still leave a scope item unestablished. Verification never establishes that the recorded times are the true times, that the effects happened, that the deployment has been assessed, or that the statements in the records are true.

• Verify evidence in your browser
• Try it on a sample
• The verifier on GitHub (coming soon)
• The TypeScript library and command line (coming soon)
• The Python verifier and its command line, ecl-verify (coming soon)
• The Go verifier and its command line, ecl-verify-go (coming soon)

Declaring a claim, in three steps

1. Test and verify

   Run the conformance tests on your implementation and write the report. Run the verifier on evidence that your deployment produced, under a trust policy of your own.

2. Write the claim

   State everything that Section 7.7 requires, in the form of the example above, and have an assessor check it where the level requires one. From L2 the assessment must be independent and include negative tests.

3. Ask to be listed

   Open a pull request that adds your claim and your report to community/implementers.yaml, with a DCO sign-off on each commit. The editors check that the submission is complete and list it as self-declared. They do not check that the claim is true.

How to be listed, in detailClaiming conformance, current version on GitHub (coming soon)

The implementers registry

The registry lists implementations whose makers have declared a conformance claim and published the report behind it. Every listing is self-declared, and G-14 certifies nothing. An assessor’s assessment is listed separately, when the implementer provides it.

No implementation is listed yet. ECL-1 Version 1.0 publication date to be announced, and listings appear here once implementers submit them.

The registry page: what a listing means and showsThe registry file on GitHub, as it stands now (coming soon)