Inspiration

It started with a simple, uncomfortable question: if something goes wrong in Poland tonight — a fire, a storm, a flood — do you actually know what to do, and where to go?

We didn't want to build another app nobody installs. We wanted to meet people where they already are: in their messaging apps. That's when "Syrena" was born — named after Poland's alarm sirens and the Warsaw Mermaid, the symbol that watches over the capital.

A note on naming: In Polish, "Syrena" carries a double meaning that doesn't survive translation. It means both "siren" (an alarm/warning device) and "mermaid" — specifically the Warsaw Mermaid (Syrenka Warszawska), the city's coat-of-arms: a sword-and-shield-wielding figure who defends the capital. In English we call the product "Siren" — capturing the warning half — but the Polish name carries the fuller idea: not just an alarm, but a protector. We liked that a tool meant to warn people and help them find safety could carry both meanings in a single word.

What it does

Syrena is a crisis companion that lives inside WhatsApp, RCS, and email. No install, no onboarding — just message it like you would a friend.

It can:

Explain what to do in a fire, a fainting episode, a storm, a flood, a heatwave, or an air attack — grounded in official RCB/MON/MSWiA safety guides, not guesswork.
Remind you about 112 and walk you through basic first aid and the recovery position.
Tell you what to pack in an emergency go-bag.
Find your nearest shelter, hospital, defibrillator (AED), or pharmacy — and tell you which kind of shelter it is, since a real bunker and a basement are very different things.
Push proactive RCB alerts to subscribers on all three channels, in Polish or English, the moment a new alert is published.

How we built it

We split the build into clean phases so we could demo something real at every checkpoint, rather than betting everything on one big-bang integration.

The conversational core runs on Amazon Bedrock AgentCore, using Amazon Nova Lite 2 as the model. It is backed by a Bedrock Knowledge Base — 94 pre-processed chunks from four official Polish government guides (the 2025 MON/MSWiA/RCB Safety Guide, RCB's flood guide, the air attack response instruction, and the storm guide), stored in Amazon S3 and indexed with Amazon Titan Text Embeddings V2 into an Amazon S3 Vectors store. Conversation history is kept in AgentCore Memory for 7 days under a hashed user ID, so the agent remembers what you asked earlier in the same session.

One design decision we locked early: RAG scope is procedural/instructional only. Safety guides and first-aid procedures go into the knowledge base. Location data and live warnings are handled by five tool Lambdas that call live APIs at query time — Amazon Location Service (SearchNearby) for hospitals, pharmacies, police and fire stations; OpenAEDMap for defibrillators; the national shelter register from dane.gov.pl; and IMGW and TVP/RCB feeds for live weather and crisis warnings. This keeps the corpus clean, frozen, and auditable. Every RAG response carries mandatory citation metadata (source, section, snapshot date) so users and reviewers can trace exactly where an answer came from.

Because this chatbot may be asked for medical guidance in a genuine emergency, we treated hallucination risk as a first-class engineering problem. We enabled Bedrock Guardrails — multilingual coverage, content filters, and contextual grounding checks that reject any response not anchored in the retrieved source documents before it ever reaches a scared user at 2am. A hard safety fallback kicks in for any life-threatening question without verified corpus coverage: a direct referral to 112, no generated procedures outside the corpus.

For reaching users, we built three fully independent channels sharing the same agent and the same RCB alert source:

WhatsApp via AWS End User Messaging Social — approved Meta templates for alerts, reply buttons for subscribe/unsubscribe and language choice, native location sharing.
RCS via AWS End User Messaging — rich suggestion chips, a RequestLocation button so users share their location with a single tap, PII masking on log groups via CloudWatch Logs data protection policies.
Email via Amazon SES — inbound receipt rules, HMAC-signed links for subscribe/unsubscribe/share-location pages served from Amazon API Gateway, so link scanners can never accidentally subscribe or unsubscribe anyone.

Each channel is a self-contained CDK stack: an inbound pipeline (SNS → SQS → Amazon EventBridge Pipes → AWS Step Functions Express router) and an outbound alert sender (the same pattern, subscribed to a shared RCB alerts SNS topic). The RCB scraper runs on an Amazon EventBridge Scheduler, scrapes new alerts, translates them Polish → English with Amazon Translate, writes them to Amazon DynamoDB, and fans them out to all three channels via SNS. Subscriber data lives in per-channel DynamoDB tables.

The legal pages (privacy policy, terms) are served over Amazon CloudFront with a custom domain managed by Amazon Route 53 and AWS Certificate Manager. Link-signing secrets are stored in AWS Secrets Manager.

Challenges we ran into

Finding the right data was harder than finding the right AI. Poland doesn't have one unified "emergency resources API" — it has a constellation of registries in different states of maturity. The hospital registry (RPWDL 2.0) is mid-migration and currently exports only XML/CSV files, not a live API. On-duty pharmacy rosters aren't centralized at all — scattered across roughly 314 separate county-level bulletin boards. We accepted that "complete" wasn't achievable in a hackathon timeline, and built a layered fallback strategy: Amazon Location Service as the dependable baseline, open government data as enrichment, with graceful degradation when a source is stale or missing.

Corpus integrity had a gap we couldn't paper over. RCB covers crisis behavior well, but doesn't provide canonical step-by-step first-aid procedures in text form. The authoritative source — ERC 2025 guidelines / Polska Rada Resuscytacji — carries a license we couldn't confirm as reuse-compatible in time. Rather than generate our own medical procedures (a non-starter for a safety product), we applied the fallback rule: first-aid questions route to 112 plus the RCB materials we could verify. Guardrails enforces this — if it's not in the corpus, it doesn't go out.

Trust was a harder requirement than throughput. A chatbot that gives slightly wrong restaurant recommendations is annoying. A chatbot that gives slightly wrong first-aid instructions is dangerous. For a typical product, a small error rate is acceptable. For a crisis assistant, the target is effectively zero — every answer must be grounded in a verified source document, or it doesn't go out. That's precisely why Guardrails' grounding checks weren't a nice-to-have — they became the single highest-priority engineering task in the whole build, ahead of even adding more channels.

WhatsApp's approval process ran on its own clock. Business Profile verification and message template approval through Meta aren't instantaneous, and they don't respect hackathon deadlines. We learned on day one that this had to be kicked off immediately, in parallel with AWS environment setup, or it would quietly become our critical path.

Location without an app is genuinely tricky. SMS, RCS, WhatsApp, and email all require the user to actively share where they are — there's no silent background GPS ping like a native app. We ask for location only at the moment it's actually needed (e.g., "find me a shelter"), using RCS's native RequestLocation suggestion chip, WhatsApp's location request message type, and a browser-based share-location page linked from email — so it never feels like a privacy ambush.

Three channels means three consistency problems. Every fixed reply is bilingual (Polish first, then English). Alert texts need to fit WhatsApp's 1,024-character body limit, Meta's template variable constraints, RCS's message format, and a plain-text email — all from the same source alert. The RCS and WhatsApp alert formats are kept in sync by a unit test that checks both against the same template definition.

Accomplishments that we're proud of

A working omnichannel crisis assistant across WhatsApp, RCS, and email — without any app installation, deployed on AWS with CDK.
A RAG corpus built from verifiable Polish government sources with per-chunk provenance metadata, so every answer is traceable to a real document.
A principled RAG boundary: location and live data stay out of the knowledge base, handled by five dedicated tool Lambdas calling live APIs instead. Clean, auditable, and easier to keep fresh.
Guardrails grounding checks as a first-class requirement — not bolted on at the end — with a hard 112-referral fallback for any question outside the verified corpus.
A single RCB alert source that fans out simultaneously to all three channels in the subscriber's chosen language (Polish or English), driven by a DynamoDB stream through EventBridge Pipes and SNS.
PII masking on RCS log groups via CloudWatch Logs data protection policies — phone numbers, coordinates, and email addresses are masked on read without changing the stored data.

What we learned

The hardest part of "AI for emergencies" isn't the AI — it's the plumbing of trust: grounding answers in real sources, enforcing corpus boundaries for life-critical questions, being honest about data gaps (a basement is not a bunker), and recognizing that every byte of location data we touch carries real responsibility. We also learned a lot about how fragmented — yet genuinely well-intentioned — Poland's civil protection data ecosystem is, and how much value there is in simply making existing public data reachable from where people already are.

What's next for Syrena

SMS support - needs more time to be implemented with phone number registration
Resolving the first-aid corpus gap: confirming ERC 2025 / PRR licensing, or finding an equivalent source with compatible terms.
Adding the three prepared corpus updates already waiting in S3: carbon monoxide, fire, and safe winter guides.
Reconciling multiple overlapping government shelter and hospital sources into one de-duplicated, consistently typed index.
Exploring voice message support for users who can't type during an emergency.
Positioning Syrena as a complement to mObywatel — reaching the roughly two-thirds of Poland that a single government app doesn't yet serve, plus tourists and foreign residents who may not have it installed at all.