Use the supervised recovery exchange when the ConfigSheets producer must connect or re-establish its order feed. Have the responsible producer's recovery request, an active KitProof release containing the intended source map, and agreement to stop that producer during review. This is separate from activating a changed job revision.
Protect the intended source
As Supervisor, open Jobs and Connect or recover a ConfigSheets feed. Obtain the recovery-request JSON through the producer's Data workflow. Check its organisation, existing order source and producer identity before choosing it in ConfigSheets recovery request.
Read and tick the declaration only after checking those facts and stopping the producer. Complete recent Accounts verification, then choose Protect source and prepare checkpoint.
This records a new import generation for that source. Previous protected bundles, ordinary CSV files and their open previews are refused for it. Existing jobs, pending source changes and kit checks remain as they were. Protecting the feed does not cancel or recheck physical kits.
Return the exact checkpoint
Download the checkpoint offered for that protected source and return it to the responsible ConfigSheets team through the agreed controlled file exchange. The exchange is supervised; the files are not digitally signed. Check the source, organisation and request history rather than treating a filename as proof of origin.
The checkpoint describes KitProof's retained jobs and revisions for the source, including the binding needed for the next protected bundle. The producer reviews refreshed input against it and prepares its new protected bundle. Do not edit the checkpoint or rebuild it manually from an old export.
Resume through normal intake
Select the new protected ConfigSheets bundle under Order CSV or protected ConfigSheets bundle and choose Preview upload. Review and accept it through normal job intake.
Protection is not a way to bypass the job source map, revision rules or whole-file validation. A higher job revision still needs its normal source-change decision and physical dispositions. Old CSV cannot be used as a fallback for a protected source simply because it looked valid before recovery.
Handle a refused or interrupted exchange
The request must match the current organisation, active source map and established producer. A changed producer identity, producer generation behind the retained one, changed receiving state or oversized checkpoint needs reviewed correction with the source team.
For an interrupted protection response, inspect the protected-source/checkpoint entry on Jobs and keep the original request file. Repeating the same unchanged request can return its retained current checkpoint; reusing its request identity with changed content is refused. A later protection or changed receiving state can make an earlier checkpoint stale. Do not invent a new source namespace or request identity to avoid that disagreement.