Sovereign Operating System · scenario Live Research Lab

Get help through degraded conditions without turning the person into a surveillance target.

LAKANA SOS — the Sovereign Operating System — is a civilian safety-response layer. It helps a person, device, or trusted local node decide whether a safety event is real enough to act on, what information is allowed to leave, which route can still carry the message, and how the event should be audited afterward.

The system is designed for the moment normal assumptions start failing: weak signal, low battery, damaged infrastructure, weather stress, coercion, stale data, no cloud path, or no immediate responder connection.

Run SOS Lab See Offline Path Read Claim Boundary

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, and routine data. That creates a cloud archive that can be breached, sold, subpoenaed, licensed, or analyzed far beyond 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 any external release is considered.

The real-world use

Rural routes, storm-damaged neighborhoods, rideshare incidents, field work, events, medical distress, and weak-signal interiors are exactly where cloud-first safety can fail at the worst moment.

How SOS acts without becoming surveillance

Sense locallyDevice-side or nearby trusted signals are evaluated close to the person first.

Minimize stateRaw signals become event type, time, evidence tier, route status, and integrity state.

Apply TSAROThe risk layer decides whether to do nothing, hold, preserve, prepare, or escalate.

Seal evidenceNICOLE hashes, separates, scopes, and governs incident evidence before release.

Deliver if permittedSOS tries live, degraded, offline, delayed, and handoff paths only when allowed.

Audit outcomeDelivery, denial, non-release, fallback, and offline preservation are recorded.

Live SOS Monte Carlo

Every slider changes the simulation. The run happens in the browser; no telemetry, cloud call, external script, or hidden model viewer is used. Results are bounded public architecture estimates, not field validation.

scenario delivery path map

Mobile view uses compact scenario maps and charts so the model fits the screen. Desktop view expands the same live results into a wider operational stage.

Reactive scenario operations stage

Signal / route field

Trust boundary state

Selected path pressure—

Offline readiness—

Battery reserve—

Disclosure restraint—

Desktop expanded operations view

Desktop route topology

Desktop battery / latency coupling

Route usage

Failure / fallback

Battery burden

Delivery latency

Offline Path — what SOS does when the cloud is gone

If the internet, cloud, or cellular network is unavailable, SOS should not pretend the event disappeared. The system shifts into offline survival behavior: preserve the event locally, seal the evidence state, record failed delivery attempts, keep the smallest necessary safety packet ready, and attempt delayed or alternative release only when a permitted path becomes available.

Offline mode does not mean magic delivery through impossible physics. If no physical path exists, SOS preserves, seals, queues, audits, and waits. It does not claim guaranteed transmission under total blackout.

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.
Physical handoff: bounded verification packet for trusted responder or anchor.
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

Evidence and claim boundary

The public SOS evidence is architecture-level and simulation-bound. The 1 work supports a disciplined Monte Carlo reporting posture, 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.