Sound and speech
Everything between audio devices and text: capture, conditioning, segmentation, and one interface over the speech engines.
ov-mediaov-asr
Privacy & security
See where Studio stores and processes your data.
This page describes local workflows, external AI, network routes and architecture in the current recording build. Data use for future AI team features will be documented for the services and capabilities offered.
Where it happens
Studio’s local recording workflow and optional external AI.
Your device
-
Capture
Microphone and system audio recorded in real time and written to disk by the backend, independent of the window.
audio -
Transcribe
Local speech models, chosen per language, turn audio into text offline.
transcript -
Summarize
The built-in local language model pulls out key points, decisions and action items.
notes -
Index
Stored in local SQLite with a vector index; when you ask a question, the answer comes only from your own recordings.
With Studio’s local models, speech recognition and text processing run on the device. After the first model downloads, no AI service account, API key or cloud subscription is needed.
Off your device
Company cloud or custom AI endpoint
For a larger model or a server your company hosts, you can connect Studio summaries and Ask to a chosen endpoint. After setup, relevant material is sent when you start a summary or question. Studio’s current automatic summaries and knowledge graphs do not use external endpoints on their own.
The boundary
What stays on your device, and what leaves only with your say-so.
Data stored locally
- Original recordings, and the data needed to recover a recording after a crash
- Transcripts, notes, meeting summaries and action items
- The local SQLite database, the vector search index and downloaded model files
- Credentials for third-party services, encrypted in your operating system's credential store
Leaves only when you act
- Model downloads: pinned versions only, checked against SHA checksums
- Audio from a YouTube link you submit, fetched by a bundled downloader; no meeting content is sent
- Calendar subscription: the one link you added, read when you connect it
- Update checks you start, and checks on whether an AI provider is available
- Summary content and Ask questions you choose to send to a company server or cloud provider
What we never collect, track or store
The application needs no account, and we run no server that holds your content. The source code contains no third-party analytics, behavioural tracking or background telemetry, and anyone reading it can confirm that. Using the software gives OptiVerse Technology Ltd no access to your recordings, transcripts, notes or usage habits.
Everything above was checked against the current source code. Before public release, we will check the bundled privacy policy again against the final release builds.
Outbound connections
Studio’s HTTP requests are managed centrally; independent routes are listed separately.
One module constructs Studio’s HTTP client. Requests through this client carry typed records of their purpose and initiator for IT and security review. The updater, system browser and YouTube downloader routes are listed below.
Inside the application
- Model downloads, pinned versions checked against checksums
- Software update checks you start
- Calendar subscription URLs you added yourself
- YouTube audio for a link you submit
- Provider model catalogs and endpoint status
- Company or custom cloud inference endpoints you configured
- External links you ask to open, handed to your system browser
ov-egress
the one HTTP client, centrally controlled
The internet
Three paths do not use this client: the application updater, handing a link to your system browser, and the bundled YouTube downloader, which runs as its own process for a link you submit. Each one starts only when you act.
Calendar lists and reminders are read from a local cache by default, so opening the application does not make network requests on its own. Every outbound route is listed in the code, and that list is checked automatically against the published privacy policy.
The overview page has the full model catalog, showing where each model runs: see the model manager
Why it matters
Understand where processing happens, who can access the material and what it costs.
For companies and professionals, local-first is a business decision as much as a privacy one.
-
See which work needs an external service
Studio recording, transcription and built-in-model summaries can process meeting content locally. When selecting an external service, assess the material sent, how it is processed and the provider’s terms.
-
No per-minute billing, so costs are predictable
Studio’s built-in models transcribe and summarize on computers you already own, without cloud inference charges per minute or token. External AI follows the selected provider’s billing.
-
Works without a network
Recording, transcription and search need no internet connection. In a boardroom with no outside access, at a client site that blocks the internet, on bad hotel Wi-Fi, or on a plane, it keeps working.
-
Your data is on your disk, with no vendor lock-in
Every recording, transcript and note lives in an open SQLite database and ordinary files on your disk. You never have to request an export from us, or keep paying a subscription just to read your old meetings.
Local model speed depends on your hardware and is usually slower than a large cloud GPU cluster. Local mode lets meeting content stay on your device for processing. External AI has different data destinations and costs, so choose what fits the work.
Technical architecture and development details
These details describe the current recording implementation, not the complete architecture of the future app.
For IT and security teams
Privacy through local storage, recovery mechanisms and data controls.
Written for teams that care about reliability, compliance and data governance: how the system is layered, what happens to audio after you press record, what each module owns, and how your meetings are kept on disk.
A true native desktop application, not a cloud service in a desktop wrapper.
The current recording build uses Tauri 2, Rust and React 19 to bring recording and content processing into a desktop application. Remote AI is optional. This describes the current implementation, not an architectural commitment for every future feature.
Strict layering is the basis of its security. Code that touches hardware, the disk or the network is kept apart from the logic that makes decisions, and the interface has authority over neither. It never holds a raw file path and cannot build an HTTP client, so there is no hidden route for data to leave through the interface.
-
Interface (User Experience)
React 19 renderer, one route table, generated type-safe bindings; isolated, with no direct disk or network access
-
Composition shell (System Integration)
Tauri 2: commands, event channels, plugin wiring, the application state lifecycle, and an orderly shutdown
-
Capability modules (Core Logic)
Rust capability crates: domain, application, media, speech, generation, retrieval, storage, files, egress, model artifacts, and a processor probe
-
Runtime and devices (Low-level Drivers)
SQLite, local filesystem, audio drivers, governed outbound HTTP, plus bundled inference helpers, ffmpeg and, on macOS and Windows, a YouTube downloader
What happens when you record
Five real-time stages, with recording state saved before display.
Audio passes through bounded capture and transcription stages. Committed text revisions and timeline markers are saved before the interface is notified.
-
Capture
System audio and microphone captured together through the operating system's native audio interfaces.
frames -
Condition
Mix, resample and buffer through bounded memory queues, so memory use cannot grow without limit.
audio -
Segment
Voice activity detection identifies speech windows before transcription; it does not prove complete words or eliminate all processing during silence.
segments -
Transcribe
A dedicated local worker pool drives the speech engine for the language you chose, entirely offline.
text -
Commit
Text revisions and timeline markers are committed to SQLite in an ACID transaction before the interface is notified.
Committed work can be recovered after interruption
Recording state is saved by the backend independently of the interface. Recovery uses committed revisions and explicit interruption records; pending audio or transcription can still be missing. On a completed stop, the terminal marker and indexing intent share a transaction so indexing can resume after restart. Current installed crash and power-loss acceptance remains open.
The capability map
Four areas around a stable core, so parts can be replaced and extended later.
Every capability has exactly one owning module, and a dependency that should not exist fails to compile instead of becoming a habit. That is what lets an underlying engine be upgraded without unsettling the rest of the application.
Contracts and Core
Domain types, abstract interfaces that the outer crates implement, and transport-neutral use cases. No framework dependencies, which is what lets everything else be swapped out piece by piece.
ov-coreov-app
Understanding
Meeting summaries and semantic search: text generation through the local engine or an endpoint you configured, chunking, embeddings, full-text search and the knowledge graph.
ov-llmov-knowledge
Durable records
What survives a restart: the SQLite store with its embedded schema and recovery, and a filesystem layer limited to verified root directories.
ov-storeov-files
Governed egress
Outbound connections: the only HTTP client the application code can build, and the pinned manifest that verifies model releases by checksum.
ov-egressov-artifacts
16
capability crates
157
registered commands
56
typed events
9
named network purposes
23
pinned model artifacts
Each command is registered once in Rust, and both the backend handlers and the checked-in TypeScript contracts are generated from that registration, so the interface and the backend cannot quietly drift apart. Every count here is read from the source tree each time this page is built.
Where state lives
One canonical store, fully under your control.
Recordings, transcripts and what was drawn from them are kept in open formats on your disk rather than in a proprietary silo. The data is yours for good, and you can back it up or move it whenever you like.
On your disk
the source of truth
SQLite database
Where all meeting data lives: meetings, transcripts, notes, action items and background work still in progress. It runs in WAL mode, so reads and writes can proceed together and data is protected through a crash.
source audio
Recording folders
Original audio and crash-recovery files. The backend decides where they go; the interface never sees the real path and cannot reach arbitrary folders on the disk.
re-downloadable
Models and caches
Local model files and caches, in folders the application manages. They can be cleared at any time and downloaded or rebuilt when needed.
rebuildable
Preferences
Interface state and user settings. Live transcripts and meeting content are never stored here, so resetting preferences leaves your meeting history intact.
kept by the operating system
OS credential store
Third-party API keys and other secrets are kept in your operating system's keychain or credential manager, and never written in plaintext to the application's files.
Delete the meeting data managed by Studio
Deleting a meeting in Studio creates a purge job for its database records, caches, audio files and index entries, and requires the interface to confirm that it cleared its cached copies. The job can continue after a restart. It does not cover exported files, your backups or material already sent to external AI services.
Honest limits
What this architecture does not do yet.
Some module boundaries are still being tidied
A few workflows still call concrete storage or device code directly from the shell instead of going through a contract. Those paths are marked as transitional and are being moved behind contracts.
Automation runs on the built-in engine only
Studio’s automatic post-meeting summaries and knowledge graphs use the built-in local engine. Live summaries are available on macOS; Windows requires hardware, runtime and model checks. The 8 GB video-memory and 16 GB system-memory thresholds are provisional, not measured minimums or performance guarantees. These Studio workflows do not call external AI services on their own.
The numbers on this page are measured, not typed
The crate, command, event, network-purpose and model counts are read from the source tree every time this page is built, so they cannot fall behind it. They can be checked; they are not marketing adjectives.
For what works today and what comes next, see the roadmap · undefined
Evaluating this for your company or team?
Email us with your business needs and workflows. We offer customized RPA services, including workflow automation, system integration and implementation support, to build a solution that fits your needs.