SAFETY
SERVICE CONTRACT · VIEW: GOV
Axiom
Example
Constraints
MUST: Cite specific safety standard or regulation for claims MUST: Distinguish between safety integrity levels across domains MUST NOT: Present compliance with one domain's safety standard as covering another
COVERAGE: 255/255
SPEC
Domain Declaration
SAFETY = SAFETY_STANDARD × CANONIC
= Structure(safety) × (C1, C2, Temporal, Relational, C5)
= owned safety-critical vertical
Lattice Formula
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.
Axioms
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.
Subdomains
| Subdomain | Standard | Formula | Industry |
|---|---|---|---|
| Aviation Software | DO-178C | ENTERPRISE | Aerospace |
| Aviation Hardware | DO-254 | ENTERPRISE | Aerospace |
| Automotive | ISO 26262 | ENTERPRISE | Automotive |
| Medical Devices | IEC 62304 | ENTERPRISE | Healthcare |
| Industrial | IEC 61508 | ENTERPRISE | Process/machinery |
| Nuclear | NRC regulations | ENTERPRISE | Nuclear power |
| Rail | EN 50128 | ENTERPRISE | Railway |
Pattern: ALL safety standards = ENTERPRISE (#63)
Safety Integrity Levels
| Domain | Levels | Highest | Meaning |
|---|---|---|---|
| Aviation | DAL A-E | DAL A | Catastrophic failure condition |
| Automotive | ASIL A-D | ASIL D | Life-threatening injury |
| Industrial | SIL 1-4 | SIL 4 | Catastrophic consequence |
| Medical | Class A-C | Class C | Death or serious injury |
Higher level = more rigorous lattice enforcement.
Example: Aviation Software (DO-178C)
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
Example: Automotive Safety (ISO 26262)
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
Safety Evidence
| Evidence Type | Lattice | Purpose |
|---|---|---|
| Hazard Log | BUSINESS | Hazard tracking |
| Safety Requirements | (#23) | Safety claims |
| Design Rationale | (#25) | Design justification |
| Verification Results | (#33) | Test evidence |
| Traceability Matrix | BUSINESS | Bidirectional trace |
| Safety Case | ENTERPRISE | Certification argument |
Validators
| Validator | Checks | Example Failure |
|---|---|---|
| C1 | Safety requirements exist | Missing safety goal |
| C2 | Evidence complete | Untested safety requirement |
| Temporal | Phases completed | Skipped review milestone |
| Relational | Boundaries defined | Unclear system scope |
| C5 | Assessment complete | No independent review |
| C6 | Standard conformance | Missing required work product |
Application
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.
The Safety Imperative
∀ system ∈ SAFETY-CRITICAL:
system = ENTERPRISE (#63)
No exceptions. No shortcuts. Lives depend on it.
LEARNING
ROADMAP
VOCAB
| Term | Definition |
|---|---|
| ASIL | Governed term in this scope vocabulary. |
| ASRS | Governed term in this scope vocabulary. |
| CANON | Governed term in this scope vocabulary. |
| CE | Governed term in this scope vocabulary. |
| CFR | Governed term in this scope vocabulary. |
| CPSC | Governed term in this scope vocabulary. |
| CPSIA | Governed term in this scope vocabulary. |
| CSA | Governed term in this scope vocabulary. |
| DAL | Governed term in this scope vocabulary. |
| EU | Governed term in this scope vocabulary. |
| FMEA | Governed term in this scope vocabulary. |
| FMECA | Governed term in this scope vocabulary. |
| HAZOP | Governed term in this scope vocabulary. |
| IEC | Governed term in this scope vocabulary. |
| ISO | Governed term in this scope vocabulary. |
| NASA | Governed term in this scope vocabulary. |
| NIOSH | Governed term in this scope vocabulary. |
| NTSB | Governed term in this scope vocabulary. |
| OSHA | Governed term in this scope vocabulary. |
| OT | Governed term in this scope vocabulary. |
| PPE | Governed term in this scope vocabulary. |
| PSM | Governed term in this scope vocabulary. |
| RAPEX | Governed term in this scope vocabulary. |
| SAFETY | Governed term in this scope vocabulary. |
| SIL | Governed term in this scope vocabulary. |
| STAMP | Governed term in this scope vocabulary. |
| STPA | Governed term in this scope vocabulary. |
| UL | Governed term in this scope vocabulary. |
INHERITANCE CHAIN
INDUSTRIES
INDUSTRY is the variable. SERVICE = PRIMITIVE(s) + INDUSTRY. Each vertical defines INTEL, CHAT, COIN.
MUST: Every INDUSTRY wires INTEL + CHAT + COIN MUST: Standards mapped to governance dimensions MUST: LANGUAGE cascades from MAGIC — no per-industry DESIGN.md MUST NOT: Create INDUSTRY without SERVICE proof
MAGIC
INTEL. CHAT. COIN. — Three primitives. One governed economy.
MUST: CANON.md in every scope
MUST: Services compose primitives — never duplicate
MUST: Primitive structure is fixed — industry is the only variable
MUST: Primitives compose into services — never duplicate
MUST: Services connect through SHOP.md and VAULT.md projection files
MUST: SHOP.md = public projection file (filesystem-discoverable, UPPERCASE per LANGUAGE)
MUST: VAULT.md = private projection file (filesystem-discoverable, auth-gated, UPPERCASE per LANGUAGE)
MUST: Instance = service projected through user governance context
MUST: Instance directories live at USER scope ({USER}/{PLURAL}/), not nested in SERVICES/
MUST: Service directories (SERVICES/{SINGULAR}/) define schemas — instances hold content
MUST: Every .md compiles to .json with the same name (direct mapping)
MUST: CANON.md = axiom + universal constraints only (no service names, no paths, no implementation)
MUST: README.md = how to run the CANON only
MUST: {SCOPE}.md = SPEC — the interface (purpose, routes, projections, ecosystem)
MUST NOT: Hardcode service names in CANON constraints (law speaks universals)
MUST: Inheritance resolves upward — scopes compose by directories
MUST: Tier algebra is canonical — DESIGN.md is the single source (COMPLIANCE tier algebra)
MUST NOT: Expose dimension internals to users or developers
MUST NOT: Hardcode outside governed contracts
MUST: Nonprofits get enterprise for free
MUST: ORG is the container; USER is the repo (`github.com/{org}/{user}`; duplicates across orgs allowed)
MUST: MARKET/ SALES/ GTM/ exist (META self-closure; one primitive each)
MUST: Each META sub-scope maps exactly one primitive (INTEL, CHAT, COIN)
MUST NOT: Add META business knowledge outside MAGIC/ scope
MUST NOT: Remove META sub-scope without replacing its primitive coverage
MUST: `{SCOPE}.md` is the scope contract surface; it MUST NOT be treated as a generic filename placeholder
MUST: LEARNING.md is the terminal — governance evidence, patterns, epoch rotation
MUST: LEARNING/ is the IDF directory — machine-generated individual data files
MUST: LEARNING.md rotates at epoch boundaries — frozen epochs archive as LEARNING-{EPOCH}.md at scope root
MUST: LEARNING.md is always the current epoch — active, append-only
MUST: Epoch boundary = EVOLUTION signal in LEARNING.md (named, dated, sourced)
MUST NOT: Delete archived LEARNING epochs — append-only history
MUST: MAGIC defines the triad interface directly:
MUST: COMPLIANCE/ + GALAXY/ + SURFACE/
MUST NOT: Define conflicting tier algebra in downstream scopes; downstream must inherit this contract
FOUNDATION
SPEC = {SCOPE}. The LANGUAGE. The v0 discovery.
MUST: LANGUAGE defines all governance primitives MUST: Every scope inherits from FOUNDATION MUST: Triad (CANON.md + VOCAB.md + README.md) in every scope MUST NOT: Define terms outside VOCAB.md MUST NOT: Hardcode outside the kernel SHOULD: Vocabulary closure — every term resolves to a definition