Trust Center

Status: Public assurance guide for Supply-Y Protocol 1.0. It summarizes published controls and evidence; it is not a production certification, service-level agreement or legal compliance attestation.

How to read this page

Supply-Y separates four claims that are often blurred together:

1. Defined in Protocol 1.0: the public contract says what an implementation must do.
2. Verified locally: committed executable evidence proves the reference implementation behaves that way under the named test conditions.
3. Verified for a customer: a specific Agent, key system, peer, transport and operating environment produced its own evidence.
4. Certified for production: an authorized assurance process bound reviewed evidence to a named implementation, scope and expiry.

The first two exist today. The third is part of a managed pilot. The fourth is not generally available. A green local test must never be presented as a customer production certificate.

The default trust boundary

Customer systems remain the source of truth for raw operational data. Customer Agents transform those records locally, choose an approved disclosure boundary and encrypt the resulting Package before it leaves the participant environment. Customer KMS or HSM systems retain private signing and decryption keys.

Supply-Y coordinates identity, public keys, signed Skills, encrypted Native Packages, Catena-X transfer references, Thread state, receipts, notifications and audit metadata. It does not receive a customer decryption key on the normal exchange path.

Evidence answers a precise question

A schema result proves object structure. A content digest proves byte integrity. A signature proves that a registered key approved exact bytes. A Policy Receipt proves what the sender Agent claimed to check. An audit chain proves the order and integrity of observed lifecycle events. None of those proves that a hidden business statement is true.

The control matrix links each claim to its canonical contract or evidence page. Reviewers should follow those links instead of treating this summary as standalone proof.

Customer-specific assurance

Before controlled use, each participant still validates its own Agent implementation, customer-local Connection Profile, KMS or HSM adapters, approved Skills, disclosure and approval rules, transport, peer compatibility, notification recovery, retention and pause authority. The resulting Compatibility Report belongs to that implementation and environment.

Two participants then prove one complete loop with fictional or sanitized data. Production data and service commitments are considered only after both parties accept the technical and business evidence in a signed pilot or service agreement.

Reporting and review

Send protocol questions with a minimal fictional example and exact artifact version. Report suspected vulnerabilities privately and do not include credentials, private keys, production tokens, decrypted Packages or customer plaintext in the first message. See Governance And Support for the correct route and Availability And Readiness for the current product boundary.

Reference build and dependency integrity

The public reference repository locks Node dependencies, pins the Python cryptographic conformance dependency and runs the complete Protocol release gate on every pull request and every push to main. The workflow installs exact dependencies, runs npm audit at moderate severity, executes all protocol and cross-language cryptographic checks, and produces a clean production build.

CI then starts that production build and runs the same browser acceptance suite used for release review. It verifies all 26 documentation routes and their unique metadata, the hosted Sandbox UI and exchange, every discovered internal link, OpenGraph output, security response headers, Axe accessibility results, keyboard navigation, responsive layouts and a nonblank interactive 3D scene. A failure retains browser screenshots for review instead of publishing a green check without page-level evidence.

GitHub Actions are pinned to immutable commit SHAs. Dependabot monitors npm, pip and GitHub Actions every week, while pull requests receive a dependency review that blocks newly introduced moderate-or-higher vulnerabilities. The current Python conformance pin is cryptography==48.0.1, which contains the fixes required by the three advisories affecting the previous 46.0.5 pin.

This evidence covers the Supply-Y reference repository and its published conformance tools. It does not certify a customer's Agent, operating system, container base image, KMS adapter or transitive dependencies; each customer must scan and attest its own deployment.