Skip to main content

cbc-bridge-service — AI Integration

Version: 1.0 Status: Draft Owner: Government / Emergency Last Updated: 2026-04-21

Companion: SECURITY_MODEL · APPLICATION_LOGIC · DOMAIN_MODEL

1. Policy Statement (read first)​

The hot path of cbc-bridge-service uses no AI.

Emergency cell-broadcast dispatch is time-critical, publicly-visible, and regulator-defensible. An LLM hallucinating a word in a P0 earthquake alert to every handset in Kabul is an unacceptable failure mode. All body content is human-authored in the upstream regulator/civil-defence workflow and delivered to this service as-is.

This document exists to make three things explicit:

  1. What AI is NOT used for (the large majority of decisions).
  2. Where AI may be used off the hot path (pre-approval review of drill template translations), always gated by human-in-the-loop.
  3. What would be required to change this policy (so that a future "AI-assisted emergency translation" proposal has a clear bar to meet).

2. AI is NOT used for​

Domain decisionWhy not
Content authoring of the broadcast bodyBodies are authored by NDMA / civil-defence / police analysts upstream. Hallucination risk is catastrophic for P0 emergencies.
Translation of the broadcast body at dispatch timeTranslations are authored upstream against the approved localisation glossary (customer-portal EP-CUST-09). The service does not translate.
Severity classificationDetermined solely by the authorised caller per their MOU. The service does not re-classify.
Geographic target selectionHuman-specified Cell-ID / polygon / region. No AI "this area needs an alert" decisions.
Drill timingDeterministic cron + admin-scheduled.
Adapter selection per MNOStatic per cbc.cbe_credentials_ref.adapter_kind.
Signature verificationCryptographic (HSM C_Verify). No ML model.
Caller authorisationDeterministic registry lookup.
Rate limitsDeterministic Redis counters.
Audit-chain verificationDeterministic hash comparison.

Any future reviewer who proposes "Why not just have an LLM classify the severity?" must reference this section and produce a formal risk-assessment ADR.

3. Where AI MAY be used (optional, off hot-path)​

3.1 AI-assisted translation-quality check for drill templates​

Purpose. When a platform admin authors a new drill body template (e.g. for the 2026-Q3 national drill), a secondary LLM review can flag translation mismatches between en, fa, ps, ar variants before the template is saved.

Not used on emergencies. Only on drill templates — and only at authoring time, not dispatch time. The live emergency hot path does not invoke any LLM.

Location. In the admin-dashboard drill-template authoring UI, not in this service. cbc-bridge-service receives only the approved, finalised template.

HITL gate. The LLM output is advisory only; a human admin must still click "Approve" before the template is saved.

4. No LLM on emergency payload — technical enforcement​

The following code-level guardrails enforce the policy:

  1. Static analysis gate. npm run lint:ai-blacklist (run in CI) searches the cbc-bridge-service source tree for imports from openai, @anthropic-ai/sdk, vllm, langchain, and equivalents. Any match fails the build.
  2. NetworkPolicy. The pod has no egress to any LLM endpoint (local or external). See DEPLOYMENT_TOPOLOGY §2.
  3. Envvar blocklist. A start-up guard rejects any env var matching ^(OPENAI|ANTHROPIC|OLLAMA|AI_)_.* except explicit allow-list (AI_FORBIDDEN_BANNER_TEXT used only in logs to make the policy loud).

5. Data-residency considerations (for the authoring surface)​

If a future phase enables AI-assisted translation review, the following constraints apply even though the call lives in admin-dashboard, not here:

ConstraintRationale
Local LLM onlyBroadcast drafts may contain sensitive operational detail (troop movements in disaster response, etc.). External LLM is a data-leakage risk.
No training on draftsDPA + zero-retention mode.
Anonymisation unneeded for drill templates (no PII)Drill bodies are generic.
Regulator visibilityDrill-template approval events logged to regulator evidence stream.

6. HITL flow (for drill-template authoring ONLY)​

Note: the LLM call is optional and happens in admin-dashboard, not this service.

7. AIProvenance VO (N/A)​

Because this service does not invoke any AI, it does not emit AIProvenance value objects. If the future AI-assisted authoring flow is built, the provenance lives on the drill-template aggregate in admin-dashboard, not on Broadcast.

8. What would change the policy​

For a future phase to place AI on the emergency hot path, the following would be required:

  1. Formal ADR proposing the change, reviewed by CTO, CISO, Legal, and NDMA.
  2. Risk assessment covering hallucination, prompt injection, and model drift.
  3. HITL gate for every AI decision that reaches dispatch.
  4. Fail-closed semantics (AI unavailable → reject, not proceed).
  5. Regulator consultation + sign-off.
  6. Dedicated SLO for AI latency / accuracy.
  7. Explicit retention policy for any prompt containing sensitive operational detail.

Absent all of the above, no AI is invoked in the hot path — period.

9. Summary​

AspectDecision
AI in hot pathNone
AI off hot pathOptional drill-template translation-quality check (in admin-dashboard)
EnforcementCI lint + NetworkPolicy + envvar blocklist
Review cadenceAnnual (with platform AI policy review)
OwnerGovernment / Emergency + CISO