The ECL-1 Version 1.0 specification
ECL-1 Version 1.0 is a set of documents: the core standard, the protocols and profiles it relies on, and the schemas, registries, and tests that make its requirements checkable. The text of each document is in the repository on GitHub, and this site hosts a copy of each, rendered for reading. Every link on this page to a document’s text, the licenses, the schemas, registries, and tests opens Version 1.0 at the repository’s tag v1.0, which does not change when the main branch does.
- Version
- ECL-1 Version 1.0, publication date to be announced. Maintained by G-14, Inc.
- Repository
- GitHub repository (coming soon), with the release notes (coming soon) and the change log (coming soon)
- Rights
- Text under CC BY 4.0, and schemas, registries, tests, and code under Apache-2.0, with G-14’s patent pledge
The document set at a glance
ECL-1 core standard, Version 1.0The guarantee, the six control layers, 628 requirements, the levels and claims, and the checklist an assessor applies. Every other document serves it.
Protocols 7
Trust and verification 2
Guides and records 3
Profiles 4
Binding profiles 5
- AARM-BINDING-1 1.0
- ACS-BINDING-1 1.0
- MCP-GATEWAY-1 1.0
- OTEL-EVIDENCE-EXPORT-1 1.0
- OAUTH-AUTHORITY-1 1.0
Machine-readable set
- Schemas (coming soon)
- Registries (coming soon)
- Conformance tests (coming soon) 953 vectors
- Browser verifier
The core standard
The core standard states what a deployment must do and what a claim must say. Its Section 7 sets the conformance levels and the claim rules, and its Section 11 is the checklist an assessor works through.
- ECL-1: External Control Layer Standard
The guarantee, the six control layers, the requirements, the conformance levels and claims, and the checklist that an assessor applies.
Protocols
The protocols define the messages, evidence, and signatures that pass between the parts of a control layer. They are normative companions of the core standard, which cites each by version in its Section 3.4.
- DCMP-2: Decision and Control Message Protocol
The messages that carry each proposed action to the decision service and its decision back to enforcement, with the facts that the decision rests on.
- EBMP-2: Evidence Bundle and Manifest Protocol
The signed records and bundles that show why an action was or was not released, what was observed, and how the evidence was verified.
- ECL Integrity Envelope 1
The signed envelope and canonical JSON form of every ECL object, and the offline package, so that evidence can be checked without a network.
- ECL Timing, Availability, and Safe-State Semantics 1
Time classes, clock skew, timeouts, and the safe state that an action class falls back to when part of the control layer fails.
- ECL Distributed and Long-Running Workflow Semantics 1
Identities and causal order for actions that are delegated, retried, run by several agents, or left partly complete.
- ECL Evidence Lifecycle Protocol 1
Retention, legal hold, export, redaction, and destruction of evidence, each recorded as a new signed fact that leaves the history unchanged.
- ECL Extension and Registry Protocol 1
How an extension is declared, versioned, and marked critical, and how registry entries are allocated.
Trust policy and offline verification
A verifier checks evidence under the checking party’s own trust policy, so that keys and policies carried with the evidence never vouch for it. These documents say what that policy holds and how evidence reaches a reader with no network path to its producer.
- ECL Trust Policy Profile 1
The trust policy that the checking party supplies: policy versions, key roles, principals, revocations, and limits on loading a policy.
- ECL Offline Verification Profile 1
How an offline package lets a reader verify evidence with no network path to its producer or to any control plane.
Profiles
A profile tightens the core for a declared deployment or assurance context. It may add requirements and prohibit optional behavior, but it may not weaken a core requirement while claiming the same conformance scope, and it applies only to a claim that declares it.
- ECL Strict Failure Profile 1
Forbids fail-open handling of the action classes in scope and requires that missing proof fail closed.
- ECL DCMP-2 HTTP Binding Profile 1
DCMP-2 over HTTPS: framing, bearer principals, limits, signed outcomes, and failure classes.
- ECL Transactional Effect Profile 1
Obligations on timing, privilege, and evidence for actions that take effect as transactions, and the evidence that each outcome leaves.
- ECL AuthZEN Binding Profile 1
Adds a check by a policy engine reached through the OpenID AuthZEN Authorization API. The engine’s permit creates no authority to act.
Binding profiles
A binding profile states how ECL-1 works with another system. It claims no conformance with that system and no endorsement by its owners, and under each profile an action is released only on an ECL-1 admit for that exact request.
- ECL AARM Binding Profile 1
An AARM control plane serves as the ECL-1 decision service or feeds one as a source of judgment inputs, and its receipts are bound to the ECL-1 evidence.
- ECL ACS Binding Profile 1
A Guardian under OWASP’s Agent Control Standard becomes a decision source whose decisions reach an action only through a signed ECL-1 decision.
- ECL MCP Gateway Profile 1
A gateway outside the AI system’s control sends each Model Context Protocol tool call for a decision and forwards only the exact call that an admit covers.
- ECL OpenTelemetry Evidence Export Profile 1
Copies decisions and evidence into OpenTelemetry log records for monitoring tools, outside the decision path.
Informative guides and records
These documents state no requirement of their own. Each obligation they describe is set, with its identifier, in the core standard or a normative companion that they cite.
- ECL Conformance Claims 1
The parts of a conformance claim and the limits of an assessment, gathered from the core standard in one place.
- ECL Deployment Profiles 1
Hosted, federated, sovereign, offline-edge, and air-gapped deployments, and the controls that the core standard requires of each.
- Issues on the normative text
Questions about the normative text that needed a decision, each with its resolution.
The repository also holds guides for buyers, implementers, and assessors in its docs folder (coming soon), among them the integration contract (coming soon), which states what an agent, a tool server, or a gateway must expose, and must not hold, to be controllable.
Schemas, registries, and tests
The core standard lists the schema set, the registry set, the validator, and the conformance vectors among its companion artifacts, which are part of the normative assessment package at every level (Section 3.4). They do not override the core, and a contradiction between them and the text is an error to report.
- schemas (coming soon)
- JSON Schemas for every DCMP-2 message, EBMP-2 record, envelope, claim, register, assessment package, trust policy, and offline package.
- registries (coming soon)
- The compiled requirements, the semantic rules, the error codes, the extensions, the algorithm suites, and the terms, each with a stable identifier.
- conformance (coming soon)
- The conformance tests: positive and negative vectors with their expected results, signed fixtures, the incident replay scenarios, and the report format. The conformance page explains them.
- formal (coming soon)
- A TLA+ model of the runtime control invariant and a Tamarin model of DCMP-2 signing and binding, with pinned-tool instructions, recorded results, deliberately broken variants, reachability witnesses, and the limits of each bounded model. They check the design, not an implementation.
- web/verifier (coming soon)
- The offline verifier for a web browser, and the TypeScript library and command line it is built on, in packages/ecl-ts (coming soon).
- packages/ecl-verify (coming soon)
- The Python verifier and its command line,
ecl-verify. - go/crosscheck (coming soon)
- The Go verifier and its command line,
ecl-verify-go.
Versions
Each document has its own version. A claim names the core version and the version of each companion it uses, as Section 7.7 of the standard requires. DCMP-2 and EBMP-2 messages also carry the version of their format in schema_version.
| Document | Version |
|---|---|
| ECL-1 | 1.0 |
| DCMP-2 | 2.0 (messages carry schema_version 2.0) |
| EBMP-2 | 2.0 (messages carry schema_version 2.0) |
| INTEGRITY-ENVELOPE-1 | 1.0 |
| TIMING-SAFE-STATE-1 | 1.0 |
| DISTRIBUTED-WORKFLOW-1 | 1.0 |
| EVIDENCE-LIFECYCLE-1 | 1.0 |
| EXTENSION-REGISTRY-1 | 1.0 |
| TRUST-POLICY-1 | 1.0 |
| STRICT-FAILURE-1 | 1.0 |
| DCMP2-HTTP-1 | 1.0 |
| TRANSACTIONAL-EFFECT-1 | 1.0 |
| AUTHZEN-BINDING-1 | 1.0 |
| AARM-BINDING-1 | 1.0 |
| ACS-BINDING-1 | 1.0 |
| MCP-GATEWAY-1 | 1.0 |
| OTEL-EVIDENCE-EXPORT-1 | 1.0 |
| OAUTH-AUTHORITY-1 | 1.0 |
Requirement identifiers are never reused. A change follows the change process in the repository, and each new minor or major version has a public review window before it is published. Six release candidates, RC-1 to RC-6, preceded Version 1.0. None was published, and all are retired.
Citing ECL-1
Cite the version you used:
ECL-1 Version 1.0, External Control Layer Standard. Maintained by G-14, Inc. Publication date to be announced. https://externalcontrollayer.ai/specification
The repository also provides citation metadata (coming soon) for reference managers.
A conformance claim needs more than a citation. The conformance page lists what a claim must state.
Report a problem in the text
Open an issue in the repository for an error, an ambiguity, or a contradiction between documents, and give the requirement identifier where there is one. A confirmed error is corrected through the change process, as an erratum or in a later version. The working group page explains how to propose a change.
Open an issue on GitHub (coming soon)How errata are published, current version (coming soon)