Conformance
An Agent, Service, or optional hosted identity Platform conforms to the applicable requirements in the AEP drafts. The aep-specs conformance materials turn selected requirements into repeatable development-time checks. They do not add an AEP endpoint or a production runtime dependency.
Know what each artifact checks
The Internet-Drafts are the normative source. JSON Schemas check the shapes of published documents and messages. Test vectors provide inputs and expected outcomes for success, rejection, and compatibility cases. A valid object is not proof that an implementation authenticates assertions, prevents replay, or handles a lifecycle transition correctly; those behaviors must be executed against implementation code.
The conformance runner classifies cases by role and profile, then sends applicable vectors through an adapter that calls the implementation. The adapter must exercise the real public behavior represented by each case. Echoing a fixture's expected output would test the fixture, not the Agent or Service.
Claim only the roles and profiles you implement
An Agent claim covers consuming Inspect, constructing assertions, calling commands, handling errors, and using issued credentials. A Service claim covers publishing Inspect, validating assertions, processing commands, enforcing idempotency, and issuing or revoking credentials it advertises. A Platform Hosted Identity claim covers its separate optional role, including Service-scoped identity provisioning and delegated signing. Do not claim the Platform role merely because an Agent calls a hosted Platform.
Agent and Service claims include core-http with an enabled identity method. Add claims only when the implementation supports the Claims catalog and its negotiation rules. Add api-key, basic, or oauth-bearer only for session-credential formats the implementation supports. A Service that does not advertise Grant and Revoke needs no credential profile. Its development-time capability manifest is test metadata, not an Inspect document.
Run fixture and implementation checks separately
From an aep-specs checkout with its Ruby dependencies installed, run the offline fixture harness:
make -C ietf check-harness
This checks the semantic relationships encoded in the fixtures. It does not connect to a live Agent, Service, or Platform and does not prove one conforms. To test an implementation, run its role adapter through the conformance runner. The adapter reads one JSON request per line and returns one JSON response per line while calling the actual implementation.
For example, from the root of aep-node, with a sibling aep-specs checkout and its Ruby dependencies installed, run the roles separately:
pnpm conformance:agent pnpm conformance:service pnpm conformance:platform
Use the corresponding SDK repository's own instructions for other languages. The Node.js commands build the selected role and invoke its adapter; they write reports under .conformance/reports. A custom implementation can supply its own manifest and adapter to the runner without adopting an SDK's test harness.
Interpret the report before relying on it
The report records the implementation name and version, tested role, claimed profiles, AEP version, and digests of the exact capability manifest and vector set. Read passed, failed, and skipped totals by category and profile. A required case cannot be skipped; an optional case may pass, fail, or be skipped. Cases unsupported for the claimed role or profile are not dispatched. A reported failure needs investigation even when the report itself is well-formed.
Missing or duplicate adapter responses, a malformed response, a required-case skip, or a nonzero adapter exit are harness failures, not successful skips. Keep the report with the release it tested so its recorded revisions identify the evidence behind the result.
Treat conformance as evidence, not certification
A green role report shows that the selected vectors passed for that implementation and artifact revision. It is not an AEP certification, a production capability advertisement, or a substitute for testing the complete deployed integration. A Service still needs integration tests for durable storage, concurrent replay and idempotency handling, authentication at protected resources, and recovery after failures. An Agent still needs tests for real Service responses, redirect boundaries, credential handling, and user-visible failure paths.
Use the conformance contract when building an adapter or investigating a vector. The Security and privacy and Errors and idempotency pages explain two important behavioral boundaries that schema validation alone cannot establish.
