LIFELINE

When the water rises, the first enemy is not the flood. It is the fog.

Comment 1

LIFELINE

When the water rises, the first enemy is not the flood. It is the fog.

What is:

LIFELINE is a human-led incident coordination system that turns partial, stale, and contradictory operational reports into inspectable plans, explicit evidence gaps, human approvals, and verifiable audit artifacts. It never dispatches a resource or decides whose life matters more.

Inspiration

I have seen the chaos surrounding wildfires closely enough to understand that the hardest part is not only the fire itself.

It is the information collapse around it.

A road that was open minutes ago can become unusable. A resource that appears available may already be committed elsewhere. Smoke changes visibility, routes disappear, and a report from one person can contradict another report from the same area. Meanwhile, the incident keeps moving.

I have seen how quickly an emergency can become an information problem: not because people do not care or do not act, but because everyone is trying to make decisions from a different fragment of reality. In those moments, people are forced to act under extreme time pressure, knowing that every decision matters.

The same pattern appears in floods, storms, evacuations, and humanitarian emergencies. The problem is often not the absence of resources. It is the absence of a shared reality clear enough to act on responsibly.

In disasters, the first enemy after the event itself is often operational fog: the gap between what happened, what was reported, what was verified, and what people believe is true.

During a disaster, minutes are not just a measurement of time. They are a measurement of uncertainty propagation. Every unverified report, outdated map, and disconnected decision increases the distance between what is happening and what people believe is happening.

The tempting answer is an AI system that "optimizes" who goes first. That is the wrong authority boundary. A fluent model can manufacture the appearance of certainty precisely when the evidence is incomplete. When a machine gets a disaster decision wrong, "the algorithm chose" is not an answer anyone can live with. Somebody must still answer who acted, on which facts, and why.

LIFELINE was built around a different question:

How can software make uncertainty useful without giving an algorithm the authority to make a life-and-safety decision?

The answer is not an AI commander or a chatbot that tells people what to do. It is an evidence system that keeps constraints, alternatives, human decisions, and unresolved questions visible from beginning to end.

The map is not the decision. The person is.

What it does

LIFELINE is a local, human-led operating system for an incident lifecycle:

incoming evidence
      ↓
briefing → deterministic validators → alerts
      ↓                         ↓
incident revisions       Verification Graph
      ↓                         ↓
planning kernel → simulations / alternatives
      ↓
human approval → audit ledger → export + offline verification

The first instinct during an emergency is to build a better map. But a map cannot tell you which information deserves trust. The hardest problem is not visualization. It is maintaining a shared reality while reality itself is changing.

LIFELINE's architecture follows directly from that insight:

  • Because uncertainty cannot be removed, LIFELINE does not hide it. Stale, unverified, and contradictory reports remain visible.
  • Because accountability cannot be delegated, LIFELINE does not automate the final decision. It produces inspectable proposals for an accountable human.
  • Because facts change, LIFELINE does not overwrite history. Reports create revisions, and decisions bind to a precise sealed plan.

It accepts typed reports about requests for help, responders and resources, shelters, and routes. It tracks provenance, freshness, verification state, and contradictions. A deterministic planning kernel can propose only combinations that satisfy explicit safety constraints. It does not silently average a rumor with a verified report, and it does not turn an unresolved contradiction into a confidence score.

For every request, the Verification Graph answers:

  • What evidence supports this proposal?
  • What evidence refutes or blocks it?
  • What is unresolved?
  • Which concrete human verification would discriminate between the competing possibilities?
  • Is a human approval the only remaining boundary, or is evidence still missing?

The output is deliberately a proposal, not a dispatch. A local authenticated coordinator must approve or reject an eligible proposal. That decision is recorded in a hash-linked ledger and can be checked offline.

LIFELINE is not trying to build the first AI emergency commander. It is trying to build something harder: an evidence layer for human coordination under uncertainty—one that helps people remain accountable when information is incomplete and consequences are irreversible.

The synthetic demo

The included scenario is a deliberately difficult synthetic flood incident, not a polished happy path. It contains:

  • two feasible proposed routes, each waiting for human approval;
  • a high-urgency request that is still unverified;
  • a conflicting request that cannot be treated as resolved;
  • reports whose declared freshness is degraded by the deterministic time gate;
  • resources, shelters, routes, capacities, medical compatibility, and explicit provenance;
  • alternative what-if scenarios, such as a bridge becoming confirmed closed or a shelter losing beds.

The browser room shows the map, proposal states, deterministic validation findings, the Verification Graph, simulations, and the optional Agent Briefing Mode. The local operations console supports creating incidents, appending or superseding typed reports, recomputing a sealed plan, viewing alerts, producing an optional cited briefing, and recording human decisions.

The demo is intentionally synthetic. It was designed to reveal failure modes that a simple dashboard hides: stale evidence, contradictory reports, missing corroboration, revisions, and a changed world invalidating an old plan.

Why it is different

Most emergency systems are optimized for displaying information. LIFELINE is designed for the moment when information stops agreeing with itself. It makes the operational fog visible instead of hiding it behind a recommendation.

LIFELINE differs in a few fundamental ways:

1. Uncertainty is part of the product, not an error state

A stale, unverified, or conflicting report does not disappear behind a score. It remains visible and changes the proposal state. The system says what it knows, what it does not know, and what evidence would change the result.

2. Deterministic constraints come before narration

The planning kernel uses explicit conditions such as resource availability, capacity, medical compatibility, route status, shelter capacity, provenance, and freshness. These are inspectable rules, not an LLM hunch.

3. Corrections preserve the past

Operational facts change. LIFELINE does not silently edit a report. Appending a report creates a new incident revision; a correction supersedes the operational snapshot while preserving the previous report in the hash-linked incident ledger. A new plan is bound to that exact revision. Old plans become stale instead of remaining quietly actionable.

4. A hash is not treated as a magic truth machine

Plans, Verification Graphs, simulations, agent briefings, and approvals carry independent integrity seals. Offline verification checks both byte integrity and semantic invariants: plan bindings, proposal coverage, allowed human-approval actions, duplicate decisions, and the interpretive-only agent boundary. A correct hash cannot make an invalid operational state acceptable.

5. The system has no dispatch authority

No API endpoint, browser button, or optional model call can dispatch a boat, send a responder, alert an external channel, or rank the value of human lives. The software creates evidence-based proposals; an accountable person makes the decision.

How we used OpenAI

LIFELINE includes an optional Agent Briefing Mode designed for the OpenAI hackathon. The important design choice is what the model is not allowed to do.

The deterministic lifecycle works fully offline. After the system has produced and verified a sealed plan and Verification Graph, an optional provider can receive a minimal, read-only packet. It returns only opaque citation selections from that closed packet. LIFELINE then renders every visible sentence locally from fixed templates and sealed values.

incident reports
      ↓
deterministic validators
      ↓
planning kernel + Verification Graph
      ↓
sealed, verified packet
      ↓
optional OpenAI citation selection
      ↓
local controlled rendering
      ↓
human reading guide

This means the provider cannot:

  • invent a family, route, resource, or metric;
  • change urgency, capacity, or evidence status;
  • alter an incident, plan, alert, or approval;
  • write operational instructions;
  • approve, reject, or dispatch anything.

It can only help a human read the sealed evidence through citations. The static demo includes a captured, independently sealed local run so judges can inspect the real controlled output without a key, backend, or provider call.

For development, the repository also includes a clearly labelled NVIDIA adapter that exercises the same constrained citation contract. The default documented hackathon path remains OpenAI. The point is architectural: the deterministic evidence and authority boundaries do not depend on which model is used as a read-only citation selector.

Technical architecture

LIFELINE is working software, not a concept paper or interface mock-up. The current tracked baseline contains 10,051 lines of code across 61 versioned files, including 5,380 lines of Python code, plus more than 100 automated regression tests.

Key components include:

  • Deterministic planning kernel — produces eligible proposals from hard constraints.
  • Typed scenario and report validation — request, resource, shelter, and route reports with complete provenance requirements.
  • Freshness and contradiction validators — evidence can only degrade from its declared state; contradictions stay explicit.
  • Verification Graph — supports, refutes, required artifacts, unresolved gaps, and human verification actions per proposal.
  • Incident backend — SQLite-backed snapshots and append-only, hash-linked revision events.
  • Local operator authentication — local roles for reporter, coordinator, reader, and admin actions.
  • Approval ledger — serialised, duplicate-resistant human decisions bound to an exact plan hash.
  • Simulation engine — declared alternative worlds, not hidden scoring or a winner-selection mechanism.
  • Alerts and briefing — deterministic attention feed and a human-readable incident view.
  • Export and offline verification CLI — plan, GeoJSON, Verification Graph, simulation, seals, approval chain, and agent briefing checks.
  • Browser operations room — map-based static room plus authenticated local operations console.
  • CRONOS-compatible trace support — planning events can be represented in an external trace structure.

The codebase also includes focused red-team work. It reproduced and fixed concrete implementation faults in approval concurrency, operator bootstrap, symlink and traversal boundaries, static-file handling, HTTP body handling, timestamp gates, and the agent briefing contract. These audits publish both confirmed findings and falsified vectors rather than treating a security checklist as proof.

Why I built it

The project was built on Linux in Codex by Anna Tchijova with ChatGPT 5.6 Terra and Luna. Its origin was deliberately outside the creator's usual work.

Anna usually uses ChatGPT to think through forensic and legal systems, where provenance, contradictory accounts, auditability, and human responsibility are central. LIFELINE began as a deliberately uncomfortable question: could the same principles used to preserve evidence in forensic systems help people coordinate when reality itself is changing every minute?

She asked ChatGPT for ten ideas that would force a genuine change of domain. Three converged into one direction: applying the principles of evidence preservation, provenance, and accountability to emergency coordination.

The collaboration was iterative rather than decorative: establish a boundary, close a module, write tests, audit it adversarially, and then compose the next module. The optional agent was deliberately added after the deterministic incident lifecycle existed. That sequence matters: it made it possible to give the model a narrow interpretive role instead of making it the system's source of truth or authority.

The repository is open source because emergency-coordination technology should not become a black box controlled by whoever owns the platform. A community facing a crisis should not need permission from a vendor to understand, adapt, or improve the tools it depends on. The people and organizations responding to a crisis should be able to inspect and audit the systems they rely on.

What we learned

The most important insight was that a useful system does not have to collapse uncertainty in order to be actionable. In fact, hiding uncertainty can make a system less safe.

We also learned that "AI assistance" becomes more credible when its authority is designed explicitly. A model can be genuinely helpful as a reading aid, while being prevented from creating facts, changing records, or issuing an instruction. That boundary is not a prompt alone; it is implemented in the packet shape, API surface, local renderer, artifact seals, verification logic, and tests.

Challenges we ran into

The hard part was not drawing a map. It was preserving a coherent contract across modules:

  • a report update must create a revision rather than overwrite history;
  • a changed revision must invalidate a previous approval target;
  • an evidence artifact must remain useful without becoming dispatch authority;
  • an integrity seal must be paired with semantic validation;
  • an optional model response must not become an untrusted source of visible operational claims;
  • the static judge experience must show a real agent result without exposing a key or pretending that a hosted page has a live backend.

Those constraints shaped the system more than the UI did.

What is next

LIFELINE is intentionally honest about its current stage: a functional research prototype with a clear path toward responsible evaluation. It has not been used in a real incident, is not field-validated, and is not production-ready. All shipped reports, people, routes, capacities, and decisions are synthetic.

Next steps are:

  1. Broader synthetic and adversarial scenario campaigns, including long incident histories, conflicting updates, scale, recovery, and temporal edge cases.
  2. Deeper invariant testing for causal ordering, crash recovery, replay, sustained concurrency, accessibility, and operator workflows.
  3. Tabletop exercises and structured feedback with operators and accessibility reviewers.
  4. Data governance, consent, authorization, retention, and incident-command integration before handling any real information.
  5. Only then, carefully governed evaluation using appropriately authorized real incident data in a non-operational research setting.

LIFELINE must not replace emergency services, incident command, local protocols, or the judgment of trained responders.

Links for judges

Closing

LIFELINE is not the ambulance. It is not the helicopter. It is not the hero.

It is the infrastructure that helps humans see the same operational reality at the same time — including what is known, what is uncertain, and what still needs to be verified.

Because in a disaster, clarity is not about having all the answers. It is about making sure everyone is looking at the same evidence before they act.

Disasters will always contain uncertainty. The goal is not to erase it with false confidence. The goal is to help humans see clearly enough to act responsibly.

Emergency technology should not make humans less responsible. It should make responsible humans better informed.

The map is not the decision. The person is.

Built With

OpenAI Codex — architecture, deterministic planning kernel, typed validators, simulation engine, 100+ regression tests GPT-5.6 — strictly bounded Agent Briefing Mode: citation selection only, zero operational authority Python 3.11+ — 5.380+ lines of deterministic backend code, SQLite-backed incident ledger SQLite — append-only, hash-linked revision events with offline verification HTML/CSS/JS — static browser operations room and map-based incident console, zero backend dependency for demo Vercel — static project deployment and synthetic incident room hosting CRONOS-compatible trace — planning events represented in external tamper-evident trace structure SHA-256 integrity seals — plans, Verification Graphs, simulations, and approvals independently verifiable offline

All:

10.051 lines, 61 files, 100+ tests — not a mock-up Deterministic planning kernel — proposals from hard constraints, not LLM hunches Verification Graph — explicit supports, refutes, gaps, and human actions per proposal Hash-linked incident ledger — corrections preserve history, old plans become stale Zero dispatch authority — no endpoint can send a responder or rank human lives Offline verification CLI — semantic invariants checked without network or API Agent Briefing Mode — OpenAI reads sealed evidence, never creates or alters operational facts

JUDGE: --- https://github.com/annatchijova/lifeline/blob/main/HACKATHON.MD

--- https://github.com/annatchijova/lifeline/

--- https://lifeline-openai-hackathon.vercel.app/

--- https://annatchijova.github.io/vigia/lifeline.html

Built With

Share this project:

Updates