Conformance and Qualification

Conformance answers whether an implementation follows a protocol contract. Qualification answers whether a particular build and deployment works with its real dependencies under the required conditions. AIP treats them as related but different evidence.

Evidence Levels

Level	What it proves	What it does not prove
Unit test	One code unit behaves as asserted	Cross-process interoperability
Schema fixture	JSON shape matches a versioned schema	Runtime policy or side effects
Core conformance	Native envelopes and invariants are implemented	External provider behavior
Profile conformance	A compatibility mapping follows its version matrix	Every independent client works
Connector frozen conformance	Advertised connector operations follow the SDK contract	Real provider availability or semantics
Integration test	Repository components work together	Deployment identity, network, or provider behavior
Isolated-live qualification	Exact build works with a pinned real product in an isolated topology	Arbitrary production topology or load
Production campaign	Deployment survives required security, restart, fault, and load scenarios	Future untested versions

Native Core Checks

Run the built-in fixture suite:

cargo run -p aipctl -- conformance run

Validate a specific envelope:

cargo run -p aipctl -- conformance run --envelope envelope.json

Export machine-readable schemas:

cargo run -p aipctl -- schema export ./exported-schemas

Release checks must verify the generated output against the versioned files under schemas/aip.

MCP Compatibility

Run against Streamable HTTP:

cargo run -p aipctl -- mcp conformance \
  --url http://127.0.0.1:18080/mcp

Run against stdio:

cargo run -p aipctl -- mcp conformance \
  --command aipd \
  --arg=--mcp-stdio \
  --arg=--service-id \
  --arg=agent:aipd:mcp-conformance

The complete release matrix covers stable MCP versions 2024-11-05, 2025-03-26, 2025-06-18, and 2025-11-25, method-family negative cases, session ownership, cancellation races, replay, OAuth boundaries, and independent client/server implementations.

Connector Conformance

A frozen connector suite must test every behavior the manifest advertises:

• exact capability and schema admission;
• trusted execution context;
• successful invocation and typed error mapping;
• streaming ordering and terminal behavior;
• cancellation confirmation;
• idempotency collision behavior;
• approval resume;
• plan, commit, compensation, and uncertain-outcome reconciliation;
• webhook authenticity and replay;
• callback and event emission;
• restart recovery.

Unsupported behavior should fail explicitly and must not be advertised.

Retained Evidence

An isolated-live report should contain no credentials and should identify:

• source commit and clean/dirty status;
• source-tree digest;
• built image digest;
• connector and upstream revisions;
• configuration class without secrets;
• start and finish times;
• scenario ids and outcomes;
• protocol message types and action ids where safe;
• restart, replay, approval, and provider evidence;
• the exact command used to reproduce the campaign.

Retained evidence must be copied from the raw run artifact without manual rewriting. A byte-for-byte comparison is preferable.

Repository Release Gate

cargo fmt --all --check
cargo clippy --workspace --all-targets --all-features -- -D warnings
cargo test --workspace --all-features
cargo test --workspace --no-default-features
cargo doc --workspace --all-features --no-deps
cargo run -p xtask -- release-check

Optional audit, dependency-policy, fuzz, semver, benchmark, load, and chaos gates are required when the release policy or changed surface calls for them.

Status Language

Use Done fully only when every evidence class required by the item exists and passes. Code completion does not satisfy a requirement that explicitly calls for external interoperability, multi-process deployment, load, fault, or credentialed product evidence.