When a manual cannot answer the most important question

FreezerData is a Dutch micro-enterprise with one to nine employees. An official European Digital Innovation Hubs case describes its “virtual service mechanic” for refrigeration equipment. The project addressed a shortage of qualified technicians: experienced specialists were spending time answering colleagues’ questions, while delayed diagnosis could mean downtime and spoiled goods for customers.

The initial idea resembled a conventional RAG assistant: load technical manuals and let a technician ask questions in natural language. A manual explains how equipment should work in general, however, not what is happening to a specific installation now. The prototype therefore added sensor readings. The assistant had to distinguish two classes of query: retrieve a procedure from documentation or inspect the current state of the equipment.

The project reached Proof of Value rather than proven large-scale production. According to EDIH, the hub contributed €10,000 and FreezerData invested €50,000. These figures relate to a demonstrator and partnership work, not a guaranteed implementation price for another company. The source provides no verified return-on-investment, answer-accuracy, or truck-roll reduction figures. That limitation is central to interpreting the case.

What the prototype connected

The solution has two different sources of truth.

  • **Static knowledge:** manuals, diagrams, maintenance rules, and fault descriptions.
  • **Dynamic data:** temperature, pressure, humidity, door state, and other signals from a particular installation.

The EDIH account says that selecting the right source and adding the correct context was a difficult part of the project. “How do I replace this sensor?” needs a manual procedure. “Should a technician be dispatched?” needs current telemetry, signal history, permissible ranges, and the exact equipment model. Many questions require both sources.

FreezerData’s current website says the platform receives data every minute, supports external 4–20 mA sensors, and stores readings in a cloud database. This is the company’s own product description, not independent verification. For another business, the transferable lesson is separation of duties: controllers and threshold rules protect equipment, analytics detect deviations, and a language model explains the data and retrieves the procedure.

An architecture without magic

A practical system can be divided into six layers.

**1. Asset registry.** Every installation receives a stable identifier, model, serial configuration, location, criticality, firmware version, and sensor list. Without a registry, an assistant may retrieve the correct manual for the wrong equipment variant.

**2. Telemetry.** A gateway collects signals, timestamps them, validates units, and buffers the stream during a network outage. Raw readings remain separate from aggregates. Missing data is marked as missing rather than converted to zero.

**3. Deterministic rules.** Critical thresholds, interlocks, and emergency scenarios stay in the controller or a dedicated monitoring system. An LLM should not decide to stop a compressor solely from free-form text.

**4. Documentation RAG.** Only approved manuals enter the index, with metadata for model, version, language, effective date, section, and page number. An answer exposes its source and excerpt, while obsolete documents are removed from retrieval.

**5. Telemetry reading tool.** The model does not receive an endless stream of values in its prompt. It calls a typed function with an installation, metric, time range, and aggregation. The function returns validated JSON with timestamps, units, and a data-quality flag.

**6. Workflow.** The assistant proposes a hypothesis and inspection checklist. A technician confirms the diagnosis, dispatch decision, and repair outcome. Feedback enters the case log but does not become “truth” automatically without review by an accountable engineer.

This design supports local deployment of sensitive components. Manuals, repair history, and telemetry may remain inside the company environment; only a sanitized query needs to leave it, if policy allows. A local model is particularly relevant when documents contain proprietary schematics and failure history reveals operating patterns. Locality alone, however, does not fix excessive permissions, obsolete manuals, or inaccurate sensors.

Data required before model selection

A useful pilot does not need thousands of PDFs. It needs a small governed set:

  • 20–50 approved manuals and service bulletins;
  • an asset registry mapping each installation to its documents;
  • a dictionary of metrics, units, and permissible ranges;
  • 30–50 sanitized diagnostic histories with confirmed root causes;
  • first-line questions and escalation rules;
  • access roles for operators, technicians, senior engineers, and administrators;
  • a gold set of questions with expected sources and permitted actions.

Telemetry quality requires its own validation. A sensor may freeze, drift, lose connectivity, or report a value under the wrong time zone. If the assistant confidently explains a bad signal, fluent prose merely accelerates a bad decision.

The boundary of responsibility

A “virtual mechanic” should remain an assistant, not an autonomous dispatcher for critical equipment.

The first risk is source blending. A model may quote a general procedure and present it as a diagnosis of one installation. The interface should distinguish “telemetry fact,” “manual requirement,” and “model hypothesis.”

The second risk is obsolete documentation. Every document needs an owner, effective period, and equipment mapping. Removing an old file from a folder is insufficient: its chunks must also disappear from the vector index and caches.

The third risk is excessive action. During an early pilot, the assistant does not need permission to change set points, restart an installation, or close a ticket. It may prepare a recommendation, but any command passes through a separate deterministic executor and human approval.

The fourth risk is leakage through documents and queries. Manuals, service records, and customer data are partitioned by organization and site. Authorization is enforced before retrieval, not after generation. Every telemetry query is logged.

Economics: count accepted decisions, not chatbot answers

Consider a modelled example unrelated to FreezerData. Suppose first-line staff send a senior engineer 15 questions each week and each consumes 20 minutes. At a fully loaded rate of RUB 1,500 per hour, that is roughly RUB 30,000 per month. If an assistant removes half of the questions and helps avoid one unnecessary RUB 12,000 site visit, the gross monthly benefit is about RUB 27,000.

With a RUB 350,000 pilot and RUB 40,000 in monthly support, this scenario does not pay back: monthly benefit is below operating cost. Recovering RUB 350,000 over one year with the same support requires verified benefit of roughly RUB 69,000 per month. More sites, expensive emergency visits, reduced product loss, or shorter downtime may provide it, but each item must be measured.

Key pilot metrics are:

  • answers linked to the correct manual and version;
  • correct routing to documentation, telemetry, or both;
  • time to decision and number of escalations;
  • false recommendations to dispatch and not to dispatch;
  • recommendations accepted by technicians;
  • avoided visits, downtime, and losses with confirmed causality.

A six-week read-only pilot

**Week 1.** Select one equipment class and one process, such as first-line diagnosis of a temperature deviation. Collect 30 real questions and establish baseline response time, escalations, and site visits.

**Week 2.** Clean the asset registry and load only current manuals. Store the model, version, and page for every retrieved fragment.

**Week 3.** Connect read-only telemetry. Validate units, timestamps, missing values, and latency. Configure two or three deterministic signal-quality checks.

**Week 4.** Implement query routing to documentation, telemetry, or both. Every answer must separate facts, sources, hypothesis, and the next safe step.

**Week 5.** Run in shadow mode: the assistant produces an answer, but the technician does not see it until after making an independent decision. Compare results and review dangerous disagreements.

**Week 6.** Expose suggestions to a limited group while retaining human approval. Decide whether to expand by cost per accepted outcome, not by conversation volume.

The FreezerData case is useful precisely because it is incomplete: €60,000 helped establish technical feasibility but did not establish economic return. The right next step for a small business is not to buy an “AI mechanic.” It is to test one narrow diagnostic scenario where controlled documentation, live signals, and human accountability meet in the same workflow.