A spoken note, a meeting, a call: when audio is turned into text, that transcript becomes a first-class capture the matter can read back and reason over. Voice transcription in Opbox is the read surface for those transcripts. It lists the TRANSCRIPT captures the system has taken in and lets you open any one to read it in full, all from the same governed capture store the rest of the platform writes to. There is no separate transcript database to keep in sync: a transcript is a capture, and the captures are the one place it lives.
What it does
Lists the transcripts the matter has captured. Open the voice surface and you see the TRANSCRIPT captures laid out as a queue: the source they came from, an excerpt of the transcript text, when each was captured, and who it came from. This is one consolidated read over the existing capture store, filtered to transcripts, so the list you see is the real record rather than a copy that can drift.
Reads a transcript in full. Pick a row and the full transcript opens beside the queue. The detail is derived from the same loaded list rather than a second fetch, so what you read is exactly what the capture holds, with its source reference and capture details alongside it.
Sits on the shared capture store, not a bespoke one. Voice transcripts are not a special case with their own tables and their own verbs. They are captures with a source type of TRANSCRIPT, living next to DOCUMENT, MESSAGE, NOTE, and OTHER captures in the one store that migration 0022 introduced. The transcript text is taken in once, through the same intake path every capture uses, and surfaced here through the same read. Folding transcription into captures rather than spinning up a separate transcription system is the consolidation principle in practice.
Keeps the readable document a regenerable view. When a transcript is taken in, its wording can also land as a readable document for people who want to work with it as prose. That document is a projection of the capture, not a second source of truth: the capture remains canonical, and the document is regenerable from it. The transcript value is never duplicated into a separate kind of record.
Governed and scoped like everything else. Reading transcripts goes through the kernel’s one front door: the read is permission-checked, RLS-scoped, paginated, and audited before it runs. You see the transcripts you are entitled to see, and every read is a governed call, not a direct query against a database.
How you use it
Open the voice surface. Go to the voice transcription view and the queue loads the TRANSCRIPT captures: source, an excerpt of the text, when it was captured, and who by. An empty queue tells you plainly that there are no transcripts yet rather than leaving you guessing.
Open one to read it. Select a row and the full transcript opens in the detail panel beside the list, with its source reference in view. Because the detail comes from the same loaded data, opening a transcript is immediate and shows exactly the captured text.
Reach a transcript the same way you reach any capture. Because transcripts are captures, they are read back through the one consolidated capture read, filtered to the TRANSCRIPT source type. The assistant reaches them the same way the surface does, through that single governed read, so a transcript is held in the shared capture store rather than sitting in a silo.
The kernel verbs behind it
The voice surface is a read; the transcript text is written elsewhere (the capture intake path), and both run through the kernel’s one front door, permission-checked and audited before they execute.
capture.list- the one consolidated read over thecapturestore; filtersourceType='TRANSCRIPT'and you get the voice transcripts that fill the queue and the detail panel.capture.ingest- the intake that takes a transcript into the store (redact-at-ingest, then fan-out to {index, document}); this is the write side, not this read surface.
See the full set in the capture verb reference.