Kabat One Earthquake early warningEarly warning Backlog

Kabat One · Product Manager assignment

Earthquake early warning for the Kabat One city platform

From client needs to a safe, phased plan the team can build

Prepared by Diego Augusto Ocampo Lagarda · November 2026

Scroll or press ↓Scroll

The brief

The assignment

  1. 01

    A municipal public safety client wants earthquake early warning inside the existing Kabat One city platform.

  2. 02

    They ask for one or more of three capabilities: alerts to key stakeholders and the public, automated emergency response, and post-event damage assessment.

  3. 03

    It must be fully integrated, using the real-time monitoring and microservices architecture the platform already has.

The task: understand the client's needs, propose a technical solution, define the work plan with risks, and describe how the teams work together.

1 · Client requirements

What the city asks for, in one page

Goal: warn people before shaking arrives, coordinate the response, and guide rescue afterward.

01

Early warning alerts

Real-time seismic data triggers alerts to services, hospitals, schools and the public.

Story: a duty officer gets the alert in seconds and can act before shaking.

02

Automated response

Planned actions run fast: stop public transport, close bridges and tunnels, send first responders.

Story: an operator approves a response plan, so no step is missed.

03

Damage assessment

Drone images, sensors and citizen reports become one live damage map.

Story: a commander sees the worst areas and sends help there first.

To brief the dev team: one goal, one user story per capability with "done" rules, and a list of what is not in version 1 (slide 7).

1 · Client requirements

What I still need to ask the client

AreaOpen questionWhy it matters
Alert dataWhich seismic agency feed, and what are its delay and format?Sets how fast we can alert
Who is alertedWhich groups, and who owns the message and the area?Avoids false or late alerts
Alert levelAt what magnitude or shaking level do we alert?Too many alerts, people ignore them
Automatic actionsWhich actions can run alone, and which need approval?Law and public safety
Systems to controlWhich transport, bridge and tunnel systems can we connect to?Decides what is possible
ScopeWhich of the three capabilities comes first? What can our platform already reuse?Sets version 1, avoids rework
SuccessHow does the city measure success? What are the budget and date?Sets scope and priority

2 · Technical solution

One flow: data in, check, decide, act

01

Data in

  • Seismic agency feeds
  • Sensors and drones
  • Citizen reports
02

Check

  • Trusted source and timing
  • Remove duplicates
  • Rate the event
03

Decide

  • Rules engine
  • Alert zones and levels
  • Mode set by each city
04

Act

  • Alerts to people
  • Response plans
  • Live damage map

Built on the existing Kabat One platform: microservices, real-time monitoring and audit log. One alert message in the CAP standard reaches every channel: cell broadcast (no app needed), mobile app, sirens, radio and TV. If one channel fails, the others still work.

  • CAP standard
  • Cell broadcast · app · sirens · radio · TV
  • Event streaming and message queues
  • Rules engine
  • Map (GIS) layer
  • Secure APIs

Secure APIs connect to seismic agencies, city systems and telecom operators.

2 · Technical solution

Automation, with a person in control where risk is high

ActionRiskMode
Alert services and hospitalsLow, easy to fixAutomatic
Alert the publicSeconds matter, false alarm costs trustAutomaticfrom a trusted feed, manual stop
Halt public transportAffects thousands of peopleApprovalsupervisor approves, or automatic if city policy says so
Close bridges and tunnelsHigh, a mistake can cause harmApprovalapproval needed
Send first respondersLife safetySuggestsystem suggests, dispatcher decides

Each city picks its mode in settings: same product, no custom code. Every action has a manual override and an audit log.

3 · Work plan

What goes first, and what waits

The city asked for one or more capabilities. I rank them by safety impact, time criticality, effort and risk, and dependencies. If the city wants only one, I recommend alerts.

Now

Early warning alerts

Most life-safety value, lowest risk. The other two need it. Waiting costs the most.

Next

Automated response

High value, higher risk. Needs city policy first. Starts as "suggest", then automates.

Later

Damage assessment

Matters after the quake, not before. Start with citizen reports, add drones and sensors later.

Not in version 1

  • New sirens or networks
  • Automatic bridge closing (approval first)
  • Damage detection from images by AI

How I run the backlog

  • Epics and stories, each with "done" rules
  • Refine with engineers before each sprint
  • Review with real operators, re-rank every sprint

3 · Work plan

Four phases, one safe step at a time

Phase 1

Discover

Close open questions, choose the data feed, define safety rules and tests.

Done: signed scope

Phase 2

Alerts MVP

Feed, checks, alerts to key groups and one public channel. Simulation mode.

Done: pilot with drills

Phase 3

Response

Response plans, approval modes, transport and bridge links, audit log.

Done: joint drill

Phase 4

Damage map

Drone, sensor and citizen data in one live map. Stakeholder training.

Done: city exercise

Research in Discover, integration testing in the next three phases, deployment at the end of each phase, and stakeholder training before each go-live. Two-week sprints with outcome goals. Indicative range: 4 to 6 months. Dates depend on feed access, city approvals and links to transport and bridge systems. Engineering sizes each phase in Discover, and we commit to dates with the client after that.

3 · Work plan

Main risks and how I reduce them

R1

Data feed delay

What can happenAlert arrives too late

How I reduce itMore than one feed, measure delay, alert only while still useful

R2

False alarm

What can happenPeople lose trust

How I reduce itChecks, thresholds agreed with authorities, manual stop, review after each event

R3

Channel fails

What can happenPeople are not warned

How I reduce itMany channels, backup power and links, health checks

R4

Wrong automatic action

What can happenTransport or bridge closed by mistake

How I reduce itApproval modes, simulation, override, rollback

R5

Peak load

What can happenPlatform slows at the worst time

How I reduce itLoad tests, separate alert service, priority queues

R6

Unclear responsibility

What can happenNobody owns the decision

How I reduce itWritten policy with the city, audit log, training and drills

R7

Expectations too high

What can happenAreas near the epicenter get little or no warning

How I reduce itState the limits in the contract and public messages. Measure warning time by zone

4 · Collaboration

One goal, three groups, one rhythm

01

Technical teams

Backend, frontend, UX/UI, QA, BI

  • Sprints with outcome goals. Clear requirements with "done" rules.
  • Engineering sizes cost and risk before we commit.
  • QA tests failure cases.
02

Public safety officials

Operators, supervisors, city leaders

  • Workshops to set alert rules and response plans.
  • Simulations with real operators.
  • They approve the policy.
  • Feedback after every drill.
03

External data providers

Seismic agencies, telecom, drone and sensor vendors

  • Agree on data format, delay and uptime.
  • Shared test environment.
  • Named contacts for incidents.

Everyone sees the same goal and gets one weekly update. Decisions and trade-offs are written down.

5 · Assumptions and next steps

What I assume, and how we will know it works

Assumptions

  • The city already runs the Kabat One platform and its real-time monitoring.
  • A seismic agency gives us a feed we can connect to.
  • The city owns the alert policy. We provide the tools.
  • We use existing channels (cell broadcast, sirens, apps). We do not build a new network.
  • Transport and bridge systems can be integrated.
  • We start with one pilot area, then the whole city.

Success measures (targets to agree)

  • Main: time from seismic feed to alert sent
  • Share of stakeholders who got the first alert
  • False alert rate
  • Drills passed with operators
  • Time to first damage map update
Next step

A kickoff workshop with the client to answer the open questions and start the Discover phase.

Backlog

And here is the proposed backlog

4 epics, 13 stories and 6 tasks, each with acceptance criteria.

  • E0Discover3 tasks
  • E1Alerts NOW6 stories · 1 task
  • E2Response NEXT4 stories · 1 task
  • E3Damage map LATER3 stories · 1 task

Open the backlog