Earthquake Response, Site Evacuation, Asset Salvage, Emergency Logistics & Privacy-Preserving Facility Continuity Architecture

SIAR — Secure, Local-First, Multi-Transport Communication Platform

Series: Core System Architecture
Part: 118
Status: Architecture specification
Primary language: Rust
Builds on: Core System Architecture Parts 50, 70–71, 94–100, 104–107, 110, 114–117

Primary purpose: define SIAR's physical-disaster and facility-continuity architecture for fire, flood, earthquake, severe weather, structural failure, environmental emergency, site evacuation, emergency shutdown, asset salvage, crisis logistics, temporary capacity, custody preservation, recovery sequencing, site requalification, and privacy-preserving continuity operations.

1. Purpose

Physical disasters can invalidate assumptions across:

power
cooling
network
hardware
access
staffing
transportation
regional availability

A robust platform must answer:

When should a site evacuate?
When should systems shut down?
What must fail over first?
Which assets are salvageable?
How are damaged devices handled securely?
How are replacement systems brought online?
How do we preserve chain of custody in a crisis?
When can a site be trusted again?

The governing principle is:

SIAR physical continuity should prioritize human safety, preserve system security and privacy, fail over predictably, salvage only verifiable assets, and restore service through explicit requalification rather than ad hoc emergency exceptions.

2. Architectural Position

             PHYSICAL HAZARD
                   │
                   ▼
          DISASTER CLASSIFICATION
                   │
          ┌────────┼────────┐
          │        │        │
        LOCAL    SITE     REGIONAL
          │        │        │
          └────────┼────────┘
                   ▼
            EMERGENCY STATE
                   │
      ┌────────────┼────────────┐
      │            │            │
  EVACUATE      FAILOVER     SHUTDOWN
      │            │            │
      └────────────┼────────────┘
                   ▼
              SALVAGE / REBUILD
                   │
                   ▼
            SITE REQUALIFICATION

3. Core Separation

Keep distinct:

human evacuation
technical evacuation
failover
shutdown
salvage
recovery
requalification

4. Non-Goals

Part 118 does not create:

person tracking during disasters
employee attendance scoring
unsafe remote operation during evacuation
security bypass justified by emergency
automatic reuse of physically exposed hardware

5. Disaster Class

#![allow(unused)]
fn main() {
pub enum PhysicalDisasterClass {
    Fire,
    Flood,
    Earthquake,
    SevereWeather,
    StructuralFailure,
    UtilityFailure,
    HazardousEnvironment,
    RegionalEmergency,
    Unknown,
}
}

6. Disaster Severity

#![allow(unused)]
fn main() {
pub enum DisasterSeverity {
    Advisory,
    Localized,
    Serious,
    Critical,
    Catastrophic,
}
}

7. Severity Is Technical/Operational

Not media classification.

8. Hard rule.

9. Hazard Scope

#![allow(unused)]
fn main() {
pub enum HazardScope {
    Rack(RackId),
    Zone(FacilityZoneId),
    Site(PhysicalSiteId),
    Region(RegionId),
}
}

10. No Person Scope

Hard rule.

11. Hazard Event

#![allow(unused)]
fn main() {
pub struct HazardEvent {
    pub class: PhysicalDisasterClass,
    pub severity: DisasterSeverity,
    pub scope: HazardScope,
    pub observed_at: CoarseTimestamp,
    pub evidence: Vec<HazardEvidenceRef>,
}
}

12. Hazard Evidence

Possible sources:

facility sensors
building alarm
site operator confirmation
utility/provider notice
regional emergency feed

13. No Single Unverified Signal For Catastrophic Action Where Avoidable

Hard rule.

14. Disaster Confidence

#![allow(unused)]
fn main() {
pub enum DisasterConfidence {
    Low,
    Medium,
    High,
    Confirmed,
}
}

15. Unknown ≠ Safe

Hard rule.

16. Facility Emergency State

#![allow(unused)]
fn main() {
pub enum FacilityEmergencyState {
    Normal,
    Alert,
    Degraded,
    Evacuating,
    Evacuated,
    Isolated,
    Recovering,
    Requalifying,
}
}

17. No Evacuated→Normal Direct

Hard rule.

18. Emergency State Transition

Normal
  ↓
Alert
  ↓
Degraded
  ↓
Evacuating
  ↓
Evacuated
  ↓
Recovering
  ↓
Requalifying
  ↓
Normal

19. Emergency Shortcuts

Catastrophic events may go:

Normal → Evacuating

or:

Normal → Isolated

20. Hard rule.

21. Human Safety Precedence

Human life and emergency egress override equipment preservation.

22. Hard Rule

No technical policy may delay evacuation required by life-safety systems.

23. Human Evacuation vs Technical Drain

Separate.

24. If humans must evacuate immediately:

automatic safe technical actions continue
manual tasks stop

25. Hard rule.

26. Emergency Technical Actions

#![allow(unused)]
fn main() {
pub enum DisasterSafetyAction {
    FreezePlacement,
    StopNewAdmission,
    DrainRack(RackId),
    DrainZone(FacilityZoneId),
    DrainSite(PhysicalSiteId),
    FailoverService(ServiceId),
    GracefulShutdownSite(PhysicalSiteId),
    IsolateNetworkZone(FacilityZoneId),
}
}

27. No Generic Shell Action

Hard rule.

28. Action Precedence

life safety
> security containment
> data integrity
> service continuity
> asset preservation

29. Hard rule.

30. Fire Response

Fire may require:

immediate evacuation
power isolation
fire suppression
network isolation
site failover

31. Fire State

#![allow(unused)]
fn main() {
pub enum FireState {
    Suspected,
    Confirmed,
    SuppressionActive,
    Contained,
    Cleared,
}
}

32. Confirmed Fire

Triggers evacuation according to site safety design.

33. Hard rule.

34. Fire Suppression Integration

Facility system is authoritative.

35. SIAR consumes coarse state:

alarm
suppression active
zone affected

36. No attempt to override certified fire system logic.

37. Hard rule.

38. Power During Fire

May require:

controlled shutdown
power cut to affected zone

39. Safety first.

40. Hard rule.

41. Flood Response

Flood/water hazards can affect:

power
cooling
floor cabling
storage
hardware

42. Flood State

#![allow(unused)]
fn main() {
pub enum FloodState {
    LeakDetected,
    LocalizedWater,
    RisingWater,
    SiteFlood,
    Receding,
    Cleared,
}
}

43. Water + Power

High-risk combination.

44. Hard rule.

45. Flood Safety Actions

Possible:

power isolate affected zone
drain workloads
protect backup media
fail over site

46. No technician intervention in unsafe electrical environment.

47. Hard rule.

48. Earthquake Response

Earthquake can invalidate:

rack stability
power
cooling
network cabling
building structure

49. Seismic Event

#![allow(unused)]
fn main() {
pub struct SeismicEvent {
    pub scope: HazardScope,
    pub severity: DisasterSeverity,
    pub structural_inspection_required: bool,
}
}

50. Post-Seismic Requalification

Required before trust.

51. Hard rule.

52. Automatic Actions After Significant Seismic Event

Possible:

freeze new placement
stop risky maintenance
drain if facility alarms trigger
mark site Requalifying

53. Hard rule.

54. Severe Weather

Examples:

cyclone
hurricane
blizzard
heatwave
dust storm

55. Preparation Window

Can allow preemptive:

fuel check
backup verification
staff reduction
capacity shift
site drain

56. Hard rule.

57. Structural Failure

Examples:

roof damage
floor failure
rack collapse
building damage

58. Immediate affected-zone isolation.

59. Hard rule.

60. Utility Failure

Long-duration power/water/telecom loss.

61. Integrates Part 116 power architecture.

62. Hard rule.

63. Hazardous Environment

Examples:

smoke contamination
chemical release
extreme heat
unsafe air

64. Human safety remains authoritative.

65. Hard rule.

66. Regional Emergency

May impact multiple sites simultaneously.

67. Examples:

regional blackout
major flood
earthquake
war/civil emergency
carrier outage

68. Avoid assuming regional independence during shared disaster.

69. Part 110 correlation model applies.

70. Hard rule.

71. Site Evacuation Trigger

#![allow(unused)]
fn main() {
pub enum EvacuationTrigger {
    LifeSafetyAlarm,
    ConfirmedFire,
    StructuralRisk,
    FloodRisk,
    HazardousEnvironment,
    AuthorityOrder,
    FacilityManagerDecision,
}
}

72. Trigger Is Not Delayed For Service Availability

Hard rule.

73. Technical Evacuation Plan

#![allow(unused)]
fn main() {
pub struct TechnicalEvacuationPlan {
    pub site: PhysicalSiteId,
    pub drain_order: Vec<ServiceId>,
    pub shutdown_order: Vec<HardwareAssetId>,
    pub failover_targets: Vec<RegionId>,
}
}

74. Precomputed

Hard rule.

75. No Crisis-Time Improvisation Baseline

Hard rule.

76. Service Drain Order

Suggested precedence:

analytics
background
bulk
optional
interactive
core messaging
control/security last

77. Hard rule.

78. Shutdown Order

Respect:

data integrity
quorum
storage
network dependencies

79. Hard rule.

80. Emergency Shutdown

If graceful drain impossible:

protect transactional integrity where possible
stop writes before abrupt storage loss

81. Hard rule.

82. Site Failover

Part 100.

83. Failover Eligibility

Target must satisfy:

security
privacy
residency
capacity
trust

84. Hard rule.

85. No Nearest-Site Fallback If Noncompliant

Hard rule.

86. Emergency Capacity Reserve

Part 101/110.

87. Disaster failover consumes protected reserve.

88. Hard rule.

89. Site Isolation

When physical compromise suspected:

network isolate
credential restrict
stop sensitive workloads
preserve evidence

90. Hard rule.

91. Disaster Communication

Internal emergency notifications must contain:

site
hazard class
operational state
required action

92. No unnecessary worker location detail.

93. Hard rule.

94. Emergency Coordination

Roles:

#![allow(unused)]
fn main() {
pub enum DisasterRole {
    SiteIncidentLead,
    FacilitiesLead,
    InfrastructureLead,
    SecurityLead,
    LogisticsLead,
    RecoveryLead,
}
}

95. Scoped Roles

Hard rule.

96. No Universal Emergency Superuser

Hard rule.

97. Emergency Authority

Time-bounded.

98. Hard rule.

99. Disaster Runbook

Must include:

evacuation
technical drain
failover
shutdown
salvage
logistics
recovery
requalification

100. Versioned.

101. Hard rule.

102. Preparedness

Preparation includes:

drills
spare inventory
alternate site
fuel
backup
emergency contacts
transport vendors

103. Hard rule.

104. Disaster Exercise

Types:

#![allow(unused)]
fn main() {
pub enum DisasterExerciseType {
    Tabletop,
    Simulation,
    ControlledFailover,
    FullSiteDrill,
}
}

105. Human Evacuation Drill

Handled by facility safety authorities.

106. SIAR verifies technical continuity behavior.

107. Hard rule.

108. Exercise Metrics

detection time
evacuation trigger time
technical drain time
failover time
recovery time
evidence completeness

109. No employee scoring.

110. Hard rule.

111. Disaster Readiness State

#![allow(unused)]
fn main() {
pub enum DisasterReadinessState {
    Ready,
    Degraded,
    NotReady,
    Unknown,
}
}

112. Unknown ≠ Ready

Hard rule.

113. Preparedness Checks

runbook current
failover target ready
backup verified
spares ready
fuel/power ready
site contacts valid

114. Hard rule.

115. Asset Salvage

Post-disaster assets are not trusted automatically.

116. Salvage State

#![allow(unused)]
fn main() {
pub enum SalvageState {
    Unknown,
    UnsafeToInspect,
    AwaitingInspection,
    Recoverable,
    Quarantined,
    SanitizationRequired,
    DestroyRequired,
    Requalified,
}
}

117. No Recoverable→Trusted Direct

Hard rule.

118. Salvage Inspection

Check:

physical damage
water exposure
smoke contamination
electrical damage
tamper state
storage integrity
firmware/boot measurements

119. Hard rule.

120. Salvage Class

#![allow(unused)]
fn main() {
pub enum SalvageClass {
    ReusableAfterInspection,
    ReusableAfterRepair,
    DataRecoveryOnly,
    DestructionRequired,
}
}

121. High-Value Crypto Hardware

More conservative.

122. Hard rule.

123. Water-Exposed Hardware

Requires:

power isolation
inspection
controlled drying/cleaning
electrical validation
re-attestation

124. No immediate power-on.

125. Hard rule.

126. Smoke-Exposed Hardware

May require cleaning/replacement.

127. Hard rule.

128. Seismic-Damaged Hardware

Check:

mounts
connectors
drives
board damage
rack stability

129. Hard rule.

130. Salvage Chain of Custody

Part 117.

131. Disaster does not suspend custody rules.

132. Hard rule.

133. Emergency Asset Movement

May simplify approvals but preserves:

asset ID
movement ID
destination
custodian scope

134. Hard rule.

135. Temporary Storage

Damaged/salvaged devices require secure holding area.

136. Hard rule.

137. Damaged Storage Media

Treat as sensitive until sanitized/destroyed.

138. Hard rule.

139. Emergency Data Recovery

If device damaged:

recover only within approved secure environment

140. No uncontrolled vendor data recovery.

141. Hard rule.

142. Disaster Logistics

Need movement of:

spares
fuel
network equipment
storage
replacement servers

143. Logistics Plan

#![allow(unused)]
fn main() {
pub struct EmergencyLogisticsPlan {
    pub site: PhysicalSiteId,
    pub required_assets: Vec<LogisticsAssetRequirement>,
    pub transport: Vec<ApprovedTransportRef>,
}
}

144. Hard rule.

145. Logistics Priority

#![allow(unused)]
fn main() {
pub enum LogisticsPriority {
    LifeSafetySupport,
    SecurityCritical,
    ServiceCritical,
    Recovery,
    Standard,
}
}

146. No User Priority

Hard rule.

147. Spare Deployment

Part 115.

148. Emergency spares must be:

provisioned
firmware-current
attested
compatible

149. Hard rule.

150. Temporary Capacity

May use:

alternate data center
approved cloud region
edge nodes
recovery site

151. Security/residency filters remain.

152. Hard rule.

153. Temporary Site

#![allow(unused)]
fn main() {
pub struct TemporaryRecoverySite {
    pub site: PhysicalSiteId,
    pub allowed_services: BTreeSet<ServiceId>,
    pub expires_at: Timestamp,
}
}

154. Temporary Means Time-Bounded

Hard rule.

155. No Permanent Emergency Infrastructure By Accident

Hard rule.

156. Emergency Networking

Can deploy:

temporary uplinks
satellite
alternate carrier
mesh/DTN

157. Must preserve crypto/authz/privacy.

158. Hard rule.

159. Local Mesh Continuity

SIAR local-first/offline capabilities may continue when WAN unavailable.

160. Good.

161. Hard rule.

162. Emergency Relay

Temporary relay must be enrolled/trusted.

163. No anonymous direct downgrade.

164. Hard rule.

165. Regional Isolation

During broad disaster, federation/local operation may continue.

166. Hard rule.

167. Disaster Supply Chain

Approved emergency vendors.

168. No unknown supplier bypass for high-trust hardware.

169. Hard rule.

170. Emergency Procurement

Can be expedited.

171. Still requires minimum provenance/security.

172. Hard rule.

173. Emergency Fuel Logistics

Facility responsibility.

174. SIAR tracks coarse readiness only.

175. No vehicle/worker tracking baseline.

176. Hard rule.

177. Disaster Documentation

Capture:

hazard
state transitions
technical actions
asset movement
recovery evidence

178. No private communications/content.

179. Hard rule.

180. Disaster Evidence Bundle

#![allow(unused)]
fn main() {
pub struct DisasterEvidenceBundle {
    pub event: HazardEventId,
    pub site: PhysicalSiteId,
    pub state_transitions_digest: Digest,
    pub asset_movements_digest: Digest,
    pub recovery_digest: Option<Digest>,
}
}

181. Signed where needed.

182. Hard rule.

183. Post-Disaster Recovery

Recovery stages:

site safety clearance
power/cooling restoration
network restoration
sensor validation
hardware inspection
attestation
data integrity checks
controlled service return

184. Hard rule.

185. Site Requalification

#![allow(unused)]
fn main() {
pub struct SiteRequalification {
    pub site: PhysicalSiteId,
    pub physical_safety_ok: bool,
    pub power_ok: bool,
    pub cooling_ok: bool,
    pub network_ok: bool,
    pub sensor_ok: bool,
    pub hardware_trust_ok: bool,
}
}

186. All Mandatory Checks Required

Hard rule.

187. Site Requalification State

#![allow(unused)]
fn main() {
pub enum SiteRequalificationState {
    Pending,
    Partial,
    Passed,
    Failed,
}
}

188. Partial ≠ Passed

Hard rule.

189. Hardware Requalification

Part 115.

190. May require:

firmware validation
measured boot
component replacement
sanitization

191. Hard rule.

192. Data Integrity Verification

Before write traffic resumes:

DB consistency
storage health
replication state
backup state

193. Hard rule.

194. Controlled Return To Service

Phases:

infrastructure only
internal service
canary
partial production
full production

195. Part 107/108 integration.

196. Hard rule.

197. No Instant Full Re-Admission

Hard rule.

198. Recovery Soak

Site may operate in monitored recovery state.

199. Hard rule.

200. Disaster Recovery vs Physical Recovery

Distinct.

201. Service may already be running elsewhere while original site is still under recovery.

202. Hard rule.

203. Failback

Separate governed change.

204. Do not fail back automatically because site power returned.

205. Hard rule.

206. Disaster Severity & Business Continuity

Part 70/100.

207. Catastrophic site loss may trigger long-term continuity plan.

208. Hard rule.

209. Data Residency

Part 103.

210. Temporary recovery location still must be compliant.

211. Hard rule.

212. Geographic Correlation

Part 110.

213. Regional hazards can affect multiple sites.

214. Hard rule.

215. Capacity Forecast

Part 111.

216. Disaster demand scenario includes:

failover load
replacement capacity
recovery workload

217. Hard rule.

218. Performance

Part 112.

219. Degraded/recovery capacity may have lower performance.

220. Must remain within continuity policy.

221. Hard rule.

222. Efficiency/Sustainability

Parts 113–114.

223. During disaster, continuity/safety outrank energy efficiency.

224. Hard rule.

225. Hardware Fleet

Part 115.

226. Emergency spares, replacement, attestation, RMA integrated.

227. Hard rule.

228. Facility Reliability

Part 116.

229. Power/cooling/environment state are primary disaster inputs.

230. Hard rule.

231. Physical Security

Part 117.

232. Custody/tamper/access controls remain active.

233. Hard rule.

234. Desired-State Integration

Part 105.

235. Emergency continuity profiles are pre-signed desired states.

236. No handwritten crisis config baseline.

237. Hard rule.

238. Inventory Integration

Part 106.

239. Disaster scope uses canonical assets/sites.

240. Hard rule.

241. Change Integration

Part 107.

242. Emergency changes can use expedited policy.

243. Hard invariants remain.

244. Hard rule.

245. Release Integration

Part 108.

246. Routine releases freeze during active critical disaster.

247. Security/recovery releases may proceed under emergency path.

248. Hard rule.

249. SLO Integration

Part 109.

250. Disaster may consume error budgets.

251. Reliability objectives remain visible.

252. Hard rule.

253. Organizational Governance

Part 104.

254. Disaster roles/escalation predefined.

255. No ad hoc permanent authority.

256. Hard rule.

257. Incident Response

Part 96.

258. Major physical disaster is operational incident.

259. Security/tamper may be parallel security incident.

260. Hard rule.

261. SOC Integration

Part 97.

262. Physical/cyber signals may correlate.

263. No person surveillance expansion.

264. Hard rule.

265. Compliance Integration

Part 95.

266. Evidence can include:

drill completion
site requalification
salvage custody
sanitization/destruction

267. Hard rule.

268. Disaster Preparedness API

#![allow(unused)]
fn main() {
pub trait DisasterPreparednessService {
    fn readiness(
        &self,
        site: PhysicalSiteId,
    ) -> Result<DisasterReadinessState, DisasterContinuityError>;

    fn plan(
        &self,
        site: PhysicalSiteId,
        class: PhysicalDisasterClass,
    ) -> Result<DisasterResponsePlan, DisasterContinuityError>;
}
}

269. Emergency Coordinator

#![allow(unused)]
fn main() {
pub trait DisasterCoordinator {
    fn transition(
        &self,
        site: PhysicalSiteId,
        state: FacilityEmergencyState,
    ) -> Result<DisasterTransitionReceipt, DisasterContinuityError>;
}
}

270. Salvage Service

#![allow(unused)]
fn main() {
pub trait AssetSalvageService {
    fn assess(
        &self,
        asset: HardwareAssetId,
    ) -> Result<SalvageClass, DisasterContinuityError>;
}
}

271. Requalification Service

#![allow(unused)]
fn main() {
pub trait SiteRequalificationService {
    fn evaluate(
        &self,
        site: PhysicalSiteId,
    ) -> Result<SiteRequalificationState, DisasterContinuityError>;
}
}

272. No Generic Emergency Shell API

Hard rule.

273. Error Taxonomy

#![allow(unused)]
fn main() {
pub enum DisasterContinuityError {
    HazardUnknown,
    SiteStateUnknown,
    EvacuationRequired,
    FailoverUnavailable,
    RecoverySiteNoncompliant,
    SalvageUnsafe,
    CustodyIncomplete,
    SiteNotRequalified,
    CapacityInsufficient,
    ScopeViolation,
    Unauthorized,
    Internal,
}
}

274. Observability

Safe metrics:

site readiness
exercise freshness
hazard state
evacuation state
failover status
salvage state
requalification state

275. Forbidden:

employee movement maps
individual evacuation timing analytics
user location
private content

276. Hard rule.

277. Disaster Continuity SLOs

Examples:

critical site runbook freshness
failover exercise success
spare readiness
site requalification evidence freshness

278. Security SLO

0 disaster recovery using untrusted hardware
0 custody rules silently suspended
0 emergency network path bypassing crypto/privacy

279. Privacy SLO

0 person-level emergency tracking retained beyond necessity
0 user location inferred from facility continuity telemetry

280. Failure Modes

false alarm
simultaneous regional impact
salvage contamination
logistics delay
recovery site unavailable

281. False Alarm

Use controlled rollback to normal.

282. Preserve event evidence.

283. Hard rule.

284. Regional Multi-Site Impact

Do not assume backup site unaffected.

285. Validate independent fault domain.

286. Hard rule.

287. Salvage Contamination

If trust uncertain:

quarantine
destroy

rather than force reuse.

288. Hard rule.

289. Logistics Delay

Use alternate approved supplier/site.

290. No security-provenance bypass.

291. Hard rule.

292. Recovery Site Unavailable

Continue degraded mode within policy.

293. No forbidden jurisdiction fallback.

294. Hard rule.

295. Testing

Need disaster-continuity testkit.

296. Test Scenarios

fire evacuation
flooded rack
earthquake site isolation
regional blackout
temporary recovery site activation

297. Evacuation Test

Life-safety trigger immediately overrides technical availability concerns.

298. Fire Test

Confirmed fire triggers correct site state.

299. Flood Test

Water + power risk isolates affected zone.

300. Seismic Test

Site requires requalification before normal.

301. Failover Test

Only compliant recovery region selected.

302. Capacity Test

Failover target has sufficient reserve.

303. Custody Test

Salvaged asset movement has valid handoff.

304. Salvage Test

Damaged hardware cannot return to Trusted directly.

305. Logistics Test

Emergency spare still requires enrollment/attestation.

306. Temporary Site Test

Recovery site expires/retired after use.

307. Privacy Test

No worker/user movement timeline generated.

308. Recovery Test

Site cannot return until mandatory checks pass.

309. Failback Test

Power restoration alone cannot trigger automatic failback.

310. Fuzzing

Fuzz:

hazard events
emergency state transitions
salvage records
logistics plans
requalification evidence

311. Property Tests

Properties:

site can never transition from Evacuated directly to Normal
unrequalified salvaged hardware can never become Trusted
recovery site outside residency policy can never be selected
human life-safety evacuation can never be blocked by service availability policy

312. Formal Verification Targets

Strong candidates:

facility emergency state machine
evacuation/failover ordering
salvage trust restoration
site requalification

313. Kani Candidate

state-transition and requalification invariants.

314. TLA+ Candidate

hazard → evacuation → failover → recovery → requalification → failback.

315. Loom Candidate

concurrent hazard signal + failover + site-state transition.

316. Performance

Disaster coordination is control-plane work.

317. Local site safety actions must operate during WAN loss.

318. Hard rule.

319. Storage

Separate:

hazard events
disaster plans
site emergency states
evacuation records
salvage assessments
logistics plans
requalification evidence

320. No workforce tracking warehouse.

321. Hard rule.

322. Partitioning

By:

site
region
hazard class
asset
recovery site

323. No user/person partition.

324. Hard rule.

325. Crate Layout

Recommended:

crates/
├── siar-disaster-core/
├── siar-hazard-detection/
├── siar-site-evacuation/
├── siar-emergency-failover/
├── siar-asset-salvage/
├── siar-emergency-logistics/
├── siar-site-requalification/
├── siar-disaster-exercises/
├── siar-disaster-observability/
└── siar-disaster-testkit/

326. `siar-disaster-core`

Owns:

PhysicalDisasterClass
DisasterSeverity
FacilityEmergencyState
errors

327. `siar-hazard-detection`

Hazard event normalization/evidence/confidence.

328. `siar-site-evacuation`

Human-safety-aware technical evacuation state.

329. `siar-emergency-failover`

Compliant target selection/failover execution plans.

330. `siar-asset-salvage`

Damage assessment/quarantine/requalification.

331. `siar-emergency-logistics`

Spare/replacement/temporary-site planning.

332. `siar-site-requalification`

Power/cooling/network/sensor/hardware trust verification.

333. `siar-disaster-exercises`

Tabletop/simulation/failover drills.

334. `siar-disaster-observability`

Aggregate continuity health only.

335. `siar-disaster-testkit`

fire/flood/seismic/failover/privacy tests.

336. Security, Privacy & Correctness Invariants

Mandatory:

1. Human life safety and emergency egress always take precedence over service availability, equipment preservation, and technical continuity; no system policy may delay required evacuation.
2. Disaster state, evacuation, failover, shutdown, salvage, recovery, and requalification are distinct explicit states; a site or asset never returns directly from disaster exposure to trusted normal operation.
3. Emergency failover may use only regions/sites that already satisfy security, privacy, residency, trust, and minimum capacity requirements; crisis conditions never authorize silent policy weakening.
4. Damaged, water-exposed, smoke-exposed, tampered, relocated, or otherwise physically exposed hardware is quarantined until inspection, custody validation, firmware/boot verification, and re-attestation or destruction are complete.
5. Chain-of-custody, sanitization, and tamper rules remain active during disasters; emergency logistics may streamline approval timing but cannot make asset movement untracked.
6. Temporary recovery sites, emergency relays, replacement nodes, spares, and offline infrastructure remain signed/enrolled/attested and time-bounded and cannot become permanent ungoverned infrastructure.
7. Disaster preparedness and recovery explicitly model correlated regional failure, power/cooling/network dependencies, failover capacity, and recovery-site independence rather than assuming backup infrastructure is unaffected.
8. Physical-disaster telemetry, drills, evacuation records, and logistics evidence are scoped to sites/assets/technical actions and cannot become employee movement analytics, user-location tracking, or workforce-performance scoring.
9. Routine releases and risky maintenance are frozen during critical facility disasters unless required for security, recovery, or incident containment under the emergency change policy.
10. Site requalification requires verified physical safety, power, cooling, network, sensor, hardware-trust, and data-integrity checks; power restoration or building re-entry alone never restores full production trust.
11. Disaster continuity preserves encryption, authorization, anonymity, federation trust, tenant isolation, and data-residency guarantees even in degraded local/offline or temporary networking modes.
12. Physical-disaster continuity integrates with DR, resilience, capacity, SLOs, hardware fleet, facility reliability, physical security, desired state, inventory, change/release governance, incident response, SOC, compliance, and sustainability without creating an emergency bypass around platform trust.

337. Initial Production Scope

Implement first:

typed PhysicalDisasterClass/DisasterSeverity
hazard scope/confidence model
facility emergency state machine
fire/flood/seismic/severe-weather response profiles
technical evacuation plans
precomputed drain/shutdown order
emergency failover target validation
site isolation
disaster role model
preparedness/readiness state
tabletop/failover exercise framework
asset salvage state machine
salvage custody integration
temporary recovery site model
emergency spare/logistics plans
site requalification checks
controlled service return
failback as separate governed change
privacy-safe disaster dashboards
disaster-continuity testkit

Then add:

regional hazard data adapters
advanced seismic/environmental modeling
logistics lead-time forecasting
automated temporary-site readiness validation
salvage laboratory workflow
formal evacuation/failover verification
cross-region disaster simulation

338. Definition of Done

Part 118 is complete when:

disaster classes/severity/scope are typed;
human safety precedence is explicit;
evacuation/failover/shutdown are separate;
fire/flood/earthquake response profiles exist;
failover targets must remain compliant;
damaged hardware is quarantined before reuse;
salvage preserves custody;
emergency spares still require trust establishment;
temporary recovery sites are time-bounded;
recovery is staged;
site requalification is mandatory;
failback is separately governed;
no workforce/user tracking is created;
disaster/privacy/fuzz/formal tests are specified.

339. Final Architecture

                    PHYSICAL HAZARD
                          │
                          ▼
                   HAZARD EVALUATION
                          │
                 ┌────────┼────────┐
                 │        │        │
              LOCAL     SITE    REGIONAL
                 │        │        │
                 └────────┼────────┘
                          ▼
                 EMERGENCY STATE
                          │
              ┌───────────┼───────────┐
              │           │           │
          EVACUATE      FAILOVER    SHUTDOWN
              │           │           │
              └───────────┼───────────┘
                          ▼
                  SALVAGE / REBUILD
                          │
                          ▼
                  SITE REQUALIFICATION
                          │
                          ▼
                CONTROLLED RETURN

Disaster-continuity safety model:

human safety first
+
precomputed evacuation/failover
+
compliant recovery sites
+
quarantine after physical exposure
+
custody-preserving salvage
+
trusted emergency logistics
+
site requalification
+
privacy-minimized continuity evidence

not:

keep staff inside to save uptime, move workloads to any available region, trust wet or tampered hardware after power-up, and suspend custody rules because it is an emergency

340. Final Principle

A physical disaster should force the system into a safer, more explicit state—not into improvised exceptions.

The correct model is:

protect people first
+
detect and classify hazards
+
evacuate and fail over deliberately
+
preserve integrity and custody
+
quarantine exposed assets
+
restore capacity through trusted logistics
+
requalify the site before return
+
never use emergency operations as justification for surveillance or security bypass

This architecture gives SIAR a privacy-preserving physical-continuity foundation for fire, flood, earthquake, severe weather, site evacuation, emergency shutdown, failover, asset salvage, emergency logistics, temporary recovery infrastructure, site requalification, and controlled return to service while preserving the anonymity, local-first, least-authority, hardware-trust, facility-security, resilience, and anti-surveillance guarantees established across Parts 34–117.

SIAR System Architecture & Technical Wiki