Synthetic Industry

Inspectable example · updated 2026-10-10

Example evidence packet for a one-job CI repair

An inspectable synthetic handover outline that distinguishes a real executed pass from skipped checks or an unrelated green run.

An example, not a customer case study. Scope and evidence limitations are described below.

This is a synthetic packet, not client proof

Suppose one Linux build job cannot find the application's package script because its working directory is wrong. The following outline shows the evidence a buyer should receive. It contains no real run, claimed repair, measured duration or customer result. Replace every field with actual authorised-run evidence before treating a packet as delivered work.

  • Request: repair the named build job; preserve its trigger, tests and runner configuration.
  • Baseline: failed run link, attempt, job ID, event, source revision, working directory and redacted first-error excerpt.
  • Change: the specific workflow-file diff and explanation of why the command ran in the wrong directory.

Acceptance record

Record the after-run link, executed job conclusion and same-context comparison beside the baseline. For a pull_request event, record the tested merge SHA as well as the branch head. If a matrix is involved, name the agreed configuration; a different matrix member passing is not evidence that the failing one was repaired.

  • The command executes and completes; skipped, neutral and continue-on-error results are not a pass.
  • The reviewer checks that no assertion, quality threshold or trigger was weakened.
  • The customer can inspect the complete changed-file list and approve the merge.

Limits and reversal

The packet states what was not tested: other jobs, other runners and any production deployment. Before merge, closing the pull request leaves the default branch unchanged. After merge, a maintainer can revert the named change under the repository's rules; reverting a workflow file does not undo external side effects from a run.

  • List independent review findings and unresolved exclusions.
  • Name who is authorised to merge and who would deploy.
  • Keep acceptance and payment evidence separate from the technical run result.

Use this outline when requesting a repair

Ask the provider to name the original failure and prove the same job ran successfully. If the only evidence is a screenshot of a green badge, ask for the run, job, event and revision. The outline is a checklist to use with an actual repair, not a runnable fixture or a delivered project.

Sources and limits