# Veritas Live Rail channel `@oshun/v10-rail-channel-veritas-live` adapts `v1.veritas-live` to the V10 Rail. It owns the public event front door, the private followed-topics-and-sources face, transcript ingestion, bounded claim extraction, asynchronous evidence verification, claim-state publication, reference-only companion cues, followed-topic claim drips, rare breaking-event elevation requests, and the grounded morning briefing offer. ## First-party production rehearsal - `VeritasProductionMediaPipelineJobControl` is the first tenant-#2 control composition over `@oshun/live-media`'s canonical durable pipeline. It fixes tenant `veritas` and its operate/manage principals internally, so callers can enqueue, query, list, or cancel only Veritas jobs while the deployment supplies the shared service and durable store. It does not import a shared server/private entry point or create a V10 media stack. - `VeritasProductionPublisherGrantControl` is the matching product authority for canonical publisher credentials. It fixes tenant `veritas`, product owner `veritas`, and the immutable `v1.veritas-live` mapping after caller options, so callers can supply only a principal and stream UUID. The host injects the shared grant operations and optional registry; the control owns create/manage scopes and tenant-bound authenticate, rotate, and revoke calls. - `VeritasProductionViewerSessionControl` and `VeritasProductionPlaybackGrantControl` fix tenant `veritas` and their service principals over the canonical durable viewer-lease and signed-grant organs. `VeritasProductionProtectedPlaybackControl` composes those ports with entitlement and principal resolution while fixing `veritas.player-client.v1`, `veritas.immersive.v1`, and the bounded identity denial. Callers cannot replace any of those authorities through cast hostile options. - `VeritasProductionRehearsalPipeline` is a production-side, test-only seam. It compiles a bounded, contiguous program schedule, derives an immutable studio graphics package, and streams caller-supplied synthetic MPEG-TS chunks through a tenant-bound `shared-media-streaming` ingest port. - Program and segment identifiers, canonical instants, duration limits, exact coverage, source bindings, and lower-third copy are validated before ingest. Every segment must reference the one declared synthetic test stream. Rights and operations status are not accepted from callers: the compiler always writes `HG-3`, `not-reviewed`, `not-approved`, and `publishable: false`. - The pipeline audits the streamed bytes while the port consumes them. Empty or oversized chunks, partial consumption, byte-count drift, digest drift, and source mutation fail closed. Product source identity is separate from the substrate stream UUID. Requests bind that UUID to the exact `veritas` resource and canonical `live-media.v1/veritas/` edge path. - The returned receipt must attest the exact program, product source, tenant resource, canonical media path, byte count, SHA-256, publication UUID, and observed time. Ordered credential-free HLS and DASH URLs on reserved test hosts must point to that publication's exact canonical object prefix. These receipts exercise the future shared-media contract only; they are not converted into a live lane offer. - The graphics package is bounded broadcast data rather than interpolated SVG. It fixes the 16:9 safe area, restrained palette, no-crawl motion posture, and a permanent `TEST SIGNAL · NOT FOR AIR` label. The web preview validates each frame again before rendering and fails loudly on detached identity, timing, accessibility, or schema fields. - The rehearsal class intentionally exposes no publish, registration, lane acquisition, or go-live method. Its result includes the existing fail-closed `FIRST_PARTY_LIVE_VIDEO_GATE` status. A supervised local gate now carries synthetic rehearsal bytes through the SQL-backed Veritas pipeline, issues a signed protected playback grant through the product wrapper, and decodes both HLS and DASH inside the actual Rail panel in Chromium before proving QoE, release, zero presence, and immediate token revocation. That gate uses a test-only in-memory player-lifecycle adapter. The default Rail composition therefore remains `not_configured`; there is still no deployed durable Veritas player adapter, playback-route host, or long-running scheduler/publisher host. `@oshun/streaming` is the repository's Kafka/event package and is not misrepresented as media delivery. HG-3 remains a separate human decision covering the rights and operating model. This rehearsal is neither that proposal nor evidence that produced coverage may ship. ## Faces - The spectator face is the public Veritas Live front door. It reads the current published event snapshot and renders its exact event title, topic, tracking state, and four-bucket trust meter. It re-derives the meter from claims instead of trusting supplied totals and never reads private follow state. - Terminal verified, contradicted, disputed, and unverified claims must carry a signed provenance receipt bound to the exact session, claim, transcript locator, verdict, sources, and timestamps. Unsupported positive state fails closed before a tile can be cached. - The player face requests one canonical follow snapshot through a read-only host port explicitly bound to the authenticated user and tenant. The response must bind back to that audience, be no later than the requested instant, use unique strict topic/source records, and stay within bounded input limits. Missing, cross-audience, future, malformed, or expanded records fail closed; the channel never creates a parallel preference store. - The player tile exposes only bounded topic/source previews and exact derived totals. User and tenant identifiers do not enter the cached payload or deep link. Empty follow state is stated plainly without recommendations, trending substitutions, or absence pressure. - Both faces are cold-cache renderable, text-only safe, silent, and motionless. The public deep link is event-specific; the private link returns to the followed-topics-and-sources view with a state-derived snapshot token. ## Followed-topic delivery - `VeritasLiveDeliveryService` reads a tenant-scoped publication stream and the authenticated user's canonical Domain Veritas notification recipient. It reuses the existing followed topics, topic/story mutes, alert cadence, priority-only choice, and in-app modality instead of creating a second V10 preference store. - A `claim.verified` drip is emitted only when an exact, active followed topic matches and the publication points to a positive terminal claim. Source stance totals must reconcile, the signed provenance envelope must bind that exact claim, and a separately provisioned trust verifier must validate its Ed25519 signature. The drip contains no user or tenant identity, priority, or interrupt field. - Every drip uses the publication instant, a stable receipt-bound identity, a compact `Verified · …` glance, and a claim-and-receipt-specific V1 deep link. The merged Rail timeline retains all batching and daypart authority. - A published breaking event may create one `emergent` request grounded by a trusted positive anchor claim. The declared `rare` class is budgeted by the real Rail arbitrator (one accepted request per channel/day by default); topic and story mutes still suppress it. The request carries no grant field, and only the Rail can admit it at loudness 3 in an eligible daypart. ## Thread morning briefing - `VeritasMorningBriefingAudioService` reads a published edition from a host-bound daily-pipeline port. It accepts one through six uniquely identified stories, each with real source attribution, a governed confidence band, and any correction or retraction notices. - Composition and speech requests use Domain Veritas's real narrated-briefing pipeline, including correction-first ordering, all six confidence bands, and the synthetic-voice disclosure. Both estimated and synthesized audio must fit the 180-second Thread budget. - Missing or invalid publication data, TTS, synthesis, delivery, or lane authority remains explicitly unavailable. A valid result is only a channel-bound audio-lane offer; the channel cannot accept that offer or start playback. A Thread daypart transition may acquire it in the existing paused, user-authorized lane posture. ## Runtime contract - `VeritasLiveClaimSession` accepts ordered, final user-caption segments and ignores interim segments. It extracts with the existing rich `@veritas/claims` heuristic over bounded caption windows and retains the source segment, speaker, language, and media-time locator for every claim. - `ingestTranscriptStream` consumes a real async caption stream. Local audio enters the same path through `ingestLocalAudio`; that function throws `LocalSpeechToTextNotConfiguredError` unless the host supplies a real `VeritasLocalSpeechToTextEngine`. - `VeritasPipelineClaimVerifier` requires an evidence provider and a signed provenance issuer. Every evidence item must contain a canonical, reviewer-attested Veritas `Source`, an explicit stance, citation and locator provenance, independence assessment, and corroboration count. The verifier computes the governed nine-factor source-quality vector and passes that vector's composite into the existing Veritas fact-checking scorer. - Verification is asynchronous and deadline-bounded. State progresses through `detected` and `checking` to a terminal verdict, or remains visibly `unavailable` when no provider is configured, the deadline expires, or the provider fails. No source, stance, verdict, or local STT result is invented. - Final-caption ingress through synchronous candidate publication, including bound ticker listeners, has an explicit 250 ms budget. `claimTickerLatency()` returns per-claim observations, the measured maximum, and budget compliance without confusing that candidate deadline with the separate asynchronous evidence deadline. - Every published session snapshot carries an exhaustive rolling trust meter. `detected` and `checking` claims are pending; verified and contradicted claims retain their own totals; disputed, unverified, and unavailable claims remain visibly unverified. The four buckets always reconcile to the session total. - Every terminal verdict carries a linkable C2PA-aligned provenance receipt whose canonical bytes bind the session, exact claim and transcript locator, verdict, source assertions, and timestamps. The Node issuer delegates signing only to `@oshun/content-signing`'s `ClaimSigner`; the portable browser verifier validates Ed25519 against a host-supplied trusted-key registry, never a key embedded by the receipt. Altered or misbound receipts fail closed. - The web ticker withholds a terminal label, confidence, trust-meter credit, and source assertions until that receipt verifies locally. A checking receipt is pending; a failed or unavailable check is visibly unverified while its receipt link and diagnostic remain inspectable. - `bindVeritasLiveClaimTicker` publishes reference-only cues to the existing RA.4 slot. Claim text, verdicts, confidence, and assessment receipts remain in the channel-owned session model. This package does not search the network, publish a daily edition or live delivery feed, persist follows, configure a speech model, deliver audio, or attach itself to a third-party player. Production hosts must supply those authorities; they must also operate the receipt endpoint and provision the browser trust registry independently of signed envelopes. The Rail overlay continues to use explicit user clock synchronization and never seeks or controls the external video.