SAFETY

SAFETY = SAFETY_STANDARD × CANONIC = Structure(safety) × (C1, C2, Temporal, Relational, C5) = owned safety-critical vertical

SAFETY = C1 ∩ C2 ∩ Temporal ∩ Relational ∩ C5 ∩ C6 = ENTERPRISE (#63)

Safety-critical systems ALWAYS require full Enterprise because:

• C1: Safety requirements must be stated explicitly
• C2: Safety must be proven, not assumed
• Temporal: Development phases, operational lifecycles
• Relational: System boundaries, hazard interfaces
• C5: Certification authorities enforce
• C6: Industry safety standards (DO-178C, ISO 26262)

There is no shortcut for safety.

1. Safety is Non-Negotiable

Safety requirements MUST NOT be traded against cost, schedule, or performance without explicit hazard analysis and residual risk acceptance.

Example: A proposed software change would save $50,000 but bypasses a safety interlock. The change MUST be evaluated through formal hazard analysis. If residual risk exceeds acceptable threshold, the change is rejected regardless of cost savings.

2. Hazard Identification

All reasonably foreseeable hazards MUST be systematically identified and analyzed.

Example: A flight control system undergoes: Preliminary Hazard Analysis, System Hazard Analysis, Subsystem Hazard Analysis, Software Hazard Analysis, and Interface Hazard Analysis. Each level identifies hazards invisible at other levels.

3. Risk Reduction

Identified hazards MUST be mitigated to acceptable risk levels through design, safeguards, or warnings (in that order of preference).

Example: A robot arm hazard of “crush injury to operator” is mitigated by: (1) redesigning to reduce force (design), (2) adding presence-sensing safety curtain (safeguard), (3) posting warning label (warning). Design solutions are always preferred.

4. Traceability

Safety requirements MUST trace bidirectionally from hazards through design to verification evidence.

Example: Hazard H-001 → Safety Requirement SR-001 → Design Element DE-001 → Test Case TC-001 → Test Result TR-001. Any break in chain means safety is not demonstrated.

5. Independent Assessment

Safety-critical systems MUST be assessed by parties independent of the development team.

Example: A medical device software team completes development. An independent software quality assurance team reviews requirements, design, code, and test results. They report directly to management, not through the development team.

Pattern: ALL safety standards = ENTERPRISE (#63)

Higher level = more rigorous lattice enforcement.

`` DECLARE(DO178C) = RTCA_DO-178C × CANONIC

Where: DO-178C provides Structure: - Software development processes - Verification objectives (by DAL) - Life cycle data requirements - Certification liaison

CANONIC provides Governance: - C1: Requirements as claims - C2: Verification evidence - Temporal: Development phases - Relational: System/software boundary - C5: DER/certification authority

Result: DO178C = ENTERPRISE (#63)

Certification Lifecycle: Planning — PSAC, SDP, SVP, SCMP, SQAP Requirements — HLR, LLR traced to system Design — Architecture documented Code — Implementation traced Verification — Testing complete Configuration — All data controlled Certification — SCI/SOI complete ``

`` DECLARE(ISO26262) = ISO_26262 × CANONIC

Where: ISO 26262 provides Structure: - Safety lifecycle (12 parts) - ASIL determination - Hardware/software requirements - Functional safety assessment

CANONIC provides Governance: - C1: Safety goals, requirements - C2: Work products, confirmation measures - Temporal: Development phases - Relational: Item definition boundaries - C5: Safety manager, assessor

Result: ISO26262 = ENTERPRISE (#63)

Safety Lifecycle: Concept — Item definition HARA — Hazard analysis FSC — Functional safety concept TSC — Technical safety concept Development — HW/SW implementation Production — Manufacturing Operation — Field use ``

To create a CANONIC safety vertical:

Identify applicable safety standard (DO-178C, ISO 26262, etc.) Create scope with CANON.md inheriting /SAFETY/ Define safety requirements from hazard analysis Document evidence for all verification Establish development phases with reviews Define system boundaries and interfaces Implement independent assessment Compile safety case for certification

Result: Owned safety-critical vertical with certifiable evidence.

`` ∀ system ∈ SAFETY-CRITICAL: system = ENTERPRISE (#63)

No exceptions. No shortcuts. Lives depend on it. ``