Safe Offline Architecture Review

Use this skill when a medical device manufacturer's systems architects, safety engineers, software engineers, or security engineers want to check a connected institutional device design before the design freezes, or before a change adds a network dependency.

This skill is Labor as Code™ for the builder architecture method in Medical Device Connectivity. Labor as Code is a skill that encapsulates a person's knowledge, judgment, taste, and skill in durable, inspectable, versioned form. The know-how is the habit of asking, for every network dependency, what the device still does, records, stops, and shows when that dependency is gone, and of finding the answer while the fix is still cheap.

The method spans three chapters. "A Device’s Safety Should Never Depend on the Network" teaches the engineering target, the eight layers and two planes, the degraded modes, and the Safe Offline, Better Online Architecture Review. "Network Failure Is a Normal Operating Condition" teaches the journal, the five record classes, reconnection, and the Offline Failure Mode Worksheet. "Context Is a Safety Feature" teaches the twelve identities and the Device Identity Matrix. Each tool is published in full in the online companion's builder tools (intellectualfrontiers.com). Read the chapters for the argument and the worked cases. This skill runs the tools on the user's own design. It never borrows the book's worked ventilator review, pump worksheet, or monitor matrix as the user's findings.

The review checks architecture. It can't judge verification or clinical risk. Whether a degraded mode was verified, whether a residual risk is acceptable, whether an AI advisory is clinically sound, and what the device's regulatory status is all belong to the manufacturer's risk management file under ISO 14971:2019, its software life cycle records under IEC 62304:2006+AMD1:2015, its verification evidence, and its regulatory team. The completed review is an input to those records. It isn't a substitute for any of them. The skill says this in every output.

The local safety envelope is the manufacturer's decision. The book found no standard that lists which functions must stay inside a device. IEC 60601-1 asks the manufacturer to identify essential performance; ISO 14971:2019 governs the risk analysis. The skill uses the envelope the user's risk analysis defines. It never writes one from general knowledge of a device type.

Before running

1. Apply the book's data rule first. Use only information the user's organization permits in an AI tool it has approved. Never accept patient information, credentials, keys, certificates, or network addresses. If a design document, log, or configuration file contains any, stop, name where it is, and ask for a version with it removed. Record that a credential or certificate exists and what it is for, never its value.
2. Get the device and the moment. Record the device class, the product and release under review, and whether this is a review before design freeze or a review of a change that adds a network dependency. For a change, get the change description.
3. Get the material. Ask for each of these and record which ones the user provides:
   • an architecture description or diagram (components, processors, partitions, processes, and what runs where);
   • the essential functions as the risk analysis defines them, with the reference to where they are defined;
   • every external dependency: enterprise network, domain name system (DNS), identity provider, vendor cloud, gateway, time service, credentials and certificates, update service, remote AI services;
   • the identity and sign-in design, including any emergency (break-glass) path;
   • the journal and synchronization design;
   • the alarm forwarding design, if the device forwards alarms;
   • the command path, if any system can send the device a command;
   • any existing degraded-mode table or failure analysis.
4. Ask who owns the review. Name the architect, safety engineer, and security engineer who will sign it. The skill drafts findings. They decide them.

Step 1: Write down the essential local safety envelope

1. List the essential functions from the user's risk analysis, quoted, with the reference. If the user has no written list, write "missing: the essential local safety envelope is not written down." That is a finding under layer 1.
2. For each function, record what it depends on in the design as described.
3. Record who may act on the essential functions. The book's settled rule: therapy changes, alarm acknowledgment, and stopping a therapy never depend on the identity provider or on a credential that can expire. An identity check may attribute an essential action but never block it.

Step 2: Run the eight-layer review

Answer each layer's question from the material. Mark each finding pass, fail, or open, and cite the part of the design it comes from. Write "not in the material" where the design is silent, and mark it open.

The local safety plane is layers 1 to 4. The network enhancement plane is layers 5 to 8. The enhancement plane may depend on the safety plane. The safety plane may never depend on the enhancement plane.

Look for these patterns in particular. Each one is an enhancement-plane dependency inside essential function:

• a remote action (for example, an acknowledgment from a phone or a central system) that changes what the device does at the bedside, unless it is a distributed alarm system designed and verified for it, with confirmed delivery and a bedside fallback;
• an essential action that needs a live identity-provider check or a credential that expires (a longer cache only moves the failure);
• a license check, cloud call, or gateway call on the path of essential function;
• network software sharing a processor, partition, or process with essential function without bounded queues and enforced limits;
• a command from an enterprise or AI system that the device doesn't validate against its own state.

One such finding fails the review. For layer 8, a pass is a pass for architecture only. Place each AI service on the AI role spectrum (observation, recommendation, workflow assistance, optimization, supervised control, autonomous control). Connectivity never by itself justifies moving it one step right. If layer 8 has any path to layer 1 settings or control, that is a fail.

Step 3: Fill the Offline Failure Mode Worksheet

Fill one row for each of the nine dependency failures:

1. Enterprise network down
2. DNS fails
3. Identity provider unavailable
4. Vendor cloud unavailable
5. Gateway unavailable
6. Time service unavailable
7. Credentials expired
8. Software update incomplete
9. Remote AI service unavailable

For each row, fill five columns from the design:

• Degraded mode. One of the four named in "A Device’s Safety Should Never Depend on the Network" (Isolated, Local sign-in, Unverified time, Reduced service), or a mode of the device's own.
• What continues. Start with the essential function. In the identity-provider and expired-credential rows, say how therapy changes, alarm acknowledgment, and stopping a therapy continue.
• What is journaled, and the worst-case outage the journal is sized to hold.
• What stops, and whether each function stops safely or waits to resume.
• What the operator sees. The exact indication, what the operator is told to do, and, for a device that forwards alarms, what the receiving system shows when the device goes silent.

Apply these rules.

1. Fill every cell from the material. Where the design is silent, write "not designed." Never propose a mode and record it as the design. The skill may suggest a mode in a separate column marked "suggestion: team to decide."
2. An empty cell means nobody designed that degraded mode. It is a finding.
3. A "what the operator sees" cell that shows nothing fails its row.
4. Loss of connectivity is an alarm condition. A device that forwards alarms must alarm at the bedside when forwarding is lost. The central system must detect a silent device by missed heartbeats and escalate to a named person and a staffed fallback. Check both halves.

Then record the device-wide answers the worksheet requires: journal capacity; unsynchronized record count and age, and the alert when age crosses the institution's limit; the atomic write; the journal epoch; clock quality; command expiry; post-outage reconciliation. Step 5 checks them against the settled rules.

Step 4: Fill the Device Identity Matrix

Fill one row for each of the twelve identities: device, component, patient, specimen, operator, clinician, location, organization, consumable, accessory, software version, workflow instance. For each row, record what it identifies, how the device learns it, which records carry it, and what goes wrong if it is missing or wrong.

1. Write "not applicable" for an identity the device doesn't touch. Never leave a row blank.
2. For each association (patient, operator, location, consumable, accessory), record how it starts and ends, and which records carry the start, the end, and who made it.
3. Flag as a wrong-patient or wrong-device risk any row where patient identity is inferred from location without a person confirming it, or where two identities share one field. Location is never a substitute for patient identity.
4. Check that an unknown operator never blocks an essential action. The device records the action as "operator not identified" and reconciles later.
5. Check that every journaled record carries its own stream, sequence number, and associations, so a backlog can't lose track of whose data it is.

Step 5: Check the settled journaling and record rules

Check the design against each rule below. These are the book's settled rules (book bible section 12). Mark each met, not met, or not in the material, and cite the design.

1. One atomic write per record and its send state.
2. Device time plus a time-quality flag and a monotonic counter, with the offset measured at reconnection, never inferred from delayed arrival. A clock-adjusted event is journaled whenever the clock is stepped.
3. Command expiry on monotonic elapsed time or verified time, never an unverified device clock.
4. Sequence numbers within a journal epoch. A wiped or replaced journal starts a new epoch, so no sequence number is reused.
5. At-least-once delivery with idempotent receipt, so each record takes effect once.
6. In recorded sequence order, with duplicates discarded by the receiver. The receiver flags gaps.
7. The journal is sized for a documented worst-case outage, sheds low-value telemetry first, never drops safety or therapeutic records, and says so visibly when it can't journal.
8. Records are hash-chained or signed.
9. The network stack can't starve the essential function (separate partition, process, or processor; bounded queues).
10. Outage records are reconciled, not merged silently. They arrive marked delayed, pass the same clinician review as other auto-documented values, and are reconciled with downtime hand charting. Nothing overwrites a clinician's entry silently.
11. Every value an AI service receives carries its age and device state. An advisory degrades to no advice when its inputs are stale.

Then sort the device's records into the five record classes and check each class's rule:

• Commands: never queued for later delivery. A command names the state it was written against and carries a validity limit. An expired or outdated command is discarded, and the sender is told.
• Current therapy state: the device is the only source of truth. Other systems show last known state with its time and a stale flag. Never merged.
• Events: journaled, sequenced, forwarded in order, with gap detection.
• Audit and assurance records: journaled and append-only. A loss is a reportable defect.
• Service and bulk data: shed or summarized first under a documented rule, and every summarization is recorded.

A therapy device never stops therapy because its journal is full. A process device may refuse to start a cycle it can't record, if the design says so.

Step 6: Rank the findings by patient-safety consequence

List every fail, open item, and unmet rule. Rank each by the worst consequence it could lead to, using the failure-consequence values from the book's Axis C. Rank in this order:

1. Essential function at risk: patient harm or therapeutic error possible. Any enhancement-plane dependency inside essential function; an essential action blocked by identity; a command queued for later delivery; therapy state merged; network software that can starve essential function.
2. Silent loss, or wrong patient: diagnostic error or delayed information that staff can't see. No bedside indication when forwarding is lost; no heartbeat detection at the receiver; an operator-sees cell that shows nothing; patient identity inferred from location; shared identity fields; safety or therapeutic records that can be dropped.
3. Wrong record: compliance or traceability failure. Time without quality flags or measured offset; sequence or epoch gaps; no duplicate discard; no hash chain or signature; outage records merged without review.
4. Degraded service: workflow disruption or inconvenience. Missing reduced-service notices, undefined service-data shedding, and gaps that affect only enhancement functions.

The ranking is the skill's reading of the design. Mark it "for the safety engineer to confirm against the risk analysis." The skill doesn't estimate probability, severity scores, or residual risk.

Step 7: Conclude with a recommendation

Close with a short statement, not an evidence pack.

1. The result:
   • Fail. One or more enhancement-plane dependencies sit inside essential function. Name each. The fix is architectural, and it costs more after design freeze. Recommend fixing before freeze.
   • Open. No fail, but named items are not designed or not in the material. List them, ranked. Recommend closing them before freeze.
   • Pass. Every layer passes, every worksheet row is complete, every identity row is filled, and every journaling rule is met. Recommend recording the review in the design records.
2. The reasoning, in three to five sentences tied to specific layers, worksheet rows, matrix rows, and rules.
3. The first three fixes, in ranked order, each as a design change.
4. What this review can't judge. State it every time: whether each degraded mode was verified; whether residual risk is acceptable; whether any AI advice is clinically valid; the device's regulatory status. These belong to the risk management file (ISO 14971:2019), the software life cycle records (IEC 62304:2006+AMD1:2015), the verification evidence, and the regulatory team. Deliberate disconnection testing belongs in the Synchronization Test Plan ("Test the Whole Connected System, With an Owner for Every Boundary").
5. When to re-run: before design freeze if this was an early pass, and whenever a change adds a network dependency.

Where the design supports more than one defensible fix (for example, a remote alarm acknowledgment kept as a verified distributed alarm path, or removed so silencing stays at the bedside), present the options side by side, each with its reasoning and what would make it right. Where the builder argues that the two-plane design costs more than it returns for a low-volume device with modest work to report, record that as a live option only with the builder's written reasoning. The book's answer for that case is the exception path buyers use, not a quiet dependency.

Where the material is too thin to review (no architecture description, no dependency list, no written envelope), say so plainly. List the material that would let the review run. Don't pass or fail a design nobody described.

Output template

SAFE OFFLINE, BETTER ONLINE ARCHITECTURE REVIEW
Device class and product: ____    Release: ____
Review type: [before design freeze / change adding a dependency: ____]
Reviewers who sign: architect ____ safety ____ security ____
Material reviewed: [list, with what was not provided]

1. Essential local safety envelope: [function | risk analysis reference | depends on]
2. Eight layers: [plane | layer | finding, cited | pass / fail / open]
3. Offline Failure Mode Worksheet: 9 rows
   [failure | mode | continues | journaled | stops | operator sees]
   Device-wide answers: journal capacity ____ unsynchronized records ____
   atomic write ____ epoch ____ clock quality ____ command expiry ____
   reconciliation ____
4. Device Identity Matrix: 12 rows
   [identity | identifies | how learned | records carrying it | if wrong]
   Wrong-patient or wrong-device risks: ____
5. Journaling rules: 11 rows [rule | met / not met / not in material | citation]
   Record classes: [class | records | rule met?]
6. Findings ranked by patient-safety consequence (for the safety
   engineer to confirm): ____

RESULT: [fail / open / pass / options side by side / material too thin]
Reasoning: ____
First three fixes: ____
Not judged by this review: verification of each degraded mode;
clinical risk acceptance; clinical validity of any AI advice;
regulatory status. These belong to the risk management file
(ISO 14971:2019), IEC 62304 software life cycle records, verification
evidence, and the regulatory team.
Re-run: ____

Rules

• Never invent a design. Every finding cites the user's material. A suggestion is labeled "suggestion: team to decide" and never recorded as the design.
• Never invent numbers. Journal capacity, outage length, heartbeat interval, validity limit, and fill threshold come from the user or read "not in the material."
• Never state standards conformance or regulatory status. The review can say a design decision should be documented in the risk file. It never says the device conforms to a standard or is cleared.
• Never borrow the book's facts. The book's worked ventilator review, pump worksheet, monitor matrix, and screen messages are examples, not the user's design.
• No patient information, credentials, keys, or network addresses in the input or the output. Use only what the organization permits in an approved AI tool.
• Rules are the book's doctrine. Label the journaling rules and the envelope rules as the book's design doctrine, not a published requirement.

Checks before calling the work done

• All eight layers, nine worksheet rows, twelve matrix rows, and eleven journaling rules are present, and no cell is blank.
• Every enhancement-plane dependency inside essential function is marked fail, not open.
• Both halves of loss-of-connectivity alarming were checked for any device that forwards alarms.
• The identity rows were checked for blocking of essential actions.
• The findings are ranked, and the ranking is marked for the safety engineer to confirm.
• The output says what the review can't judge.
• The conclusion names fail, open, or pass, labeled options, or says the material is too thin and what would let the review run.

What this skill does not do

It doesn't verify the design, test the device, accept a risk, or sign the review; the manufacturer's engineers and its risk and quality processes do. It doesn't write the essential safety envelope from a device type. It doesn't judge whether an AI service's advice is clinically sound or what its regulatory path is. And it doesn't treat a network with good uptime as a reason to let essential function depend on it.