Protocol Concepts

Supply-Y is an Agent-to-Agent coordination protocol for cross-company supply chains. It lets companies exchange a small, controlled business judgment without exchanging the raw data used to produce that judgment.

What “controlled reasoning” means

Controlled reasoning is reasoning with a defined disclosure boundary. The sender decides what conclusion is useful to share, expresses it in a structured Package, identifies the facts and uncertainty behind it, and states what was deliberately withheld.

It does not mean that Supply-Y reads a company's reasoning and approves it. Plaintext validation happens inside the sender's environment because Supply-Y normally cannot decrypt the Package.

What Supply-Y standardizes

Supply-Y standardizes only the network boundary:

• object identity, version and trace fields;
• the minimum meaning of a Package and Response;
• confidence, intent, disclosure boundaries and response obligations;
• thread lifecycle and audit events;
• Skill identifiers and scenario-specific output contracts;
• transport-independent integrity and receipt semantics.

Each company remains free to use its own Agent, models, ERP schema, semantic layer and internal transformation logic.

Core objects

Object	Purpose	Plain-language meaning
Reasoning Package	Carries the sender's bounded business judgment	“Here is what we believe, why it matters, and what we need from you.”
Response Object	Carries the recipient's structured reply	“Here is what we agree with, what constrains us, and what we will do.”
Loop Thread	Orders multiple Packages and Responses	“These messages belong to the same business problem.”
Policy Envelope	Records disclosure and approval boundaries	“This is the purpose, retention and forwarding rule applied locally.”
Network Story	Captures the current shared judgment	“This is what the network currently agrees on and what remains open.”
Audit Event	Proves lifecycle actions without exposing content	“This object was accepted, delivered, opened or rejected at this time.”

Stable envelope and scenario payload

Every protocol object has a stable base envelope for identity, authorship, traceability and compatibility. Thread-scoped objects also require thread_id. A reusable Policy Envelope is intentionally not tied to one thread.

Supply-Y object
├── common object envelope
│   ├── object identity and type
│   ├── protocol and schema version
│   ├── creation time and creator
│   ├── correlation and idempotency trace
│   └── thread identity when thread-scoped
└── scenario payload
    ├── facts and evidence references
    ├── reasoning and confidence
    ├── requested action
    └── disclosure boundaries

When a Package crosses the network, a separate delivery envelope adds sender, recipient, Skill, expiry, digest and transport metadata. Keeping object identity separate from delivery routing prevents transport concerns from leaking into every business object.

For Audit Events, created_by identifies the service that wrote the immutable record while actor identifies the organization, Agent or human that performed the recorded action. The distinction is deliberate.

This split avoids a single industry-wide mega-schema. Companies agree on the small object crossing the boundary, not on how every internal system stores its data.

The collaboration loop

A Supply-Y exchange is a stateful loop, not a broadcast alert.

observed -> reasoned -> shared -> responded -> aligned -> actioned -> measured -> closed

Not every scenario uses every phase, but every transition is explicit and auditable. A timeout, rejection or partial failure is recorded as state rather than hidden inside an email chain.

Value for every tier

Participant	Direct benefit
Tier 3	Warns customers early without exposing exact inventory, capacity or commercial terms
Tier 2	Receives enough context to assess component impact and request clarification
Tier 1	Coordinates mitigation across components without forwarding raw supplier data
OEM	Receives a decision-ready risk picture without demanding every supplier's source data

The network works only when each participant receives actionable context while keeping its own data boundary.

No blind forwarding

If Company B receives a Package from Company A and needs to involve Company C, B creates a new Package for C under the appropriate Skill. A's original Package is not automatically forwarded.

This rule creates a new disclosure decision and audit boundary at every company hop.

Two transport modes

Native Mode stores one encrypted Package in Supply-Y storage. Catena-X Mode transfers the same logical Package through existing EDC infrastructure and stores only transfer references and audit metadata in Supply-Y. The Package is never sent through both paths at the same time.