UmbraAudio/specs/18-UmbraTrans.md

Spec 18 — UmbraTrans: Meaning-Preserving Translation and Multilingual Audiobooks

• Status: Proposed architecture and implementation specification
• Date: 2026-09-23
• Scope: New system; additive to UmbraAudio
• Primary source language: English
• Initial target locales: French, Italian, German, Spanish, Russian, Japanese, and Simplified Chinese

1. Executive Summary

UmbraTrans is a separate multilingual production system built around the analysis and voice identity work already performed by UmbraAudio.

The system turns one English manuscript into:

• a canonical, meaning-aware representation of the book;
• high-quality translated books in each target locale;
• multilingual audiobooks in which a listener can recognize the same characters and narrator across languages;
• translation, pronunciation, voice, and audio quality reports; and
• reproducible release packages for text and audio.

UmbraTrans does not treat a sentence as an isolated string to be translated. It builds a hierarchy of book, chapter, scene, beat, discourse unit, and utterance information. The translation subsystem receives the scene's goals, conflict, relationships, chronology, terminology, speaker intent, and discourse context before it translates individual utterances. The result is a natural target-language performance that preserves the message and dramatic force rather than mirroring English word order.

The first implementation must not alter the current UmbraAudio codebase, database, speaker files, voice references, generation markers, routes, or audio outputs. UmbraAudio is an upstream, read-only provider. UmbraTrans writes to a separate project data area and communicates through versioned file or service contracts.

The quality target is publication-grade output, with human review reserved for the highest-risk decisions and exceptions. The source author controls the English source, English analysis, glossary, pronunciation decisions, and intended meaning. Target-language translation, localization, and audio validation are performed by UmbraTrans and its subsystems; the author is not required to translate or approve every target-language line.

The recommended first deliverable is not seven complete books. It is a validated source package, a representative translation in German plus one CJK lane, and a small set of cross-language voice samples. Only after those gates pass should the system expand to all seven locales and full-book production.

2. Motivation and Goals

2.1 Goals

1. Import an English manuscript from the formats supported by UmbraAudio and, eventually, public-domain books and historical scans.
2. Preserve the source text and create a stable, language-neutral source model that can be reused by translation, audio, search, adaptation, and future Umbra systems.
3. Translate the complete book into:
   • French (fr-FR by default);
   • Italian (it-IT);
   • German (de-DE);
   • Spanish (es-ES);
   • Russian (ru-RU);
   • Japanese (ja-JP); and
   • Simplified Chinese (zh-Hans).
4. Make translation quality meaning-first, context-aware, and consistent across a book.
5. Analyze communication at the scene and utterance levels, including goals, conflict, threats, commands, promises, emotional turns, relationships, and subtext.
6. Produce target-language books with stable character names, terminology, punctuation, typography, and metadata.
7. Produce target-language audiobooks with a recognizable cast and a consistent radio-play performance style.
8. Validate the source analysis, translations, target pronunciation, voice identity, and final audio before release.
9. Support incremental rebuilds: changing a glossary entry should not require rebuilding unrelated chapters, and changing a voice profile should not invalidate translations.
10. Make every output traceable to source text, analysis decisions, model/engine versions, and quality reports.

2.2 Non-goals for the first version

• Changing or replacing UmbraAudio's existing pipeline.
• Reusing English audio as a literal waveform for every target language.
• Treating a back-translation score as proof of translation quality.
• Automatically publishing books or distributing them without a rights/release check.
• Requiring the author to review every target-language sentence.
• Building a new general-purpose machine-learning model before validating the contracts and workflow.
• Selecting a single TTS engine for all languages before measuring language-specific quality.
• Silently falling back to a different voice, language, or engine during a release build.

3. Design Principles and Non-negotiable Invariants

3.1 Meaning before literal wording

The source message, speech act, relationships, and dramatic force are authoritative. Word order, idiom, metaphor, and even sentence boundaries may change when required by the target language. A translation may compress, expand, reorder, or split source material when that produces a better target-language result, provided the alignment and meaning checks pass.

3.2 Context before utterance

No dialogue or narration unit is translated from its local string alone. Every unit has a stable scene and chapter context, a speaker, addressee information where available, discourse dependencies, and a meaning frame. Ambiguous pronouns, ellipsis, register shifts, threats, and implied meanings must be resolved with that context.

3.3 Stable identity across languages

A character's speaker_id is the identity key in every language. Target languages may use different voices because their phonetic and prosodic systems differ, but the listener must be able to recognize the same character by the approved combination of voice identity, role, relationship, and performance style.

The system distinguishes:

• character identity: the same fictional speaker;
• voice identity: the approved target-language realization of that speaker; and
• performance state: the emotion, pace, and delivery for one particular utterance.

The third must not silently replace the first two.

3.4 Versioned, reproducible artifacts

Every generated artifact records the source revision, analysis revision, translation revision, glossary revision, voice-profile revision, pronunciation revision, engine/model version, and quality-report version. Re-running a build with the same inputs must produce the same logical result or a recorded, explainable difference.

3.5 Quality gates, not optimistic completion

A stage is complete only when its required artifacts exist and its hard quality gates pass. Warnings may be accepted with an explicit reason. Critical semantic, attribution, pronunciation, or technical errors block release.

3.6 English is the source of truth

The immutable English source and its approved source-side meaning decisions are canonical. Imported UmbraAudio analysis is advisory until it passes the source review gate. A target-language issue does not silently rewrite English. If target translation reveals genuine source ambiguity, UmbraTrans records a source-side issue for the author or source operator to resolve.

4. System Boundary and Relationship to UmbraAudio

UmbraTrans is additive. The initial implementation must not change the behavior or data files of the existing UmbraAudio system.

English manuscript
        │
        ▼
┌──────────────────────────────────────────────────────────┐
│ Existing UmbraAudio                                      │
│ parse → character discovery → speaker attribution →       │
│ utterance/prosody data → approved English voice identity  │
└──────────────────────────────────────────────────────────┘
        │ read-only snapshot/adapter
        ▼
┌──────────────────────────────────────────────────────────┐
│ UmbraTrans source adapter                                │
│ normalize IDs, snapshot confidence, preserve provenance   │
└──────────────────────────────────────────────────────────┘
        │
        ▼
  Source Book Package (versioned)
        │
        ├── semantic/discourse enrichment
        ├── terminology and pronunciation preparation
        ├── target-language translation lanes
        ├── target-language voice casting
        ├── target-language TTS rendering
        ├── translation and audio QA
        └── assembly/export

4.1 What UmbraTrans consumes from UmbraAudio

The original English source file is the authoritative text artifact. UmbraTrans can accept either a raw manuscript or a completed UmbraAudio project; in both cases it performs its own structure-preserving parse when possible, retaining chapter, paragraph, page, heading, and source-offset information. UmbraAudio's parsed chapter text is an advisory cross-check, not the sole source of truth.

The adapter may read, without writing, the following kinds of information:

• project and source metadata;
• chapter order, titles, and source text;
• utterance order, text, type, and context;
• speaker names, aliases, demographics, vocal traits, and communication style;
• speaker attribution confidence and reasoning when present;
• emotion, pace, emphasis, pause, and instruction metadata;
• approved English voice references and voice status when available; and
• source pronunciation records and confirmed spellings.

These values are hints for speaker identity, segmentation, prosody, and voice direction. UmbraTrans assigns its own stable IDs, preserves the source hierarchy, and records an independent confidence and provenance value for every imported claim. It must not use a mutable database row ID, a renumbered utterance_index, or a display name as a durable identity.

The adapter must tolerate missing optional fields. It records unknown or needs_review rather than inventing confidence. In particular, a confidence value supplied by UmbraAudio is not treated as calibrated release evidence until it has been reviewed or validated by UmbraTrans.

The first adapter must not assume that a proposed identity-export endpoint exists. It must work from the currently available read-only database/JSON artifacts and may adopt a formal UmbraAudio export later without changing the UmbraTrans contract.

4.2 What UmbraTrans must not do to UmbraAudio

It must not:

• modify .umbra/project.db, speakers.json, voice_assignments.json, or voice files;
• renumber or rewrite UmbraAudio utterances;
• write translation text into UmbraAudio's source fields;
• reuse UmbraAudio's audio markers as target-language markers;
• call private UmbraAudio functions as a required integration boundary;
• change the current web UI, CLI, TTS behavior, or export behavior; or
• require an UmbraAudio migration before the first UmbraTrans prototype.

The preferred integration is a read-only adapter that creates a coherent snapshot. For SQLite, that means a read-only/backup connection or an online backup, not a call to a configuration loader or database class that creates directories, tables, or migrations as a side effect. JSON, voice references, and prompt artifacts must be copied or hashed from the same snapshot window. The adapter must be safe while an UmbraAudio batch is running.

If a future UmbraAudio version exposes a formal export endpoint, the adapter can use that endpoint without changing the contract. An integration test must prove that an import leaves all UmbraAudio files unchanged.

4.2.1 Coherent snapshot protocol

A snapshot is a versioned artifact, not a best-effort collection of files. The adapter creates a snapshot_id and records the source project path, source file resolution, schema versions, file hashes, timestamps, and any available generation markers.

The protocol is:

1. Resolve project.source_path against the project root using one documented rule. Reject missing, ambiguous, or unexpectedly external paths unless the operator explicitly approved that source location. Copy the raw source into UmbraTrans storage before parsing it.
2. Open the source database through SQLite's read-only or online-backup interface. Do not call umbraaudio.config.load_config(), Database.connect(), or any helper that creates directories, tables, or migrations.
3. Copy or hash speakers.json, voice_assignments.json, voice references, pronunciation records, and prompt artifacts from the same snapshot window. A file that changes while being copied is retried and then rejected if it cannot be stabilized.
4. Compare available generation/status markers and re-check file hashes. If the database, JSON, and audio artifacts cannot be shown to belong to one generation, fail closed and request a quiet source project or an explicit operator-approved mixed-generation import.
5. Write a snapshot manifest containing every source and hint artifact hash. Never write the snapshot back into the source project.

The integration test uses a WAL database, an active writer, a relative source path, spaces and Unicode in paths, and a read-only source-tree permission mode. It compares a complete before/after UmbraAudio file hash and configuration snapshot and proves that no new or modified UmbraAudio file was created by the import.

4.3 UmbraTrans data area

Each book has an isolated data directory, for example:

<umbratans-root>/{book-slug}/
├── source/
│   ├── snapshots/{snapshot_id}/
│   ├── source_book.v1.json
│   ├── source_text/
│   └── provenance.json
├── analysis/
│   ├── scenes/
│   ├── discourse_units/
│   ├── entities/
│   └── issues/
├── glossary/
│   ├── glossary.v1.json
│   └── pronunciation.v1.json
├── translations/
│   ├── fr-FR/
│   ├── it-IT/
│   ├── de-DE/
│   ├── es-ES/
│   ├── ru-RU/
│   ├── ja-JP/
│   └── zh-Hans/
├── voices/
│   ├── identity/
│   ├── capabilities/
│   └── profiles/{locale}/
├── audio/
│   ├── clips/{locale}/
│   ├── chapters/{locale}/
│   └── masters/{locale}/
├── quality/
│   ├── source/
│   ├── translation/{locale}/
│   └── audio/{locale}/
├── manifests/
└── logs/

The directory is separate from UmbraAudio's .umbra directory and is rooted outside the source project. Shared model weights and voice references may be referenced by immutable path or content hash, but target artifacts are never written into the source project.

4.4 Current UmbraAudio audio boundary

The current UmbraAudio TTS path is not assumed to be multilingual. Its request path, language setting, English reference samples, pronunciation handling, and audio markers are specific to the existing English production workflow. Target-language requests must pass an explicit locale/language to a target-capable adapter and must not be sent through an English-only fallback merely because the existing server is available.

UmbraTrans must not reuse the English Rainbow Passage as the canonical target reference. Each target voice profile has a target-language reference and, where supported, a target reference transcript. Prompt and voice caches are scoped by work, logical speaker, locale, voice revision, and TTS model; a filename-derived slug shared across projects or languages is not safe for multilingual production.

4.4a Target TTS capability registry

Before Phase 4, UmbraTrans registers one or more target engines in a versioned capability registry. An engine is not accepted merely because it accepts arbitrary text; it must publish and pass a benchmark for each supported locale. This specification defines the contract and readiness gates; it does not claim that a particular provider currently supports all seven locales.

Each TTSCapabilityProfile records:

• engine and model identity, version, weight/config hash, and license;
• supported language/script/locale combinations;
• supported voice IDs and whether cloning, voice design, or both are available;
• reference-audio language and transcript requirements;
• pronunciation, SSML/phoneme, stress, pitch-accent, and lexicon controls;
• maximum text/span size, segmentation behavior, and supported output formats;
• language identification and synthesis metadata;
• concurrency, timeout, retry, and cancellation behavior; and
• measured quality, pronunciation, identity, and fallback results for the pilot.

A preflight request includes locale, script, voice profile, render-span lengths, pronunciation plan, and required output format. It returns pass, blocked, or unsupported, with machine-readable reasons. A blocked locale/voice combination never reaches generation. The all-locale v1 goal means that every requested locale has at least one validated engine/profile path; it does not require one engine to support every locale.

4.5 Reuse assessment

UmbraAudio supplies useful upstream evidence, but UmbraTrans must not confuse existing conveniences with a durable multilingual contract.

UmbraAudio capability	UmbraTrans use
Chapter and utterance segmentation	Advisory alignment hints; re-segmented into source/target semantic units
Speaker profiles, aliases, voice traits, and English prosody	Seed data for source meaning frames and identity contracts
Approved English voice references	Optional identity evidence and reference for engines with demonstrated cross-language support
Attribution confidence and reasoning	Advisory evidence with independent UmbraTrans confidence and review
Current English TTS and audio markers	Not reused as target-language generation or cache state
Current English-oriented WER/quality checks	Not reused as translation or CJK release gates
Current database row IDs and mutable indices	Never used as stable cross-language IDs
Proposed identity-export work	Optional future input; not a prerequisite for the adapter

This assessment keeps reuse useful while making every missing contract an explicit UmbraTrans responsibility.

5. Canonical Source Book Model

The source model is the reusable foundation of UmbraTrans. It must be more expressive than a list of sentences and more stable than a particular LLM response.

5.1 Hierarchy

WorkEdition
└── Chapter
    └── Scene
        └── Beat / dramatic situation
            └── MeaningBlock / discourse block
                └── Translation unit
                    └── Source span / clause
                        └── Speaker turn or narration span

TranslationRevision
└── TargetBlock
    └── TargetSpeechUnit
        └── Target render span

The source hierarchy describes the English work; the target hierarchy describes one locale-specific revision. TargetSpeechUnit is not required to mirror one source utterance. A target block or speech unit may merge, split, or reorder source units while retaining explicit alignment links.

Not every book has an explicit scene break. Scene boundaries may be inferred and must be marked as inferred. Not every unit is dialogue. The model supports narration, dialogue, inner thought, written text, signs, letters, headings, captions, and front/back matter.

5.2 Required hierarchy records

Record	Stable identity	Required information
WorkEdition / Book	book_id	source language, title, author, edition, rights/provenance, source hash
Chapter	chapter_id	order, title, source text hash, front/back-matter role
Scene	scene_id	chapter, boundaries, participants, setting, time, viewpoint, goal, conflict, stakes, outcome, confidence
Beat	beat_id	scene, turn in action/communication, causal links, tension/change
Discourse block	block_id	scene, speaker/topic continuity, rhetorical function, preceding/following references
Translation unit	unit_id	source text, type, speaker, addressee, speech act, meaning frame, dependencies, risk flags
Source span	span_id	unit, character/line offsets, source hash, optional page/edition anchor

IDs are opaque and stable within a book revision. They must not depend on a translated display name or a database row number that can change after re-indexing. The identity registry persists speaker IDs, aliases, role instances, merge/split decisions, and supporting evidence across source revisions. An automatic merge or identity rename is never treated as harmless; it creates a reviewable identity revision and invalidates the affected target artifacts.

5.3 Scene meaning frame

Each scene receives a structured SceneMeaningFrame containing, where supported by the source:

• scene purpose and immediate objective;
• participants and non-speaking entities;
• relationships and changes in relationship;
• physical setting and relevant time period;
• point of view and narrative mode;
• initiating event and expected outcome;
• conflict, threat, danger, stakes, and urgency;
• promises, demands, commands, warnings, secrets, and revelations;
• emotional trajectory and turning points;
• chronology and causal links;
• unresolved references, ambiguities, and source issues; and
• translation constraints, including terms that must remain consistent.

The frame is an evidence-bearing analysis, not an invitation to add plot facts. Every non-obvious claim records supporting source unit IDs and confidence.

5.4 Utterance meaning frame

Each translation unit carries a MeaningFrame with at least:

{
  "speech_act": "assertion",
  "propositions": [
    {
      "text": "The speaker reports a direct order from an authority.",
      "source_spans": ["span_..."],
      "certainty": 0.96
    }
  ],
  "intent": "warn the listener without openly defying the authority",
  "stance": "guarded",
  "emotion": "fearful",
  "addressee_ids": ["speaker_..."],
  "references": ["entity_..."],
  "terminology_ids": ["term_..."],
  "dependencies": ["unit_..."],
  "ambiguities": [],
  "translation_risks": ["register", "implicature"]
}

propositions are semantic obligations, not a demand for one-to-one sentence mapping. They allow validation to compare what was said even when the target uses different syntax or splits one English sentence into several target sentences.

5.4a Fail-closed identity readiness

Speaker identity is a release prerequisite, not a best-effort annotation. The UmbraTrans identity registry stores, for every logical speaker:

• stable speaker_id and speaker kind (named_character, recurring_role, scene_role_instance, group, ai, or narrator);
• canonical English name, aliases, titles, and role scope;
• source evidence spans and attribution evidence kind;
• confidence, review status, and unresolved alternatives;
• merge/split history and identity revision; and
• co-occurring speakers and cast-distinctiveness group.

An adapter may create candidates, but it must not silently merge aliases, turn a role into a named character, or assign a low-confidence pronoun. Pronoun, role-only, off-screen, group, and AI cases follow explicit evidence rules. If two candidates remain plausible, the unit is needs_source_review.

The source identity gate blocks translation and audio release when any speaking unit has an unresolved speaker, an unapproved role/instance policy, or an identity revision that has not been reviewed. Non-speaking mentions may remain unresolved only when they cannot affect a target utterance, and the exception is recorded. The current UmbraAudio display name, nullable character_id, and default confidence are never sufficient by themselves.

A source identity report lists every unresolved unit and every proposed merge/split. This gate is independent of whether a future Spec 17 identity export is implemented.

5.5 Source span and alignment rules

Every source span records character offsets into an immutable source chapter artifact. The source text is never silently normalized in place. A normalized derivative may be created, but it retains a mapping to the original and records normalization operations.

Target text may have any of these alignments:

• one source unit to one target unit;
• one source unit to several target units;
• several source units to one target unit;
• a reordered or nested alignment; or
• a non-textual rendering such as a stage direction or deliberate ellipsis.

Every target unit must point back to one or more source units. A target unit with no source anchor is a defect unless explicitly marked as an editor's note.

5.5a Source format and offset contract

Source offsets are Unicode code-point offsets into an explicitly identified immutable artifact, not offsets into an unversioned database string. The source package records the encoding, newline convention, Unicode normalization form, and whether offsets are absolute, chapter-relative, or page/paragraph-relative. Normalization maps every changed code point back to the raw source; CRLF conversion, combining marks, and repeated passages must not make two spans indistinguishable.

Each importer has a format contract:

• EPUB records spine order, heading hierarchy, anchors, footnotes, and unsupported markup;
• PDF records page and block anchors plus OCR/extraction confidence;
• DOCX records paragraph, heading, table, caption, and note anchors; and
• TXT/MD records byte/character encoding, heading, and line-ending provenance.

Images, tables, maps, captions, footnotes, and decorative elements receive an explicit preserved, omitted, nonverbal, or unsupported disposition. A book whose source coverage cannot be accounted for is blocked rather than silently flattened. Fixtures must cover CJK text, combining characters, CRLF, repeated passages, tables, images, and notes.

5.5b Ordered target render spans

A target block may contain multiple speakers, a group utterance, an overlap, or an approved non-textual event. It therefore cannot be represented safely by one target string and one speaker ID. Each TargetBlock contains ordered TargetRenderSpan records:

{
  "render_span_id": "de_block_004_span_02",
  "order": 2,
  "source_span_ids": ["span_041", "span_042"],
  "disposition": "translated",
  "speaker_id": "speaker_kainda",
  "surface_text": "…",
  "overlap_group": null,
  "pronunciation_plan_id": "de_pron_plan_004"
}

Required dispositions are translated, approved_omission, nonverbal, and editor_note. Omissions require source-review approval and a reason; they are never silently inferred by alignment length. Overlapping spans declare an overlap_group and explicit start/end ordering. A group or multi-speaker block is rendered as multiple spans or an explicitly defined group-performance track, never guessed from a single speaker.

The translation package, audio renderer, and assembler all consume this ordered span schema. A one-to-one target_text field is only a convenience projection for a single speaker span; it is not the canonical render contract.

6. Source Preparation and Author Control

The source preparation stage is the only stage where the source author has routine editorial authority.

6.1 Source preparation tasks

1. Preserve the original manuscript and compute a content hash.
2. Parse chapters, headings, paragraphs, page breaks, dialogue, and scene markers.
3. Validate encoding, extraction completeness, and paragraph order.
4. For scans, record OCR uncertainty and page/line anchors for later review.
5. Create immutable chapter artifacts and stable IDs.
6. Discover speakers, aliases, roles, entities, places, dates, and technical terms.
7. Analyze scenes, beats, discourse, and communication.
8. Build the English glossary, pronunciation candidates, and source-side issues.
9. Produce a source review package and a machine-readable source manifest.
10. Freeze the source revision before target translation begins.

6.2 Author review boundary

The author or source operator may edit:

• the English source text and normalization decisions;
• character identity, aliases, and relationships;
• intended meaning, speech acts, conflict, and scene interpretation;
• canonical names, terms, and pronunciation decisions that are source facts;
• style, register, and emotional intent; and
• unresolved source ambiguities.

The author does not need to:

• translate target-language passages;
• choose target-language voice models;
• approve every target sentence; or
• diagnose target pronunciation for every locale.

A target subsystem may raise a source_ambiguity issue. It cannot resolve that issue by silently changing the English source.

6.3 Source approval

A source revision is approved only when:

• all chapters and required front/back matter are accounted for;
• source coverage is complete, including explicit dispositions for tables, images, notes, captions, and unsupported elements;
• source text hashes match the manifest;
• speaker IDs are stable for all speaking units or exceptions are recorded;
• no speaking unit remains unresolved, ambiguous, or dependent on an unapproved role/instance/AI identity decision;
• scene boundaries and critical meaning frames have been reviewed;
• names, numbers, negations, and high-risk terms have no unresolved critical issues; and
• the author/source operator has approved the English preparation package.

The approval is recorded as an immutable event. Later target work references that exact source revision.

7. Translation Architecture

7.1 Target locale profiles

Each target locale has a versioned profile. At minimum it defines:

• BCP 47 locale and language/script pair;
• target writing system and text direction;
• sentence and utterance segmentation rules;
• quotation, dialogue, ellipsis, and emphasis conventions;
• number, date, time, measurement, and currency conventions;
• honorific, address, politeness, and register guidance;
• pronoun, kinship, and discourse reference behavior;
• target-specific typography and line-breaking rules;
• pronunciation and TTS capabilities;
• supported TTS engines and language-specific fallbacks; and
• target-specific human-review policy.

The initial locale set is:

Language	Locale	Script	Notes
French	fr-FR	Latin	Default French France profile; other variants may be added later
Italian	it-IT	Latin	Default Italian Italy profile
German	de-DE	Latin	Default German Germany profile
Spanish	es-ES	Latin	Default Spanish Spain profile; Latin American variants may be added later
Russian	ru-RU	Cyrillic	Stress, case, and inflection are first-class concerns
Japanese	ja-JP	Japanese mixed scripts	Kanji readings, pitch/accent, honorifics, and line segmentation matter
Simplified Chinese	zh-Hans	Simplified Han	Segmenter must not assume whitespace between words; punctuation and readings matter

Locale is not just a language label. A later fr-CA, de-AT, es-MX, or zh-Hant-TW must be a separate profile and release lane, not an accidental string substitution.

7.2 Translation job graph

Source package frozen
        │
        ├── Build book/scene summaries and discourse graph
        ├── Build entity/term/reference indexes
        └── Build target locale profiles
                    │
                    ▼
          Scene translation briefs
                    │
                    ├── Draft target units with source context
                    ├── Translate longer blocks with overlap
                    └── Run terminology and alignment checks
                    │
                    ▼
          Scene-level continuity/reconciliation pass
                    │
                    ▼
          Independent fidelity and fluency verification
                    │
                    ▼
          Target text freeze
                    │
                    ├── Pronunciation and TTS preparation
                    ├── Target voice casting/rendering
                    └── Final release validation

Each target language is an independent lane. A failure or revision in French must not silently alter German, Italian, Spanish, Russian, Japanese, or Chinese artifacts.

7.3 Scene translation brief

UmbraTrans maintains a work-level translation brief and style guide in addition to the scene brief. It records person and tense, narrative versus direct-speech register, literalization versus cultural-adaptation policy, names and titles, historical vocabulary, humor, dialect, honorifics, and any approved terminology decisions. A translation memory may provide approved examples, but it never replaces scene context or semantic checks.

Before target text generation, each scene receives a compact brief containing:

• source scene ID and source hash;
• scene goal, conflict, stakes, and outcome;
• participants and speaker/addressee map;
• relevant book and chapter context;
• preceding and following scene summaries;
• entity and term IDs with target forms;
• names, honorifics, and relationship rules;
• discourse conventions and point of view;
• chronology and causality constraints;
• source ambiguities and approved interpretations;
• required emotional/register trajectory; and
• risk classification.

The brief is generated from evidence-bearing source records. It is not a free-form summary that may contradict the source.

7.3a Hierarchical translation memory

Context retrieval is an explicit subsystem, not an unbounded conversation transcript. UmbraTrans maintains versioned memory artifacts at four levels:

• Book memory: premise, point of view, global style, terminology, and durable facts;
• Arc memory: a multi-scene conflict, promise, reveal, injury, relationship change, or objective;
• Scene memory: the current brief, participants, local chronology, and unresolved references;
• Entity memory: names, roles, relationships, preferences, and last-known state for each character, group, place, object, and term.

Every memory fact stores supporting source IDs, valid time range, confidence, and revision. A fact is never promoted to book memory solely because a model repeated it. Conflicting facts are retained with their evidence and marked unresolved until source review or an explicit narrative exception explains them.

Retrieval is deterministic: select the current scene, dependent prior scenes, referenced entities, active arc facts, and unresolved issues using a token budget defined by the locale profile. Compaction may shorten a summary but must preserve fact IDs, evidence links, and conflict markers. Target-language memory is separate from source memory and records which target wording and terminology were used.

A cross-scene benchmark covers names, promises, injuries, timeline facts, relationship changes, and repeated off-screen speakers. A translation that loses one of these facts fails even when each individual sentence is fluent.

7.4 Drafting rules

The target translator receives source units plus their scene brief and relevant context. It returns structured output:

{
  "target_unit_id": "fr_ch006_s02_u003",
  "source_unit_ids": ["ch006_s02_u003"],
  "target_text": "…",
  "alignment": [
    {"source_span_id": "span_001", "target_char_start": 0, "target_char_end": 42}
  ],
  "meaning_notes": ["preserves the warning force without adding a new threat"],
  "uncertainty": null,
  "risk_flags": []
}

The translator must:

• preserve propositions, modality, negation, speech act, and speaker intent;
• use the target language's natural grammar and idiom;
• keep names and terms consistent with the glossary;
• retain meaningful repetition, hesitation, and register when they carry character or dramatic information;
• avoid adding explanations, facts, dialogue, or emotional claims not present in the source;
• preserve the distinction between narration and speech;
• respect target punctuation and script conventions; and
• leave a low-confidence issue rather than fabricate a confident translation.

7.5 Translation unit boundaries

The existing UmbraAudio utterance segmentation is an input anchor, not an immutable translation boundary. A scene may require:

• merging several source units when the target grammar demands it;
• splitting a long source unit at a natural target pause;
• moving a clause across a target sentence boundary;
• preserving a repeated phrase for rhetorical effect; or
• rendering an English-specific sound or pun with a target equivalent.

The target renderer must still preserve source anchors, speaker identity, and the relationship between dialogue and narration.

7.6 Terminology, names, and cultural adaptation

A versioned glossary stores at least:

• stable term/entity ID;
• source form and aliases;
• target forms by locale;
• whether the form is translated, transliterated, retained, or localized;
• pronunciation/reading data;
• usage constraints and examples; and
• provenance and approval status.

Names, invented terms, ranks, units, organizations, technologies, and culturally specific references receive explicit policies. The system must not silently translate a name in one chapter and transliterate it in another.

Adaptation is permitted only when the source's communicative intent is preserved and the adaptation is recorded. Literalism is not a quality rule.

8. Translation Validation

Translation validation is a first-class subsystem, not an optional afterthought.

8.1 Hard checks

The following conditions block release when found in a critical unit:

• missing or duplicated source content;
• changed negation, modality, quantity, or certainty;
• changed speaker, addressee, or speech act;
• invented entity, event, motive, or threat;
• lost conflict, warning, promise, or emotional force;
• inconsistent name, title, or terminology in a way that changes identity;
• untranslated target-language content or accidental language mixing, except explicitly approved editor notes and registered source terms;
• broken source/target alignment; or
• unresolved source ambiguity presented as a confident target fact.

8.2 Soft checks

Soft checks produce warnings or review recommendations:

• awkward but understandable phrasing;
• register drift;
• repeated target terminology that may be stylistically valid;
• punctuation or typography inconsistencies;
• minor pacing or rhythm concerns;
• optional cultural adaptation opportunities; and
• low-confidence terminology or pronunciation decisions.

8.3 Validation methods

UmbraTrans uses several independent methods:

1. Deterministic checks: missing anchors, duplicate IDs, glossary violations, locale script checks, punctuation rules, numbers/dates, and untranslated segments.
2. Semantic comparison: compare source propositions and discourse obligations with the target, independent of word order.
3. Independent critic: a verifier model or reviewer receives the source, target, alignment, and brief and reports defects with evidence.
4. Continuity check: compare neighboring target units for names, register, tense, deixis, and discourse flow.
5. Back-translation: useful as a diagnostic signal, never the sole release gate.
6. Human review: required for high-risk units and a qualified, statistically useful sample of lower-risk units, with release sign-off defined by the locale profile.
7. Benchmark scoring: track results by language, scene type, risk class, and model version to detect regressions.

The same model that drafted a passage must not be the only judge of that passage. The system should support an independent model, a different prompt, deterministic checks, or human review.

8.4 Review queue

A unit enters review when it has any of the following:

• low source-analysis confidence;
• unresolved pronoun, deixis, or ellipsis;
• threat, conflict, legal, medical, technical, or culturally sensitive content;
• new entity, invented term, or unresolved name;
• target critic disagreement;
• low confidence in translation, alignment, or register;
• pronunciation ambiguity; or
• a repeated phrase that may carry a cross-scene reference.

Review decisions are stored with the unit, evidence, reviewer or model, reason, and resulting revision. A target review does not modify the source revision.

8.5 Quality report

Every target language receives a report containing:

• units translated and units blocked;
• coverage and alignment rates;
• critical, major, minor, and warning counts;
• speech-act, entity, number, negation, and terminology checks;
• critic agreement and disagreement rates;
• human-reviewed sample results;
• unresolved issues;
• model/provider/prompt versions; and
• release recommendation.

Thresholds are calibrated per locale and risk class. A single universal numeric score is not sufficient for a high-quality literary translation. Native review uses a documented rubric covering semantic accuracy, completeness, fluency, register/style, terminology, speaker intent, and target-language naturalness. Critical errors override an otherwise high average score.

8.6 Verification bundles and release benchmark policy

A verifier receives an immutable bundle, not a path that invites undeclared private reads. The translation bundle contains the source package, semantic package, source snapshot, locale profile, glossary, translation package, ordered render spans, and relevant memory retrieval. The audio bundle contains the audio manifest, approved target text and render spans, voice profiles, pronunciation plans, audio QA profile, rights manifest, and all reference evidence required by the checks.

Every issue is evidence-bearing and includes issue type, severity, source/target IDs, observed evidence, expected invariant, detector/reviewer, and repair state. A verifier that cannot load one of its declared inputs fails closed.

Each locale has a versioned TranslationQualityProfile and a human-reviewed benchmark created before production use. The benchmark covers narrative-heavy, dialogue-heavy, high-conflict, high-risk terminology, role/pronoun ambiguity, and long-range continuity passages. The initial pilot requires at least 20 representative scenes and 500 source units per locale, with every high-risk category represented; production sample sizes are calculated from the declared error rate and confidence interval.

The minimum release policy is fail-closed:

• zero critical omissions, additions, speaker errors, negation/modality errors, or identity-changing entity/number errors;
• zero major errors in the high-risk human-review set;
• a predeclared maximum major-error rate for the full benchmark, recommended at or below 0.1% before expansion;
• a qualified native reviewer signs off on every locale's high-risk set and stratified release sample, with a recommended mean rubric score of at least 4/5 and no rubric dimension below 3/5;
• independent adjudication is required when reviewer and model disagree; and
• no release occurs when the benchmark, reviewer qualification, or required sign-off is unavailable.

Thresholds are stored in the locale profile and changes create a new reviewed benchmark revision; they cannot be relaxed silently to make a build pass.

9. Voice Identity and Multilingual Audio Production

9.1 The cross-language voice problem

An English voice reference cannot be assumed to produce a reliable German, Russian, Japanese, or Chinese voice merely by changing the input text. Speech models, phoneme inventories, prosody, and training data differ by language. UmbraTrans therefore treats English voice identity as evidence and direction, not as a guarantee of a bit-identical target voice.

The release contract is:

A listener must recognize the same character, narrator, role, and relationship in every released language, even when the target voice has language-appropriate timbre and pronunciation.

UmbraTrans must choose and record one of these identity policies for a work:

• Same actor: the same acoustic performer is intended across all languages. This is allowed only when the selected engine demonstrates the required cross-language identity.
• Native equivalent: each locale uses a native-language performer who preserves the character's age, gender presentation, role, relative energy, and cast relationships.
• Hybrid: a stable broad identity is shared while accent, phonetics, and prosody are adapted to each target language.

The recommended default is hybrid/native equivalent: preserve the logical character and recognizable identity features, then use a target-native voice profile where exact cross-language cloning is not demonstrated. A project may choose a stricter policy, but it must not claim an identity level that its listening tests do not support.

9.2 Voice identity contract

The source speaker profile produces a language-neutral VoiceIdentityContract:

{
  "speaker_id": "speaker_kainda",
  "role": "character",
  "narrator": false,
  "identity_features": {
    "pitch_register": "mid",
    "timbre": "clear",
    "texture": "smooth",
    "energy_baseline": "assertive",
    "pace_baseline": "moderate",
    "formality": "conversational",
    "age_presentation": "young-adult",
    "accent_policy": "no unsupported accent",
    "distinguishing_trait": "measured, articulate delivery"
  },
  "relationship_constraints": [
    "distinct from the narrator",
    "distinct from the AI voice in shared scenes"
  ],
  "source_voice_reference": "voices/kainda_ref.wav",
  "source_voice_revision": "voice_004"
}

The contract is stable across languages. It does not contain a language-specific voice name or assume that a particular engine is available. The logical speaker model keeps separate IDs for named characters, recurring roles, scene-scoped role instances, group or collective speakers, AI/computer voices, and the narrator. A localized display name or title is an attribute of a locale profile, not the identity key.

9.3 Target voice profile

For each locale, UmbraTrans creates a versioned TargetVoiceProfile:

{
  "speaker_id": "speaker_kainda",
  "acoustic_instance_id": "de_acoustic_kainda_01",
  "cast_kind": "named_character",
  "scene_scope": null,
  "locale": "de-DE",
  "profile_revision": "de_voice_003",
  "engine": "target-tts-adapter",
  "model": "model-name-and-version",
  "voice_id": "native-or-multilingual-voice-id",
  "reference_audio": "voices/de-DE/speaker_kainda.wav",
  "identity_contract_revision": "identity_002",
  "pronunciation_lexicon_revision": "de_pron_007",
  "pronunciation_plan_revision": "de_pron_plan_004",
  "approved": true,
  "approval_evidence": "review/speaker_kainda_de.json"
}

A target profile must be approved for that locale before it can be used for a release. Different locales may use different native voices, provided they satisfy the same identity contract and cast-distinctiveness requirements.

9.4 Voice realization strategies

The renderer chooses the best available strategy and records which one it used:

1. Multilingual voice clone: use a model that explicitly supports the target language and preserves the source identity.
2. Target-language voice design: derive a native target voice from the identity contract, target-language voice description, and an approved target reference.
3. Hybrid identity anchor: use the source reference or speaker embedding only when the engine demonstrates cross-language support; combine it with target-language conditioning and native pronunciation.
4. Target voice pool: use a curated native voice whose measured identity and distinctiveness satisfy the contract.

If no strategy can meet the identity gate, the locale/speaker combination is not released. UmbraTrans must not choose a random voice merely to keep a batch moving. Every request must state the target language and locale explicitly, and the adapter must verify the returned audio is in that language. An unavailable multilingual model, an English-only server, or an unsupported voice is a blocked build condition—not permission to fall back silently to English, Edge-TTS, or a narrator voice.

9.5 Cast distinctiveness

Distinctiveness is checked per locale and per co-occurring cast, because phonetics and voice models differ across languages. The check considers:

• speaker confusion in target-language samples;
• similarity to the target narrator;
• similarity between characters who share scenes;
• intelligibility and naturalness;
• target pronunciation and prosody; and
• human recognizability of the character identity.

Raw speaker embeddings from English and German audio are not assumed to be numerically comparable. Cross-language identity is validated through the identity contract, target voice samples, structured descriptors, and human listening. Within-language embedding similarity remains useful as one signal.

9.5a Cast matrix and listener identity benchmark

Logical identity and acoustic casting are separate. A locale's cast matrix maps each logical speaker to one or more approved acoustic instances, and records whether a role is single, scene-scoped, group, overlapping, synthetic, or deliberately changed by scene. A group may use a shared group voice, multiple member voices, or a defined ensemble effect; the choice is explicit. A scene-role instance cannot silently inherit another scene's voice.

The listener benchmark is randomized and native-listener based. Each trial presents a reference utterance, a same-character utterance, and different-character controls from the target locale. It records same/different decisions, confidence, response time, listener locale, and a chance baseline. The acceptance threshold, confidence interval method, minimum sample size, and adjudication rule are declared in the locale quality profile before the test. The recommended pilot gate is at least 90% correct same-character identification, no more than 10% false identification of different characters, and a reported lower confidence bound above the chance baseline. A release cannot claim cross-language voice continuity without a passing benchmark for each locale policy.

9.6 Prosody and performance translation

English emotion, pace, and speech-act metadata are direction, not literal target values. The target performance pass maps:

• speech act and force;
• emotional intensity and restraint;
• target-language politeness and register;
• sentence rhythm and pause placement;
• emphasis and contrast;
• question, command, threat, and warning contours;
• target-specific pronunciation and stress; and
• the character's stable voice baseline.

The output is a target PerformancePlan that can be passed to a TTS adapter. A target language may require a different rhythm or emotional treatment to preserve the same communicative effect.

9.7 Target pronunciation

The target pronunciation subsystem produces a locale-specific lexicon, including:

• target spelling and reading;
• transliteration where appropriate;
• IPA or engine-supported phoneme data;
• language-specific stress, pitch accent, or syllable rules;
• context-sensitive readings for names and homographs;
• pronunciation audio previews;
• TTS override syntax or SSML where supported; and
• unresolved pronunciation issues.

Examples of language-specific concerns include Japanese kanji readings and pitch/accent, Simplified Chinese character readings and word segmentation, Russian stress and inflection, German compound words and proper names, French liaison and elision, Italian consonant length, and Spanish accent and dialect policy.

The target pronunciation lexicon is separate from the English source pronunciation data.

9.7a Pronunciation plan and engine negotiation

A lexicon entry is not yet a render instruction. Before synthesis, the pronunciation subsystem resolves every flagged term in a render span into a versioned PronunciationPlan:

{
  "plan_id": "de_pron_plan_004",
  "locale": "de-DE",
  "engine_capability_revision": "tts_cap_003",
  "surface_text": "…",
  "resolved_tokens": [
    {
      "text": "…",
      "reading": "…",
      "phoneme": null,
      "ssml": null,
      "source": "confirmed_lexicon"
    }
  ],
  "unsupported_terms": [],
  "manual_audio_references": [],
  "status": "ready"
}

The plan records whether the selected engine can honor each reading, phoneme, stress, or SSML instruction. Unsupported terms are blocked or routed to an explicitly approved pronunciation audio/manual-audio path; they are never silently guessed by the TTS model. The approved translated text remains unchanged. Only the resolved plan and any manual audio are passed to the renderer, and the plan is included in the audio cache key and QA bundle.

10. Audio Rendering and Audio Validation

10.1 Render unit

The audio renderer receives a target speech segment and a render request:

{
  "clip_id": "de_ch006_s02_u003_0001",
  "source_unit_ids": ["ch006_s02_u003"],
  "target_block_id": "de_block_004",
  "language": "de",
  "locale": "de-DE",
  "render_spans": [
    {
      "render_span_id": "de_block_004_span_01",
      "order": 0,
      "speaker_id": "speaker_kainda",
      "voice_profile_id": "de_voice_003",
      "surface_text": "…",
      "disposition": "translated",
      "pronunciation_plan_id": "de_pron_plan_004"
    }
  ],
  "performance_plan": {},
  "pronunciation_plan_revision": "de_pron_plan_004",
  "tts_capability_revision": "tts_cap_003",
  "engine": "target-tts-adapter",
  "model": "model-name-and-version",
  "seed": null
}

The request and response are immutable build inputs. The renderer writes one clip per render span (or an explicitly defined group-performance track), never guessing a speaker for a multi-speaker target block. approved_omission and editor_note spans are not spoken unless a release profile explicitly defines a separate performance treatment. The renderer records duration, sample rate, channels, engine, model, voice profile, capability revision, and generation timestamp.

10.2 Cache and invalidation

A clip cache key includes at least:

• target text hash;
• source unit, target block, and ordered render-span IDs;
• locale and locale-profile revision;
• speaker/acoustic-instance IDs and target voice-profile revision;
• performance-plan hash;
• pronunciation-plan and lexicon revisions;
• TTS capability profile, engine/model/weight/configuration versions;
• generation parameters; and
• radio/mix treatment revision;
• Audio QA profile and verifier/model versions.

The invalidation matrix is:

Change	Rebuild scope
English source text	Source analysis, all affected target translations, target audio
English meaning/analysis decision	Affected translation briefs, target units, and audio
Glossary term	Units containing that term, dependent continuity checks, and affected audio
Target translation text	That target locale's affected clips and chapters
Target pronunciation entry	Clips containing the term in that locale
Voice profile	That speaker's clips in that locale; cast checks; chapters containing that speaker
Performance plan	Affected clips only
Audio mix/radio treatment	Masters and affected assembly, not translation text
TTS model version	Audio clips requiring the new engine, subject to an explicit re-render policy
Source identity analysis or speaker merge/split	Affected source gate, translations, voice bindings, and audio; re-run dependent cast checks
Locale profile or memory retrieval policy	Affected target translation, verification bundle, and downstream audio/release
Verifier, ASR, or Audio QA model/profile	Affected quality report and release approval; audio may be rechecked without retranslation
Rights, metadata, or voice/model license	Release manifest and affected approvals; no automatic regeneration unless content policy changes
Co-speaker cast profile	Cast matrix, affected co-occurrence checks, chapters, and release approvals

10.3 Audio quality checks

Each clip and chapter is checked for:

Technical integrity

• file exists, is non-empty, decodes, and has the expected duration;
• no hard clipping, malformed frames, or truncation;
• correct sample rate, channel layout, and loudness profile;
• acceptable silence and pause boundaries; and
• no accidental cross-language or cross-speaker concatenation.

Speech intelligibility

• target-language identification;
• ASR transcript quality against the approved target segment, using WER for space-delimited languages and CER or an equivalent character-level metric for Japanese and Chinese;
• proper-name, number, and terminology recall;
• pronunciation of flagged terms and names;
• detection of omitted, repeated, or hallucinated speech; and
• intelligibility under the selected radio-program mix.

Voice identity

• target speaker matches the approved target voice profile;
• no confusion with co-occurring characters;
• stable identity across chapters;
• correct narrator/character distinction; and
• human-recognizable identity contract for a sampled set.

Performance

• intended emotion and speech act are perceptible without theatrical distortion;
• target-language rhythm and pauses are natural;
• threat, command, question, and warning contours are appropriate;
• voice remains intelligible over music/effects, if used; and
• no cross-language prosody artifact is accepted silently.

10.3a Audio QA profiles

Audio QA is configured per locale and pinned per release. An AudioQaProfile records:

• ASR model/version and reference normalization rules;
• WER or CER calculation, Unicode normalization, punctuation handling, and number/name normalization;
• language-ID model/version and false-positive/false-negative threshold;
• minimum name, terminology, and flagged-pronunciation recall;
• pronunciation benchmark cases and manual-audio policy;
• naturalness, prosody, and radio-mix human rating rubric;
• minimum clip, chapter, and final-master listening sample;
• hard and soft thresholds, retry policy, and escalation owner; and
• permitted ASR nondeterminism or adjudication process.

For Japanese and Simplified Chinese, the profile uses a documented CER or equivalent character-level metric after approved normalization; it never reuses an English whitespace-WER threshold. Every locale must pass clip and final-master checks. An audio build with no pinned QA profile is blocked.

Recommended initial hard gates, to be ratified per locale before the pilot, are: language identification confidence at least 0.99, WER at or below 0.05 for the selected Latin-script ASR profile, CER at or below 0.08 for Japanese and Simplified Chinese, 100% recall for explicitly flagged critical names/terms, 100% technical-integrity pass, and a native listener naturalness rating of at least 4/5. The cross-language identity profile must predeclare its same-character acceptance rate, false-identity rate, chance baseline, and confidence-interval method. A locale may tighten these values; it may not silently loosen them after seeing a build result.

10.4 Radio-program treatment

The default output is a speech-led radio-play audiobook:

• distinct narrator and character voices;
• restrained, consistent delivery;
• intentional scene transitions;
• clean speech-first mixing; and
• optional period-appropriate room tone, stingers, or music when rights and quality are confirmed.

Music and effects are a separate radio_profile layer. They must not obscure pronunciation or change the meaning of a scene. The first release may produce a clean audiobook master and a radio-treated master from the same approved speech clips.

10.5 Assembly and release

The assembler uses the target clip manifest and language-specific chapter timing. It can reuse an existing audio assembly implementation through an adapter, but UmbraTrans owns the target manifest and release metadata.

Each locale release contains:

• translated text files in one or more supported formats;
• chapter and clip manifests;
• approved voice profiles and identity contracts;
• translation and audio quality reports;
• cover/title/author metadata in the target language;
• rights and provenance records; and
• final M4B/MP3/WAV outputs according to the release profile.

A release is never assembled from a mix of locales or from unapproved clips.

10.6 Translated-book rendering

The target text renderer consumes the frozen target blocks and produces a reader-facing book while retaining the structured translation package and alignment sidecar. It must:

• preserve chapter order, headings, front matter, back matter, and intentional scene breaks;
• apply target-language punctuation, quotation, typography, numerals, and script rules;
• keep speaker identity and dialogue/narration boundaries semantically correct;
• avoid exposing analysis notes, confidence values, or TTS-only pronunciation directives in the reader-facing text; and
• produce target-language metadata and credits without silently translating legal or attribution information.

The first text export is UTF-8 Markdown plus the structured package. EPUB, DOCX, and PDF exporters are downstream adapters and must be tested against the same frozen target revision. TTS-only rendering changes, such as pronunciation hints, remain separate from the approved translated text.

11. Versioned Data Contracts

All contracts use a schema name and version. Unknown fields must be ignored by older consumers; missing required fields must fail validation rather than be silently defaulted.

11.1 Source Book Package

{
  "schema": "umbra.source_book/v1",
  "book_id": "book_deal_hunter",
  "source_language": "en",
  "source_revision": "source_007",
  "snapshot_id": "snapshot_20260923_001",
  "identity_revision": "identity_002",
  "coverage_manifest": "source/coverage.v1.json",
  "title": "Deal Hunter",
  "author": "B. D. Murphy",
  "source_hash": "sha256:...",
  "provenance": {
    "source_path": "…",
    "edition": "author manuscript",
    "rights_status": "author-owned",
    "prepared_by": "…",
    "prepared_at": "2026-09-23T00:00:00Z"
  },
  "speakers": [],
  "chapters": [],
  "scenes": [],
  "units": [],
  "entities": [],
  "terms": [],
  "issues": [],
  "approval": {
    "status": "approved",
    "revision": "source_007",
    "approved_at": "2026-09-23T00:00:00Z"
  }
}

The arrays may be stored in separate files for large books, but the package manifest must identify the parts and their hashes.

11.2 Translation Package

{
  "schema": "umbra.translation/v1",
  "book_id": "book_deal_hunter",
  "source_revision": "source_007",
  "source_snapshot_id": "snapshot_20260923_001",
  "source_identity_revision": "identity_002",
  "locale": "de-DE",
  "translation_revision": "de_007",
  "locale_profile_revision": "de_profile_002",
  "glossary_revision": "glossary_003",
  "chapters": [],
  "units": [
    {
      "target_unit_id": "de_ch006_s02_u003",
      "source_unit_ids": ["ch006_s02_u003"],
      "target_text": "…",
      "speaker_id": "speaker_chief_guard",
      "render_spans": [],
      "alignment": [],
      "meaning_obligations": [],
      "risk_flags": [],
      "status": "validated"
    }
  ],
  "quality_report": "quality/translation/de-DE/report.v1.json",
  "approval": {
    "status": "approved",
    "revision": "de_007"
  }
}

The target_text and speaker_id fields in this example are convenience projections for a single-speaker target unit. render_spans is the canonical field for multi-speaker, group, overlap, omission, and nonverbal blocks.

11.3 Voice Identity Contract

The contract is referenced by every target voice profile and every rendered clip. It must be immutable for a given identity_revision.

11.4 Audio Build Manifest

{
  "schema": "umbra.audio_build/v1",
  "book_id": "book_deal_hunter",
  "source_revision": "source_007",
  "source_snapshot_id": "snapshot_20260923_001",
  "source_identity_revision": "identity_002",
  "locale": "de-DE",
  "translation_revision": "de_007",
  "voice_identity_revision": "identity_002",
  "audio_revision": "de_audio_004",
  "clips": [
    {
      "clip_id": "de_ch006_s02_u003_0001",
      "source_unit_ids": ["ch006_s02_u003"],
      "target_unit_id": "de_ch006_s02_u003",
      "render_span_ids": ["de_block_004_span_01"],
      "speaker_id": "speaker_chief_guard",
      "voice_profile_id": "de_voice_003",
      "path": "audio/clips/de-DE/de_ch006_s02_u003_0001.wav",
      "status": "validated"
    }
  ],
  "chapters": [],
  "quality_report": "quality/audio/de-DE/report.v1.json"
}

11.5 Subsystem ports

The initial implementation may use local Python modules, but the logical boundaries are fixed:

class SourcePackageReader(Protocol):
    def load(self, book_id: str, revision: str) -> SourceBookPackage: ...
    def snapshot(self, umbraaudio_project: Path) -> SourceBookPackage: ...


class SemanticAnalyzer(Protocol):
    def analyze(self, source: SourceBookPackage) -> SemanticPackage: ...


class Translator(Protocol):
    def translate_scene(self, request: TranslationSceneRequest) -> TranslationDraft: ...
    def reconcile_scene(self, request: TranslationReconciliationRequest) -> TranslationDraft: ...


class TranslationVerifier(Protocol):
    def verify(self, bundle: TranslationVerificationBundle) -> TranslationQualityReport: ...


class TargetVoiceProvider(Protocol):
    def get_or_create_profile(self, contract: VoiceIdentityContract, locale: str) -> TargetVoiceProfile: ...


class TargetTTS(Protocol):
    def preflight(self, request: TTSPreflightRequest) -> TTSPreflightResult: ...
    def synthesize(self, request: SpeechClipRequest) -> AudioClipResult: ...


class TTSCapabilityRegistry(Protocol):
    def get(self, locale: str, engine_id: str) -> TTSCapabilityProfile: ...


class AudioVerifier(Protocol):
    def verify(self, bundle: AudioVerificationBundle) -> AudioQualityReport: ...

These are logical interfaces, not permission to import or mutate UmbraAudio internals. TranslationVerificationBundle and AudioVerificationBundle are immutable, versioned collections of the contracts described above. They are constructed by the orchestrator, content-addressed, and passed explicitly to verifiers. A verifier may not silently read a private project file, call a mutable database helper, or fetch an unpinned model.

TranslationVerificationBundle contains SourcePackage, SemanticPackage, source snapshot/coverage evidence, LocaleProfile, glossary, TranslationPackage, ordered render spans, and the exact memory retrieval used for the scene. AudioVerificationBundle contains AudioBuildManifest, approved target text/render spans, TargetVoiceProfiles, PronunciationPlans, AudioQaProfile, rights evidence, and reference audio/transcripts.

12. Orchestration, State, and Scheduling

12.1 Per-locale state machine

SOURCE_RECEIVED
  → SOURCE_SNAPSHOT_READY
  → SOURCE_NORMALIZED
  → SOURCE_SEMANTICALLY_ANALYZED
  → SOURCE_IDENTITY_READY
  → SOURCE_MEMORY_READY
  → SOURCE_APPROVED
  → LOCALE_PROFILE_READY
  → SCENE_BRIEFS_READY
  → TRANSLATION_DRAFTED
  → TRANSLATION_RECONCILED
  → TRANSLATION_VALIDATED
  → TEXT_FROZEN
  → VOICE_PROFILES_APPROVED
  → TTS_CAPABILITY_READY
  → AUDIO_RENDERED
  → AUDIO_VALIDATED
  → ASSEMBLED
  → RELEASED

A failure records the stage, attempt, error class, affected IDs, and recovery action. A locale can move backward to the earliest invalidated stage without resetting unrelated locales.

12.2 Scheduling

• Source analysis is a shared prerequisite for all target languages.
• The source identity gate and hierarchical memory must be ready before translation drafting; unresolved speaking identity blocks dependent scenes.
• After source approval, target language lanes may run in parallel.
• Within a language, scene briefs and memory retrieval precede scene translation.
• Translation of neighboring scenes may overlap for continuity, but each target unit has a single owning scene and revision.
• Pronunciation and voice preparation may proceed after a text candidate exists, but release audio waits for a frozen, validated target text.
• TTS capability preflight and pronunciation-plan resolution precede synthesis.
• TTS generation is resumable at render-span/clip granularity.
• Assembly waits for all required chapter clips, overlap/group tracks, and chapter-level quality checks.
• A release waits for all required manifests, metadata, rights records, reviewer sign-offs, and reports.

12.3 Idempotency

Every job has a stable job_key derived from its input revisions. Re-running a completed job does not create a new revision. A changed input creates a new revision and records the dependency edge that caused the invalidation.

12.4 Content-addressed dependency graph

Reproducibility is implemented as a content-addressed dependency graph, not as a log line. Every artifact records hashes for:

• raw source snapshot, source parse, semantic analysis, identity registry, and memory;
• glossary, locale profile, translation brief, prompt, retrieved context, and target text;
• TTS capability profile, model/configuration/weight hash, voice profile, pronunciation plan, and generation parameters/seed;
• translation verifier, ASR/QA models, Audio QA profile, and radio/mix profile; and
• rights, metadata, credits, and release policy.

Canonical serialization is UTF-8 with sorted keys and a documented number/Unicode policy. Revisions are append-only and committed atomically: a partially written job is never a readable release input. The graph records both upstream and downstream edges so a changed co-speaker profile, locale profile, QA model, or rights record invalidates exactly the affected cast checks, translations, clips, chapters, and releases.

The cache key and release manifest must include every dependency hash, not only the text and speaker name. A deterministic seed is used when the engine supports one; supported nondeterminism is recorded with an acceptance rule and repeatability measurement.

13. Review, Roles, and Approval

13.1 Roles

Role	Responsibilities
Source author/operator	English source, source analysis, intended meaning, glossary, source approval
Translation system	Drafting, terminology application, continuity, candidate generation
Translation verifier	Independent fidelity, fluency, and risk review
Target-language reviewer	Qualified native review, adjudication, and release sign-off for the locale profile
Audio director	Voice casting, performance direction, radio treatment, audio approval
Release operator	Metadata, rights, packaging, final release decision
UmbraTrans orchestrator	Scheduling, retries, provenance, state, and gate enforcement

13.2 Review policy

The system aims to review a small, high-value queue rather than every line. It still requires broad automated coverage and human sampling. Review effort is allocated by risk:

• critical/high-risk units: human review before release;
• medium-risk units: independent model review plus a human sample;
• low-risk units: automated checks plus a qualified native stratified release sample, unless a regression is detected.

Machine output may be auto-accepted into a candidate revision, but it is never an unattended release decision. Every required approval is bound to exact source, target, voice, model, and artifact hashes. Changing any of those inputs invalidates only the affected approval and downstream artifacts.

The author can inspect source-side issues and their downstream impact, but is not assigned routine target-language proofreading. A target-language reviewer may correct a translation without changing the English source. A proofreader must not silently make a new creative or identity decision; such a change is routed through the appropriate source or release review.

14. Public-Domain and Historical Book Support

Public-domain ingestion is a supported future source class, not merely another file extension.

14.1 Rights and provenance

For every source, record:

• author and original publication information where known;
• source edition and digitization source;
• jurisdiction-specific public-domain determination;
• scan/digitization provenance;
• whether the source contains modern editorial additions; and
• license or permission status for the specific edition and distribution.

Public-domain status is jurisdiction- and edition-dependent. It does not automatically clear the rights of a new translation, voice model, music library, or recording. The source rights status and the output rights status are separate fields. A public-domain source must still pass a rights gate before distribution, and every release records the rights holder, jurisdiction, credits, and output license.

14.2 Historical text preparation

Historical and public-domain sources require:

• OCR confidence and page/line provenance;
• spelling and typography preservation policy;
• archaic vocabulary and idiom handling;
• footnote/endnote policy;
• illustration, map, caption, and table handling;
• front matter and advertising removal or preservation policy;
• uncertain-name and uncertain-term issue tracking; and
• a normalized text derivative that never overwrites the source scan/extraction.

Modernization must be explicit. A source may be translated in its historical form, normalized for readability, or both, but the choice is recorded and cannot vary by target language without explanation.

15. Security, Privacy, and Operations

UmbraTrans is expected to handle unpublished manuscripts and author drafts.

• Prefer local or private model endpoints for source and translation data.
• Do not send a manuscript to a cloud provider without an explicit data-processing policy and project configuration.
• Store API keys outside manifests and source packages.
• Redact secrets and credentials from logs and quality reports.
• Preserve immutable source artifacts and write derived data to separate directories.
• Validate file paths and prevent path traversal in artifact assembly.
• Record model/provider requests sufficiently for reproducibility without exposing credentials or unnecessary private text.
• Make deletion and archival explicit; deleting a derived translation must not delete the approved source revision.
• Treat public-domain ingestion as untrusted input until rights and extraction checks pass.
• Treat manuscript text, OCR output, metadata, and retrieved reference material as data, never as model instructions; isolate them from system prompts and tool permissions.
• Maintain a provider allowlist and record retention, no-training, regional processing, and deletion settings before a provider may receive source or target text.
• Require authenticated, role-based access for review, approval, artifact download, and release operations; separate author, proofreader, audio, and release permissions.
• Encrypt private source and target artifacts at rest and in transit where the deployment requires it; keep encryption keys outside the artifact store.
• Resolve and validate paths with symlink-safe canonicalization before copying, hashing, or assembling files; reject traversal, device files, and paths outside the project root.
• Run untrusted parsing and model-input preparation in a restricted worker or container with no unnecessary credentials or write access.
• Record voice-actor consent, model license, reference-audio license, and music/effects rights evidence in the release manifest. A technically valid voice is not automatically authorized for distribution.

UmbraTrans maintains a threat model covering path traversal, prompt injection in manuscripts and OCR, malicious archives, model-provider leakage, unauthorized review, cache poisoning, voice-license violations, and cross-project artifact contamination. Security controls are release requirements, not optional hardening.

16. Proposed Package and Module Boundaries

The eventual implementation may live in this repository, but the first phase should be a separate umbratans package or service with no required changes to umbraaudio:

umbratans/
├── contracts/       # Versioned Pydantic/JSON schemas
├── adapters/        # Read-only UmbraAudio and file importers
├── source/          # Snapshots, normalization, IDs, hashes, provenance
├── semantics/       # Scenes, beats, discourse, propositions, memory
├── terminology/     # Entities, names, terms, cultural adaptation
├── locales/         # Language profiles and script/typography rules
├── translation/     # Briefs, drafting, render spans, verification bundles
├── voices/          # Identity contracts, cast matrix, capabilities, profiles
├── pronunciation/   # Target readings, plans, phonemes, previews
├── audio/           # Render requests, TTS adapters, cache, assembly
├── quality/         # Translation, audio, and release gates
├── orchestration/   # State machine, jobs, retries, invalidation
├── storage/         # Artifact manifests, atomic writes, locking
└── cli/             # Operator commands and status reporting

The first implementation should prefer standard-library and existing project-compatible clients where possible. New dependencies require a separate dependency review and must not silently change the UmbraAudio environment.

The recommended deployment boundary is a separate distribution, virtual environment, or container. UmbraTrans may live in the same source repository for development, but its installable package, dependency lock, model configuration, and output root must be separate from the umbraaudio distribution. Production code must not import private umbraaudio modules; it communicates through the read-only adapter and versioned contracts. The default UmbraTrans output root is outside the source project's umbraaudio data directory, even when both tools share a volume.

A subprocess integration test runs snapshot and build against a read-only source tree, uses a separate environment, and compares UmbraAudio file/configuration hashes before and after. This test prevents a packaging or dependency change from becoming an accidental UmbraAudio behavior change.

17. Implementation Plan

Phase 0 — Decisions and contracts

Deliverables:

• approve the target locale list and locale policy;
• define the source/translation/voice/audio schemas, including ordered render spans, verification bundles, and pronunciation plans;
• define the source snapshot, fail-closed identity, TTS capability, and release-quality contracts;
• select a small English fixture with scenes, conflict, threats, ambiguous references, named entities, invented terms, and multiple voices;
• define the source author approval boundary;
• define target review staffing, benchmark minimums, and release sign-off policy; and
• select candidate TTS engines and define the per-locale capability benchmark.

Exit criterion: every subsystem can be implemented against a versioned contract without reading another subsystem's private files.

Phase 1 — Read-only source adapter

Deliverables:

• perform a coherent, read-only snapshot of an existing UmbraAudio project while it may be running, with a snapshot ID and fail-closed generation check;
• parse the original source with structure/offset preservation where possible and use UmbraAudio chapter text as an advisory cross-check;
• import chapters, utterances, speakers, aliases, confidence, prosody, and pronunciation data when available;
• create stable UmbraTrans IDs and hashes without using mutable row IDs or display names;
• preserve missing/unknown fields explicitly;
• produce a source manifest and import report; and
• pass the active-writer, WAL, relative-path, Unicode-path, and read-only-tree integration tests.

Exit criterion: repeated snapshots are deterministic and the UmbraAudio project remains byte-for-byte and behaviorally unchanged.

Phase 2 — Source semantic enrichment

Deliverables:

• scene and beat detection;
• discourse and speech-act analysis;
• entity/reference graph;
• source meaning frames and propositions;
• fail-closed speaker identity registry and role/AI/group resolution;
• format-specific source anchors and normalization maps;
• hierarchical book/arc/scene/entity memory;
• glossary and source issue generation;
• source quality report and review package.

Exit criterion: a human can inspect and correct the English preparation, and every downstream unit points to a stable source context.

Phase 3 — Translation pilot

Start with two contrasting target lanes:

• one Latin-script European language, recommended de-DE; and
• one non-Latin or segmentation-sensitive language, recommended ja-JP or zh-Hans.

Deliverables:

• locale profiles and translation-quality profiles;
• translation briefs and hierarchical memory retrieval;
• draft, reconcile, and verify passes using explicit verification bundles;
• ordered render-span alignment and terminology validation;
• target text package and quality report; and
• a human-reviewed benchmark for both lanes.

Exit criterion: the fixture produces natural, meaning-preserving translations with no unresolved critical semantic or identity defects.

Phase 4 — Voice identity and audio pilot

Deliverables:

• language-neutral voice identity contracts and per-locale cast matrices;
• target voice profiles for the pilot locales;
• pronunciation lexicons, resolved pronunciation plans, and preview workflow;
• TTS capability registry and fail-closed preflight;
• clip-level rendering from ordered render spans and cache;
• pinned target-language ASR and Audio QA profiles; and
• randomized native-listener identity benchmark for the same character.

Exit criterion: a listener can identify the same character in both pilot languages, and all critical pronunciation/technical audio checks pass.

Phase 5 — All requested locales

Add French, Italian, Spanish, and Russian, then complete Japanese and Simplified Chinese with language-specific test suites and at least one passing TTS capability profile per locale. Each locale must pass its own profile, terminology, script, pronunciation, audio, and human-review gates. A locale is not considered complete merely because its text files were generated.

Phase 6 — Public-domain ingestion

Add provenance/rights checks, OCR confidence handling, historical text policy, and fixture books from multiple periods and scan qualities. Test both preservation and normalization modes.

Phase 7 — Production hardening

Add durable job recovery, artifact locking, cost/usage reporting, observability, release metadata, operator UI or CLI dashboards, regression benchmarks, backup/restore, retention/ deletion policies, provider allowlists, role-based access, encryption, sandboxed parsing, voice-rights evidence, and separate-environment packaging tests.

18. Test Strategy and Acceptance Criteria

18.1 Contract tests

• schema validation rejects missing IDs, invalid locales, and broken references;
• source snapshots are deterministic;
• all target units have source anchors;
• all target speakers have a voice identity contract;
• every audio clip has an approved target voice profile and a valid translation revision;
• active-writer snapshot tests prove no UmbraAudio file, directory, or configuration is created or modified;
• unresolved speaker, role, group, AI, or scene-instance identity blocks release;
• TTS preflight rejects unsupported locale/voice/pronunciation combinations;
• multi-speaker, merged, omitted, nonverbal, and overlapping target blocks round-trip through render spans; and
• verification bundles are complete and do not require undeclared private reads.

18.2 Semantic-context tests

Fixtures must include:

• a threat whose literal words are mild but whose scene context makes it dangerous;
• a command that is softened by politeness;
• a pronoun with multiple possible antecedents;
• a repeated line spoken by the same off-screen character;
• a named character mentioned in dialogue but not speaking;
• a scene transition with a changed cast;
• an idiom, pun, or culturally specific reference;
• numbers, negation, uncertainty, and modality; and
• an invented term whose meaning is established across scenes.

Tests must prove that the translator receives scene/beat context and that a locally fluent but contextually wrong translation is rejected.

18.3 Language-specific tests

• French and Italian: register, agreement, punctuation, and natural sentence rhythm;
• German: compound nouns, gender/article decisions, formal address, and correct names;
• Spanish: register, dialect policy, punctuation, and names;
• Russian: Cyrillic script, case, stress, inflection, and speech-act force;
• Japanese: kanji readings, mixed scripts, honorifics, segmentation, and target punctuation;
• Simplified Chinese: word segmentation without spaces, character readings, punctuation, and natural spoken syntax.

18.4 Audio tests

• mocked TTS tests for preflight, request/cache/invalidation behavior, and capability profile enforcement;
• target-language ASR checks with WER/CER appropriate to the script and pinned QA models;
• pronunciation-plan tests for names, invented terms, flagged words, and unsupported engine features;
• speaker identity tests within each locale, including groups, overlaps, and scene roles;
• randomized native-listener cross-language listening benchmark with a chance baseline and confidence interval;
• loudness, peak, clipping, silence, duration, and file-integrity tests; and
• failure tests for unavailable models, malformed responses, language mismatch, and accidental fallback.

18.5 Initial release targets

These are pilot targets, not claims of guaranteed literary quality:

• 100% of source discourse units have a target disposition;
• zero unresolved critical omissions, additions, speaker errors, negation errors, or high-risk entity/number errors in a release audit;
• zero major errors in the predeclared high-risk human-review set and no more than the locale profile's benchmark limit for major errors overall;
• 100% of target units are in the intended locale and script (or have an explicitly approved mixed-script exception);
• 100% of speaking units have a reviewed stable identity, including role/group/AI policy;
• all flagged pronunciation terms are resolved or explicitly blocked through a PronunciationPlan;
• 100% of release clips and final masters pass their pinned technical and intelligibility profiles;
• every locale has a qualified native reviewer, stratified release sample, adjudication record, and documented issue rate; and
• a listener can identify sampled recurring characters across languages at the declared acceptance rate with a reported chance baseline and confidence interval.

18.6 Snapshot, format, security, and packaging tests

• Snapshot tests cover WAL databases, an active writer, relative and Unicode/space paths, read-only source trees, and before/after source-tree hashes.
• Format fixtures cover EPUB structure, PDF page anchors, DOCX tables/notes, TXT/MD line endings, CJK and combining characters, repeated passages, images, and unsupported elements.
• Identity fixtures cover pronouns, off-screen voices, role-only speakers, groups, AI, merges, splits, and scene-scoped instances.
• Translation fixtures cover merge, split, reorder, approved omission, nonverbal spans, editor notes, overlap, and multi-speaker blocks.
• Memory fixtures cover names, promises, injuries, timeline facts, relationship changes, and repeated off-screen speakers across scenes.
• Security tests cover malicious archives, prompt injection, path traversal, symlinks, provider leakage, unauthorized approval, cache poisoning, and voice-rights evidence.
• A subprocess test runs UmbraTrans in a separate environment against a read-only source tree and proves that the UmbraAudio distribution and project remain unchanged.

19. Risks and Mitigations

Risk	Mitigation
Literal or context-blind translation	Scene briefs, discourse graph, semantic obligations, independent critic
Lost conflict, threats, or speaker intent	Explicit speech-act and scene-conflict analysis with hard checks
Character names drift across chapters	Stable entity IDs and versioned locale glossary
Wrong speaker attribution	Fail-closed identity registry, confidence/evidence fields, and source review queue
English voice does not transfer to target language	Language-neutral identity contract plus target voice profile and explicit strategy
Target voices collide	Per-locale cast checks and target-language listening review
Pronunciation errors	Target pronunciation lexicon, previews, ASR checks, and language-specific overrides
Model self-evaluation	Independent verifier, deterministic checks, benchmarks, and human sample
Long-context inconsistency	Hierarchical summaries, overlap, scene reconciliation, and target memory
Public-domain OCR or rights errors	Source provenance, confidence spans, rights gate, and non-destructive normalization
Silent quality degradation	Explicit fallback records, blocked release, and no automatic voice substitution
Cost and runtime growth	Incremental scene/clip caching, parallel locale lanes, and revision-based invalidation
Unreviewed cultural adaptation	Adaptation policy, evidence trail, and target-language review for sensitive content
Unsupported target TTS locale or feature	Versioned capability registry, per-locale preflight, and blocked unsupported combinations
Mixed-generation or relative-path import	Snapshot ID, raw-source resolution, read-only backup, generation/hash checks, and fail-closed import
Unresolved speaker or role identity	Fail-closed identity registry, evidence-backed review, and no unresolved speaking unit at release
Restructured target blocks lose speaker identity	Ordered render spans, dispositions, overlap/group rules, and span-level rendering
Verifier uses unpinned or private context	Explicit immutable verification bundles and pinned QA/model profiles
Cross-scene facts drift	Hierarchical memory with provenance, deterministic retrieval, and continuity benchmarks
Stale approval or cache contamination	Content-addressed dependency graph, append-only revisions, scoped caches, and hash-bound approvals
Package/dependency change affects UmbraAudio	Separate distribution/environment, no private imports, read-only subprocess integration test
Voice or model rights are unclear	Rights evidence, provider allowlists, consent/license records, and release gate

20. Open Decisions and Recommended Defaults

These decisions do not block the architecture, but they should be settled before the corresponding implementation phase:

1. Target-language review staffing: recommended target-language reviewers for high-risk scenes and a statistically meaningful sample of all other scenes.
2. Translation model/provider: keep the port provider-neutral; benchmark at least two model configurations before selecting a production default.
3. Voice identity policy: release on character continuity and approved target voice profiles, with bit-identical cross-language timbre treated as an optional capability.
4. Text output formats: begin with UTF-8 Markdown and a structured JSON package; add EPUB/DOCX/PDF exporters after the contract is stable.
5. Audio output formats: produce WAV intermediates, MP3 for distribution, and M4B when metadata and chapter navigation are validated.
6. Radio treatment: ship a clean speech master first; make music/effects an optional, separately licensed profile.
7. Public-domain policy: preserve the source edition and create an explicit normalized derivative; never silently modernize or discard front matter.
8. Source review policy: the author approves English preparation; target-language correctness is owned by the translation and release workflow.
9. TTS provider selection: benchmark at least one target-capable engine per locale; do not declare the seven-language audio target achievable until every locale has a passing capability profile and pronunciation/identity test.
10. Release thresholds: approve the per-locale benchmark size, major-error limit, reviewer qualification, adjudication process, and listener-identification threshold before the pilot; changes require a new benchmark revision.

21. Definition of Done for UmbraTrans v1

UmbraTrans v1 is complete when:

• an existing UmbraAudio project can be snapshotted through the coherent, fail-closed protocol without modification;
• the source package contains stable book/chapter/scene/unit/utterance identities, format/offset anchors, and a reviewed fail-closed speaker identity registry;
• scene, utterance, and hierarchical memory analysis is available to the translator;
• one English book can produce all seven target text lanes;
• each target lane has a locale profile, glossary, ordered render spans, translation QA report, qualified review evidence, and frozen revision;
• each target language has at least one passing TTS capability profile, approved target voice profiles for the full speaking cast, and resolved pronunciation plans;
• Japanese and Simplified Chinese pronunciation, script, and CER handling pass their language tests;
• each target audiobook has clip-level provenance, pinned Audio QA reports, and passing final-master checks;
• a randomized native-listener benchmark confirms recurring character identity across languages with a declared acceptance rate;
• all release artifacts are reproducible from a content-addressed dependency graph; and
• no UmbraAudio source, database, configuration, route, output, distribution, or dependency environment is modified by the UmbraTrans path.

22. Enterprise Control Plane

The multi-user project catalog, authorization, artifact lineage, commercial voice/pronunciation library, billing/entitlements, and distributed job infrastructure are specified separately in 19-enterprise-control-plane.md. UmbraTrans project data contracts are designed to be stored by that control plane without changing this per-book production boundary.

23. Summary

UmbraTrans is not a word-by-word translation layer placed after UmbraAudio. It is a meaning-aware production system that reuses UmbraAudio's English analysis and voice identity evidence while adding scene context, translation planning, target-language validation, multilingual pronunciation, target voice casting, and audiobook production.

The central architectural decision is to keep two things separate:

1. what the source means and who is communicating it; and
2. how a particular language and voice system expresses and performs it.

That separation allows the same character to be recognizable across English, German, French, Italian, Spanish, Russian, Japanese, and Simplified Chinese without pretending that all languages have the same grammar, pronunciation, or vocal physics.