Distress sensing, contextual review, evidence sealing, and first protective actions occur locally rather than waiting for a remote service.
Sovereign emergency protection. When communication fails, safety stays local.
When communication fails and pressure rises, SOS is designed to keep protection local, private, and alive. This page is a public web edition of the LAKANA SOS white paper for Olympic-scale venues, public events, and people at their most vulnerable moments. It describes what SOS is designed to do, how it is architected to protect a person and their evidence during crisis, and where its current validation posture begins and ends. It does not disclose protected implementation mechanics.
Quiet and silent protective behaviors are part of the stated purpose. The system can protect without forcing visible disclosure.
Evidence minimization, redaction, revocable release, and consent-centered governance are architectural, not optional.
Ordinary tools fail at exactly the wrong time
A finals session is underway at a whitewater venue. Radio traffic is stacking. Spectator bandwidth is crushing cellular service. An athlete, volunteer, or spectator experiences a coercive or fast-moving emergency, but the people closest to it cannot assume the network will hold, cannot assume every feed is trustworthy, and cannot assume the victim is safe to visibly ask for help.
If protection depends on a continuous internet path, then the system weakens precisely when crowds, incident traffic, and venue congestion are highest.
If the software cannot tell when its timing, witness, or sensor picture has become unreliable, it can sound confident after it has stopped being trustworthy.
If the vendor or institution owns the evidence path by default, the person’s most sensitive moment becomes someone else’s data asset.
SOS is designed on the assumption that the moment of danger is also the moment in which ordinary assumptions about connectivity, consent, and visibility start to fail. The point is not maximal collection. The point is dependable protection with minimal exposure.
SOS is organized around continuity, truth, and user control
Distress sensing, contextual review, evidence sealing, and first protective actions occur locally rather than waiting for a remote service to authorize them.
If timing confidence collapses, witness conditions become untrustworthy, or the physical story stops making sense, the system becomes more conservative rather than more performative.
SOS is not designed to force a user to choose between getting help and surrendering ownership of their most sensitive moment. On-device processing, evidence minimization, redaction, and revocable release pathways are structural commitments.
Six layers working in sequence and in parallel
The device watches motion, acoustic, interaction, and contextual signals for panic, surge, coercion, vehicle anomaly, or other safety-critical patterns without requiring raw cloud upload.
Detection does not automatically imply public exposure. The system can shift into overt, quiet, or silent protective states depending on context and user safety.
If a person cannot safely reveal distress, SOS includes silent witness activation and covert continuity modes as part of the stated architecture.
If infrastructure degrades, nearby devices and longer-range relays preserve emergency communication. Multi-transport: BLE, UWB, WiFi NAN, LoRa, LEO Satellite.
Critical material is sealed, time-bounded, and logged so later review can distinguish authentic evidence from altered or invented evidence.
Redaction, minimization, expiration, and controlled release keep the person from becoming the least protected part of their own emergency.
| Public layer | Named functions | What the person experiences |
|---|---|---|
| Detection | ATC, BAS, ACE | The system notices distress quickly, on-device, without broadcasting raw data by default. |
| Decision & integrity | TSARO, TIV, WCO | The system checks whether the event picture is credible enough to act on and fails closed when trust degrades. |
| Communication | GMP, SAB, PTT | Emergency information continues moving even when ordinary networks are weak or absent. |
| Evidence custody | QREV, IEL, QDD | Captured evidence is sealed, attributable, and harder to alter, seize, or quietly erase. |
| Privacy & release | EME, HRE, LDPL | The person is not forced into all-or-nothing exposure; only the minimum necessary data path is used. |
| Recovery | SIA, OLCK, PRRS, APHR | Survivable path for identity continuity, legal packaging, and post-event recovery. |
SOS is a civilian protection stack, not a surveillance stack disguised as one.
SOS limits harm while preserving a trustworthy record
The person does not need to wait for a full cloud round trip before the device acts. SOS notices, classifies, and shifts into an appropriate protective mode locally, including modes suited for visible emergency, quiet escalation, or silent continuity under duress.
Local sensing → Credibility review → Mode selection → Mesh continuity → Help.
SOS captures the minimum viable record, seals it locally, preserves timing and attribution, redacts when appropriate, and only moves into broader release pathways under explicit or governed conditions.
Minimal capture → Seal & time-bound → Anchor & attribute → Privacy-filter → Controlled release.
The public value of SOS is not merely that it can collect evidence. It is that it tries to collect less, protect more, and preserve trust after the event.
The difference is architectural, not cosmetic
| Decision area | Conventional approach | SOS approach |
|---|---|---|
| Internet failure | Functionality drops toward offline logging | Local detection and alternate continuity paths remain central |
| Person cannot visibly ask for help | Visible alarm flows dominate | Quiet and silent escalation remain part of the design |
| Timing is disputed | Timestamps taken at face value | Timing confidence is actively checked and can fail closed |
| Witness data is polluted | More reports look better by default | Witness credibility is treated as a validation problem |
| Evidence is captured | Capture often precedes governance | Capture, minimization, sealing, and release are tightly coupled |
| Device is seized or pressured | Disablement and disclosure are easy targets | Coercion resistance and hardened evidence custody are first-class concerns |
| Privacy conflicts with utility | Utility usually wins by default | Privacy controls embedded in evidence and broadcast path |
| Old data | Retention grows for product reasons | Expiration and controlled preservation are explicit design choices |
What the evidence says so far: simulation, not field proof
The strongest public posture is disciplined honesty: some parts of the current SOS validation stack performed well, and some parts still exposed limits. These are research-stage and simulation-stage findings, not operational Olympic field outcomes.
| Validation area | Current result | Public reading |
|---|---|---|
| H1 — Chain of custody | 30/30 trials, zero integrity violations, ~2.48s anchor latency | The evidence chain behaved consistently in the test harness, supporting the claim of attributable custody. |
| H3 — Fail-closed guarantee | Zero fail-closed violations | The safety posture is visible in the validation stack and is not just a marketing phrase. |
| H4 — Acoustic & autonomic path | 1.00 accuracy, 0 FPR, ~85ms latency | Promising for on-device triage. Remains a controlled simulation result, not field accuracy. |
| H5 — Mesh robustness | Baseline urban, rural, 20% Byzantine: passed. 33% Byzantine urban: failed. | SOS shows robust mesh behavior up to a point, not that it defeats every hostile witness regime. |
| H6 — Reserve behavior | 62 validated-sim bursts vs. 10-burst requirement | Low-power survival design is not merely conceptual inside the current simulation stack. |
| Gap tests | One orphan-shard recovery test failed. Several other gap tests passed. | The program surfaces real edge cases instead of hiding them. |
Fail-closed behavior, evidence integrity, low-latency detection posture, and reserve continuity all have meaningful support in the present research stack.
Field performance in crowded venues, user behavior under real duress, RF hostility above the tested threshold, and operational recovery procedures all require real-world study.
A credible public claim is not “SOS is finished.” A credible public claim is “SOS already behaves like a serious safety program because it publishes its weak points along with its strengths.”
Why this matters for world-stage venues and public events
Oklahoma City is no longer a hypothetical sports host. With official 2028 competition venues including canoe slalom and softball, venue safety planning must account for world-level athlete protection, public crowd management, reputational scrutiny, and cross-institutional coordination at once.
For a world-stage event, the question is not whether a platform can collect more information. The question is whether it can protect people when publicity, pressure, and infrastructure stress peak at the same time.
A coercive, medical, or fast-moving safety incident at a whitewater course can combine water noise, crowd density, radio congestion, and visual confusion. SOS is designed for exactly that kind of mixed-signal environment.
The pressure is about crowd flow, fan-zone density, player transit, and the reputational consequences of disputed incidents. SOS provides local evidence integrity and privacy-preserving escalation.
Large events expose volunteers, temporary staff, transportation personnel, and vendors. A protection system limited to elite competitors leaves a major duty-of-care gap. SOS is civilian protection infrastructure.
Defensible resilience: local-first protection, privacy-aware evidence, off-grid continuity, and transparent validation posture. These are public-interest properties, not merely product features.
A serious safety paper tells reviewers where the architecture stops
- We do not claim completed Olympic deployment. This paper describes a public architecture and a research-and-implementation program, not a finished venue-wide operational rollout.
- We do not present simulation as field truth. The current validation materials are useful and in several places strong, but they remain simulation-stage evidence until real deployments are completed.
- We do not claim that SOS replaces emergency services. SOS is a protection and continuity architecture. It is not a substitute for trained responders, venue command, or public emergency systems.
- We do not claim universal accuracy under every acoustic, crowd, or RF condition. The present stack includes encouraging results and a failed extreme Byzantine scenario and orphan-shard edge case.
- We do not claim that every privacy or legal question is automatically solved by cryptography. Governance, jurisdiction, consent, and evidence law still matter.
- We do not claim that anti-coercion measures make coercion impossible. The public case is that SOS treats coercion as a real design condition instead of ignoring it.
- We do not claim that the safest system is the one with the most data. Our public position is the opposite: less exposure, better timing, stronger integrity, and clearer accountability.
The right next step is a structured review, not a marketing demo
If you are responsible for athlete, workforce, or spectator safety in an Olympic or Paralympic venue environment, the first conversation should center on operating scenarios: where connectivity degrades, where coercion risk is real, and how evidence governance should work when incidents are contested.
If you evaluate public-interest technology, the relevant question is whether SOS improves safety without normalizing broad surveillance. We welcome review against resilience, civil-liberties posture, and transparent validation discipline.
If your institution works in human factors, cybersecurity, emergency management, sports science, civil liberties, or public-interest technology, SOS creates a field-validation and publication opportunity across multiple disciplines.
If your team operates in mass-gathering, venue, or rapid-response environments, the fit question is practical: what would you need from a local-first protective stack that ordinary tools do not currently provide?