Cover4
Stage: bench-tested and simulated; not yet field-testedPatents: 34 U.S. provisional applications, none grantedRadio: designed to FCC Part 15.247, not yet certified

SDK Partners · Alerting and workforce-safety platforms

An offline delivery lane for your alerting platform.

Your alerts reach staff with cell and Wi-Fi down, and every recipient answers by name. Your app, your login, your brand and your contract. Cover4 sits underneath as the lane that keeps working when the networks you rely on do not.

For: mass-notification, workforce-safety, venue-tech and campus-safety platforms that want offline delivery and proof of receipt for their customers. Partnerships are non-exclusive.

01 The gap in your customers' coverage

When cell and Wi-Fi fail, your customers cannot see who got the alert.

Delivery depends on the network

Push, SMS and in-app alerts need cell, Wi-Fi or internet, which jam in a crowd or a storm. Stadium data uploads failed up to 46% on game day in a 2026 preprint.

Sent is not received

Even when an alert lands, the operator rarely knows who saw it, who acted and who is missing.

The result

At the critical moment, your customer's operator is guessing.

Source: arXiv 2607.16008 (preprint), checked October 30, 2026.

02 What your app gains

Your platform stays the system of record. Cover4 adds delivery and proof of receipt.

Orders land offlineBench

STOP, HOLD, evacuate and shelter reach phones and staff tags with no cell or Wi-Fi.

Answers by nameBench

Each reply returns with a name. Anyone missing is listed with the reason: node down, jammed or out of range.

HELP with locationBench

A typed request for help, placed at the nearest node.

A record that holds upBench

Who was told what, when, and who answered, hash-chained and signed, for your customers' after-action reviews.

03 How it fits

Four parts, one loop: send, carry, show, answer.

Partner SDK · version 0.2.0 · November 4, 2026
Your appA Swift Package or XCFramework for iPhone and an AAR for Android, with the same API shape on both, plus React Native and Flutter wrappers.
IntegrationAbout 30 lines of Cover4 code in our sample staff app: a banner, CONFIRM, I NEED HELP, and one backend call that hands the phone its enrolment after your normal sign-in.
IdentityUsers enrol through the login they already have in your app. No new account. Device keys are sealed to each phone; your backend never holds one.
Your customers' siteCover4 nodes on the customer's network first, with Cover4's battery radio network as backup. Cover4 makes no hardware: sites use off-the-shelf devices running Cover4 firmware.
Staff tagsFor people without a phone, or with it off. The tag alerts and confirms on its own.
Offline licenceA missing licence never blocks an alert or a reply.
Tested on emulators and our digital twin. Not yet inside a partner app or on real staff phones.
Link protocols · Rev CIllustrative
Diagram of Cover4 link protocols: control center and backup base, gateways, nodes across the site, then the crew app, a phone without the app, and staff devices; replies come back over any working lane to either base.
Every hop, the radio it uses and its backup; lanes tested on our own boards on the bench in October 2026, not in the field. Rev C, November 4, 2026, drawn before the November 5 encryption update; see Security for the current state. Full size

04 Ways to work together

Four partner models. You keep the customer.

1 · We supply the kit

Cover4 supplies the nodes, staff tags and control center to the site; your app carries the alerts.

2 · You bundle it

Cover4 inside your product, sold under your contract. Most alerting partners start here.

3 · Your hardware, our firmware

Your certified devices run Cover4 firmware under licence.

4 · Bring your own devices

The site uses supported off-the-shelf certified devices it already owns or buys.

Non-exclusive. Your app uses the SDK under licence; Cover4's patent filings cover the Cover4 system, not your app. Commercial terms are agreed before a pilot starts.

05 Proof and security

What the lane has done on our bench.

Results relevant to partnersBench = our boards, 1 to 3 phones
StageDateResult
Bench2026-10-26STOP confirmed by name in 3.1–4.6 s, tap included, on phones never paired and with Wi-Fi off.
Bench2026-10-29A relay died right after taking a reply: another relay delivered it in 16 s. The control center was killed mid-alert: the backup took over in 15 s.
Twin2026-11-04A phone running only SDK 0.2.0 received a STOP, answered SAFE and NEED HELP, and the control center named the person.
Simulated2026-11-05Festival scale, 2,500 staff with tags: 0 of 24,232 taps uncounted over 10 runs, worst end of every range.
Not yet shownopenThe SDK inside a partner app. Any field event.

Only the site can send

Orders are signed at the site; devices reject anything unsigned, altered or replayed.

Pinned pairing

The SDK accepts only enrolments the site signed, for the site it expects.

HELP is encrypted

HELP messages and operator replies are encrypted end to end. Security details

Stated limitsRead before a pilot
  • The SDK is not yet inside any partner app; your pilot would be the first.
  • On iPhone, a force-quit app or Bluetooth switched off stops alerts. Alarms through silent mode need Apple's Critical Alerts entitlement, granted to the partner's app on application; we help prepare it.
  • Battery use on real phones is measured in the pilot. Voice is not on phones yet.
  • Designed to FCC Part 15.247, not yet certified.

A 60-day pilot at one of your customer sites.

You put the SDK in a test build of your app at one customer site. We bring the nodes, tags, control center, walk test and an engineer on site. Pass mark: every order answered by name, or flagged with the reason. A joint case study follows, built on field results only. The first step is a technical call, then the SDK and sample apps under NDA.

Email partners@getcover4.com

partners@getcover4.com