# Representative Use Cases **Status:** Live customer guide for Supply-Y Protocol 1.0. The catalog below is generated from six committed protocol scenario fixtures paired one-to-one with the six interactive demo scenarios; it is not a list of unverified marketing claims. ## How to use this catalog Choose the loop that is closest to one real cross-company decision. Compare the business problem, participant sequence, transport availability and acceptance criteria before discussing integration. Each loop links to the exact interactive scenario and its source fixture. The scenarios are representative starting points. A customer pilot narrows one of them to named participants, an approved Skill, a specific decision window and an explicit disclosure boundary. ## What stays the same across every loop Every use case uses the same Protocol 1.0 envelope, identity binding, Package and Response lifecycle, signed policy evidence, recipient receipt, thread semantics and ciphertext-safe audit model. The scenario Skill changes the shared business meaning and allowed fields; it does not replace the protocol. One Package uses one transport path. Native Mode stores one encrypted Package in Supply-Y. Catena-X Mode moves the Package through the participants' EDC data plane while Supply-Y stores references and audit evidence, not a duplicate payload. ## From representative fixture to pilot A passing fixture proves that the intended object shape and scenario rules are executable. It does not prove that a customer's data mapping, Agent, KMS, EDC connector or operating process is ready. Start with fictional or sanitized data in the [Protocol Playground](/docs/playground), open the matching 3D loop, and then use [Plan a Managed Pilot](/docs/pilot) to define customer-specific responsibilities, stage gates, acceptance evidence and exit rules. ## Six representative loops Compare the business problem and first acceptance criteria at a glance. Expand any loop to inspect its complete participant sequence and success criteria, then open the exact 3D scenario or source fixture. ## Material Risk Collaboration Loop A Tier 3 material supplier sees a constrained material family for the next 6 to 8 weeks, but cannot disclose customer names, exact capacity or allocation formulas. - **Mode:** risk - **Participants:** Brand OEM -> Tier 1 -> Tier 2 -> Tier 3 - **Transport:** Native + Catena-X - **Scenario:** `scenario_material_constraint_001` - **Thread:** `thread_material_constraint_01` - **Interactive demo:** [Open this 3D loop](https://supply-y.net/demo?scenario=material-risk) - **Source fixture:** [`fixtures/scenarios/material-constraint.json`](https://supply-y.net/docs/reference#fixtures-scenarios-material-constraint-json) ### Expected loop 1. Tier 3 sends material_constraint_reasoning to Tier 2 2. Tier 2 responds with component_impact_response 3. Tier 1 requests OEM priority decision 4. OEM provides priority ranking 5. Tier 1 forwards only the allowed priority class back to Tier 2 for upstream recovery planning 6. Network Story summarizes agreed facts, unresolved questions and next actions ### Success criteria - No raw customer data leaves the sender - Every package has a Policy Envelope - Human approval is required before external send - OEM priority is propagated as a safe class token rather than raw volume or program strategy - Every lifecycle transition emits an audit event - Network Story can be read by nontechnical reviewers ## Weekly Demand and Capacity Alignment The OEM forecast shifts for the next 8 weeks and suppliers need to respond with safe capacity ranges rather than raw planning data. - **Mode:** planning - **Participants:** Brand OEM -> Tier 1 -> Tier 2 -> Tier 3 - **Transport:** Native - **Scenario:** `scenario_weekly_alignment_001` - **Thread:** `thread_weekly_alignment_01` - **Interactive demo:** [Open this 3D loop](https://supply-y.net/demo?scenario=weekly-alignment) - **Source fixture:** [`fixtures/scenarios/weekly-alignment.json`](https://supply-y.net/docs/reference#fixtures-scenarios-weekly-alignment-json) ### Expected loop 1. OEM sends demand_change_reasoning 2. Tier 1 responds with capacity_response 3. Tier 2 adds component-level context 4. Tier 3 replies with material-range evidence 5. Tier 1 returns a consolidated feasible plan to the OEM 6. Participants close the loop with a Network Story update ### Success criteria - Demand shift is expressed as a controlled reasoning object - Capacity is shared as range or confidence band - Supplier constraints are summarized into an executable OEM-facing plan - Responses update the Loop Thread - The story can be replayed from audit events ## Incident Mitigation War Room A Tier 2 connector production incident appears and multiple supply-chain parties need to mitigate together without broadcasting customer exposure, exact recovery capacity, commercial penalties or allocation formulas. - **Mode:** incident - **Participants:** Brand OEM -> Tier 1 -> Tier 2 -> Tier 3 - **Transport:** Native - **Scenario:** `scenario_incident_mitigation_001` - **Thread:** `thread_incident_mitigation_01` - **Interactive demo:** [Open this 3D loop](https://supply-y.net/demo?scenario=incident-mitigation) - **Source fixture:** [`fixtures/scenarios/incident-mitigation.json`](https://supply-y.net/docs/reference#fixtures-scenarios-incident-mitigation-json) ### Expected loop 1. Tier 2 sends incident_alert to Tier 1 2. Tier 1 escalates impact_notice to Brand OEM 3. Brand OEM replies with mitigation_priority_decision 4. Tier 1 sends mitigation_plan to Tier 2 5. Tier 2 asks Tier 3 for recovery_support 6. Tier 3 replies with recovery_commitment 7. Tier 1 returns a mitigation_status_story to Brand OEM 8. Network Story summarizes mitigation status, open questions and next actions ### Success criteria - Incident impact is shared at bounded family or priority-band level - OEM priority is returned as protected guidance - Recovery commitments are expressed as ranges and confidence bands - Sensitive commercial and customer exposure details stay hidden - Every participant contributes to the loop rather than only receiving a broadcast - The final incident status is readable by management without exposing supplier incident records ## Quality Containment and Lot Trace A Tier 2 connector lot shows a quality defect signal and the network needs to contain affected assemblies, trace material genealogy and narrow quarantine scope without exposing raw inspection logs, customer fallout or supplier process IP. - **Mode:** incident - **Participants:** Brand OEM -> Tier 1 -> Tier 2 -> Tier 3 - **Transport:** Native + Catena-X - **Scenario:** `scenario_quality_containment_001` - **Thread:** `thread_quality_containment_01` - **Interactive demo:** [Open this 3D loop](https://supply-y.net/demo?scenario=quality-containment) - **Source fixture:** [`fixtures/scenarios/quality-containment.json`](https://supply-y.net/docs/reference#fixtures-scenarios-quality-containment-json) ### Expected loop 1. Tier 2 sends quality_alert to Tier 1 2. Tier 1 sends containment_notice to Brand OEM 3. Brand OEM replies with stop_ship_decision 4. Tier 1 sends containment_plan to Tier 2 5. Tier 2 asks Tier 3 for lot_trace evidence 6. Tier 3 replies with trace_evidence_response 7. Network Story summarizes quarantine scope, release conditions and open quality actions ### Success criteria - Defect signal is shared as lot family, confidence and containment action rather than raw inspection rows - OEM containment decision is forwarded as a protected class token - Tier 3 trace evidence is reduced to genealogy hash, release status and forwardable summary - Customer-specific failure counts, process recipes and commercial exposure remain hidden ## Engineering Change and Substitute Approval A Tier 3 material substitute needs to move through component, harness and OEM approval gates while each party exposes validation evidence and decision scope without revealing formulas, prices, volumes or program strategy. - **Mode:** planning - **Participants:** Brand OEM -> Tier 1 -> Tier 2 -> Tier 3 - **Transport:** Native - **Scenario:** `scenario_engineering_change_001` - **Thread:** `thread_engineering_change_01` - **Interactive demo:** [Open this 3D loop](https://supply-y.net/demo?scenario=engineering-change) - **Source fixture:** [`fixtures/scenarios/engineering-change.json`](https://supply-y.net/docs/reference#fixtures-scenarios-engineering-change-json) ### Expected loop 1. Tier 3 sends substitute_material_proposal to Tier 2 2. Tier 2 sends component_change_request to Tier 1 3. Tier 1 sends engineering_approval_request to Brand OEM 4. Brand OEM replies with conditional_approval 5. Tier 1 forwards approved_change_instruction to Tier 2 6. Tier 2 sends qualification_plan to Tier 3 7. Network Story summarizes approval scope, required gates and open qualification evidence ### Success criteria - Engineering properties and risk bands can be shared without exposing material formula IP - OEM decision is represented as conditional approval plus forwardable test gates - Supplier execution packet contains only trial scope and evidence requirements - Every approval and gate can be traced back to the originating change request ## Compliance and Sustainability Evidence An OEM requests sustainability, origin and product carbon evidence for a harness family. Suppliers must return decision-ready attestations, bands and hashes without exposing sourcing maps, process energy contracts, costs or unrelated customer data. - **Mode:** risk - **Participants:** Brand OEM -> Tier 1 -> Tier 2 -> Tier 3 - **Transport:** Native + Catena-X - **Scenario:** `scenario_compliance_evidence_001` - **Thread:** `thread_compliance_evidence_01` - **Interactive demo:** [Open this 3D loop](https://supply-y.net/demo?scenario=compliance-evidence) - **Source fixture:** [`fixtures/scenarios/compliance-evidence.json`](https://supply-y.net/docs/reference#fixtures-scenarios-compliance-evidence-json) ### Expected loop 1. Brand OEM sends sustainability_evidence_request to Tier 1 2. Tier 1 sends component_evidence_query to Tier 2 3. Tier 2 sends origin_attestation_query to Tier 3 4. Tier 3 replies with material_evidence_response 5. Tier 2 replies with component_compliance_summary 6. Tier 1 returns OEM_evidence_package to Brand OEM 7. Network Story summarizes complete evidence, provisional evidence and open certificate refresh ### Success criteria - Compliance evidence can move as status, bands and certificate hashes - Sub-supplier names, mine routes, energy contracts and cost models remain hidden - OEM receives a decision-ready evidence package rather than raw supplier records - Catena-X style evidence exchange can be reviewed without committing to real integration --- Canonical HTML: [Representative Use Cases](https://supply-y.net/docs/use-cases) Agent documentation index: [llms.txt](https://supply-y.net/llms.txt)