The Operator's Boundary: Models, Workers, and Security

Open Notebook's operator boundary answers a question that the user interface cannot answer by itself: where does control end once a research workspace begins to call models, workers, databases, and network services? This chapter examines the model registry, local and hosted provider choices, self-hosted service topology, background jobs, credential custody, and basic hardening. The practical result is a deployment judgment: a reader can identify what stays inside the system, what crosses its perimeter, what is merely queued, and which protections are still their responsibility.

Provider choice is a matrix, not a brand preference

Open Notebook does not hard-code one language model into every workflow. It stores provider credentials separately from model records, then links a model to the credential that can use it. When a task runs, the application resolves that relationship into the configuration expected by its provider interface. The same pattern can select language, embedding, speech-to-text, and text-to-speech models.

This arrangement matters because research features have different technical needs. A language model can explain a passage, but it does not automatically provide the embeddings needed for semantic search. A transcription model can turn an interview into text, but it does not necessarily produce a useful analysis. A text-to-speech model can voice a script, but it does not decide whether the script preserved the source's caveats. Treating all of these as “the AI model” hides the points where data and failure can move.

The model registry makes those distinctions configurable. Defaults can be assigned by task, and a particular operation can override the default. A transformation can use a model chosen for extraction rather than the model used for Chat. A long-context task can be directed to a model intended for larger inputs. An embedding model can be configured separately from the conversational model. This is useful when a researcher wants to balance quality, speed, cost, hardware, and privacy across different stages.

It also makes provider portability more concrete than a slogan. The application translates its internal task into a common provider interface, while the provider registry records which modalities and discovery paths each service actually supports. A local endpoint and a hosted endpoint can therefore occupy the same model-selection surface. But a common interface does not make the providers equivalent. They may differ in context limits, supported modalities, model behavior, latency, pricing, and reliability. A feature that works with a language model may still need a separate provider for embeddings or speech.

A credential-linked model is the preferred path because the model points directly to the credential record that supplies its configuration. Older environment-variable provisioning remains as a fallback for models without a linked credential, but it is less expressive: a single environment configuration cannot represent the same set of per-provider credentials and task-specific relationships. The settings interface is not merely a friendlier place to paste a key. It is the layer that gives the application enough structure to choose among multiple credentials and models at runtime.

The application also rechecks provider URLs close to the moment of use. That matters for self-hosted endpoints and compatible gateways, where a URL can be configured by the operator. A URL that was acceptable when saved may not be safe to call later if its hostname is redirected to a dangerous address. Request-time validation and DNS pinning narrow that gap. They do not make an untrusted provider trustworthy, but they reduce one class of accidental or malicious redirection.

The right provider decision starts with the data boundary. “Local” should mean more than the browser and database running on a home server. Ask where the content goes at every stage:

• Is a web page fetched by a local parser or a managed extraction service?
• Are embeddings generated by a local endpoint or a cloud API?
• Does the language model receive the full source, selected context, or only a derived insight?
• Are recordings transcribed locally or sent to a speech service?
• Is podcast text voiced by a local engine or a hosted TTS provider?

If every relevant stage stays inside the trusted deployment, the workflow can be genuinely local. If even one stage sends content outward, it is hybrid.