Provider protocol v3 conformance is unverifiable: no kit identity is pinned

[rldyourmnd]

Summary

This repository implements provider protocol v3 and has no verifiable link to
the contract it implements. Nothing here references the public conformance kit
provider-kit/v3 — no version, no checksum, no source. Conformance is currently
an assertion.

Nothing is incompatible today. All five provider repositories were compared on
2026-08-15 and agree with ai_stp on protocol version, the six core commands,
the optional command, the operations and the provenance fields. What is missing
is any way to prove that, or to notice when it stops being true.

Why the version alone will not do

kit_version did not identify a contract. Two consecutive commits in ai_stp
both published 0.1.0, and the second changed the machine bytes: it added
recover-operation to commands, core_commands and apply_commands, added
setup_stable_id and setup_version to the provenance fields, and moved the
provider-info schema's command-array bounds from 5/6 to 6/7.

So 0.1.0 names both a six-command and a seven-command core. It must not be
used as a reference.

What changed in ai_stp

The kit now carries a content-addressed identity, decided in
ADR-0085-provider-kit-identity-is-its-content-digest:

• SHA256SUMS covers the three machine files — manifest.json,
  provider-info.schema.json, conformance-cases.json;
• the aggregate digest is SHA-256 over the canonical SHA256SUMS bytes, so
  any change anywhere in the kit changes it;
• it is published in a new KIT-IDENTITY.json beside the kit, not inside
  manifest.json — the manifest is covered by SHA256SUMS, so writing the
  digest into it would make the digest an input to itself;
• kit_version is bumped to 0.2.0 as the correction and is now a readable
  label. The digest is what to pin; it does not depend on anybody keeping a
  version honest.

Current identity:

Field	Value
kit_version	0.2.0
protocol_version	3
aggregate_digest	sha256:d45add27fded30962f411441547c92cc9d06264035c2d314357c24d3d983b819

What is being asked here

1. Record the exact kit identity this repository implements — version and
   aggregate digest, not the version alone.
2. Verify the local protocol copy against the kit rather than against
   independently maintained literals. cli-tools/provider_protocol_v3.py is
   byte-identical across all five provider repositories — one blob,
   10a9879b6cecdd1e9bb8cbfe4acd0638cc287687, 26562 bytes, verified through the
   GitHub API on 2026-08-15 — and is linked to nothing. A local validator
   comparing local literals stays green through any future drift, because both
   sides of its comparison are the same copy.
3. Name the kit identity in release or conformance evidence, so a provider
   release states which contract revision it was built against.

Known blocker, stated rather than left for you to discover

ai-engineers-guild/ai_stp is private, and the $id in
provider-info.schema.json
(https://nddev.asia/schemas/provider-protocol/v3/provider-info.json) currently
returns 404. Under JSON Schema 2020-12 an $id is an identifier and not a
retrieval address, so that is not itself a defect — but it does mean there is no
public place to fetch the kit from yet.

Publishing the kit as an immutable artifact is an open decision on the ai_stp
side. Until it is taken, this issue is about agreeing the mechanism and
preparing the check, not about wiring a download. If you would rather wait for
publication before doing anything, say so here and it will be sequenced that
way.

Filed from ai-engineers-guild/ai_stp.