For IT, security, and compliance teams.

Technical brief for firm IT departments evaluating Local Motion for deployment.

This page is the technical companion to the user manual and the state ethics matrix. It is written for the IT, security, and compliance reviewers at a law firm — the people who decide whether to greenlight the tool for the attorneys at the firm. It covers what the software does at a network and system level, where data flows, what configuration the firm controls, and the current compliance posture.

If you need depth beyond what's here — architecture diagrams under NDA, a security questionnaire response, or a pilot deployment — reach out and we'll work with you on what we can provide today and what is on the roadmap. We do not currently hold any formal compliance attestations; see Compliance posture below for the honest snapshot.

What this page is for

Local Motion is a Windows desktop application that listens to a remote hearing in real time and surfaces case law / rules / facts from a library the lawyer prepared in advance. It is a research and preparation tool. The single most important architectural property — the property an IT/security reviewer should focus on first — is that the AI it talks to is structurally constrained to citations the lawyer has reviewed and approved in advance. That property is the answer to Mata v. Avianca and to the broader hallucination concern; see the objections page for the litigator framing.

Architecture & data flow

Two-tier system. A Windows desktop application running on the lawyer's machine handles audio capture, transcription routing, and panel rendering. A backing service (operated by Local Motion on Cloudflare's edge) handles activation-key validation, hearing-quota tracking, citation verification, and the admin dashboard. Both communicate over HTTPS.

The citation-lock

The property that distinguishes Local Motion from a free-form chatbot in front of a judge. The mechanism is mechanical, not stylistic.

Step 1 — IDs as the only currency

Every entry in the lawyer's library has a stable internal identifier. The model never sees URLs, reporter citations, or free-form names as something it can write back; those exist only as labels next to IDs in the prompt context.

Step 2 — Schema-enforced enums

The citation-emitting fields of the agent's tool schema are typed as JSON-Schema enums whose values are the literal set of currently-loaded library IDs (plus a sentinel "NONE"). The model cannot emit a value outside the enum without producing an invalid tool call that the runtime rejects.

Step 3 — Forced tool use

The LLM is invoked with the tool call forced. There is no free-text response channel from the model. The only path the model has to produce a citation is to choose from the enum.

Step 4 — Server-side validation

On return, the runtime re-validates each ID against the current library (which may have changed during the call window). Any unrecognized ID — should one ever slip through — is normalized to NONE. The lawyer never sees an unrecognized citation.

Audio handling

The audio path is the most sensitive part of the system for a security review. Plain answer:

1. Capture. Two parallel streams. System audio (everything the computer is playing — Zoom / Teams / Meet) via Windows' built-in loopback mechanism. Microphone via the system default input. Both are resampled to 16 kHz mono on the device.
2. Buffering. Samples are held only in memory, in a bounded ring buffer. No write to disk.
3. Transmission to STT. Each ~4-second chunk is encoded as a WAV blob and POSTed over HTTPS to whichever speech-to-text provider the firm has configured (see AI providers). With the local STT option, no audio leaves the device — transcription runs locally via whisper.cpp.
4. Discard. Once the STT provider returns text, the audio chunk is discarded from the in-memory buffer. The transcript is appended to a rolling 60-second window.
5. Audio never reaches the LLM. Only the transcribed text plus the lawyer's library content reach the configured LLM provider.

Session recording (writing audio to disk) is off by default. If a firm explicitly enables it via configuration, audio files are written to a local directory on the lawyer's machine. Local Motion does not upload or aggregate recordings.

For the privilege analysis underlying the third-party-vendor disclosure question, see the objections page → privilege. For the privacy-policy text covering audio handling, see the privacy policy.

AI providers (third parties)

Local Motion does not itself operate large language models or speech-to-text in v0.1. The lawyer (or the firm's IT department) configures which third-party providers the app contacts. The firm can choose providers whose data-handling posture it has already vetted.

Speech-to-text providers

Language-model providers

Recommended for high-sensitivity matters: configure the Custom provider to point at a self-hosted Whisper-compatible STT and a self-hosted LLM (Anthropic- or OpenAI-format) on the firm's own network. The citation-lock applies identically regardless of provider, because the constraint lives in the tool-schema enum, not in the model.

Network requirements

Outbound HTTPS only, from the lawyer's machine, to a small, explicit set of hosts. No telemetry, no analytics, no inbound connections.

No outbound call to any other host should occur. If the firm's egress monitoring flags an unexpected destination, that's a bug — please tell us.

Data retention & deletion

On the lawyer's machine

• Audio buffers — held in memory only; discarded after the STT call. Not written to disk except when the user explicitly enables session recording.
• Library (cases / procedure / knowledge JSON) — held under the user's local app-data directory. Backed up only if the user backs it up. Deleting the directory deletes the library.
• License file — contains the validated activation key + plan metadata. Under the user's app-data directory. Deleting it bounces the app to the Activation screen on next launch.
• Post-hearing review records — capture every advice card surfaced this session plus any per-card thumbs / notes. Written atomically to the local sessions directory. The user can export, delete, or leave them; Local Motion does not upload or aggregate them.

In Local Motion's backing service

• Activation-key records — issued by an admin; stored as SHA-256 hashes. Plaintext is shown only at creation. Revocation is immediate.
• Hearing usage — start/end timestamps and durations per activation key, for plan quota enforcement. No advice content, no library content, no audio.
• Signup form submissions — name, firm, email, phone from the early-access form. Held for sales follow-up; deletable on request.
• Contact form submissions — name, email, topic, message. Same retention.
• Citation-verification queries — citation strings sent to the corpus lookup; not associated with the lawyer's identity in our logs.

On account closure or deletion request, all server-side records associated with an account are removed within 30 days. Customer-side data (libraries, session logs) is not held by Local Motion at all and is the firm's to manage.

Authentication & admin access

End-user (lawyer) authentication

The desktop app is gated behind an activation key (a 32-character credential prefixed lm_). The key is issued by an admin in advance, emailed to the lawyer, and entered once on the Activation screen. It is validated against the backing service on first launch and re-validated periodically. Revocation from the admin dashboard takes effect on the next periodic re-validation.

Admin dashboard

The administrative interface at localmotion.ai/admin is gated by three layers:

• IP allowlist — only specific source IPs configured by Local Motion can even see the admin URL exists; non-allowlisted clients receive 404 (not 403, so the existence of the page is not disclosed).
• Email OTP — single-recipient one-time code (6 digits, 10-minute expiry, single use, rate-limited).
• HMAC-signed session cookie — HttpOnly, Secure, SameSite=Strict, 4-hour TTL.

The admin dashboard is operated by Local Motion (not the firm). It is used to issue / revoke activation keys and to triage signups and contact messages. A future enterprise tier may include a firm-scoped admin sub-interface; that is roadmap, not shipped.

Configuration the firm controls

Local Motion is configured via JSON files in the user's app-data directory. The firm's IT department can ship a baseline configuration and update it centrally if desired (e.g., via Group Policy file deployment or RMM tooling). All configuration is hot-reloaded — saved changes apply within ~300 ms without restarting the app.

Examples of firm-controllable settings:

• STT and LLM provider selection (Groq / OpenAI / Anthropic / self-hosted endpoint / local Whisper).
• Environment-variable names for API keys (the firm decides which env var holds which key; Local Motion never reads keys from JSON config files).
• Network device selection (which microphone, which output device for loopback).
• Trigger sensitivity (silence threshold before the agent fires, max interval).
• UI defaults — panel position, opacity, text size, dark mode.
• Logging — session recording on/off, retention directory.
• Hotkey bindings — fully reassignable.
• The agent's system prompt template — editable; the bundled default is calibrated to the citation-lock guarantee and bar opinion compliance.

API keys themselves are never stored in configuration files. They are read from environment variables at runtime. If the relevant variable is missing, the app refuses to start the affected pipeline with a clear error.

Installation & updates

Local Motion is a single Windows executable. v0.1 ships an unsigned alpha installer; v0.1 GA will be Authenticode-signed. macOS is on the v0.2 roadmap.

Updates are delivered out of band — the app does not auto-update in v0.1. Each release is a fresh installer. A managed update channel for firm-wide rollouts is on the enterprise roadmap; for now, firms re-deploy the installer through their normal endpoint-management workflow.

Self-hosting & on-prem

For maximum data control, the Custom STT and Custom agent providers can point at any compatible inference endpoint on the firm's own network. Suggested patterns:

• Audio fully local: configure the local STT (whisper.cpp; runtime pipeline is v0.2) or run a Whisper-compatible HTTP server on the firm's network and point the Custom STT provider at it.
• LLM on the firm's own network: deploy any OpenAI- or Anthropic-format-compatible inference server (vLLM, llama.cpp server, a private deployment of Claude / GPT through Bedrock or Azure OpenAI) and point the Custom agent provider at its URL.
• Hybrid: mix and match — e.g., local Whisper for audio, hosted Claude for the agent.

Turnkey on-prem deployment of the Local Motion backing service itself (activation, quota, citation verification) is engaged per-scope on the Custom tier. Contact us for requirements.

Compliance posture

We do not over-claim. Where an attestation hasn't happened, it's listed plainly as not held. Anyone asking "are you SOC 2 / ISO / HIPAA?" can be told no, today, without footnote.

Feature & roadmap status

Plain snapshot of what's shipped vs. roadmap. Detailed architecture available under NDA.

Need a security questionnaire response, a DPA, an architecture deep-dive under NDA, or a pilot deployment? Reach out and we will route you to the right resource.