bbchops/transcription
1
0
Fork 0
generated from john/python-template
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Updates to docs. Added new transcription_methodology, revised approach to revisions: 1 revision per document (that can be updated)

Browse Source
This commit is contained in:
Jim Lancaster
2026-07-29 13:29:44 -05:00
parent ec61013b47
commit eaf9805121
6 changed files with 77 additions and 45 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/architecture.md
+5 -5
View File
@@ -20,7 +20,7 @@ Current scope includes:
- content source upload and metadata capture
- asynchronous transcription jobs
- prompt-library driven transcription behavior, with one Markdown file per prompt
- original transcription review and optional revision history
- original transcription review and optional revision review
- full-text search over accepted transcripts
- export of transcript data
@@ -61,7 +61,7 @@ flowchart LR
Worker --> MG
```
## Runtime Ownership And Startup Policy (V1 Step 1)
## Runtime Ownership And Startup Policy
The current implementation now uses explicit lifespan-owned runtime resources.
@@ -136,7 +136,7 @@ Production transcription flow:
3. The in-process worker de-queues the job and calls the transcription provider.
4. The application persists original transcription output on the job, plus confidence metadata and provenance events.
5. Job status transitions from queued to processing to transcribed or failed.
6. The UI and API expose status, optional revision history, and searchable transcription text.
6. The UI and API expose status, optional revision to original transcription, and searchable transcription text.
## Data Model Ownership
@@ -152,8 +152,8 @@ System-of-record entities:
- each processing job stores the original immutable provider output (`text`)
- provider metadata (`provider`, `model`, `prompt_name`) and failure detail (`error_detail`) are job-owned processing artifacts
- revisions are optional user-authored edits linked to a content source
- a revision can be created from either original `job.text` or a previous revision
- many jobs will have zero revisions; revision history is additive and never overwrites original provider output
- a revision can be created from original `job.text`
- many jobs will have zero revisions; revisions are additive and never overwrite original provider output
- a document groups one or more content sources (images, PDFs, and future source types)
Storage strategy: