Burn Rate & Approvals — Resource Intelligence and Collective Accountability in Battlefield Medicine

The Two Questions That Define Command Decisions

In any sustained medical operation — disaster response, field hospital, or combat — commanders face two recurring questions:

1. How long can we keep operating? Not "what do we have in stock" but "at the current consumption rate, when does each supply category run out?"

2. Who authorized that decision? When an irreversible procedure is performed — an amputation, a controlled substance administered by someone outside their normal scope — there must be a documented chain of accountability.

xGrid answers the first question with the Burn Rate engine and the second with the Multi-Signature Approval and Permission Escalation systems. All three work offline, on the same Raspberry Pi that runs everything else.

Part 1: Burn Rate — Predictive Supply Intelligence

Beyond Inventory Counts

Traditional inventory systems answer "how many do we have?" Burn rate answers "how long will they last?"

The difference is critical. A medical station with 8 units of Ketamine sounds comfortable. But if you have consumed 8 units in the last 12 hours, you have approximately 12 hours of supply remaining. That changes every decision — rationing protocols, resupply requests, patient allocation.

Three Time Windows

The system calculates consumption rates over three windows, each serving a different planning horizon:

A 4-hour window during an active mass casualty event shows high consumption — perhaps 2 units per hour of packed red blood cells. The 24-hour window shows a lower average because the overnight hours were quieter. Both numbers are true. They serve different decisions.

Severity Classification

The system auto-classifies every tracked supply into four tiers based on hours remaining:

Severity	Hours Remaining	What It Means
CRITICAL	≤ 4 hours	Start rationing now. Request emergency resupply. Consider activating the Walking Blood Bank.
WARNING	4-12 hours	Monitor closely. Prepare escalation procedures. Alert command.
CAUTION	12-24 hours	Routine monitoring. Plan for depletion.
STABLE	> 24 hours	No immediate action needed.

The dashboard surfaces CRITICAL items first. A commander glancing at a tablet sees immediately: "O-negative blood: 2 hours. Ketamine: 3 hours. Chest seals: 11 hours." That is actionable intelligence, not an inventory spreadsheet.

System Endurance

The most important number on the burn rate dashboard is the overall system endurance — the minimum hours remaining across all critical supply categories.

Your station might have 48 hours of oxygen, 72 hours of IV fluids, and 2 hours of O-negative blood. Your system endurance is 2 hours, because the first supply to run out determines when you can no longer operate at full capacity.

This number integrates with the xGrid Resilience Framework, combining lifeline resources (oxygen, power, water) with consumable resources (medications, blood, supplies) into a single endurance figure that command can act on.

No New Database Tables

Burn rate requires zero additional database tables. It reads from existing consumption records — pharmacy dispensing logs, inventory consumption events, blood unit status transitions, equipment status changes — and calculates rates in real time.

This is deliberate. Adding tables adds migration complexity and backup overhead. Burn rate is a read-only analytical layer on top of the data that already exists.

Part 2: Multi-Signature Approvals — The Letterman Rule, Digitized

Historical Context

In 1862, during the American Civil War, Dr. Jonathan Letterman established that amputation decisions require three senior surgeons to vote before proceeding. The reasoning was not about medical knowledge — a single surgeon usually knows whether amputation is necessary. It was about distributing the moral weight and legal liability of an irreversible decision.

160 years later, the same principle applies. In LSCO conditions, where a combat medic may be performing procedures far outside their peacetime scope of practice, collective accountability is not just good practice — it is legal protection for everyone involved.

How Voting Works

A physician creates an approval request. Other qualified personnel vote. The system tracks every vote with timestamps, justifications, and cryptographic hashes.

The settlement logic is conservative — any dissent blocks approval:

• One REJECT vote → Request REJECTED, regardless of how many approved
• Required number of APPROVE votes reached → Request APPROVED
• ABSTAIN counts as neutral — neither helps nor blocks

This is not majority rule. It is unanimous consent. The reasoning: if even one qualified surgeon believes an amputation is not yet necessary, that dissent should prevent the procedure. The patient's limb cannot be reattached.

Approval Categories

Procedure	Required Signers	Rationale
Amputation	3	Irreversible tissue loss
Enucleation (eye removal)	3	Irreversible sensory loss
Organ removal	2	Irreversible organ function loss
Whole blood transfusion	2	Special immunological risk
Controlled substance use	2	Regulatory constraint
DCS Phase 1 surgery start	2	Major surgical decision point

Emergency Override

On the battlefield, three surgeons may not be available within 30 minutes. The emergency override allows:

• Condition: Request marked as urgent + 2 approvals received + 30 minutes elapsed
• Effect: Auto-approved with EMERGENCY_OVERRIDE flag
• Audit Trail: Permanently marked in the record and CSV export

The system does not eliminate the requirement. It reduces it under documented, time-bounded conditions. The audit trail ensures post-incident review can evaluate whether the override was justified.

Vote Integrity

Every vote is hashed: SHA-256(voter_id + request_id + vote + voted_at). This is not encryption — the votes are readable. It is tamper evidence. If a vote record is modified after the fact, the hash will not match, and the tampering is detectable.

The complete approval history — requests, votes, escalations, overrides — can be exported as CSV for legal archiving.

Part 3: Permission Escalation — The Peace-War Bridge

The Legal Paradox

Taiwan's Medical Practice Act limits scope of practice. A combat medic cannot perform a needle chest decompression in peacetime. But in LSCO, that same medic may be the only person available to save a tension pneumothorax patient.

xGrid does not solve the law — that is for legislators. It provides:

1. A clear mode-switching mechanism
2. Complete documentation of every action taken outside normal scope
3. An audit trail that protects both the performer and the authorizer

Three Operating Modes

Wartime mode requires dual confirmation — two senior officers must both activate and confirm. This prevents accidental activation. The 24-hour auto-expire prevents "forgot to turn it off" — if nobody renews, the system automatically downgrades to Peacetime.

Three Authorization Patterns

When a medic performs a procedure outside their normal scope, the authorization is documented in one of three ways:

Pre-authorized: A medical officer grants advance authority. "SGT Wang is authorized to perform needle decompression for the next 24 hours." The medic performs independently within the window. The system auto-logs the override.

Real-time: No pre-authorization exists. The medic performs the procedure and simultaneously confirms authorization with a medical officer via radio. The authorization is recorded with the officer's name.

Post-hoc: Offline scenario — the medic performs without communication capability. Upon reconnection, they document: "CPT Lee approved post-hoc at 16:30." The system records the time difference for audit review.

All three patterns produce the same output: a tamper-evident record with SHA-256 hash, linking the performer, the procedure, the patient, the authorizer, and the timestamp. The audit trail is identical regardless of which pattern was used.

Scope Check at Point of Care

When a user attempts to record a procedure, the system checks three things simultaneously:

1. Current permission mode — Is the system in Peacetime, Emergency, or Wartime?
2. User's role — Are they a physician, paramedic, or combat medic?
3. Procedure type — Is this within their scope for the current mode?

If the combination is not authorized, the system blocks the action with a clear message: "This procedure requires Emergency or Wartime mode." If it is authorized via pre-authorization, the system auto-logs the override. If authorized but without pre-authorization, the system requires the "authorized by" field to be filled.

The system never silently allows an out-of-scope procedure. It never silently blocks a life-saving one. Every action is documented.

Why These Three Systems Belong Together

Burn rate tells you what resources you are consuming. Approvals ensure irreversible decisions have collective accountability. Permissions ensure every action is within authorized scope — and if it is not, that the exception is documented.

Together, they answer the questions that command and legal review will ask after the operation:

• Were resources managed responsibly? Burn rate data shows consumption patterns and when rationing began.
• Were irreversible decisions made collectively? Approval records show who voted, when, and why.
• Were scope expansions documented? Permission overrides show exactly who did what, under whose authority, in which mode.

In a well-connected hospital with electronic health records and legal departments, these questions are answered by existing systems. In a field hospital running on a Raspberry Pi with no network, they are answered by xGrid.

---

Related: Why Battlefield Medicine Needs Offline Systems — An LSCO Overview · Every Bag's Journey — Blood Product Chain of Custody · When the Wall Is Breached — Safety-II