Conformance And Certification

Supply-Y conformance answers a practical question: can two independently operated Agents exchange the same Package safely and reach the same result?

The current repository provides an executable preview suite. It is useful implementation evidence, but it is not yet a Supply-Y production certificate.

Run the current suite

npm run check

The cross-language crypto check uses the pinned dependency in tools/requirements-conformance.txt. Install it in a Python virtual environment before running the full gate.

The release gate runs:

• strict Protocol Release Manifest validation, exact artifact byte counts, digests and discovery/install/profile pinning;
• OpenAPI linting;
• API-document/OpenAPI parity and 29 schema-valid request and response examples;
• AJV object-schema and domain validation;
• an independent dependency-free Python validation pass;
• Thread, Network Story, Package, Response and customer-local evidence-reference resolution;
• Native Mode encryption, signature and tamper vectors in Node JOSE, independent WebCrypto and Python cryptography implementations;
• signed notification, durable inbox, retry, replay and ordered-recovery cases;
• exchange-ledger and Agent safety behavior cases;
• cross-language Native and Catena-X interoperability with a Node.js sender, Python recipient and Node.js receipt verifier;
• signed Policy Receipt structure, signature, binding, approval and Package-eligibility decisions;
• customer-local connection-profile structure, secret-reference boundary and compatibility-report binding;
• TypeScript SDK build, all-fixture validation, Native protect/open, KMS adapter boundaries and 21-method API parity;
• TypeScript and production site builds.

API contract conformance

The current 1.0 Agent API is one contract expressed in three forms: the readable endpoint tables, the OpenAPI 3.1.1 document and executable examples. The release gate rejects drift between them.

Current evidence:

• all 21 documented operations exist in OpenAPI;
• all 21 OpenAPI operations appear in the readable API documentation;
• every operation has a unique operationId, summary and explicit success response;
• every mutation declares Idempotency-Key;
• all 29 committed request and response examples satisfy their referenced component schemas;
• the Docs endpoint reference is generated from these same OpenAPI and example files.

This proves contract consistency, not hosted service availability. Production certification still requires running the same operations and negative cases against a real sandbox.

Object conformance

An implementation must produce all six protocol objects with the shared object envelope and reject the published invalid fixtures.

Current evidence:

• 7 valid examples accepted;
• 17 invalid examples rejected;
• 6 of 6 object schemas use the shared envelope definitions;
• both validation implementations reach 24 of 24 expected outcomes.

The red-team set rejects inline integrity and base_transport objects. Content digests, sender signatures and transport routing belong to the delivery envelope and audit evidence, not inside the business object they protect.

Schema-valid does not mean factually true. It means the object is structurally compatible and satisfies the published local conformance rules.

The Protocol Playground runs these same schema and domain-profile checks inside the customer's browser against all 24 committed fixtures. It is an implementation aid, not a hosted exchange sandbox or certification result.

Thread context conformance

Individual objects can be valid while their references are wrong. The TypeScript SDK therefore exposes validateThreadContext to verify one complete collaboration snapshot before an Agent accepts it or generates an audit view.

The current suite passes 15 of 15 outcomes:

Area	Required behavior
Thread identity	Thread id and thread_id agree
Membership	Story and supplied objects belong to the same Thread
Story pointer	network_story_id resolves to the supplied Network Story
Basis resolution	Every Story basis ID resolves to an object of the declared protocol type
Basis time	No basis object was created after the Story that cites it
Current coverage	Current Package and Response chains are represented in Story basis
Response linkage	Every Response points to a current Package in the Thread
Evidence resolution	Every Package and Response evidence ID resolves in the customer-local evidence index
Evidence integrity	Evidence IDs are unique, timestamps are possible and digests use RFC 9530 SHA-256 syntax

Package IDs are immutable at the exchange boundary: reusing an accepted Package ID with changed content is already rejected by exchange behavior conformance. A Story basis reference therefore identifies one immutable accepted object rather than a mutable database row.

The evidence index contains references and digests only. It is read locally by the customer Agent; neither the index nor raw ERP, MES, QMS or document evidence is uploaded to Supply-Y for this check.

TypeScript SDK conformance

The TypeScript SDK packages the same object validator, Native cryptographic profile and Agent API surface for customer-controlled Agents.

Current evidence:

• all 24 committed valid and red-team fixtures reach their expected outcomes;
• all 18 Skill update cases produce the published decision without automatic activation;
• both signed Skill releases verify from raw contracts and bytes, while changed artifact, manifest, trust set and requested coordinate are rejected;
• the intended recipient and sender both open the committed Native vector;
• a fresh two-recipient Package protects and opens with the published algorithm profile;
• customer-controlled signer and decrypter adapters protect and open without passing a private JWK into the SDK;
• a signer that changes the requested payload and a decrypter that substitutes plaintext are rejected;
• an unrelated private key and changed sender signature are rejected;
• metadata that differs from the protected object is rejected before encryption;
• all 21 OpenAPI operations are exposed with bearer authentication, correlation IDs and mutation idempotency;
• RFC 9457 API errors preserve status, code, correlation and retryability.

This proves the local package agrees with the repository contract and exposes a non-exporting key-operation boundary. It does not prove a specific customer KMS or HSM product, registry availability, a hosted endpoint or production certification.

Native cryptographic conformance

The Native Mode vector proves that:

• authenticated delivery metadata matches the OpenAPI contract;
• the sender's ES256 signature verifies;
• sender and recipient can decrypt the same JWE ciphertext;
• an unlisted key cannot decrypt it;
• the canonical plaintext digest matches;
• changed signatures and ciphertext are rejected.

The current vector passes the same 9 of 9 checks in three implementations across two languages:

• the JOSE reference path uses the jose package;
• the independent WebCrypto path parses the JWS and JWE itself, derives the ECDH shared secret, implements the RFC 7518 Concat KDF, unwraps the content key with AES-KW and decrypts with AES-GCM;
• the Python path independently parses the same wire artifacts and performs ES256, P-256 ECDH, Concat KDF, AES-KW and AES-GCM through cryptography.

This resolves the local cross-language Package-vector gap and reduces the risk that one JOSE library hides a protocol misunderstanding. Production certification still requires customer KMS or HSM lifecycle evidence, an implementation maintained outside this repository and independent review.

Key lifecycle conformance

The key lifecycle vector separates four questions that implementations often blur together:

Question	Required rule
May this key sign a new Package?	It must be active or still retiring at both created_at and first observation
Does emergency revocation invalidate this Package?	Reject when created_at is at or after invalid_from
May an old Package still be verified?	Require matching tamper-evident acceptance proof before retirement or revocation cutoff
May retained ciphertext still be decrypted?	Only while the participant retains the matching private key or has completed a valid rewrap

The current suite passes 24 of 24 outcomes. It registers a distinct replacement P-256 signing key, verifies the new signature through JOSE and WebCrypto, proves the old public key cannot verify that signature, and rejects missing lifecycle fields, unknown keys, wrong key use, backdated post-retirement ingress, compromised signatures and unavailable historical decryption keys.

These checks define protocol behavior. They do not prove that a customer KMS actually disabled, retained or destroyed a private key at the declared time.

Notification delivery conformance

The notification suite proves the reliable boundary between Supply-Y and a customer Agent. The same committed webhook request is verified with Node and WebCrypto using the exact RFC 9421 P-256 signature base and RFC 9530 body digest.

The current suite passes 24 of 24 outcomes:

Area	Required behavior
Signature	Cover method, authority, path, body digest, content type, delivery ID, event ID and attempt
Integrity	Reject changed body bytes, changed covered headers and expired signatures
Retry	Retry network, 408, 425, 429 and 5xx failures; stop malformed or unauthorized 4xx requests
Dead letter	Stop after attempt 7, preserve the event and alert the endpoint owner
Deduplication	Treat automatic retry and manual replay as the same immutable event
Ordering	Store out-of-order events, hold them behind a sequence gap and release them in order
Recovery	Poll retained events with an opaque cursor and no duplicate on resume
Acknowledgement	Return the original result for an exact retry and reject changed content under the same idempotency key

A webhook 204 proves durable receiver inbox storage only. It is deliberately separate from the signed Package receipt that proves received, opened, rejected or failed business lifecycle state. See Events And Webhooks.

Signed Skill conformance

The Skill suite verifies two concrete JSON rule packages: supply-y.core@0.1.0 and supply-y.material-risk@0.1.0. Skills are data, not remotely executable plugins.

The current suite passes 21 of 21 outcomes:

Area	Required behavior
Artifact	Validate against the Skill Artifact Draft 2020-12 schema
Release	Validate against the OpenAPI SkillRelease contract
Identity	Artifact, release and requested coordinate agree
Integrity	RFC 8785 canonical JSON produces the committed RFC 9530 SHA-256 digest
Publisher	ES256 release signature verifies against the declared preview key
Dependency	Every exact Skill dependency resolves in the catalog
Safety	Package content is untrusted data with no instruction override or tool execution
Domain rules	Required paths exist in committed fixtures and prohibited disclosures are explicit
Negative cases	Changed artifact digest and changed release signature are rejected

The committed publisher key is intentionally test-only. These checks prove artifact and installation mechanics, not production publisher custody.

Skill publisher trust conformance

skill-publisher-key.schema.json defines strict public records for test-only-preview, active, retiring and revoked keys. The hosted preview record contains no private JWK and is checked against the isolated signing test vector.

The current suite passes 14 of 14 lifecycle decisions plus public/private separation and invalid-record checks. It covers local-only preview trust, production rejection, validity start, impossible observation time, planned retirement, revocation cutoff, key identity mismatch and digest-bound historical acceptance. A historical proof must bind the complete signed release digest to an acceptance time after publication and before cutoff. Run it with npm run validate:skill-publishers; SDK conformance evaluates the same cases independently.

Skill update conformance

The update suite turns Skill lifecycle rules into 18 deterministic decisions. It covers initial installation, equal and older versions, compatible additive and security updates, capability expansion, manual-download policy, breaking changes, invalid release or artifact contracts, protocol incompatibility, publisher trust, signature and digest failure, missing dependencies, deprecation, skipped migration paths and installed-release revocation.

Decision	Meaning
no_change	Keep the current version; the candidate is not newer
download_for_approval	The candidate may be cached and verified, but remains disabled until operator approval
manual_review	Capability or download-policy changes require a customer decision before download
manual_migration	The update is breaking or cannot be applied directly from the installed version
reject	Trust, integrity, compatibility, dependency or release status failed
disable_installed_and_alert	The installed release was revoked and must stop running

All outcomes preserve operator_approval_required. The OpenAPI SkillRelease contract rejects automatic activation, and both signed preview releases include the same invariant inside their signed update policy. Run the cases with npm run validate:skill-updates.

Agent discovery conformance

The /.well-known/supply-y document gives an Agent one stable, schema-validated place to discover installation formats, OpenAPI, signed Skills, publisher-key status, conformance and security boundaries.

The current suite passes 14 of 14 outcomes. It verifies the v0.5.0 discovery contract on supply-y.net, exact stable protocol release and digest, versioned installation and conformance-profile links, Skill coordinates against committed releases, the test-only publisher restriction, the release gate and machine-readable privacy boundary. Negative cases reject unknown fields and any attempt by discovery to claim that a production API is available.

Agent Conformance Profile 1.0

agent-conformance-profile-1.0.json is the published, language-neutral evidence contract for onboarding. Each of its nine checks fixes four things: the check ID, the Agent or customer infrastructure that must execute it, the exact public Bundle or customer resource used as input, and every required result ID. Discovery and the installer pin the profile's exact bytes with an RFC 9530 SHA-256 digest.

The current suite passes 18 of 18 outcomes. It validates the profile, resolves every public Bundle path and category, keeps the public protocol_contract independent of the restricted TypeScript SDK, verifies all three Compatibility Report examples against the same exact results, and rejects missing results, unknown execution fields and an SDK declaration in the public profile. The Java production-blocked example deliberately records agent_interoperability as not_run; reference repository output cannot be borrowed to turn that customer-specific check green.

Agent install manifest conformance

agent-install/0.9/manifest.json is the versioned machine-readable source used by the website and copy-paste installer. agent-install/0.9/schema.json rejects unknown fields and fixes the current supply-y.net resources, profile digest, integration paths, trust boundary and required checks.

The current suite passes 19 of 19 outcomes. It cross-checks the v0.9.0 one-paragraph execution prompt, digest-pinned Protocol 1.0 Manifest and 55-entry public Agent Bundle, Agent Conformance Profile 1.0, public contract path, restricted SDK fallback, signed Skill releases, publisher lifecycle, Policy Receipt, customer-local connection profile, Compatibility Report 0.5 and all eleven optional source-backed commands. Negative cases reject unknown fields, removal of the public contract path or conformance pin, advertising the restricted SDK as public and any false claim of production publisher trust.

Customer Connection Profile conformance

customer-connection-profile.schema.json gives an installing Agent one strict customer-local shape for API and OAuth metadata, identity, transport, KMS or HSM key references, approved Skills, local policy and notification delivery. It stores typed references, not secret values, private keys or business payloads. The complete profile remains in the customer environment.

The current suite passes 18 of 18 outcomes. It validates the reference profile, pins the exact Protocol 1.0 Release Manifest, matches both approved Skill coordinates and digests to signed releases, and binds the exact canonical profile digest, identity and transport into the Compatibility Report. Negative cases reject stale release digests, unknown fields, inline OAuth secrets, private JWKs, missing or plaintext credential references, insecure token and webhook URLs, incomplete Catena-X configuration, missing approvers, duplicate Skill coordinates, signing/encryption key reuse, production HTTP API URLs and production test-only keys.

Agent compatibility report conformance

An installing Agent must finish with JSON that satisfies Agent Compatibility Report 0.5. The report names all nine required check IDs and records executed_by, observed_at and every exact result ID for each check, plus the selected release and transport, key-adapter state, missing configuration and an explicit enablement decision.

The current suite passes 13 of 13 outcomes. It accepts a complete TypeScript local-preview report whose digest, identity, Skills and transport match the customer-local connection profile, and an honest Java protocol_contract production-blocked report with no SDK field and no borrowed interoperability result. It rejects a missing installed SDK on the optional TypeScript path, any SDK field on the public contract path, duplicate or incomplete result IDs, mismatched profile environments or decision scope, unknown fields, empty evidence and a structurally valid report that claims production enablement while checks, credentials, key adapters, the production API or publisher trust are incomplete.

This distinction matters: JSON Schema proves report structure; the Supply-Y decision profile proves that the Agent's conclusion follows from the evidence.

Policy Receipt conformance

The sender Agent applies policy locally because Supply-Y cannot inspect encrypted business content. Before creating a Package, it signs a PolicyReceiptCreate claim and submits it to POST /v1/policy-receipts. The claim binds the exact Package ID, content digest, sender, recipient, protocol version, Skill version, Policy Envelope digest, five required check outcomes and any human approval.

The current suite passes all 17 receipt decisions and 24 contract checks. It verifies the committed ES256 signature and exact Policy Envelope digest, accepts a valid signed claim as Package-eligible, and keeps structurally valid but failed checks or missing approval as accepted evidence with ineligible authorization. It rejects missing, duplicate or unknown checks; Package, digest, party or policy mismatches; impossible evaluation and approval times; unknown keys; tampered signatures; and business plaintext injected into the receipt. PackageMetadata now requires the accepted policy_receipt_id.

This is tamper-evident evidence of what the sender Agent claimed to enforce. It does not prove that hidden business facts are true or that a malicious implementation honestly performed its local scan. Certification, customer-controlled logs and bilateral audit remain the stronger assurance layers.

Exchange behavior conformance

The deterministic Exchange Ledger harness uses the authenticated metadata from the cryptographic vector and the Package Metadata schema from OpenAPI.

Case	Required result
First valid submission	202 accepted; create one durable operation
Exact retry with the same idempotency key	Return the original operation; create no new effect
Same key with different content	409 idempotency_key_reuse
Same Package ID under a new key	409 duplicate_package_id
Expired Package	409 package_expired
Creation time beyond allowed clock skew	400 timestamp_out_of_window
Unknown recipient Agent	409 recipient_capability_unavailable
Request and metadata transport modes disagree	400 transport_mode_mismatch
Missing idempotency key	400 idempotency_key_required
Missing required delivery metadata	400 request_invalid

These 10 cases establish the expected state semantics. They do not claim that a hosted production service already implements them.

Two-Agent transport interoperability

The repository now runs a Node.js sender, a separately implemented Python recipient and a Node.js receipt verifier as isolated operating-system processes. The roles exchange only serialized protocol artifacts. The same business Package is exercised through two transport runs:

Mode	Where the encrypted Package exists	What Supply-Y retains	Result
Native	One Supply-Y encrypted-object entry	Authenticated metadata, ciphertext reference, receipts and audit	Recipient verifies, decrypts and returns a signed receipt
Catena-X	One participant EDC asset	Signed transfer manifest, EDC IDs, asset digest, receipts and audit	Recipient obtains the EDC asset, verifies its digest, decrypts and returns a signed receipt

The Catena-X control manifest binds connector_id, asset_id, asset_digest, contract and transfer IDs to the authenticated Package metadata with an ES256 signature. Supply-Y does not create a Native ciphertext copy for that run.

Current reference evidence:

• 26 of 26 interoperability checks pass;
• six Node.js and four Python process runs complete, including rejection paths;
• both modes produce the same business-content digest and object semantics;
• the Python recipient independently verifies the JWS, decrypts the JWE, checks authenticated metadata and validates the Reasoning Package with the dependency-free Python validator;
• recipient-signed receipts match the OpenAPI contract;
• both lifecycle histories form valid append-only hash chains;
• the Catena-X run leaves zero Native objects and one EDC asset.
• changed recipient identity, transfer references, asset digest and receipt contents are rejected.

This closes the repository-local cross-language Agent gap, but it is not independent-vendor interoperability. Both implementations are maintained in this repository and the EDC is a deterministic local adapter. The public hosted Sandbox exercises the Native API with fictional data; an independently maintained external Agent, customer KMS or HSM systems and a real partner connector remain required for certification.

Safe Agent boundary

Every decrypted Package enters an untrusted-data channel. Package text must never become a system instruction and must never inherit tool permissions.

The current safety fixtures require:

Input	Required disposition
Normal supply-chain reasoning	Continue to Skill validation
“Ignore previous instructions” content	Manual review; no tool calls
Embedded ERP or credential tool request	Manual review; no tool calls
Embedded active script content	Manual review; no tool calls

The reference harness uses explicit examples to verify control-flow expectations. Its pattern detector is not a complete prompt-injection defense. A certifying Agent must demonstrate isolation at the prompt, tool, credential and runtime boundaries even when no keyword detector fires.

Certification levels

Level	Evidence required
Schema Compatible	Object fixtures and shared-envelope checks pass
Secure Package Compatible	Crypto vectors, key lifecycle and negative cases pass
Exchange Compatible	Idempotency, replay, expiry, receipts and state transitions pass against a sandbox
Safe Agent Compatible	Hostile-content suite produces no unauthorized prompt or tool effect
Catena-X Compatible	The same logical Package completes one EDC transfer with matching audit evidence
Supply-Y Certified	All required levels pass for a named implementation and time-limited version

Certification applies to a specific Agent, Skill set, transport mode, version range and evidence date. It does not permanently certify an organization or every future release.

Evidence package

A certification submission should contain:

1. implementation name, owner and version;
2. supported protocol, schema, Skill and API versions;
3. signing and encryption key identifiers, without private keys;
4. machine-readable test results and timestamps;
5. sandbox audit event IDs and Package digests;
6. failure evidence for all required negative cases;
7. declared transport modes and Catena-X connector versions when applicable;
8. expiry date and conditions that invalidate the result.

Source material

• conformance/exchange-behavior.cases.json
• conformance/agent-conformance-profile-1.0.json
• conformance/agent-conformance-profile-1.0.schema.json
• conformance/agent-compatibility-report-0.5.schema.json
• conformance/notification-delivery.cases.json
• conformance/agent-safety.cases.json
• discovery/customer-connection-profile.schema.json
• discovery/customer-connection-profile.example.json
• conformance/policy-receipt.cases.json
• conformance/skill-publisher-key.cases.json
• conformance/skill-update.cases.json
• conformance/thread-context.cases.json
• conformance/two-agent-interoperability.cases.json
• test-vectors/crypto-profile-0.1.json
• test-vectors/key-lifecycle-0.1.json
• test-vectors/policy-receipt-0.1.json
• test-vectors/webhook-signature-0.1.json
• examples/valid/
• examples/invalid/
• scripts/validate-exchange-behavior.mjs
• scripts/validate-agent-conformance-profile.mjs
• scripts/validate-skill-publisher-lifecycle.mjs
• scripts/validate-thread-context.mjs
• scripts/validate-agent-interoperability.mjs
• scripts/validate-key-lifecycle.mjs
• scripts/validate-notification-delivery.mjs
• scripts/validate-policy-receipts.mjs
• scripts/validate-customer-connection-profile.mjs
• scripts/validate-skill-releases.mjs
• scripts/validate-skill-update-policy.mjs
• scripts/validate-discovery-manifest.mjs
• discovery/agent-install-0.9.schema.json
• discovery/agent-install-0.9.json
• discovery/supply-y-discovery-0.5.schema.json
• discovery/supply-y-discovery-0.5.json
• skills/skill-artifact.schema.json
• skills/supply-y.core/0.1.0/
• skills/supply-y.material-risk/0.1.0/
• validation/interoperability-report.json
• openapi/supply-y.openapi.json
• openapi/examples.json
• scripts/validate-openapi-contract.mjs
• scripts/validate-typescript-sdk.mjs
• packages/typescript-sdk/
• tools/validate_crypto_vector.py
• tools/requirements-conformance.txt

The next conformance milestone is to run the same cases against two independently maintained Agents using customer KMS or HSM systems, then repeat the Catena-X path with a partner EDC connector. The public hosted Sandbox is evaluation evidence, not independent certification evidence.