Offline is a test you run.

If a BAS assistant is meant to work without the internet, I want to prove that with the network connection unavailable. Load the application. Open the evidence. Ask a useful question. Inspect the result. Restart it and do the same work again.

That is the offline standard I’m building toward for local specialists. It applies to the declared workflow as a whole, including the parts around the model.

Define what is disconnected

Offline needs a precise boundary. A workstation may still need the building’s local network to read a controller or reach a local service. Removing access to the public internet is different from disconnecting the workstation from every device it is supposed to inspect.

The proposed test should state which local connections remain available and which external connections are blocked. That makes the result reproducible. “It worked on my laptop” leaves too much unexplained.

A useful release should also state what was installed in advance. Initial model acquisition and later updates can be separate procedures. They should not reappear as surprise dependencies during an ordinary diagnostic session.

The files have to be there

There is already explicit support for this at the model-loading layer. Hugging Face’s Transformers documentation describes downloading the required files ahead of time, preventing Hub HTTP calls with HF_HUB_OFFLINE=1, and loading cached files with local_files_only=True.

Those controls address that library’s loading behavior. They are not a certificate that the rest of an application works offline.

For the system I want to build, the dependency list must include the model, tokenizer, runtime, reference material, search components, interface assets, and any tool needed for the claimed task. Authentication and startup deserve the same attention as answer generation. An application that needs an external sign-in to reach its local expert has an external dependency in that workflow.

The right list depends on the implementation. The requirement is to identify it, package it, and test it.

Run the whole job at the bench

My proposed offline acceptance test begins on a controlled test system with the required local BAS connection preserved and outbound internet access blocked.

Start from a stopped application, select a test device, gather the available evidence, and complete a diagnostic exchange. Open the references the answer cites. Save the investigation. Restart the service and verify that the documented recovery behavior works.

Then make the test less comfortable. Remove an expected reference file. Stop the model process. Supply stale observations. Make one local tool unavailable. The system should report those conditions accurately, without inventing fresh readings or claiming an action succeeded.

This is also where we measure hardware behavior. Record the tested machine, model version, memory use, and response time for the actual task. A release claim should belong to that measured configuration. “Runs locally” is too broad to tell an engineer what equipment to prepare.

Keep the controls independent

The expert’s understanding and the connector’s available actions are separate. A diagnostic installation can expose read operations while the expert still explains repairs and prepares configuration proposals. Each installed integration should state exactly which operations it supports.

I also want a clear failure boundary: stopping the assistant should leave the existing controls operating as designed. That boundary needs validation in the test setup. It should not depend on the model following a polite instruction.

The same discipline applies to a phone interface later. A phone reaching an on-site service over local Wi-Fi is one configuration. Running the model directly on the phone is another. Each deserves its own measured claim.

Offline capability becomes useful when an engineer knows exactly what remains available, what hardware it needs, and how it behaves when part of the system stops. That is the result I want to publish.

Sources

• Hugging Face: Transformers installation and offline mode

Source reviewed October 5, 2026. The acceptance tests and deployment criteria above are proposed requirements for this project, not reported test results.