Live Transcription vs Hansard-Only Summarization Architecture

[c12i]

1. Context

Bunge Bits is evolving toward supporting two ingestion paths for parliamentary sessions:

A. Live-stream transcription → summarization
B. Hansard ingestion via odnelazm → summarization

Live transcription enables near real-time summaries but introduces infrastructure cost, operational fragility, and personal maintenance burden. Hansard-based summarization is cheaper and operationally simpler but introduces publication latency (typically 7+ days after sittings).

This discussion evaluates whether live transcription should remain a core architectural component.

2. The Problem

We need to decide whether Bunge Bits should:

1. Continue full live transcription.
2. Move to Hansard-only summarization.
3. Adopt a hybrid model (provisional live summary + canonical Hansard-backed update).

The decision must balance:

• Timeliness
• Cost
• Operational sustainability
• Maintainability
• Product differentiation

3. Goals

• Minimize recurring infrastructure cost.
• Eliminate single-operator dependency and personal compute bottlenecks.
• Preserve meaningful product differentiation.
• Maintain technical simplicity where possible.

Non-goals:

• Perfect real-time accuracy.
• Full verbatim transcript fidelity (unless strategically necessary).

4. Options Considered

Option A: Archived Live Stream Transcription + Summarization (Current Direction)

Pipeline:
Live stream → whisper (local/cloud) → transcript → summarization → publish.

Pros:

• Near real-time summaries (high recency value).
• Direct linkage between summary and stream.
• Competitive differentiation (fast coverage).

Cons:

• Compute-intensive (GPU or long CPU runtimes).
• Cloud cost or local machine dependency.
• Operational fragility (PC uptime required).
• Personal bottleneck risk.

Risks:

• Burnout.
• Funding instability.
• Inconsistent availability.

Option B: Hansard-Only Summarization via odnelazm

Pipeline:
Hansard published → ingest via odnelazm → summarize → publish.

Pros:

• Minimal compute requirements.
• Cloud-cheap and predictable.
• No live infrastructure dependency.
• Canonical source material (official record).

Cons:

• 7–10 day latency.
• Loss of “hot news” positioning.
• Reduced perceived urgency.

Risks:

• Weakening Bunge Bit's differentiation if recency is a core value.

Option C: Hybrid Model (Provisional + Canonical)

Phase 1:
Live lightweight transcription → provisional summary (clearly labeled).

Phase 2:
Hansard ingestion → re-summarize → update/replace summary.

Pros:

• Retains recency.
• Canonical correction layer.
• Clear versioning model.
• Best user-facing experience.

Cons:

• Most architectural complexity.
• Still requires live compute.
• Potential operator bottleneck if local.

Risks:

• Overengineering relative to user demand.
• Sustained maintenance overhead.

5. Key Decision Questions

1. Is recency a validated or inferred need?

   • Would journalists or analysts actively depend on same-day summaries?
   • Is engagement materially higher for fresh sessions?

2. What is the acceptable publication latency?

   • <6 hours?
   • <24 hours?
   • 7+ days acceptable?

3. What is the maximum sustainable monthly infrastructure cost?

4. Can archived live stream ingestion be event-triggered (only during sittings) rather than persistent?

5. Is full transcription necessary for archived live stream summaries, or would structured agenda-based extraction suffice?

6. Evaluation Criteria

We will evaluate options against:

• Monthly cost (target: near-zero to low predictable cloud cost).
• Operational independence (no constant local uptime dependency).
• Time-to-publish.
• Engineering complexity.
• User engagement metrics (if measurable).

7. Proposed Interim Strategy

Recommendation:

1. Default to Hansard-only summarization as baseline (stable, low-cost core).

2. Instrument demand for recency (analytics, user feedback).

3. Prototype constrained live summaries:

   • Event-driven.
   • Limited model size.
   • Explicitly labeled as provisional.

4. Re-evaluate after collecting usage data for 4–8 weeks.

This approach prioritizes sustainability first, differentiation second.

8. Open Questions

• Would users tolerate a clearly labeled “Provisional AI Summary (Live)”?
• Should summaries be versioned (v1 live, v2 Hansard-backed)?
• Is there a funding path that justifies real-time infrastructure?