# Common Questions

**Status:** Live customer guide for Supply-Y Protocol 1.0. This page explains the current protocol and service boundary; it is not part of the immutable 1.0 wire contract.

## Is Supply-Y a central data lake?

No. Supply-Y is an Agent-to-Agent coordination protocol, not a place where companies upload their ERP, MES, QMS, PLM or lake data. Source records and internal transformations stay in each company's environment. Only a bounded Package crosses the company boundary.

In Native Mode, Supply-Y stores one encrypted Package plus routing and audit metadata. In Catena-X Mode, the Package travels once through the participants' EDC data plane and Supply-Y stores transfer references and audit evidence, not a duplicate payload. See [Security and Trust](/docs/security) for the exact data-ownership table.

## Can Supply-Y read our business data?

Not by default. The sender encrypts a Native Package before it leaves the company, and Supply-Y does not hold a customer decryption key. Supply-Y can read the metadata needed to route and audit an exchange, such as organization IDs, Package ID, content digest, protocol version, timestamps, transport mode and receipt state.

The sender and authorized recipient can decrypt the Package with their own keys. Plaintext becomes visible to Supply-Y only in a separately approved, time-limited joint-audit session after both parties authorize the exact scope.

## Where does each kind of data live?

| Data | Normal location |
| --- | --- |
| Raw source data and internal reasoning | Customer systems and Agent environment |
| Customer private keys | Customer KMS or HSM |
| Decrypted Package | Authorized sender and recipient Agents |
| Native Package ciphertext | Supply-Y encrypted object storage |
| Catena-X Package | Participant EDC data plane |
| Identity, routing, thread state and receipts | Supply-Y metadata services |
| Event hashes and audit evidence | Supply-Y append-only audit store and customer evidence stores |

The [Architecture](/docs/architecture) page maps these locations to the API and service flow.

## Do we need to install a Supply-Y Gateway?

No Supply-Y Gateway is required inside the customer network. A company needs an Agent runtime that can make outbound HTTPS calls, use customer-controlled signing and encryption keys, and apply approved Supply-Y Skills. The Agent may be one the company already operates. A company without an Agent can use a customer-isolated Jenae deployment.

Connection settings are stored in a customer-local Connection Profile containing references to credentials, keys, webhook configuration, transport and approved Skills. Secret values and private keys do not go into that profile or into Supply-Y. See [Install In Your Agent](/docs/agent-install) for the guarded onboarding path.

## What does “controlled reasoning” mean?

Controlled reasoning is a bounded business output: relevant facts, assumptions, uncertainty, confidence, requested action and disclosure limits. It is not a model's private chain of thought, a raw database export or an instruction for the recipient's Agent to execute tools.

The sender shares enough context for the recipient to make a decision while explicitly identifying what was withheld. The [Protocol overview](/docs) renders one passing Package fixture with its shared fields and protected fields side by side.

## Who defines and enforces policy?

SupplyWhy maintains the protocol contract and publishes signed default Skills for common collaboration patterns. Participating companies review shared business meaning. Each customer controls its own data mapping, disclosure choice, approved recipients, retention setting, forwarding rule, local approvers and Agent tool permissions.

Because Supply-Y cannot normally read plaintext, policy checks happen in the sender's environment. The sender's Agent signs a Policy Receipt bound to the exact Package digest, recipient, policy and evaluation result. Supply-Y verifies that signed receipt and its bindings; it does not pretend to re-run plaintext checks it cannot perform.

## How can audit work when Supply-Y only has ciphertext?

Audit does not require the platform to read the business payload. Supply-Y records Package and thread IDs, content digests, signatures, actors, timestamps, protocol and Skill versions, state transitions, Policy Receipts and recipient receipts in an append-only hash chain.

This proves which identities exchanged which exact bytes under which rule and what lifecycle events the platform observed. It does not prove that a business statement inside the Package is true. When content review is necessary, both parties can authorize a limited joint-audit session without turning normal operation into a central plaintext archive.

## Can a recipient forward the Package to another company?

There is no blind forwarding. If Company B receives a Package from Company A and needs to involve Company C, Company B creates a new Package for Company C under a new disclosure decision, recipient binding and Policy Receipt.

The original Package is forwarded only when its explicit policy allows that recipient and action. This creates a separate audit boundary at every company hop and prevents downstream access from being inferred from an upstream relationship.

## What changes when both companies already use Catena-X?

Supply-Y reuses the participants' EDC connectors as the data plane. The same logical Package identity, digest, policy and thread semantics apply, but the Package is transferred peer to peer through one EDC asset. Supply-Y coordinates identity, thread state, transfer references, notifications and audit evidence.

The data is not sent twice: one Package travels through one transport. Native Mode stores ciphertext once in Supply-Y; Catena-X Mode stores no duplicate Package in Supply-Y. The [Architecture](/docs/architecture) explains both paths.

## How is malicious or prompt-injection content handled?

Every incoming Package is untrusted data. A recipient verifies identity, signature, digest, expiry, schema and Skill version before business processing. Package text is isolated from system prompts, credentials and tool permissions; scripts, binaries, undeclared attachments and instruction-override attempts are rejected or quarantined.

High-impact operational actions require customer-defined approval. The conformance suite includes explicit cases for instruction override, tool execution and active content. See [Security and Trust](/docs/security) and [Conformance and Certification](/docs/conformance).

## What happens if one step succeeds and another fails?

Supply-Y does not hide partial failure behind a false all-or-nothing result. Each accepted Package, delivery attempt, notification, receipt and thread transition has its own durable state. Idempotency keys make retries safe; a durable Agent inbox and ordered polling recover missed webhooks; exhausted deliveries move to a dead-letter path for operator action.

A thread remains pending, failed or partially completed until the missing action is retried, rejected or resolved. No later step is reported as complete merely because an earlier API call succeeded. See [Events and Webhooks](/docs/events) for retry and recovery behavior.

## Is Protocol 1.0 production-ready?

The interoperable Protocol 1.0 specification is stable and published through an immutable Release Manifest and digest-pinned Agent Bundle. Its schemas, fixtures, crypto vectors, behavior cases and reference interoperability evidence are executable today.

That does not mean every implementation surface is generally available. Hosted production APIs, production Skill signing trust, public SDK distribution and the certification service currently require a managed pilot. The [Versioning and Compatibility](/docs/versioning) page separates stable contracts from implementation availability line by line.

## How should a company evaluate Supply-Y?

Start without production credentials or customer data:

1. watch the [Package Loop Demo](/) to understand the collaboration pattern;
2. inspect and edit passing and rejected objects in the browser-local [Protocol Playground](/docs/playground);
3. follow [Getting Started](/docs/getting-started) to verify the public release and first local loop;
4. give the guarded [Agent installer](/docs/agent-install) to the company's Agent and review the generated Compatibility Report;
5. [plan a managed pilot](/docs/pilot) only after identity, keys, configuration, interoperability and production trust evidence are complete.

Questions about a real workflow can be routed through [Governance and Support](/docs/governance) without sending customer plaintext.

---

Canonical HTML: [Supply-Y Protocol FAQ](https://supply-y.net/docs/faq)
Agent documentation index: [llms.txt](https://supply-y.net/llms.txt)