Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

A meeting’s raw files

A part writes each meeting’s transcript twice, under the raw directory millpond hands it: once as the service served it, and once as a plain copy with one line per turn. The capture line names both files in its raw field. Neither file enters git.

Two files

  • The transcript as served is the service’s own form, whole: whatever structure, speaker labels and timings the service gave. It keeps everything the service recorded, so a later reading loses nothing to a conversion eddy made.
  • The plain copy has one line per turn, a turn being what one speaker says before the next speaker starts. Every part writes the same plain shape, so a reader meets one form of transcript whatever service recorded the meeting.

The layout is shared code, so wispr, webex and teams lay a meeting out the same way, and a part added later inherits it.

The line goes to git, the files stay on the host

A capture line is small. It holds what millpond checks and what enters git as the capture: the key, the source, event_at, the title, the url and the names of the raw files. A raw file is the material, and a long meeting’s transcript runs to megabytes.

A meeting's line and its raw files A part prints one capture line and writes two raw files for a meeting. The line becomes an unread capture in the inbox, in git, which curation, crew and herdr's pane read. The two files, the transcript as served and a plain copy with one line per turn, go to the host's raw bank under the capture's name, never into git. The capture points at them as host and path. A reader session, millpond's verbatim check and a person following the pointer read the raw files. A part prints one line, writes two files The capture line key, source, event_at, title, url, the files' names small: one per meeting Two raw files the transcript as served a plain copy, one line per turn up to megabytes The inbox, in git an unread capture, no excerpt The raw bank on the host, under the capture's name; never in git <host>:<path> READ BY curation crew and its planner herdr's inbox pane READ BY a reader session the verbatim check a person following the pointer
A part's line becomes the capture in git, and its two files go to the host's raw bank, which the capture points at. A meeting's words never reach GitHub: only a reader, millpond's verbatim check and a person following the pointer read them.

Only millpond reads the line (landing a capture). It writes the capture into the inbox, in git, banks the raw files in the host’s raw bank under the capture’s name, and gives the capture a pointer of the form <host>:<path> (217h). The raw bank is millpond’s (what stays on the host). Raw transcripts stay outside version control, and the capture cites them (111), so a meeting’s words never reach GitHub with the record.

A hosted Flywheel adds one rule: raw material a capture points at is never read on a host serving more than one flywheel. A reading that must follow the pointer runs on the operator’s own machine or a pool host (263).

Who reads them

Three readers use a meeting’s raw files once millpond banks them:

  • A reader session. A meeting capture has no excerpt, so its transcript is the reader’s whole input. The reader’s instructions are the inbox’s data, never eddy’s (119). They say what makes a signal, how to name a speaker a transcript leaves unnamed, and how the operator draws signals from a meeting.
  • millpond’s verbatim check. millpond refuses a signal whose excerpt does not appear verbatim in its capture’s raw material (the verbatim check). Every excerpt a reader takes from a meeting is therefore a quote from one of these two files.
  • A person following the capture’s pointer to the transcript itself.

A sounding opened on a decision a meeting left open takes the meeting’s transcript as one of its sources (sounding’s book).

eddy writes the files and nothing about what they mean. A transcript that leaves a speaker unnamed reaches the raw bank unnamed, and the reader names the speaker by the inbox’s instructions.