A plant manager asking “why is the night shift behind on quality” doesn’t want a dashboard. They want the answer, in a sentence, with enough behind it to act on. Ask your factory is built to be that box: type the question in plain words, get an answer pulled from the same live data every screen in Spall already shows, with the records it used listed right next to it.
The point isn’t the chat interface. It’s that the answer is grounded in something you can check. Every response names its sources, a downtime table, a set of logbook notes, the same $-ranked opportunity board the Opportunities page shows, so a manager who doesn’t fully trust the sentence can go look at the record behind it.
How a question gets answered
A question first gets matched to the slice, or slices, of data most likely to hold the answer: maintenance, downtime, quality, shift performance, money, jobs, fleet health, alerts, and a few more. A narrow question, “what maintenance tickets are open,” pulls one slice. A broad question, one with “why,” “biggest,” “worst,” or “compare” in it, pulls several at once, because a question like that is asking for a comparison across reasons, shifts, and cost, not a single table.
That routing step matters because it’s what keeps the answer from free-associating off the words in the question. The system doesn’t ask a model to imagine what a downtime number might be. It pulls the actual downtime table for the actual time window, hands that to the model as the only material it’s allowed to answer from, and the model’s job is to summarize what’s in front of it, not invent something plausible.
Twenty questions, and what each one cites
Downtime and cost. “What’s our biggest cost this week?” cites the same dollar-ranked opportunity board the Opportunities page shows, so the number in the sentence matches the number you’d see on screen. “Which asset is losing us the most money?” and “what are the top reasons Press 3 goes down?” cite the downtime table by reason and asset. “Is our downtime data reliable right now?” cites what share of stops carry a reason code versus none at all, so the answer can say a ranking is thin before you act on it.
Rate and pace. “How is Press 1 running against its target?” cites the resolved ideal rate, whether that target came from the job currently running or the machine’s own nameplate speed, and says plainly when no target is configured anywhere instead of making one up.
Quality. “What’s our first-pass yield this week?” and “what’s the top defect reason on the Fanuc line?” cite the quality table broken out by asset and reason.
Shift performance. “How’s the shift in progress doing?” and “which shift is falling behind?” cite live shift totals. “Which shift and machine combination is losing the most time, and is it getting worse?” crosses those two dimensions, a question the shift table alone can’t answer and the asset table alone can’t either, so both get pulled together.
Maintenance. “What repairs are open right now?” and “what got fixed on the mill this week, and how?” cite open and recently resolved work items, including the notes people actually wrote on them, credited by role rather than by name.
The logbook. “What did the second shift supervisor flag last night?” cites recent shift-log notes, which can carry the name of whoever wrote them since a logbook entry is a record of what a person reported, not a ranking of people.
Jobs. “What’s on the board right now, and what’s behind?” cites the live dispatch and job records.
Fleet health. “Is any gateway offline, and since when?” and “why does Line 2’s data look stale?” cite connectivity and clock-sync status.
Alerts. “What’s open right now?” cites live alert state.
Cross-cutting. “Why is scrap up on nights?” is deliberately broad. It pulls shift, quality, and downtime together, because a real answer to “why” usually needs more than one table to say something true.
What it says when it can’t answer
A question about something the platform doesn’t track, energy cost per part when no energy meter is wired up, labor cost, anything outside what Spall actually measures, gets a plain “the data doesn’t cover that” instead of an estimate built on nothing. A question about a downtime window where most stops carry no reason code gets an answer that says so up front instead of ranking causes as if every stop had been labeled. A rate question about a machine with no target configured anywhere shows its real rate and says plainly that no target exists, instead of picking one without telling you.
If AI answers aren’t turned on for your account, the screen says that directly and nothing else on Spall changes. Monitoring, alerts, and every dashboard work exactly the same with or without it. A skeptical plant manager doesn’t have to take the sourcing on faith either: the same downtime, quality, and shift tables the answer cites are the ones already rendered on the Opportunities, Historian, and Reports screens, so checking a cited figure means opening a screen you already use, not learning a new one.
A question that spans two shifts of history, “how did nights compare to days last week,” behaves the same way as a single-shift question: the shift class pulls both, and the answer states each shift’s own numbers side by side instead of averaging them into one figure that would hide which shift actually drove the difference. That’s a small design choice with a real consequence: a plant manager reading the answer gets the comparison they asked for, not a blended number that answers a slightly different question than the one they typed.
Why the sourcing is the point
A number without its source is a claim. The same number with a table cited next to it is something a shift supervisor can check before a meeting instead of during one. That’s the actual design goal here, not a chat box that sounds confident, an answer a skeptical plant manager can verify in under a minute. How to Read an Insight Card covers the same discipline applied to the automated findings the AI surfaces on its own, before anyone asks it a question.
Quick recap
- A question gets matched to the live data slice, or slices, most likely to hold the answer, downtime, quality, shift, money, maintenance, and more, before anything gets written.
- A broad question (“why,” “biggest,” “compare”) pulls multiple slices together, since a real answer to “why” rarely lives in one table.
- Every answer names its sources: the exact table, note set, or board it drew from, so it can be checked, not just believed.
- A question the platform doesn’t track gets “the data doesn’t cover that,” not an invented number.
- Thin or uncoded downtime data gets flagged in the answer itself, instead of a confident-looking ranking built on gaps.