LindaProtocol

From ICPAC early-warning signals to human-approved, auditable action readiness.

Comment

Inspiration

IGAD and county response teams already have early warning systems, forecasts, trigger rules, and ways to reach communities. The harder moment comes after a signal appears. Someone still has to decide what action fits the evidence, confirm that transport and partners are ready, get the right people to sign off, and leave a record that can be checked later.

That gap shaped Linda Protocol. We wanted a working desk for the people between a forecast and field action. The project is intentionally not another alerting app. It takes the evidence and channels already in the ICPAC and Husika ecosystem seriously, then focuses on the human decision process around them.

What it does

Linda Protocol turns a forecast or trigger into an activation readiness case. It records the source, retrieval time, and SHA 256 hash of the evidence, then evaluates a versioned demonstration policy in deterministic code. The case shows which action cards are eligible, what tasks need to be completed, and what is holding the team up.

Three distinct roles take part in approval: an early warning specialist, a county DRM officer, and an NGO or finance lead. A critical blocker prevents the case from moving forward. When all three approve, Linda creates an immutable decision packet, an Exercise CAP 1.2 alert, a Husika ready payload that validates against Husika's published schema, and an offline field bundle. It does not send public alerts or move money.

How we built it

We built Linda as a React and TypeScript web client backed by FastAPI and SQLite. The application uses typed API contracts, role based cookie authentication, and a guarded case state machine. Each case mutation is written to a hash chained audit log. Approval records use HMAC SHA 256 over a canonical case snapshot, so the application can verify that every signer approved the same record.

The data layer can consume ICPAC trigger and forecast surfaces, while recorded fixtures keep the demo usable when an upstream service is unavailable. The policy and action cards are reviewed YAML files with visible assumptions. We used WeasyPrint for the packet, lxml for CAP validation, JSON Schema for the Husika payload, and Material UI for the dashboard. Gemini is limited to structured assists for explaining evidence, ranking already eligible action cards, and suggesting a blocker category. It cannot change policy, tasks, approvals, or case state.

Challenges we ran into

The main challenge was scope. The first impulse in an early warning hackathon is to build messaging, a chatbot, maps, and every possible data feed. That would have overlapped with systems already used in the region and made the core decision problem easy to miss.

We also had to keep the prototype honest. Public upstream data can change or fail, so the interface distinguishes live, cached, stale, and replay evidence. The demo scenario includes synthetic escalation data, and it is labelled as such. We avoided treating team authored thresholds, costs, or action cards as government policy. We also kept the Husika boundary clear: Linda validates a payload against the published OpenAPI contract, but an authorised Husika operator must dispatch it.

Accomplishments that we're proud of

The best part of Linda is that the workflow can stop. A transport task marked as a critical blocker prevents a case from reaching review. A new assessment supersedes old approvals. A stop condition can revoke an approved case. Those are less flashy than a button that says activate, but they are closer to how accountable early action needs to work.

We are also proud that the output is inspectable. Judges can look at the policy trace, source hashes, task history, signatures, export checksums, and audit chain instead of taking a dashboard on faith. The project can produce four usable artifacts from the same approved record, including an offline bundle for a low connectivity setting. The path remains usable if the AI assists are unavailable.

What we learned

We learned that early warning is not only a data problem. It is a coordination problem with named people, limited lead time, incomplete evidence, and a need for clear accountability.

We learned to separate decision support from decision authority. An AI explanation can make a policy trace easier to read, but it should not decide whether a trigger fired, choose beneficiaries, release funds, or send an alert. We also learned that interoperability is more convincing when it is testable. Validating CAP XML and a Husika shaped payload gave us a useful boundary without claiming a production integration we do not have.

What's next for Linda Protocol

The next step is validation with county DRM teams, ICPAC, and humanitarian partners. They need to review the policy values, action cards, role definitions, and approval rules before any operational use. We would then replace the demonstration data and policy assumptions with authorised sources and locally agreed protocols.

On the technical side, we want to deepen the adapters for approved ICPAC data products, add partner controlled identity and signing, and complete a formal integration path with Husika. We also want to use the audit record for after action learning: what was approved, where readiness failed, how long each handoff took, and whether the action happened in time. Any operational deployment would keep human authorisation in the loop and preserve the Exercise boundary until partners approve a live service.

Built With

Share this project:

Updates