How it is tested, and what that does not yet prove.
Resilience claims are easy to make and hard to check. This page is the check. It sets out the test architecture behind Continuity, which parts of it are measured and which are synthetic, the degradation scenarios it is put through, and how to reproduce any of them yourself in a browser.
It also states the thing most technology companies leave out: Continuity has not been tested on real radio hardware, and no field results are published here, because there are none to publish. What follows is a demonstrator with an honest account of its own boundaries.
A single edge node, a bank of synthetic bearers, and a decision log.
Continuity runs as an edge-resident process on standard Linux. The test harness puts it on one node, gives it several network interfaces to choose between, and drives those interfaces through controlled degradation while recording every decision it makes and why.
Interface discovery
The node enumerates and classifies every network interface available to it, rather than being told in advance which bearer is which. This is the same path a real deployment takes.
Runs against the real Linux network stackPer-bearer telemetry
Latency, jitter and packet loss are sampled continuously per bearer. In the demonstrator these values are produced by the degradation simulator rather than observed on a modem — see section 02.
Real sampling loop, synthetic inputsScoring
Each bearer is scored 0–100 from that telemetry, weighted by the priorities of the traffic class in question — command and control, voice, telemetry or bulk. The weighting is what separates a mission-aware decision from a fastest-link decision.
Deterministic, inspectable per samplePolicy selection and hysteresis
The policy engine selects a path from the scores and the active mission context, with anti-flap hysteresis so a marginal bearer cannot oscillate the session. Selection is rule-driven and auditable, not a model inference.
No AI/ML in the decision pathFailover and recovery
Traffic moves to the selected path and the session is carried across the switch by an encrypted overlay. When the preferred bearer recovers, the node returns to it under the same policy.
Across simulated bearersEvent timeline
Every decision is written to a timeline with its reason, a network-only versus mission-aware comparison, and a mission-influence figure. The timeline is the artefact a reviewer should argue with.
The output this page asks you to checkThe decision logic is real. The bearers are not.
This is the distinction that decides how much weight anything else on this page can carry, so it is drawn before any results rather than after them.
What is genuinely exercised
- Interface discovery and classification against the Linux network stack
- The scoring function, its inputs and its weighting by traffic class
- Policy evaluation, including anti-flap hysteresis behaviour
- The failover decision, its timing relative to the degradation event, and the recovery decision
- Session continuity across the overlay during a switch
- The reasoning recorded for every decision
What is injected, not observed
- The bearers themselves — there is no cellular modem, satellite terminal or radio in the loop
- Latency, jitter and packet-loss values, which the degradation simulator generates
- Physical-layer behaviour: terrain, weather, geometry, contention, interference
- Modem attach and re-attach times, which on real hardware often dominate switch latency
- The mission context source, which is a simulator behind the interface a real feed would use
The four shapes a link fails in, and what each one should provoke.
Each scenario is a controlled degradation applied to one or more bearers, with an expected policy response. The point of stating the expectation in advance is that a run can then disagree with it.
Congestion
Throughput on the active bearer collapses while the link stays nominally up. Expected response: the score degrades before any interface goes down, and a lower-throughput but healthier path wins for latency-sensitive classes while bulk traffic is allowed to stay.
Hard outage
The active bearer drops without warning. Expected response: failover on the next sample, the session held across the switch by the overlay, and a return to the preferred bearer once it is back and has cleared hysteresis.
Sustained packet loss
A bearer stays up and fast but lossy. Expected response: the traffic class decides — command and control moves, bulk transfer does not. This is the case a throughput-ranked system gets wrong.
Mission-priority override
The mission context raises the weighting on reliability and resilience while the network itself is unchanged. Expected response: the selected bearer changes without any link changing, and the timeline records the mission influence that caused it.
Run the scenarios yourself, in a browser, without asking us.
The demonstrator is public. Nothing on this page needs to be taken on trust, and no sales conversation is required to see it decide.
Open the demonstrator
Go to jscontinuity.systems. The console shows the current bearer set, live per-link scoring, the selected path and the event timeline.
No account, no installApply a degradation
Use the scenario controls to congest, drop or add loss to the active bearer, or to raise mission priority with the network untouched.
Scenario controls, Selections tabRead the decision, not the outcome
Check the timeline entry against section 03's expected response. The entry carries the reason, the network-only comparison and the mission-influence figure — enough to tell whether the policy did the right thing for the right reason, or the right thing by accident.
Event timelineTell us where it is wrong
If a decision looks wrong for your environment, that is the single most useful thing you can send us. It is also how the scenario set grows.
hello@jegasec.comNo field results are published, because there are none.
Continuity has not been run on real cellular, satellite or radio hardware. There is no bench data from physical modems, no platform trial, and no third-party validation. Publishing a table here with figures drawn from a simulator would be worse than publishing nothing, so this section stays empty until it can be filled honestly.
- Interface discovery across bearers
- Live per-link scoring
- Policy-driven path selection
- Automatic failover with the session held
- Anti-flap hysteresis
- Browser-accessible demonstrator
- Integration with real modem hardware
- Representative platform trials
- Behaviour under sustained degradation
- Policy authoring for operator teams
- Long-run stability at the edge
- Operational certification or Defence accreditation
- Production or fielded deployment
- Performance benchmarks from real-world testing
- Validated cellular, satellite or radio integrations
- Customers, contracts, pilots or field trials
Where this evidence stops.
- Single node. Continuity has not been tested across a fleet of nodes or a multi-node topology.
- Synthetic bearers. Every degradation is injected by a simulator, so the physical layer is entirely absent from the results.
- No independent validation. Every observation on this page was made by JEGASEC, on JEGASEC's harness.
- Short runs. Nothing here speaks to stability over days or weeks at the edge.
- No adversarial testing. Jamming, spoofing and deliberate interference are outside both the harness and the product.
- Research build. Continuity is a research and demonstration build, not a fielded, operational or certified system.