CONTEXT(CLONE)
Sign in

Challenge root-cause reports before they are closed

For: Quality manager or customer quality engineer approving problem-solving reports

Pattern: Adversarial reviewRuns todayDesigned for 4 to 150 agents
Get early accessSign in to use

The pain today

Problem-solving reports are closed under customer deadlines. The stated root cause often does not explain why the defect escaped, or the corrective action does not address the cause. The reviewer has minutes per report.

The ask

“I attached our open problem-solving reports with their evidence attachments as text. For each one, make the best case that the root cause and corrective actions are sound, then attack it: does the cause explain both occurrence and escape, does the evidence support it, do the actions address it? Tell me which reports hold up.”

Plain words, as you would say it to a colleague. Edit it to fit your case before you send it.

What you attach or connect

  • Problem-solving reports as text
  • Supporting evidence and test summaries as text
  • Customer complaint descriptions

The unit of work

One worker task per one problem-solving report.

Why a swarm fits

Reports are independent, and each gets a defender and a challenger with the same small file. The opposed roles surface gaps a single friendly read lets through.

Not for

Finding the true root cause. It tests the argument on paper and has no access to parts, measurements or the process.

The decision tree

6 typed decisions, each with an action for every answer

At fixed moments in a run, the engine puts one narrow question to a decision model. The decision model never writes text: it answers yes or no with a probability, picks from listed options, or gives a score, about a small slice of the material. The engine then does exactly what this tree says, which is what makes the run auditable. The thresholds are the template's design values, not measured results.

  1. Planner, while planning

    Scope checkYes or no, with a probability

    Before work starts on a unit

    Does the report contain a problem description, a stated root cause and at least one corrective action?

    Sees only: The section headings and first lines of one report

    Why: Incomplete reports are returned to their owner instead of being argued over.

    • Yes: 0.60 or higherthenAccept
    • Unsure: 0.30 up to 0.60thenEscalate to a strong model
    • No: below 0.30thenSkip this unit

  2. After workers, the judge checks

    Evidence checkYes or no, with a probability

    After a worker answers

    Does the quoted evidence in the report show the stated cause present on the affected parts or lot, in the report's own data?

    Sees only: The stated cause and the quoted evidence passage

    Why: Tests the defender's case against evidence in the file, not against plausibility.

    • Yes: 0.85 or higherthenAccept
    • Unsure: 0.50 up to 0.85thenEscalate to a strong model
    • No: below 0.50thenReject and retry

  3. Evidence checkA choice among options

    After a worker answers

    Does the report state why the defect was not detected before shipment, separately from why it occurred?

    Sees only: The report's root cause and detection sections

    Why: The escape cause is the part most often missing and the one customers ask about.

    • States an escape cause with evidencethenAccept
    • States an escape cause without evidencethenMark unresolved
    • Silent on escapethenMark unresolved

  4. Evidence checkYes or no, with a probability

    After a worker answers

    Does the quoted corrective action name the same process, tool, parameter or document that the stated root cause names?

    Sees only: The stated root cause and one quoted corrective action

    Why: Finds reports where the action and the cause do not connect.

    • Yes: 0.85 or higherthenAccept
    • Unsure: 0.50 up to 0.85thenEscalate to a strong model
    • No: below 0.50thenReject and retry

  5. Evidence checkYes or no, with a probability

    After a worker answers

    Does the report state how the action's effect was checked, with a date or a result?

    Sees only: The report's verification section

    Why: Flags closures that rest on an action being done rather than shown to work.

    • Yes: 0.85 or higherthenAccept
    • Unsure: 0.50 up to 0.85thenEscalate to a strong model
    • No: below 0.50thenReject and retry

  6. Accountable person, before anything is settled

    Person decidesYes or no, with a probability

    Before anything is reported as settled

    Did any challenge survive, or is the report due to be sent to a customer?

    Sees only: One report's verdict sheet

    Why: The quality manager approves or rejects each report; the swarm only lists what the paper does not show.

    Accountable: The quality manager owns approval or rejection of each report; the customer quality engineer owns what is sent to the customer.

    • Yes: 0.40 or higherthenAsk a person
    • Unsure: 0.15 up to 0.40thenAsk a person
    • No: below 0.15thenAccept

The fleet: who does what

Model tiers by role, not brands: you choose the models. Strong reasoning models plan and reconcile, small fast models do the wide work, and the judge is a decision model from a different family, so it does not share the workers' blind spots.

  1. Planner

    A strong reasoning model sets the challenge checklist: occurrence, escape, evidence, action fit, verification of effect.

    Decisions here:1. Scope check

  2. Workers

    Small fast workers from an open-weight family build the supporting case for one report from its own text.

    Designed for 4 to 150 agents, one worker task per one problem-solving report. Each worker receives only its own unit.

  3. Judge, from a different model family

    Challengers and a decision model from a different family attack each case and rule on which claims the evidence supports.

    Decisions here:2. Evidence check3. Evidence check4. Evidence check5. Evidence check

  4. Reconciler

    A strong reasoning model summarises per report what survived, what fell and what evidence is missing.

  5. Accountable person

    The quality manager owns approval or rejection of each report; the customer quality engineer owns what is sent to the customer.

    Decisions here:6. Person decides

Checked before anything is accepted

  • Every surviving claim cites a passage in the report or its evidence
  • A cause that does not explain the escape is marked incomplete
  • Actions with no stated verification of effect are flagged

What comes back

  • Per-report verdict sheet: supported, unsupported, missing evidence
  • Questions to send back to the report owner
  • Reports where cause and action do not connect
  • Common weaknesses across reports

What to measure

  • Challenges the quality manager agrees with
  • Reports reopened after closure
  • Review time per report
  • Cost per report

Names of measures only. No result is claimed for this template.

Templates open in the workspace chat with the ask filled in. Nothing runs until you send it.

Get early accessSign in to use

More in Manufacturing and quality

Find recurring causes across non-conformance reports

For: Quality manager or continuous improvement lead across several plants or lines

Non-conformance reports are written by many people in free text.

Pattern: Map, verify, reduceNeeds scale6 decisionsDesigned for 40 to 500 agents

Trace failure modes through control plan to work instructions

For: Quality engineer or process engineer preparing for a customer or certification audit

The process failure analysis lists controls, the control plan should carry them, and the work instructions should tell the operator how.

Pattern: Hierarchical decompositionNeeds live models6 decisionsDesigned for 12 to 300 agents