What SOS is

SOS is the LAKANA branch for civilian emergency and degraded-condition protection. It watches for a safety-relevant event, reduces the event into a small state, checks whether the state is strong enough to permit action, chooses the best available delivery route, and records what happened for later review.

The problem

Most safety apps begin by collecting and centralizing sensitive location, motion, routine, and emergency data. That can create a cloud archive that outlives the original safety purpose.

The purpose

SOS tries to protect the person without creating a permanent data source. The first decision happens on the device, local hardware, or nearby trusted node before external release is considered.

The real-world use

Rural routes, storm-damaged neighborhoods, rideshare incidents, field work, school incidents, nursing-home welfare checks, non-diagnostic medical distress signaling, and weak-signal interiors are exactly where cloud-first safety can fail.

How SOS acts without becoming surveillance

Sense locally Device-side or nearby trusted signals are evaluated close to the person first.
Minimize state Raw signals become event type, time, evidence tier, route status, transport condition, and integrity state.
Apply Threat-Adaptive Safety Response Orchestrator (TSARO) Protocol TSARO validates sensor plausibility, safety envelopes, user-unavailable posture, and fail-closed escalation.
Seal with Non-Interactive Cryptographic Oversight & Ledger Enforcement (NICOLE) Protocol NICOLE scopes release, records denial, governs custody, verifies proof state, and prevents raw evidence from becoming a default cloud asset.
Deliver through Blue Force Bridge (BFB) or Tactical Audio Bridge (TAB) only if permitted BFB receives bounded responder packets. TAB remains consent-gated. If the user is unavailable, emergency access is only a bounded candidate, not automatic raw access.
Audit outcome Delivery, denial, non-release, fallback, escrow request, shard-quorum state, and offline preservation are recorded.

What may leave, what stays sealed, and who can recover it

LAKANA separates emergency rescue authorization from legal evidence reconstruction. A user can recover access without giving LAKANA a master key, and an emergency can be handled without turning raw evidence into a default responder feed.

Emergency Human Escrow

2-of-5 rescue authorization

Used when the user may be missing, unconscious, medically impaired, not answering, an older adult living alone, a nursing-home resident, or a child at school. This can support welfare status, trusted-contact confirmation, bounded Blue Force Bridge handoff, or Tactical Audio Bridge emergency-candidate review.

In this public capstone version, escrow is modeled only as a bounded authorization concept; it is not a deployed identity, legal, medical, or emergency-access service.

  • Purpose: rescue authorization when the user is unavailable.
  • Does not unlock raw evidence by itself.
  • Requires TSARO emergency posture, NICOLE custody, and audit.
Device Evidence Shard Quorum

3-of-7 legal reconstruction

Used for sealed raw evidence reconstruction later, inside Post-Event Legal Mode. Seven independent shard commitments can exist across trusted or rotating devices, but three valid shards are required. LAKANA does not hold enough material to reconstruct the vault alone.

  • Purpose: legal / forensic reconstruction, not immediate rescue.
  • One shard is useless alone.
  • Shard identities, derivations, and recovery logic remain withheld.
No Biometric Unlock

Password-first sovereign custody

Sovereign evidence access should not depend on face unlock, fingerprint unlock, or biometric convenience. A memorized passphrase is different from a physical trait. LAKANA uses password-first custody for raw vault access, escrow recovery, and Post-Event Legal Mode.

  • No biometric unlock for raw evidence.
  • No password stored by LAKANA.
  • No security-question answer as a direct unlock.
Sealed Recovery Directory

Recover the account, not the raw vault

LAKANA may store an encrypted recovery directory: guardian routing, encrypted shard manifest, public-key commitments, rotation state, recovery policy hash, and audit receipts. It should not store plaintext holder lists, plaintext passwords, raw keys, or enough material to reconstruct user evidence.

  • Lost device can restore account shell and settings.
  • Forgotten password does not automatically unlock old raw evidence.
  • Recovery attempts create NICOLE audit receipts.

What may leave the device

Bounded welfare status, rescue-scoped route hint, validity window, audit receipt, and role-scoped Blue Force Bridge packet.

What is not released by default

Raw audio, raw video, continuous location stream, private sensor history, passwords, plaintext shard lists, and protected implementation constants.

Why Monte Carlo is used

Emergencies are uncertain. Networks and power degrade. Evidence can be stale or contradictory. Responder verification may fail. Protection must remain bound.

Why this is not a tracking app

Tracking apps ask: where is everyone all the time? LAKANA SOS asks: who needs help, what is safe to reveal, which route is viable, and what access is authorized right now?

Legacy tracking app

  • Continuous visibility
  • Cloud custody
  • Always-on map
  • Platform access risk
  • Audio/location history becomes a surveillance surface

LAKANA SOS

  • Local-first safety state
  • On-demand sharing
  • Consent-gated responder access
  • NICOLE evidence custody
  • Denied access logged
  • Failed transport recorded as state
1. Quick Sensitivity Bands

Which part of the safety path matters most?

After the live browser Monte Carlo run completes, this check summarizes which SOS layer is carrying the most pressure for that exact result. It shows grouped influence bands, not raw model internals.

Run linkRun Monte Carlo above first.
ScenarioWaiting for selected run.
StatusNot ready yet.
How to read the bandsHigh means the strongest pressure in this run. Medium means a meaningful but not dominant contributor. Low means present but constrained. A high band is not a failure; it identifies where the run was stressed.
Run the Monte Carlo above to generate live influence bands.
Sensitivity readout

Influence bands

Run the Monte Carlo above to generate live influence bands.

Offline Survival Path — what SOS does when live service fails

SOS is modeled for the moment a normal cloud path, cellular path, or Wi-Fi path is no longer dependable. The first duty is not to keep broadcasting. The first duty is to preserve the event, protect the person, seal the minimum safety state, and look for a lawful physical path that still exists.

The offline path can include local hold, WORM evidence sealing, nearby relay, non-RF handoff, delayed release, and a Sovereign Home Connection through a paired desktop or laptop on wired service or a dedicated LAKANA home device.

Offline mode does not claim impossible physics. If no physical path exists, the correct SOS behavior is sealed preservation, Island Mode, blackout reporting, and later release only when a permitted route returns.

Offline route states

  • Local hold: event recognized but not externally released.
  • Local evidence seal: NICOLE creates a minimized hashed incident record.
  • Device-to-device relay: bounded relay packet if a trusted nearby device is available.
  • Low-bandwidth burst: compact packet through available low-bandwidth channel.
  • Non-RF handoff: bounded verification packet through a local physical, acoustic, kinetic, or responder handoff path where supported.
  • Sovereign Home Connection: paired wired desktop/laptop or LAKANA home device validates and routes or preserves the packet.
  • Delayed delivery: release only when a permitted route returns.
  • Audit closure: failed path and non-release are still recorded.

What stays local by default

  • Raw sensor streams
  • Routine history
  • Continuous location history
  • Background audio
  • Personal behavior patterns
  • Non-incident movement
  • Full evidence vault

What may leave if permitted

  • Event type
  • Bounded location estimate
  • Time-limited safety packet
  • Responder-relevant status
  • Integrity hash
  • NICOLE audit marker
  • Minimal scene context
  • Delayed custody packet
Core SOS protocols

How the SOS protection stack works

SOS is a layered protection system. Each protocol has a different job: detect a safety event, constrain action, govern evidence release, preserve custody, and communicate only what is justified by the situation.

SOS

Sovereign Operating System

SOS is the civilian protection layer of LAKANA. It receives a safety-relevant event, reduces raw signals into a bounded safety state, and decides whether the situation should be preserved locally, delayed, denied, or released through a narrow rescue path. It exists to protect people in degraded conditions without turning routine movement, audio, location, or sensor data into a permanent surveillance record.

TSARO

Threat-Adaptive Safety Response Orchestrator

TSARO is the safety-response authority gate inside SOS. It checks whether the event is strong enough, current enough, and coherent enough to justify action. When evidence is weak, stale, contradictory, unverifiable, or unsafe to release, TSARO contracts the available action space so the system preserves or delays instead of over-sharing.

NICOLE

Non-Interactive Cryptographic Oversight & Ledger Enforcement

NICOLE is the custody and release layer. It governs who may receive a packet, what scope that packet may contain, how long it remains valid, and how denials or non-release decisions are recorded. Its purpose is to make rescue access auditable while preventing raw evidence, private routines, and protected vault material from becoming a default cloud asset.

BFB

Blue Force Bridge

Blue Force Bridge is the responder-facing handoff path. It receives a bounded rescue packet only when SOS, TSARO, and NICOLE permit release. BFB is designed to communicate actionable emergency context without giving responders continuous surveillance access or unrestricted raw evidence.

TAB

Tactical Audio Bridge

Tactical Audio Bridge is the consent-gated audio authorization path. It can support emergency communication when voice, gesture, or user intent can be validated, but it does not automatically open a live audio channel. TAB exists because emergency audio can help during distress, yet raw audio is also one of the most sensitive forms of evidence.

CivOS

Civilization Operating Substrate

CivOS is the degraded-state transport and preservation substrate. It describes how SOS behaves when normal cellular, Wi-Fi, cloud, power, or responder routes are impaired. It supports local hold, mesh or nearby relay, store-and-forward, offline preservation, and delayed delivery so that failure of the network does not automatically become failure of custody.

Background IP & Claim Boundary

The LAKANA SOS architecture, including TSARO, NICOLE, CivOS, Blue Force Bridge, and Tactical Audio Bridge concepts, is pre-existing proprietary technology owned by LAKANA Sovereign Systems LLC. This capstone environment is a limited public-safe academic evaluation interface demonstrating local-first safety state, degraded transport behavior, consent-gated responder access, and audit-bound evidence custody.

This page does not transfer ownership, license production rights, disclose protected implementation constants, or assign LAKANA Sovereign Systems LLC intellectual property to any institution.

The SOS evidence shown here is architecture-level and simulation-bound. The work supports disciplined Monte Carlo reporting, separated comparison suites, degraded-state stress testing, delivery-path attribution, BFB handoff metrics, and failure-mode transparency. It does not prove field readiness, deployment certification, medical performance, real-world attacker resistance, or guaranteed emergency delivery.

Correct interpretation: SOS is a research safety architecture and validation candidate. It is not a replacement for 911, emergency managers, official warning systems, medical devices, or professional responders.

Capstone Evaluation Scope

This capstone evaluates

  • Local-first safety-state modeling
  • Browser-bounded Monte Carlo simulation
  • Degraded transport behavior
  • Fail-closed escalation logic
  • Consent-gated responder access
  • Public-safe audit and evidence boundary
  • Tablet-based user/responder simulation

Out of scope

  • Real emergency dispatch
  • Live WebRTC audio
  • Medical diagnosis
  • Law-enforcement certification
  • Field validation
  • Production deployment

Next Phase Validation

  1. Tabletop degraded-communications drill
  2. Emergency Management partner workflow review
  3. Closed responder simulation pilot
  4. Privacy/legal review
  5. Federal R&D / SBIR-aligned pathway
  6. Field exercise after governance approval

The capstone prototype is a phase-gate demonstration, not a deployment-certified emergency system.

Submission Readiness

This page demonstrates a browser-executable capstone prototype for local-first civilian safety modeling. The prototype includes bounded Monte Carlo execution, degraded transport simulation, fail-closed decision logic, consent-gated responder access, audit-bound evidence custody, and user/responder tablet interfaces.

Status: Public-safe academic evaluation interface.

Known limits of this public demo

  • Browser run capped at 5,000 trials.
  • Public-safe approximations only.
  • Protected constants withheld.
  • No live emergency dispatch.
  • No WebRTC audio session.
  • No field validation claim.
  • No medical triage certification.

What SOS does not do

  • No continuous public location feed.
  • No silent responder audio.
  • No raw evidence vault access by default.
  • No general-purpose listening.
  • No automatic Tactical Audio Bridge session.
  • No unlogged denial or failed transport.
Public-safe academic evaluation interface Browser Monte Carlo cap: 5,000 trials per run Protected implementation details withheld

Evaluation implementation vs. target architecture

The capstone uses a serverless backend to make the public simulation reviewable, rate-limited, and reproducible. The modeled production architecture remains local-first. The cloud-hosted simulation service is an evaluation implementation, not the claimed final safety execution substrate.

Open the full Capstone Review page for the requirements matrix, test evidence, architecture explanation, and research alignment.

© 2026 MarTaize Fails / LAKANA Sovereign Systems LLC. Patent Pending. All Rights Reserved. Public-safe simulation page. Protected implementation details, private thresholds, raw traces, and production credentials are withheld.