Afterword

A recording preserves a meeting, but it does not settle what anyone agreed to do. Decisions may be tentative, owners may be implied, and a date can refer to a discussion rather than a deadline. Afterword is a self-initiated concept for a web app that turns recordings into decision drafts for human review.

The proposed output is a structured record of an action, its owner and its date, with uncertainty kept visible. The purpose is not to make a transcript look shorter. It is to help a reviewer decide what can safely be carried forward and what still needs clarification.

The constraint is epistemic rather than cosmetic: a fluent sentence is not evidence that a meeting reached a decision. The design therefore treats model output as a proposal with provenance, not an automated result. A reviewer needs a path back to the relevant source and an option to leave an item unresolved without being pushed toward a tidy but false summary.

1. Audio enters the proposed pipeline.
2. Transcription produces a source representation for review.
3. Structured extraction proposes decisions, owners and dates.
4. Every proposed item must pass through the required human review gate.
5. Only reviewed decisions can leave as an output.

The uninterrupted gold line is intentional, but the gate interrupts it visually and operationally. There is no bypass from extraction to output. A reviewer is not asked to bless a polished summary at the end of the process; they are the required authority that decides whether a proposed record is sufficiently supported to travel further.

• Extract a schema, not a polished paragraph.

  The planned model response would separate the decision, owner, date and supporting source reference. Schema validation can reject malformed output, but cannot establish truth. A prose-only summary was rejected because it can conceal uncertainty in its flow; structured fields make absence and disagreement easier for a reviewer to see and challenge.

• Leave missing information unresolved.

  An absent owner or unclear date should remain marked for review. Guessing makes a neat interface at the expense of an honest record. The accepted trade-off is that a decision list may contain open questions, because forcing completion in the product would turn an ambiguity in the meeting into an error in the record.

• Keep approval separate from extraction.

  The model would propose; a reviewer would approve or return the item. The application should record that distinction explicitly. Automatic forwarding was rejected because a plausible sentence can still misstate authority, timing or intent. Nothing should enter another team's task system merely because a language model produced a confident-looking object.

• Design for interrupted processing.

  Upload, transcription and extraction would be separate recoverable jobs. A failure should identify the affected stage and preserve completed work where appropriate. A single opaque processing step is simpler to draw, but it makes recovery and retention harder to reason about. Storage, deletion and access rules need agreement before any real recording is accepted.

The review card below contains a fictional decision draft. Use its controls to mark the draft as reviewed or return it for clarification. The status message changes, and either choice can be reversed. The source note remains beside the proposed action so that the basis for review is visible.

This is a local interaction study. It does not upload audio, call a model, store an approval or create a task. Its deliberately short sample illustrates the review gate without implying that transcription or extraction has already been built. Real recordings would require secure handling and a usable source-playback interface.

Proposed: a TypeScript web interface and API, object storage for recordings, a background job queue, a transcription service and a language model supporting structured output. PostgreSQL would keep draft and review state. Provider selection would follow evaluation of representative, authorised material and agreed handling requirements.

The proposed stack is intentionally separable. It allows a failed transcription to be retried without rerunning review, and it keeps the record of a human decision distinct from the generated draft it concerns. The final design would still need to establish source retention, reviewer permissions, export rules and an error policy before any real meeting material moves through it.

In progress. Afterword is self-initiated concept work, not a client commission or a released product. The review control is an interface study only. Next work would evaluate extraction errors, ambiguous ownership and source traceability before implementing an audio-processing pipeline or connecting external task systems.