Governance And Support

Status: Public operating process for Supply-Y Protocol 1.0. This document is not part of the immutable 1.0 wire contract and may be clarified without rewriting that release.

Supply-Y governance has one job: let two companies depend on the same protocol without asking either company to surrender control of its systems, data or Agent. The protocol contract is maintained centrally; business meaning is reviewed with the participants who use it; every company remains responsible for what its own Agent sends and does.

Who decides what

Decision	Accountable party	Required participation
Protocol envelope, lifecycle, security baseline and release Manifest	SupplyWhy protocol maintainers	Compatibility and security review before publication
Cross-company semantic profile and scenario Skill	SupplyWhy publishes the signed contract	Affected OEM and supplier roles review the shared meaning and examples
Customer data mapping and transformation	Each customer	Customer data owner and Agent operator
Local disclosure, approval and tool permissions	Each customer	Customer security and business approvers
One bilateral exchange	Sender and recipient	Both identities and the intended recipient are bound to the Package
Conformance result	The implementation that ran the checks	Evidence must name the actual Agent and execution environment
Production certification	SupplyWhy certification program	Independent evidence and customer-controlled test results; not currently generally available

SupplyWhy can define protocol rules and publish default Skills. It cannot silently activate a Skill, read encrypted business content, approve a customer disclosure or replace a customer's local authorization. Download and signature verification prove what was published; operator approval decides what runs.

How a protocol change is made

1. State the problem. A proposal identifies the affected object, API, Skill, transport or security rule and includes a concrete supply-chain example.
2. Classify compatibility. Maintainers label it editorial, additive, security-sensitive or breaking before implementation starts.
3. Change the executable evidence. A behavior change must update the relevant schema or OpenAPI contract, positive example, rejection case and conformance check.
4. Review the shared meaning. Changes to business semantics or a scenario Skill include review from the participant roles affected by that meaning.
5. Publish a release candidate. Exact artifacts, migration notes, known limits and verification results are reviewable before promotion.
6. Publish immutable bytes. A released version receives fixed URLs, byte counts and digests. Published release artifacts are never edited in place.

An editorial correction may improve live documentation when it does not change valid wire behavior. Any change that alters what an implementation accepts, rejects, discloses or does requires versioned executable evidence. A breaking change requires a new protocol major version and a migration path.

Release acceptance gate

A protocol release is publishable only when all applicable evidence is present:

• strict schemas and a machine-readable API contract;
• valid examples and expected rejection fixtures;
• cryptographic and lifecycle test vectors;
• Agent safety and two-party interoperability cases;
• explicit compatibility and migration rules;
• a security impact review and known-limit statement;
• an immutable Manifest with exact artifact digests;
• a human-readable release note that separates stable contracts from implementation availability.

Passing repository checks proves that the published artifacts agree with one another. It does not certify a customer's Agent, KMS, EDC connector or production operating process. Those claims require evidence from the named customer environment.

Shared semantics and Skills

Supply-Y deliberately avoids one universal internal data model. Each company may keep its own ERP schema, ontology and transformation logic. The shared boundary standardizes only the business meaning needed for one collaboration pattern.

A semantic proposal therefore includes field meaning, units, allowed granularity, prohibited disclosures, role-specific examples and ambiguous cases. SupplyWhy turns the approved boundary into a versioned Skill and fixtures. Participating companies review the meaning; SupplyWhy maintains the signed artifact; each customer decides whether to activate it.

Support routes

Use the route that matches the problem. This prevents customer data from ending up in the wrong channel.

Need	Route	What to include
Documentation defect, schema question or reproducible interoperability problem	Email a protocol question	Protocol version, artifact URL, minimal fictional example and expected behavior
Authorized repository collaborator	Repository issue tracker	The same sanitized technical context; this route requires repository access
Suspected vulnerability or key/trust failure	Start a private security report	Affected version and impact only; request a secure follow-up channel before sending sensitive detail
Managed pilot or commercial onboarding	Plan a managed pilot	Companies, intended workflow, Agent stack, transport choice and target timeline
Active pilot incident	The named private pilot incident channel	Correlation ID, timestamp, affected tenant and ciphertext-safe evidence only

Never put credentials, private keys, production tokens, customer plaintext, decrypted Packages or confidential company names in a public issue. Start with object IDs, digests, timestamps, protocol versions and sanitized reproduction data.

Security response

SupplyWhy coordinates reported protocol and publication vulnerabilities through a private channel. The initial email establishes contact; sensitive reproduction material is exchanged only after the parties agree on a suitable secure follow-up channel. The same reporting contacts are machine-discoverable at /.well-known/security.txt for security scanners and response teams. The response process is:

1. confirm receipt and preserve the original report privately;
2. reproduce and classify the impact without requesting customer plaintext by default;
3. identify affected versions, trust roots and implementations;
4. prepare a fix, conformance regression and customer action;
5. coordinate disclosure with the reporter and affected participants;
6. publish an advisory and versioned replacement when disclosure is safe.

If a signing key or published artifact is compromised, the response may include key revocation, release disablement and a mandatory migration. A historical release remains acceptable only when customer-controlled evidence proves that its exact signed digest was accepted before the key cutoff.

Current service boundary

Protocol 1.0 is a stable interoperability specification. The hosted production API, production Skill trust root and certification service are not generally available. Public docs, schemas, fixtures, the Agent Bundle and local conformance evidence can be evaluated today; production credentials, operational support and service levels require a managed pilot or signed service agreement.

No public uptime, response-time or incident-resolution SLA is claimed before that agreement exists. Pilot commitments belong in the pilot record, including named contacts, severity definitions, support hours, data-retention settings and escalation paths.

Evidence retained for accountability

Governance decisions should remain auditable without collecting customer plaintext. Supply-Y retains the proposal or issue, review decision, release classification, exact artifact digests, conformance output and publication time. Customers retain their local mapping, approvals, private keys, decrypted content and environment-specific execution evidence.

This split allows a later reviewer to answer who published which rule, which implementation ran it and which exact release governed an exchange, while keeping customer business content under customer control.