A model can produce an answer on your computer while other parts of the same application send information elsewhere. Those two statements can both be true. The model's calculation has a location, but search, conversation storage and synchronization each have their own route. Understanding privacy means following the information through those routes instead of treating the model's location as a description of the whole system.

Consider an invented application with a downloaded model. Its prompt contains a general question, A: “What is a nebula?”, and a synthetic note, B: “Project Cedar: draft meeting at 10:00.” The project and meeting are made up. We also define Y as an example answer placeholder; no model generated it. In every configuration below, the model calculation stays on the device and a local transcript contains A, B and Y.

We will change three optional routes around that calculation. This is a paper data-flow example, not a test of any named product. Official documentation supplies real examples of the distinctions: LM Studio describes local features and separate connectivity-dependent operations, while Ollama distinguishes local operation from cloud-hosted models. [1][4] Our fictional routes make the consequences inspectable without claiming that either product secretly sends the invented prompt.

Local inference describes the execution location of the model computation. It does not, by itself, specify the complete application's input handling, auxiliary requests, persistence or subsequent synchronization. Those are separate edges in a data-flow model. A privacy statement needs an explicit system boundary and time interval before “local” can be interpreted as a claim about data movement.

Define a fictional application whose model consumes fields A and B on the device. A contains “What is a nebula?”; B contains the synthetic string “Project Cedar: draft meeting at 10:00.” Y is a stipulated answer placeholder, not model output. A local transcript F stores A, B and Y in all cases. No real project, private information, installed model, provider call or network observation enters the construction.

The three optional routes introduced below are independent of the inference location. This separation is compatible with documented distinctions between local functionality and connected features in LM Studio and Ollama [1][4]. The construction is not an implementation audit of those products. Its purpose is to identify which conclusions follow from a declared route and payload, and which require additional evidence about components outside the model runtime.

LM Studio's offline documentation says that downloaded models, document processing and its local server can operate without an internet connection. The same page lists connectivity for activities such as model discovery, downloads and update checks. [1] Those are different activities. Downloading a model file is a network operation, but that fact alone does not show that a later conversation was sent with it.

The practical reading question is which feature a statement covers. “This downloaded model runs offline” describes a narrower situation than “every feature and every connected application will always remain offline.” A later choice to use another service changes the route that needs explanation. Similarly, a local server can be only one component behind a separate chat interface. Evidence about that server needs to be combined with evidence about the interface's own behavior.

In our invented application, obtaining the model is outside the modeled session. During the session, model execution is fixed as local. We are therefore free to compare different surrounding routes without changing that premise. This keeps the example focused: the question is where the declared fields go, rather than whether the model was originally downloaded or whether its name happens to contain the word local.

The retained LM Studio offline page scopes its claims to locally available models and core operations, while identifying model discovery, downloads, runtime downloads and update checks as connectivity-dependent [1]. These operations have different inputs and purposes. Observing a model-download connection would establish that connection, not the contents of a later inference request.

Treat a feature claim as a conditional statement over a configuration. The relevant condition can include a selected local model, a particular document-processing path and the surrounding application. A local inference endpoint does not automatically describe an independent client that invokes it. Conversely, unrelated connectivity does not by itself prove that prompt content crossed the network. Payload and component identity matter in both directions.

Our construction begins after model acquisition and fixes the inference location across all configurations. That choice deliberately holds one variable constant while changing auxiliary routes. The resulting comparison concerns declared field movement within the modeled interval. It supplies neither a complete inventory of a commercial application's traffic nor a conclusion about traffic before that interval. The feature boundary is part of the claim, rather than a detail to discard once the model runs successfully.

Local and temporary describe different things. LM Studio's chat documentation says that conversations are stored in JSON files and provides a way to reveal their location. [2] A conversation saved on the same computer can remain available after the model finishes its reply. The absence of a remote recipient would not, on its own, establish the absence of that local copy.

Our fictional transcript F makes this distinction explicit. It contains the question, synthetic note and placeholder answer in every one of the eight configurations we will examine. Turning off all three external routes leaves F unchanged. Therefore “nothing followed these declared routes” and “the conversation was never stored” have different truth values in the same example. We have stipulated persistence rather than inferred it from a network observation.

This also separates storage from model training. A file containing a conversation and a change to model weights are different events; the existence of one does not demonstrate the other. Our model performs neither training nor a deletion operation. If a reader needs to understand a particular application's history behavior, the useful evidence is its storage setting, documented location and retention behavior, considered separately from the inference location. We are not editing real conversation files or assuming their internal format is stable.

On-device persistence and on-device inference are separate properties. The LM Studio chat documentation identifies JSON conversation storage and warns against relying on or manually editing that structure [2]. That is evidence of a durable local representation in the documented application, not evidence that every application stores the same fields or uses the same path.

For the original example, define F={A,B,Y} as a local transcript that persists throughout the comparison. F exists even when Q=L=S=0. The zero-route case therefore has no declared remote transmission while retaining local content. A network conclusion cannot be substituted for a persistence conclusion, because the two predicates refer to different events and locations.

Likewise, persistence is not equivalent to a model-weight update. The construction includes a transcript record but no training transition. It also includes no file deletion, secure erasure or operating-system access assessment. For an actual application, a storage investigation would need the relevant configuration and behavior of the component that writes the record. The local-model premise alone does not establish those properties, and a particular provider's account-level deletion feature would not automatically describe an independently stored file.

Give the fictional application three independent switches. Q enables a remote lookup that sends only the general question A. L enables a remote content log that sends the full prompt, A plus B. S enables a later cloud synchronization of the saved transcript, A plus B plus Y. Each route has a different invented recipient. No real service is contacted, and these choices are not descriptions of a named application's defaults.

For the comparison, assume every enabled route successfully sends its stated fields at its scheduled time. Q and L act during the session; S acts during a later synchronization interval that is also included in our model. This assumption lets us reason about the routes themselves. A separate example will examine what happens when the device is disconnected during the earlier interval.

The payload matters as much as the destination. With only Q enabled, information leaves the device, but the synthetic note B does not travel through any declared route. With only L enabled, both prompt fields leave. With only S enabled, the saved answer placeholder leaves too. Saying merely that an application “uses the network” would hide those differences. Counting connections would also miss which information was included in each one.

Define three independent Boolean configuration flags. Q sends payload {A} to a fictional lookup recipient during interval I1. L sends {A,B} to a distinct fictional content-log recipient during I1. S sends the saved transcript {A,B,Y} to a third recipient during later interval I2. The observation boundary includes both intervals. Successful transmission of every enabled route is stipulated for the eight-case enumeration.

These are explicit payload definitions, not assumptions that ordinary telemetry necessarily includes prompts or that every backup service synchronizes every directory. The local inference node remains unchanged. The number Q+L+S counts distinct declared recipients in this construction; it is neither a packet count nor a count of HTTP requests, and it assigns no severity or probability to a route.

The field-level consequences already differ among the single-route cases. Q exports A while leaving B and Y local under the declared paths. L exports A and B, and S exports all three fields. This illustrates why component location and aggregate traffic volume are insufficient to characterize content movement. A useful record associates each recipient with its actual payload, purpose and interval. Remote retention and subsequent use remain unspecified until separate evidence supplies them.

Write the switches in the order Q, L, S, using 1 for on and 0 for off. The code 100 means lookup only; 010 means content log only; 001 means later sync only. In 000, none of the three declared routes sends anything. The model still runs locally and the local transcript still exists. There are eight possible three-switch combinations, including the four cases with two or three routes enabled.

The general question A leaves whenever at least one switch is on. The synthetic note B leaves when L or S is on. The placeholder answer Y leaves only when S is on. For example, 110 sends A to both lookup and logging, and B to logging; 101 sends A to lookup and sends the whole transcript to sync. Both reach two recipients, but they distribute different information to those recipients.

These eight cases are configurations we chose to enumerate. They are not equally likely events, a survey of applications or a privacy score. The result is a way to inspect a claim: even after fixing the model's location, we need the surrounding routes and payloads to know where particular fields go. The zero-route result applies only to this declared construction and time window; it cannot establish that an unexamined real application has no other traffic.

Encode configurations as QLS. The eight assignments are 000,001,010,011,100,101,110,111. Under the stated successful-transmission assumption, A crosses the device boundary iff Q∨L∨S, B crosses iff L∨S, and Y crosses iff S. These expressions concern declared payload membership, not deductions from packet sizes or an observed connection log.

The equal-recipient-count cases expose a useful distinction. For 110, the lookup receives A and the content-log recipient receives A,B. For 101, the lookup receives A and the sync recipient receives A,B,Y. Both have Q+L+S=2, while the recipient-field relation differs. Configuration 011 reaches logging and sync, and 111 reaches all three. None of those changes moves model execution away from the device.

The truth table is a finite logical enumeration, not a probability model or security test. It assigns no likelihood to the eight states and contains no hidden route-discovery mechanism. Configuration 000 has no declared export in I1 or I2 but retains F. It says nothing about excluded components, earlier disclosures or subsequent intervals. The precise conclusion is that inference locality alone underdetermines the field-routing behavior of this explicitly described application.

Suppose someone sees a connection while a local model application is open. Several questions remain: which component made it, what operation caused it and what information it carried? An update check and a request containing a conversation are different events. LM Studio's privacy policy, for example, describes device and app information and an IP address in connection with update checks. [3] That statement should be read in its stated feature context.

Our Q-only case shows the same reasoning with visible fields. A remote request exists, and A is in its payload. B is absent from that payload. Reporting “there was network activity” would be true but incomplete; reporting “the entire prompt was sent” would contradict the model. In the L-only case, the full prompt is explicitly included, so the conclusion changes because the payload changed.

Nor should a content-free description automatically be treated as a complete privacy assessment. A statement about which fields are absent still leaves the included fields, recipient and purpose to consider. This article does not assign a universal sensitivity level to metadata or to the example question. It demonstrates a narrower reading habit: describe the information actually supported by the evidence, rather than replacing missing payload knowledge with either reassurance or suspicion.

A network event identifies an operation only to the extent that the observation resolves its component, destination, timing and payload. LM Studio's retained policy gives an attributed example of update-related device/app information and IP handling [3]. That documented operation is separate from its stated handling of local conversations and optional cloud features. It is not an independent verification of those practices.

In the fictional Q-only state, observing the declared payload establishes export of A. It does not establish export of B or Y. In L-only, the declared {A,B} payload supports the broader prompt-content conclusion. This distinction comes from field-level evidence, not a general rule that a particular type of connection is harmless or harmful. An aggregate connection count cannot recover the recipient-field relation by itself.

Metadata also remains information. Calling a record metadata does not specify its complete contents, retention or linkability, and this construction evaluates none of those properties for a real service. The useful discipline is to keep the claim at the evidence's resolution. Where payload details are unknown, record that uncertainty. Where a particular field is explicitly included or excluded in a defined route, preserve that narrower conclusion without extending it to all components or intervals.

Now change the time story in a separate example. At a fictional 11:00, the device is disconnected. Q and L are off, the local model processes A and B, and transcript F is saved. S has been explicitly configured to run later. At 11:15, the device reconnects and that scheduled route sends A, B and Y. No external transmission happened during the disconnected interval in this construction, yet a later copy reaches another recipient.

Microsoft's OneDrive documentation provides a real example of files synchronizing between a computer and cloud storage, with changes syncing when online. [5] The relevant condition is that the file belongs to a configured synchronization path. We are not claiming that LM Studio or Ollama's default folders are in OneDrive, or that every local file is automatically included. The hypothetical route is deliberately stated rather than assumed.

This is why the end of the observation window matters. Watching only the reply at 11:00 would miss the event at 11:15. Turning a connection off for one interval also says nothing about copies made earlier. A clear privacy record therefore follows saved content through its later configured handling. It should identify when synchronization is included in the claim and when the available evidence ends.

The separate offline timeline fixes Q=L=0 and configures S as a later scheduled operation. At 11:00, while disconnected, local inference and persistence produce F={A,B,Y}. At 11:15, after connectivity returns, the stipulated sync event exports F. This is an invented event sequence, not a measurement of synchronization latency or a claim that any particular application queues the same work.

OneDrive's documentation supports the general existence of configured computer/cloud file synchronization and online propagation of changes [5]. Applying that mechanism to an AI transcript requires evidence that its actual storage location is included. The article makes no claim about default chat paths, selected folders or an existing account configuration. It also performs no backup change or file deletion.

An observation restricted to the first interval is insufficient to characterize the second. Likewise, present disconnection cannot retroactively negate a prior transfer. The model's useful implication is temporal: persistence can connect an earlier local computation to a later configured export. To assess that route, retain the storage destination, synchronization scope and observation interval alongside the inference setting. “Offline during generation” and “no later remote copy” are claims about different intervals and therefore need different evidence.

Three questions often get compressed into one: did a remote service process the request, did it keep the content afterward, and did it use that content for training? They describe different events. A request can be processed remotely under a policy that says its content is not retained after completion. A promise about training alone would not tell us whether the request was processed remotely or how long any record was kept.

The inspected LM Studio policy describes transient processing for optional purchased cloud features that the user chooses to use, with stated limits on retention and training. Ollama's FAQ likewise distinguishes local use from processing by cloud-hosted models and states limits on storing, logging and training on that content. [3][4] These are the providers' documented claims, not findings from an audit conducted for this article.

Our invented data-flow example specifies transmission but leaves remote retention and later use unknown. That means we can say which recipient receives B without inventing what it does afterward. A fuller record would need the applicable feature terms and relevant evidence for those later stages. Keep each answer attached to its question; otherwise a true statement about one stage can be used to imply an unsupported conclusion about another.

Remote processing, post-request retention and training use are separate predicates. A no-training statement does not logically imply absence of remote processing. A limited-retention statement describes another boundary and needs its own scope, covered data and duration. These distinctions are about interpreting claims; the article supplies no jurisdictional legal assessment or verification of a provider's deletion systems.

LM Studio's inspected policy attributes transient processing and stated retention/training limits to selected optional cloud features [3]. Ollama's FAQ states that cloud-hosted models process prompts/responses while describing limits on content storage, logging and training [4]. Those statements must remain attached to the named services and features. They cannot establish the behavior of an unrelated client, separate log collector or cloud-storage account.

In the original model, each enabled route establishes delivery of a defined field set. Retention duration and subsequent use are deliberately unspecified. It would therefore be invalid to infer either indefinite storage or immediate deletion from the route table. Additional policy and implementation evidence would be required for those claims. Separating the stages lets a record acknowledge what is established about delivery while leaving later handling explicitly unresolved, without substituting a broad privacy label for the missing information.

Ollama's FAQ documents a local-only mode that disables its cloud models and web search. [4] That is a useful feature boundary to understand. It does not describe the settings of an independent chat interface, a separate logging service or a file-synchronization program. To understand the whole arrangement, identify which component each switch controls and which components remain outside its scope.

In our example, suppose a change turns Q off while L and S remain on. The configuration moves from 111 to 011. The lookup recipient stops receiving A, but the content log still receives A and B, and later sync still receives A, B and Y. One route has changed successfully. The wider claim that no prompt content leaves would still be false under the remaining declared routes.

The opposite also deserves a precise description: if all three routes are off, none sends content in our modeled intervals. That is a valid result for the defined system, even though the local transcript persists. We do not need to dismiss a useful setting because it has a boundary. We need to describe its effect at the right level and avoid silently extending that effect to other applications, prior copies or future configuration changes.

A configuration control has an enforcement scope. Ollama's FAQ identifies disabling its cloud features as removing access to its cloud models and web search [4]. The article does not execute that configuration or infer control over other processes. An independently implemented client or synchronization service requires its own documented behavior and configuration evidence.

Within the fictional system, applying Q:=0 to state 111 yields 011. The lookup edge is removed, while the L and S edges remain. Consequently A and B still cross the device boundary, and Y still crosses through S. This is a direct state transformation over the declared route graph. It does not show that the control failed; it shows that the control's defined effect is narrower than the proposed whole-system conclusion.

Similarly, state 000 legitimately has no export through the three modeled edges while preserving local F. Both conclusions should survive the description. A scoped control can be effective without establishing every desired property of the application. The relevant review therefore maps each configuration to the component and route it governs, records the resulting state and treats earlier copies or later changes as separate events. No universal privacy toggle is implemented or assumed by the model.

Chrome's Network panel documentation explains that it records requests while DevTools is open and lets a reader inspect request details. [6] This can help with a browser-based interface. The useful question is which page or component the view covers and which period it recorded. A result from that view has a boundary, just as a screenshot shows one part of a larger scene.

Imagine that a browser sends A and B to a local backend, which then performs the fictional L operation itself. The browser's page-level request and the backend's outgoing request are different operations. A conclusion about the backend requires evidence that covers the backend. That is a reasoning consequence of the component boundary, not an observed behavior of Chrome, Ollama or LM Studio in this article.

Time matters here too. Opening a recording tool after an event would not reconstruct the event merely because the tool is now visible. A filtered display may also present only the selected part of a record. These limits make careful observations more useful: record what was visible, when recording began and which component was examined. We have not performed a capture, and no empty network panel is offered here as proof of complete application privacy.

The Chrome documentation scopes the Network panel to page loading and network-resource inspection, with recording while DevTools is open and request-detail views [6]. Such evidence has an observing component and an interval. The inference that it does not automatically characterize a separate process follows from that scope; it is not a result of an application test performed here.

Consider a stipulated browser-to-local-backend request followed by an L request initiated by the backend. The page's request record and the backend's outbound operation are separate edges. Evidence covering the former cannot establish the complete payload history of the latter without additional observation. The same principle applies when the synchronization program is independent of both browser and model runtime.

Observation timing and display selection also belong in the record. A tool that starts recording after an operation does not establish that the earlier operation was absent, and a filtered display should not be confused with the complete underlying set. These are limits on a conclusion, not instructions to distrust every captured request. State the covered process, interval and selection, then match each claim to that scope. No packet capture, browser experiment or whole-device monitoring was conducted for the fictional route table.

A useful description of our fictional application would identify the local model, the saved transcript and the current QLS configuration. For 100, it would say that the model uses A and B locally, the lookup receives A, the local transcript retains A, B and Y, and the other two declared routes are off. It would also say that the model does not specify the lookup recipient's later retention or use. That record is more informative than a single local-or-cloud label.

For an actual application, the same questions guide reading: which feature is selected, which component receives each field, where history is stored, which folders or services are configured to synchronize, and what the applicable policy says about later handling. Keep the source and date of each statement. A provider's declaration, a configuration record and a limited observation are different forms of evidence; each can answer a particular part of the question.

Our example establishes no ranking between products and no guarantee about an installation. It does establish why the whole path matters. The model can remain on the device across eight configurations with different remote recipients and payloads. Follow the fields, the saved copies and the time window, and the meaning of local becomes specific enough to be useful.

An inspectable record for configuration 100 contains at least the inference location, local persistence F, recipient-field mapping Q→{A}, disabled L/S state and observation interval I1∪I2. It also leaves remote retention and subsequent use unspecified. That is the complete supported description of this finite construction; it should not be silently expanded into a claim about an installed product or an earlier or later session.

A real record would attach evidence to the corresponding fields: documented feature behavior, actual configuration, covered component and interval, relevant storage/synchronization scope and applicable processing terms. Distinguish a vendor declaration from an observed event and distinguish both from an original logical deduction. Retaining version or retrieval date matters when a feature or policy can change. It also makes later updates targeted: a changed route can be reconsidered without pretending that every earlier assumption was freshly verified.

The central result is underdetermination, not a product verdict. Holding model execution local leaves multiple possible recipient-field relations and persistence states in a larger application. In our declared example F is fixed, while Q,L,S vary; a different application would need its own inventory. Tracking those components and intervals turns a broad locality statement into specific claims that can be checked, qualified and updated as evidence changes.