Under Pressure

The gates stay on.

Hospital software is easy on the day everything is up. These are the lines Nightingale OS draws for the days it isn't — when the EHR goes off, when the numbers want your watch data, when the budget says cut the floor, when a query wants to know who you are. Each line is drawn in code, and each one keeps its own receipts.

Downtime Mode

When the EHR goes off, the gates stay on.

Every hospital knows the bad day: the electronic record is down and the hospital reaches for paper binders. Nightingale OS treats that day as a mode, not a blackout — the safety gates keep running while the systems around them are dark, and everything captured while offline is tagged with its own provenance so nothing written on paper can later pass for something captured live.

The gates do not take a holiday

Downtime mode is not the product with the safety rules switched off. The LIS heartbeat carries the promise in one line — safety gates remain active in downtime mode — and that line is load-bearing, not decorative.

Provenance on every downtime entry

Rows created while offline carry a provenance label — lisSource=nightingale-downtime — so a downtime entry is always distinguishable from a live one, by any reader and by any query.

Reconciliation when the feeds return

The tag is the reconciliation key: when systems come back, offline entries are matched and reconciled instead of silently diverging from the record of what happened.

Offline capture, purged on logout

Offline entries live on the device until they sync — in a local store the logout flow purges, with tests. The shared bedside tablet belongs to the next clinician too.

nightingale-downtime
the provenance tag on every downtime row
lisHeartbeat.js composes the tag and states the promise in the same line; rows written in downtime mode carry it for reconciliation (verified 2026-10-05).
Purge on logout
the offline store is emptied when the shift ends
localDowntimeStore purgeDowntimeStore() is wired into the logout flow, with its own test file (verified 2026-10-05).
The Biometric Firewall

Your watch is not a management tool.

Wearables only become deployable if the data can never become a management feed. So the raw signals — heart-rate variability, resting heart rate, sleep, activity — never leave the paired phone. What crosses the firewall is a derived score with its confidence band and consent-flagged factors, in three participation tiers with no penalty for choosing the lowest.

Raw signals never cross

The leadership-facing layer has no column for an individual's raw biometrics. That is not a policy someone could waive — it is a schema shape that cannot hold the data, so the promise does not depend on anyone's good behavior.

Consent first, by scope and platform

A request without active, scoped consent is refused — including tier-3 no-participation staff, whose requests are refused outright. Participation moves at will between tiers.

Aggregates keep the same floor

Any aggregate over biometric-derived data holds the platform-wide privacy floor of at least five, server-side — the same k that governs every manager-facing aggregate the platform publishes.

5
aggregate floor, server-side
biometricFirewall.js DEFAULT_K (verified 2026-10-05).
3
participation tiers, opt-in, no penalty
NIGHTINGALE_OS_ARCHITECTURE.md W73 — a manager cannot see which tier a nurse chose (verified 2026-10-05).
The Process-Insight Firewall

Location data answers questions. It does not watch people.

Real-time location tags can make a hospital measurably better, and the same tags can make it a surveillance state. The firewall keeps the first and refuses the second: location data is queryable only through pre-vetted aggregation templates that cannot return individual rows by construction, every run is logged where the staff council can audit it, and any council member can veto a template at any time.

Templates, not free-form queries

There is no API surface for an unapproved query. Buckets that fall below the anonymity floor return suppressed counts, and individual traces are not in the queryable schema at all.

Time-shifted, not real-time

Results exclude the most recent week. You can study patterns from last week; you cannot watch real-time movement.

A public log and a veto that binds

Every template run is recorded — issuer, parameters, k achieved, rows returned, a public summary — and a staff-council veto deactivates a template immediately and refuses all future runs.

Individual opt-out

A staff member can opt their tag out entirely; their pings are excluded from every aggregation regardless of the template.

10
unique staff per bucket, default floor
processInsightFirewall.js DEFAULT_MIN_K — configurable per template, never below five (verified 2026-10-05).
7
days minimum before data is queryable
processInsightFirewall.js DEFAULT_MIN_TIME_SHIFT_DAYS (verified 2026-10-05).
The Slack Is Sacred

Finance gets a 4xx error, not a soft warning.

A unit's resilience floor — the slack that absorbs a bad night — is the first thing a tight budget asks to spend. The platform refuses to spend it. Trades, coverage offers, shift rosters, and sick-call backfills that would drop a unit below its floor get a refusal with a citation, not a warning with an override. The Code of Design puts it in one line: Finance gets a 4xx error, not a soft warning.

One floor, every door

Trade approval, coverage offers, roster scheduling, and sick-call backfill all cross the same policy. The floor is not negotiable per workflow — which is exactly the loophole it exists to close.

Erosion, shortage, critical

Three severities, escalating with how deep the cut goes. Erosion is already a refusal — the system does not wait for the floor to be fully broken before it speaks.

The erosion ledger

Every below-floor acceptance that does happen is recorded with who asked and why, and the ledger feeds executive metrics and the manager performance composite. How the hospital is actually being run is written down, with receipts.

4xx
the response when a trade would cross the floor
slackPolicy.js enforcement at trades, coverage offers, rosters, and sick-call backfill (verified 2026-10-05).
Erosion ledger
every below-floor acceptance, recorded
who asked, and why — feeding executive metrics and the manager performance composite (verified 2026-10-05).
The Positive-Deviance Miner

It also looks for what is going right.

Every other line on this page refuses something. The deviance miner completes the just-culture picture: it finds the outlier unit doing it right and makes the pattern teachable, instead of punishing the difference. A diagnosis cohort is split into an optimal arm and a comparison arm on a pre-declared outcome definition, and feature prevalence is compared across the arms — the miner proposes, humans decide what to teach.

The outcome is declared first

The outcome definition and cohort window are pre-declared, not chosen after the results look interesting. The miner is a hypothesis generator, not a retrospective fishing expedition.

Association, with honest intervals

Results carry confidence intervals and false-discovery-rate correction, and every result says ASSOCIATION — hypothesis-generating, ranked against nothing. No leaderboard, no discipline.

Small arms are refused

Each arm must hold at least five distinct patients or the query refuses with PDM_001 — an arm too small to be anonymous is an arm the platform will not compare.

5
distinct patients per arm, minimum
positiveDevianceMiner.js K_FLOOR; refusal PDM_001, cited to 45 CFR §164.514 (verified 2026-10-05).
ASSOCIATION
every result says so
with a two-proportion test, a Newcombe difference interval, and Benjamini-Hochberg correction (verified 2026-10-05).
The Margin Case

The CFO's slide, already written.

The architecture document prices the burnout program the way a CFO would: turnover replacement cost from the published nursing literature (NSI, Aiken, Shanafelt, Tawfik), malpractice and adverse-event exposure, and CMS value-based payment — line by line, each line with its source. The program it prices is mandatory leave wired to EAP and HR, never to the supervisor, plus the wellness engine stack behind it.

$1.4-4M
net benefit per year, modeled
NIGHTINGALE_OS_ARCHITECTURE.md W82 (verified 2026-10-05).
2-7x
return on the program, annually
NIGHTINGALE_OS_ARCHITECTURE.md W82 (verified 2026-10-05).
~$250-600K
program cost per year, modeled
NIGHTINGALE_OS_ARCHITECTURE.md W82 (verified 2026-10-05).
300
bed community hospital, the model basis
the sizing basis stated in the architecture doc's cost section (verified 2026-10-05).

A model, not a measurement: these figures are computed from published literature, not yet observed on a live deployment, and the outcome claims behind them are preregistered and remain UNVALIDATED until the validation protocol runs at a pilot site.

What Is Built, and What Is Not Proven

Built, and not yet proven.

Everything on this page exists in the repository today, with tests. Here is the exact edge of what it does not claim.

Built and tested, not yet installed

No hospital is running these gates against live feeds yet; the integration paths are exercised against fixtures until a pilot changes that. The gates are code, not field results.

Modeled, not measured

The ROI line is sourced arithmetic. The preregistered outcome claims stay UNVALIDATED until the validation protocol runs — that is a property of the claims, not a footnote about them.

Structural, not attitudinal

The firewalls are schema shapes, boot-time scans, and refusal paths — properties of the code a later release cannot quietly waive. A policy can be revised; a missing column cannot hold the data.

The council holds the veto

Oversight is not a dashboard the platform controls. The staff council can veto a template at any time, and the query log is theirs to audit.

See It Run

The refusals are the product.

Request a demo and we will show the gates refusing things on the live preview — including, on request, the ones that refuse us.