What can AI actually do with my Vorne XL data?

What does asking an AI about your Vorne data actually get you?

One thing, done properly: you type a question about production the way you would say it to a colleague, and you get an answer built out of your own records. Advisor is the part of the suite you talk to. It looks up what your tables and fields mean, writes a read-only query against your production database, runs it, and answers from the rows that came back.

The answer arrives in whatever shape fits the question:

• a sentence or two when the answer is a number
• a chart when a comparison or a trend reads better as a picture
• a sortable, paginated table when there are more rows than fit in a paragraph

Underneath the answer is the part that matters most on a plant floor: the tool trail. It lists what Advisor did to get there, and you can open any step and read it, including the SQL it wrote and the rows that came back. A number you cannot check is a number you cannot act on, so the query is on the screen rather than behind a support ticket.

A conversation keeps its context, so the second question gets shorter. Ask which machines had the most downtime this month, then "now just the top three", "why was Line 16 down", or "chart that", without restating the line or the dates.

Which questions does it answer well?

The ones a supervisor already asks on a Monday morning, where the data exists and somebody normally has to go and pull it:

• What was overall availability yesterday?
• Which machines had the most downtime this month?
• Chart OEE by line for last week.
• Show all devices and their current status.
• How much of Friday's downtime on the packaging line had no reason code on it?
• Which reason code cost us the most minutes on Line 3 in the last four weeks?
• Compare second shift to first shift on quality for this month.
• What does this field in the data actually mean?

Three things sharpen an answer more than anything else: which machine, line or area you mean, which time range, and which metric. "Downtime" has a hundred answers. "Downtime on Line 14 last week, by reason" has one.

These are the questions a scheduled report never covers, because nobody specified them a week in advance. When one answer raises three more, Explorer is where you take it and slice it yourself.

What has to be true before it can answer anything?

The honest prerequisite: the data has to be somewhere it can be queried. Advisor reads your production database. It does not read an XL board, and it cannot answer a question about history that was never collected off one.

That matters more on Vorne hardware than it sounds, because the boards are a rolling window rather than an archive. An XL 800 keeps production records for the last 1,000 shifts and 1,000 jobs and drops the oldest rows when it runs out of room. Ask about the same quarter three years ago and the answer depends on whether somebody was collecting off the board at the time. Collection is what turns a rolling window into a history.

If some of your lines are still on V1 boards, the second half of that is conversion. Once a V1 line is collected and converted into the V2 shape it sits in the same tables as everything else, and Advisor answers about it without caring which generation the board was. What happens to your V1 data when you move to V2 covers what conversion does and does not recover: V1 history answers at job and shift grain, because that is the grain the board wrote.

The other prerequisite is the one nobody markets: answers are only as good as what was recorded. If half your stops carry no reason code, "why were we down" gets a thin answer, because the reason was never written down. Advisor says so rather than filling the gap with something plausible, which is worth knowing before you expect it to explain a year of unexplained stops.

Where does it run, and what leaves the plant?

Your data and your queries: on your server

The application and the production database run on your server, like the rest of the suite, and on an in-plant install that server is inside your network. Every query Advisor runs is executed there, against your database, in a read-only transaction with a 30-second timeout. Write statements are rejected before they run, more than one statement in a single query is refused, and there is no path from Advisor to an XL device. Ask it to change something and it will tell you it cannot, because it genuinely cannot.

The model: wherever you point it

The model that reads your question and writes the SQL does not run on that server by default. Advisor talks to it over an HTTP API that hosted model services and self-hosted model servers both implement, and the address it talks to is a configuration setting. So the endpoint can be a hosted model service, a model deployment in your own cloud tenant, or a model server on hardware inside your plant network. Be precise about the middle one: a deployment in your own cloud tenant is your account and your controls, but it is still off the plant network. Only the third keeps the traffic in the building. Which of the three you want is a decision to make before the deployment, not after.

Exactly what crosses, when the model is hosted

On a hosted endpoint, this is the whole of what is sent:

• the question you typed, and the earlier turns of that conversation
• the structure it looked up, which can be the whole database schema rather than the few fields the question needed: table and column names and their types, the data dictionary entry for a field, the formula for a metric
• the SQL it wrote
• the instructions Advisor works under and the list of tools it is allowed to call, which are the same for every plant and contain nothing of yours
• the rows each query returned, capped at 500 rows per query
• the short notes it keeps about how you work, such as which line you look after, which are preferences rather than numbers or conclusions

One thing about that list is worth spelling out, because it is easy to miss: a conversation carries its own history. The rows an earlier question pulled back are sent again with your follow-ups, until the thread gets long enough that Advisor works from a summary of the earlier turns instead. A new thread starts clean.

And what does not cross: the database itself. There is no copy, sync, upload or bulk export of it anywhere in this, nothing is loaded before you ask, and no XL board is contacted at any point. Of the data in it, what goes out is what your questions actually pulled back, not the years of history sitting behind them.

So the accurate short version is this. Nothing is copied out of the database: it stays on the server the suite is installed on, which on an in-plant install is inside your plant network. Where the model is hosted, what goes out is Advisor's own instructions, your question and the conversation around it, the structure and definitions it looked up, the SQL, and the rows each query returned. On a model server inside your plant network, even that stays in the building. Anyone who tells you a hosted assistant sends nothing is describing something else.

What will it not do?

These boundaries are deliberate, not gaps waiting to be filled in a later release.

• It does not change anything. No writes to the database, no writes to a board, no settings, no equipment. It reads and it answers.
• It does not act on its own. It answers the question in front of it. It does not create alert rules, assign work, or do anything between your questions.
• It does not guess. If the data will not support an answer it says it does not know, and that includes forecasting: no prediction it cannot back with what is in your database.
• It does not tidy your data. An OEE over 100 percent, a negative count, a timestamp in the future: it flags what looks wrong and still shows you what is actually stored, rather than quietly correcting it into something believable.
• It does not assess people. No individual employee comparisons, no HR questions. Shifts and teams, yes. Named operators ranked against each other, no.
• It does not stray off the floor. Production, OEE, downtime, quality, jobs, parts, devices, shifts and what your data holds. Anything else, it declines.
• It does not carry numbers between conversations. Results go stale by the hour, so nothing is kept as fact once a thread ends. Every answer is queried fresh.

Two practical limits are worth knowing. One query returns at most 500 rows, and a result that was truncated is reported as truncated rather than presented as the whole list. A query stops at 30 seconds and Advisor asks before retrying with a longer limit, so nothing expensive runs against your database without you saying yes.

Where do these statements come from?

Everything on this page about what runs where, what is sent and what is refused describes our own software and was checked against how it is built, not against a brochure. The board behaviour comes from Vorne's published XL material and from our own work against those interfaces, and the XL 800 page lists those sources in full.

Vorne is a separate company, and Vorne, XL and the XL model names on this page are its marks. We describe what our software does with XL data once that data is in your database. We do not speak for Vorne.