# ToFScope architecture > **Tip: Technical documentation** > > This section is for developers, administrators, and other readers who want to understand more details about how ToFScope is built, deployed, and maintained. It covers the application architecture, file compatibility, building and testing, deployment, and documentation maintenance. For instructions on actually using the application, start with the [user guide](../../docs/getting-started/index.md). # Architecture overview ToFScope allows users to analyze ToF-SIMS acquisitions through a convenient browser interface. This page describes how data flows through the major parts of the application and explains how the application is built. An **acquisition** is an HDF5 (`.h5`) file containing measurements from an instrument. A **signal** describes the ion data being viewed; it can come from a stored channel in the original acquisition, or from a custom mass window. An **analysis** is the current collection of signals, selections, calibration, and display settings for an open file. # The whole system *\[Rich HTML output -- view on the documentation site\]* In the usual local setup, the Python service (run via `tofscope`) and browser interface run on the same computer. This server/client design will allow for future versions of ToFScope to run remotely while users access the tool with their local browser. The service also supplies the browser's application files; no JavaScript development environment (Node) is needed to run the packaged app. The browser displays results and communicates with the Python service, which runs the calculations. The service reads acquisitions, coordinates calculations, and can create separate copies or exports. It keeps the original acquisition unchanged. ToFScope can also be configured for other deployments. Self-hosted server use is under development, and the container workflow is untested. The [deployment guide](../../docs/technical-documentation/deployment.md) describes the current boundaries and setup. # Typical analysis pipeline *\[Rich HTML output -- view on the documentation site\]* Some acquisition files need [preparation](../../docs/getting-started/first-analysis.md#preparing-raw-acquisitions) to create initial ion maps from raw measurement events before they can be explored. ToFScope previews that operation and creates a copy after the user confirms the action. In the *Explore* view, an ion image, mass spectrum, front projection, and depth profile provide different perspectives on the same acquisition. A user can select a region of interest, change the depth frame range, or compare signals; the views update to reflect those choices. *Depth calibration* relates acquisition frames to physical depth when those depths are known. *Identify peak* helps compare measured peaks with isotope candidates. The *3D volume* view shows spatial signal data. See the [user guide](../../docs/getting-started/index.md) for much more detail on these points. # Inside the application The following diagram explains how the browser frontend communicates with the Python backend process: *\[Rich HTML output -- view on the documentation site\]* The **frontend** is the interface in the browser that a user interacts with. It manages screens and interactions, sends requests, and draws plots and 3D scenes using data returned by the service. The **API** handles requests and session access between the browser and service. The application layer manages open analyses, commands, background jobs, and cached arrays. Presentation code prepares data for displays and exports, science code implements calculations, and storage code works with acquisition and saved files. Arrows in this figure show major relationships, not every dependency. Readers who want to follow the code can start with the [frontend screens](https://github.com/datasophos/ToFScope/tree/main/frontend/src/app), [frontend API code](https://github.com/datasophos/ToFScope/tree/main/frontend/src/api), and the backend's [API](https://github.com/datasophos/ToFScope/tree/main/src/tofscope/api), [application](https://github.com/datasophos/ToFScope/tree/main/src/tofscope/application), [presentation](https://github.com/datasophos/ToFScope/tree/main/src/tofscope/presentation), [science](https://github.com/datasophos/ToFScope/tree/main/src/tofscope/science), and [storage](https://github.com/datasophos/ToFScope/tree/main/src/tofscope/storage) modules. # Following a selection This example follows the data flows that cascade from a change to an Explore selection, such as the region of interest. It shows the common path; individual actions can use different endpoints. After a change, the service sends the browser an **analysis snapshot**: a record of the analysis settings at that moment, including the selected signals, region, depth range, and display settings. It also includes a revision number that identifies that version of the analysis. The snapshot describes the current state; the plotted data is requested separately. *\[Rich HTML output -- view on the documentation site\]* The browser uses the snapshot to decide which panels need fresh data and avoids displaying a response for an older revision. The service may reuse arrays from a memory cache to avoid repeated work; the cache is bounded and is not permanent storage. Some operations take longer and use a background job instead of this immediate display path. Examples include custom signal integration, raw preparation, isotope measurements, and saving. The interface can report job progress and results while the service schedules the work. # Data, saving, and exports *\[Rich HTML output -- view on the documentation site\]* The open analysis and in-progress jobs live in the service's memory; unsaved work is lost when it restarts. The **Save as** action creates a new HDF5 copy with the acquisition and committed analysis, so it can be reopened later. If the opened file is itself a prepared or saved copy, that file is the source for the new copy. CSV and image exports are sent directly through the browser to the user's Downlods and can be used to share results; **Save as** preserves the analysis for further work. [Configuration and storage](../../docs/technical-documentation/deployment.md#configuration-and-storage) covers service resources and locking. # Building a development version *\[Rich HTML output -- view on the documentation site\]* Developers can use the [`scripts/build_frontend.py`](https://github.com/datasophos/ToFScope/blob/main/scripts/build_frontend.py) script via `uv run python scripts/build_frontend.py`. It runs the frontend build defined in [`frontend/package.json`](https://github.com/datasophos/ToFScope/blob/main/frontend/package.json), copies the resulting files into `src/tofscope/static/`, and records a manifest. Running `uv build` creates the Python distributions; [`setup.py`](https://github.com/datasophos/ToFScope/blob/main/setup.py) checks the bundled assets during the package build. At runtime, the local service serves those prebuilt assets and the API; the browser runs the interface. The [building and testing instructions](../../docs/technical-documentation/building-and-testing.md) list the commands, and [deployment](../../docs/technical-documentation/deployment.md) describes other configurations.