How Do You Prompt-Engineer a Custom OEE Dashboard for Your Machines?

Short answer: define the OEE math explicitly in the prompt rather than letting the model infer it, pull machine states from your monitoring platform's API instead of recalculating from raw signals, and add explicit guard rules for the edge cases where efficiency math silently goes wrong. OEE is deceptively easy to get almost right — the formula is three factors multiplied together, which any model can reproduce from memory. The problem is that "almost right" OEE is worse than no OEE at all, because a plausible-looking number gets trusted and acted on. This article covers how to prompt for a dashboard that computes it correctly, and the specific constraint rules that prevent the errors models reliably make.

Copy this prompt to get started

Paste this into Claude (Opus handles the multi-step math validation more reliably on the first pass; Sonnet is fine for iterating afterward):

Act as a senior manufacturing solutions architect. Build a production-ready OEE dashboard component that fetches machine states from a monitoring platform REST API and calculates OEE on the fly, highlighting bottleneck workcenters.

Follow these rules exactly:

1. Do not invent the OEE formula from memory. Use: Availability = Run Time / Planned Production Time; Performance = (Ideal Cycle Time × Total Count) / Run Time; Quality = Good Count / Total Count; OEE = Availability × Performance × Quality.
2. Never allow any factor to exceed 1.0 — if it does, that indicates a data problem. Surface it as a warning, do not clamp it silently.
3. Handle division by zero explicitly for every ratio. Return null and a reason string, never 0 or 100%.
4. Treat "no data received" as distinct from "machine stopped." Do not include no-data periods in Planned Production Time.
5. Use exact decimal arithmetic or explicit rounding only at the display layer — never round intermediate factors.

Ask me clarifying questions about my API's response shape before writing the fetch logic.

Contents:

1. Why OEE math goes wrong when a model writes it
2. Pull, don't recalculate: the first architectural decision
3. Defining the math explicitly in the prompt
4. The guard rules that prevent silent errors
5. Prompting for resilient JSON parsing
6. Bottleneck detection: the part worth building custom
7. Validating the output before anyone trusts it
8. Common pitfalls
9. Frequently asked questions
10. Conclusion

Why OEE math goes wrong when a model writes it

Ask any capable model to "calculate OEE" and it will produce something that looks correct: three factors, multiplied, formatted as a percentage. The failure modes are subtler than a wrong formula:

• Ambiguous definitions get resolved arbitrarily. Is "Planned Production Time" scheduled shift hours minus planned breaks, or total calendar time? Both are defensible; a model will pick one silently, and the resulting number can differ by tens of percentage points.
• Edge cases return plausible numbers instead of errors. A machine with zero run time in a period produces a division by zero. Unguarded, that often becomes 0%, 100%, or NaN rendered as something harmless-looking rather than an explicit "insufficient data."
• Factors above 100% get quietly clamped. Performance over 1.0 almost always means the ideal cycle time is wrong, not that the machine is superhuman. Clamping it to 100% hides a real data problem.
• Rounding compounds. Rounding each factor to two decimals before multiplying produces a different OEE than rounding once at the end — small, but enough to make two systems disagree and erode trust in both.

None of these produce errors or crashes. They produce numbers, which is exactly what makes them dangerous. The whole point of prompt-engineering this carefully is that the failure mode you're defending against is silent plausibility.

Pull, don't recalculate: the first architectural decision

Before writing any math at all, decide whether you should be writing it. If your monitoring platform already computes OEE with validated logic, tested against real production data, the better architecture is to fetch that computed value through the platform's API and build your custom visualization on top of it — not to recompute it independently from raw signals.

The reason is organizational, not technical: two systems computing the same metric with slightly different definitions produce two different numbers, and the ensuing "which OEE is the real one" conversation costs more than the dashboard saved. Recalculate only when you genuinely need a definition the platform doesn't offer — a different shift model, a custom exclusion, a what-if scenario — and when you do, make the difference explicit in the UI so nobody mistakes it for the official figure.

Defining the math explicitly in the prompt

If you are computing OEE yourself, the single highest-value thing you can do is refuse to let the model use its memory of the formula. Specify every term, including the ones that feel obvious. Our guide on measuring OEE in practice covers the formula itself in depth; what matters for prompting is that each variable has exactly one definition in your context:

Use these definitions and no others. Planned Production Time = scheduled shift duration minus scheduled breaks and planned maintenance windows. Run Time = Planned Production Time minus all unplanned stop duration. Ideal Cycle Time = the per-part standard I supply, not a value derived from historical averages. Total Count = all parts produced including scrap. Good Count = Total Count minus scrap and rework. If any of these are missing from the data, return an explicit error naming which one — do not substitute a default.

That last clause is the important one. Models are strongly biased toward producing an answer, and in the absence of an input they will often infer a reasonable-seeming substitute rather than failing loudly. For a metric that drives investment decisions, failing loudly is the correct behavior.

The guard rules that prevent silent errors

These are the constraints worth including in every prompt that touches OEE math, and worth asserting in the generated code itself rather than trusting the model to have honored them:

• No factor above 1.0. Availability, Performance, or Quality exceeding 100% is a data problem — usually a wrong ideal cycle time or a miscounted part total. Surface it as a visible warning on the affected machine, not a clamped value.
• No implicit zero-substitution. Every ratio needs an explicit zero-denominator branch returning null plus a reason, so the UI can render "insufficient data" rather than a misleading 0%.
• No-data periods excluded, not zeroed. A period where the machine wasn't reporting isn't downtime — it's unknown. Including it as downtime understates Availability and quietly punishes machines with connectivity issues. This is the same distinction covered in our piece on shop floor data quality.
• Rounding only at display. Keep full precision through the calculation chain; format once, at render time.
• Timezone-explicit period boundaries. Shift boundaries computed in the wrong timezone shift every duration in the calculation. Require explicit timezone handling rather than server-local defaults.

A useful follow-up prompt once code exists:

Write unit tests for the OEE calculation covering: zero run time, zero total count, Performance computing above 1.0, a period with no telemetry at all, and a shift crossing midnight. For each, assert the function returns an explicit error or warning rather than a numeric result.

Prompting for resilient JSON parsing

API responses are the other reliable source of silent failure. Models tend to write parsing code that assumes the happy path: every field present, every type as expected, every machine in the response. Real API responses have optional fields, nulls where numbers are expected, and machines that disappear between calls.

Parse the API response defensively. Validate types explicitly rather than assuming them. If a machine record is missing a field required for OEE, exclude that machine from the aggregate and list it in a "machines excluded from calculation" section with the reason. Never let a single malformed record break the whole dashboard render.

The "excluded machines" pattern is worth adopting generally: it makes data gaps visible rather than making the aggregate quietly wrong, which is the difference between a dashboard people can trust and one they eventually stop believing.

Bottleneck detection: the part worth building custom

Straight OEE per machine is something most monitoring platforms already show. The custom logic that actually justifies building your own view is usually the interpretation layer — specifically, identifying which workcenter is constraining the line rather than just which has the lowest number.

A machine at 60% OEE that nothing downstream depends on matters less than one at 85% that everything queues behind. Prompting for this means supplying the relationship structure the platform doesn't know about:

Given this workcenter sequence [supply your line structure], rank workcenters by constraint impact rather than raw OEE. Weight each machine's losses by its position in the flow and its downstream dependency count. Show the top three constraints with the specific loss category (availability, performance, or quality) contributing most to each.

That last requirement — naming which of the three factors dominates a given machine's loss — is what turns a dashboard from a scoreboard into something that suggests where to act.

Validating the output before anyone trusts it

• Reconcile against the platform. If your monitoring platform also computes OEE, compare your custom figure against it for the same period and machine. Differences should be explainable by a deliberate definition choice, not a mystery.
• Sanity-check against the floor. Ask someone who was on shift whether the reported downtime matches what they remember. Machine data that contradicts operator memory usually means a state-detection or definition problem.
• Test with a known-bad period. Pick a shift where something clearly went wrong and confirm the dashboard reflects it. A dashboard that shows healthy numbers during a known bad shift is worse than useless.
• Check the boundaries. Run the calculation for a period spanning a shift change, a weekend, and a planned maintenance window — these are where period-definition errors surface.

Common pitfalls

• Deriving ideal cycle time from historical averages. This bakes existing inefficiency into the baseline, making Performance look better than reality and hiding the exact losses OEE is meant to reveal.
• Averaging OEE across machines. A simple mean of machine-level OEE values is not line OEE and can be badly misleading, particularly across machines with very different cycle times or utilization.
• Assuming Quality is 100% because scrap data isn't connected. Defaulting an uninstrumented factor to perfect silently inflates the headline number — better to show OEE as incomplete than confidently wrong.
• Letting the model choose the period boundaries. "Last 24 hours" versus "yesterday's shifts" produce meaningfully different numbers; specify which, explicitly.
• Shipping without reconciliation. A custom OEE figure that has never been compared against a known reference is a number nobody should be making decisions on yet.

Frequently asked questions

Should I calculate OEE in the dashboard or pull it pre-calculated from the monitoring platform?

Pull it pre-calculated whenever the platform's definition fits your needs — it preserves a single source of truth and avoids two systems reporting different numbers for the same metric. Calculate custom only when you genuinely need a definition the platform doesn't offer, and label it clearly as a custom figure when you do.

Why does my prompt-generated OEE differ from my platform's OEE?

Almost always a definition difference rather than a math error: different treatment of planned downtime, different shift boundaries, a different ideal cycle time source, or different handling of no-data periods. Reconciling the two usually means comparing definitions line by line, not debugging the arithmetic.

Which Claude model is better for this kind of calculation-heavy work?

Opus tends to be more reliable on the initial pass for multi-step math with edge-case handling, which is exactly the risk area here. Sonnet is a good faster choice for subsequent UI iteration once the calculation logic is written and tested.

How do I stop the model from "fixing" my OEE definitions to match what it thinks is standard?

State explicitly that your definitions override its training, and ask it to flag disagreement rather than silently correcting: "If you believe any definition I've given is non-standard, say so explicitly and wait for confirmation — do not substitute your own." Models are considerably more likely to honor an instruction that gives them a sanctioned way to raise an objection.

Conclusion

A custom OEE dashboard is one of the highest-value things to vibe-code and also one of the easiest to get subtly wrong, because the failure mode isn't a crash — it's a believable number. The defense is specificity: define every term explicitly rather than letting the model infer it, add guard rules that force loud failure over plausible substitution, and reconcile the output against a known reference before anyone starts making decisions on it. Pull pre-computed values where you can; when you do compute your own, make the definitional differences visible rather than hidden.

Related articles:

• How Do You Vibe-Code a Real-Time Shop Floor Dashboard with Claude and Python?
• Measuring OEE in Practice: Formula and Results
• What Machine Signals Matter for OEE
• Feeding Machine Data into Custom Systems via API
• MDCplus Machine Connectivity & Integrations

About MDCplus

Our key features are real-time machine monitoring for swift issue resolution, power consumption tracking to promote sustainability, computerized maintenance management to reduce downtime, and vibration diagnostics for predictive maintenance. MDCplus's solutions are tailored for diverse industries, including aerospace, automotive, precision machining, and heavy industry. By delivering actionable insights and fostering seamless integration, we empower manufacturers to boost Overall Equipment Effectiveness (OEE), reduce operational costs, and achieve sustainable growth along with future planning.