# Plan a Managed Pilot

**Status:** Live customer operating guide for Supply-Y Protocol 1.0. It explains how a managed pilot is scoped and accepted; it is not part of the immutable 1.0 wire contract or a public service-level agreement.

## What the pilot is

A Supply-Y pilot proves one useful cross-company decision loop between two named participants. It is deliberately narrower than a production rollout: one business question, one sender, one recipient, one approved Skill and one transport path.

The pilot must prove both sides of the exchange. The business participants receive enough bounded information to act, while the technical evidence proves which exact protocol release, Agent configuration, Package bytes, policy decision and receipts governed the loop.

The pilot is not a request to centralize ERP data, replace either company's Agent or open customer systems to Supply-Y.

## Entry criteria

| Area | Minimum needed before a two-party exchange |
| --- | --- |
| Participants | One business owner and one technical owner at each company |
| Decision | One concrete question, intended recipient, response type and decision window |
| Agent path | Existing company Agent or a customer-isolated Jenae deployment |
| Data | A fictional or sanitized example that demonstrates the required business meaning |
| Keys | Customer-controlled signing and encryption key plan; no private key export |
| Transport | One choice for the pilot: Native Mode or Catena-X EDC |
| Controls | Named disclosure approver, retention rule, forwarding rule and tool permissions |
| Operations | Security contact, pilot incident contact and agreed pause authority |

A participant can begin discovery before all criteria are complete. No cross-company exchange starts until both participants approve the scope and the technical readiness evidence.

## Who does what

| Owner | Responsibility |
| --- | --- |
| Sending company | Maps local source data, chooses what to disclose, approves the recipient and signs the outbound policy result |
| Receiving company | Defines the useful response, verifies incoming data as untrusted, controls local tools and returns a signed receipt or response |
| Both companies | Agree the shared business meaning, success criteria, transport path, retention and escalation rules |
| SupplyWhy | Provides the pinned protocol contracts, signed pilot Skills, isolated coordination service, conformance run and ciphertext-safe audit evidence |

SupplyWhy does not approve a customer's disclosure, hold customer private keys or decide whether an Agent may act in a customer system.

## Data and key boundary

The pilot starts with fictional or sanitized data. If both companies later approve a bounded operational exchange, only the Package defined by the selected Skill crosses the company boundary. Raw source records, internal transformations, credentials, private keys and decrypted Packages stay in customer-controlled environments.

In Native Mode, Supply-Y stores one encrypted Package plus the metadata needed for routing and audit. 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 second copy.

Supply-Y does not receive a customer decryption key. A content-level joint review is a separate, time-limited action that requires both participants to authorize the exact Package and scope. See [Security And Trust](/docs/security) for the complete ownership table.

## Pilot stages and gates

| Stage | Work | Gate to continue |
| --- | --- | --- |
| 1. Scope | Name the decision, participants, value for each side, protected data and target response | Both business owners approve one written loop definition |
| 2. Local readiness | Pin Protocol 1.0, configure customer-local references, validate fixtures and run the Agent compatibility checks | Each Agent produces a reviewed Compatibility Report; production exchange remains disabled |
| 3. Two-party sandbox | Exchange a fictional or sanitized Package and Response Object through the selected transport | Signatures, digests, receipts, thread state and recovery behavior match on both sides |
| 4. Controlled exchange | Enable only the approved Skill, recipient, fields, retention and decision window in an isolated pilot environment | Both participants approve the exact controls and can pause the loop independently |
| 5. Closeout | Review business outcome, disclosure boundary, failures, audit evidence and operating ownership | Joint written decision to stop, revise, repeat or prepare a production agreement |

Passing one stage never silently enables the next. Every enablement decision is explicit, evidence-bound and reversible.

## Acceptance evidence

The final pilot record should let either participant reconstruct the exchange without asking Supply-Y for business plaintext. It contains:

- the exact Protocol 1.0 Manifest URL and digest;
- the selected Skill coordinates, release digest and publisher status;
- one Compatibility Report for each participating Agent and environment;
- customer-local Connection Profile digests, never the credentials or private keys they reference;
- Package, Response Object, Policy Receipt and recipient receipt identifiers, digests and signatures;
- Native or Catena-X transfer evidence showing that one Package used one transport path;
- an ordered thread and append-only audit evidence;
- one demonstrated notification retry or ordered recovery path;
- one tested pause, revocation or retention action;
- a business review naming the action taken, value for each participant and information deliberately withheld.

A pilot succeeds only when the technical evidence passes and both participants agree that the bounded information was useful enough to make the named decision. Schema validity alone is not business success.

## Failure, pause and exit

Either participant may pause its Agent or stop the pilot according to the agreed authority. A partial failure remains visible as its own state; it is retried, rejected or resolved rather than reported as a completed loop.

At exit, SupplyWhy stops pilot credentials and delivery, applies the agreed ciphertext retention or deletion rule, and exports ciphertext-safe audit evidence. Each customer retains its local mappings, approvals, keys, decrypted content and Agent logs. The stable protocol artifacts and customer evidence remain portable; continuing with Supply-Y is not required to read them.

## Commercial and support boundary

Protocol 1.0 does not define pricing, uptime or incident-response commitments. Pilot fees, usage measures, any value-linked commercial model, support hours, severity definitions and response targets belong in a signed pilot order.

Any billable measure must be deterministic and reviewable by both parties. Supply-Y does not rely on reading customer plaintext or on a unilateral estimate of savings to calculate a charge. No public SLA is implied by this guide.

## Start without sending sensitive data

Send only the minimum sanitized context needed to plan a call:

- the two participant roles or company types;
- the decision the loop should help make;
- who would send and who would respond;
- existing Agent language or the need for Jenae;
- Native or Catena-X transport preference, if known;
- the desired evaluation period and named business and technical contacts.

Do not send credentials, private keys, production tokens, raw ERP exports, decrypted Packages or confidential contract data. [Start a pilot conversation](mailto:hello@supplywhy.ai?subject=Supply-Y%20Managed%20Pilot) with sanitized context, or first complete the public [Getting Started](/docs/getting-started) path without an account or customer data.

---

Canonical HTML: [Plan a Managed Pilot](https://supply-y.net/docs/pilot)
Agent documentation index: [llms.txt](https://supply-y.net/llms.txt)