When a shipped MCP breaks, what happens and who fixes it?

Two paths lead to a Repair Blueprint: (1) a managed monitoring run detects endpoint, schema, tool or version drift against the shipment baseline, or (2) a creator directly reports a defect on an already-shipped product. Both route to the same REPAIR station.

OBSERVATION -> drift detected -> REPAIR_RECOMMENDED
REPAIR -> repair_blueprint_receipt (root_cause_hypothesis)
(creator owns the fix) -> new commit
REVERIFICATION -> reverification_receipt (new build)
RESHIPMENT -> new shipment manifest, same product lineage
OBSERVATION -> resumes

A duplicate incident matching an existing case's dedup key (product_id + failure_classification + affected_surfaces) groups into that one case — it never forks a parallel case for the same underlying problem.

A fixed 12-field record: observed_fact, timestamp, product_version, evidence_refs, reproduction_procedure, expected_vs_observed, affected_surfaces, failure_classification, confidence, candidate_causes, recommended_direction, prohibited_out_of_scope.

This is a hard, repeated rule, not a preference: SaSame proposes a Repair Blueprint; it never silently edits creator code. The creator executes the actual repair. A Repair Blueprint is not actioned until the creator explicitly accepts or rejects it — a rejected or ignored blueprint stays open, it is never silently closed as resolved. A creator-submitted fix creates a new version lineage entry; it never overwrites the prior, failing version.

Reverification re-runs the identical inspection contract used at first shipment — the "before/after" test contract stays the same unless a migration is explicitly justified and recorded, never silently relaxed.

An unknown result on a blocking layer is never silently counted as pass or fail — it routes to manual review instead. Every inspection and reverification receipt carries a fixed forbidden-word list (safe, trusted, approved, endorsed, recommended, malware-free, malware scan, certified-safe) — the record states only what was measured.

A successful reverification automatically triggers reshipment and a distribution update. A failed reverification returns to the creator with the new evidence — never reported as a false completion. This is enforced at the data layer, not just by convention: a reshipped-resolved state requires a passing reverification result to exist first, and at most one active repair case can exist per product/failure-classification pair at a time.