The Anthropic prompting playbook, for reliability.

You are a reliability engineer. Build a FMEA for this asset, following IEC 60812.

Asset: [centrifugal pump, cooling-water service, VFD-driven, 75 kW]
Duty: [continuous, criticality A - safety and production]
Context: [paste operating conditions and failure history]

Work function by function. For each function, break every row into:
- Failure mode: HOW the function fails, written as a consistent noun-phrase (e.g. "loss of containment", "fails to start", "degraded flow"). One mode per row. Never fold the cause or the mechanism into the mode.
- Failure mechanism: the physical/chemical process behind it (fatigue, cavitation, corrosion, wear, erosion...).
- Cause: the root trigger of that mechanism.
- Effects at three levels: local, on the system, and on the plant / end user.
- Current controls: how it is detected or prevented today.
Then Severity, Occurrence, Detection.

Rules:
- Keep failure-mode wording consistent across the whole sheet - same style and verb form throughout.
- Do NOT invent S, O or D ratings. Where you lack data, leave the cell blank, mark it an assumption, and list the exact field data (failure history, run hours, inspection records) needed to score it.
- Give a one-line engineering justification for each failure mode.

WhyAsset context (rule 1) + a hard ban on invented ratings and a demand for justification you can check (rule 4).

Act as an RCA facilitator. Here is the event:
- What failed: [DE bearing on fan 12-FN-03]
- When and symptoms: [paste]
- Evidence collected: [vibration, temperature, photos, work history]

Build a cause-and-effect logic tree, not a 5-Whys shortcut. Rules:
- Start from the failure event, then branch downward. Each level answers "what had to be true for this to happen?"
- Carry every branch through all three root types: physical (the mechanism), human (an error or decision), and latent/systemic (the process, standard or gap that allowed it).
- For each node, state the evidence that supports it. No evidence = mark it a hypothesis to verify, and name the test or record that would confirm or kill it.
- Stop each branch at a cause we can actually control.

Work only from the evidence I gave you. When you have enough to point to the most likely root(s), say so and stop - don't pad the tree with generic causes.

WhyFull incident context (rule 1) + act on the evidence you have, flag what's missing, don't over-branch (rule 3).

Here is my asset list with each item's function, duty and consequence of failure: [paste or attach].

Score each asset on my risk matrix: consequence x likelihood.
- Consequence: score the worst credible outcome across safety, environment, production/output and cost - and name which one drives it.
- Likelihood: base it on the failure history / MTBF in the data, not a guess. Flag where the history is too thin to trust.
- Adjust for redundancy and detectability: an asset with a standby or clear warning signs is lower risk than a hidden single point of failure.

Return a ranked table: asset, consequence score, likelihood score, overall criticality band (A/B/C), and the single driving consequence.

Keep it tight - the ranking and the reason, no methodology essay.

WhyA short instruction, because the attached context does the steering (rule 6), grounded in your real asset data (rule 1).

Attached is 24 months of work-order history (asset, date, failure code, downtime hours, cost).

Find the bad actors - the roughly 20% of assets driving most of the pain. Rules:
- Rank three ways, because they surface different offenders: by failure frequency, by total downtime, and by total cost.
- Separate the chronic (fails often, small each time) from the acute (rare but catastrophic) - they need different fixes.
- Where run-hours are available, normalise (failures per 1,000 running hours) so a hard-worked asset isn't unfairly flagged.
- Group by failure code so a repeat mode stands out.

Cite the records behind each number. Where a field is blank, don't guess - tell me how many records you dropped and why.

WhyGrounded in the real export (rule 1) + prove it by citing rows and reporting dropped data instead of guessing (rule 4).

Here are the times-to-failure and the suspensions (censored units still running): [paste].

Fit a Weibull distribution. Rules:
- Include the suspensions - don't discard censored units, they carry information.
- Use median-rank regression for a small sample, MLE for a larger one, and tell me which you used and why.
- Report beta (shape) and eta (characteristic life, 63.2%). Interpret beta plainly: <1 infant mortality, ~1 random, >1 wear-out - and say what that implies for the maintenance strategy.
- Give B10 and B50 life only within the range the data supports.
- Show the probability plot with the points so I can sanity-check the fit, and comment on goodness of fit.

Do not extrapolate beyond the data. If the sample is too small to trust (say, fewer than ~5-6 failures), tell me that instead of handing me a confident number.

WhyShow the fit and handle censoring = evidence (rule 4) + an explicit "don't extrapolate, flag a weak sample" fence (rule 2).

Using RCM logic per SAE JA1011 and the failure modes I've listed for [asset], select a maintenance task for each mode.

For each failure mode:
- First classify the consequence: hidden, safety/environmental, operational, or non-operational.
- Then apply the task-selection logic in order:
  1. On-condition (predictive) if there's a detectable P-F interval long enough to act on.
  2. Scheduled restoration or discard if there's an age-related wear-out point and it's effective.
  3. Failure-finding for hidden failures, with a stated interval.
  4. Run-to-failure only if no task is worth doing AND the consequence allows it.
- State the task and its interval.

Do NOT default to calendar-based tasks where an on-condition task applies. Do NOT leave a hidden failure without a failure-finding interval.

For each choice, give the one-line engineering reason it fits - the mechanism and the JA1011 criterion. I want the justification, not your internal reasoning.

WhyHard fences against the two classic RCM mistakes (rule 2) + ask for the engineering reason, not the model's internals (rule 5).

Attached is the OEM manual for [asset]. Build a preventive maintenance routine from it.

For each task give: task, frequency, craft/skill, estimated duration, parts/consumables, and any safety/isolation (LOTO) note. Return it as a table.

Rules:
- Every task must trace to a specific manual section - cite the page or clause.
- Mark each task condition-based or time-based (condition-based wherever the manual says inspect-then-act).
- Consolidate duplicates and group by frequency so the routine is actually runnable on the floor.
- If the manual gives no frequency, mark it "OEM-silent" and flag it for engineering judgement - do not invent an interval.

WhyGrounded in the actual manual (rule 1) + every task cited to its source, no invented intervals (rule 4).

Here are my parts with lead time, unit cost, usage history and the criticality of the asset each one serves: [paste].

Recommend a min/max for each. Rules:
- Min (reorder point) = expected demand over the lead time + safety stock. Size the safety stock from criticality and lead-time variability, not a flat rule.
- Flag insurance spares separately: a critical, long-lead item can justify holding one even at near-zero usage, because a stockout stops production.
- Classify each part: stock on-site, order on demand, or insurance spare.
- Give the recommendation with one line of reasoning. When the data is enough to decide, decide - don't ask me for a policy I haven't set.

Do not recommend stocking everything: explicitly call out the cheap, fast-lead, low-criticality parts we should NOT hold.

WhyAct and recommend once the data supports it, don't over-ask (rule 3) + an explicit "don't over-stock" fence (rule 2).

Turn the analysis below into a half-page memo for a plant manager who is not a reliability specialist.

- Open with the bottom line: the decision and the number - what it's costing us now and what we should do.
- Then three bullets of evidence, strongest first.
- Then the ask: the decision, budget or approval you need, and by when.

No RCM jargon, no method lecture. Under 200 words. Plain language a non-engineer will act on.

[paste the analysis]

WhyA lean, outcome-first instruction (rule 6) + tell it what to leave out: jargon and length (rule 2).

Attached is a [pump] OEM manual (PDF). Extract every maintenance action into a table: task, interval, craft, tools/parts, safety note, and the exact source (section and page).

Rules:
- Only include tasks actually written in the manual - quote the sentence you took each one from.
- Normalise intervals to a consistent unit (hours or months) and keep the original wording in a note.
- Keep anything you infer rather than quote in a separate "inferred" list, so I can review it apart from what's sourced.
- Flag ambiguous or conflicting instructions instead of resolving them silently.

WhyGrounded in the manual (rule 1) + quote the source and split inferred from sourced so you can trust it (rule 4).