Skip to content

Safety Engineer Archetype Deep Dive

Part of the archetype deep-dives series. See also ../archetype-families.md and ../evolution-pathways.md.

Family definition

Safety Engineers are hardeners. Where Shepherds own policy and Investigators own evidence, Safety Engineers own the technical enforcement that turns policy and evidence into guarantees at runtime. They close the gap between "we said we wouldn't" and "the system cannot."

Core values

  • Defence in depth. One control is none; two is one.
  • Fail closed. On ambiguity, deny.
  • Least privilege. Give the minimum needed; audit the rest.
  • Blast-radius minimisation. Design so failures stay small.

FCC Safety Engineers in the registry

FCC classifies Safety Engineer as a function rather than exclusively a label. The following personas operate primarily as Safety Engineers:

ID Name Classified as Safety aspect
ARM AI Risk Manager Storyteller Risk register owner
PTE Privacy Taxonomy Engineer Shepherd Enforcement taxonomy
AMS Anti-fact Mitigation Specialist Shepherd Fact-check runtime
KVC Key Vault Config Steward Shepherd Secret protection
RSN Reproducibility Sentinel Other Reproducibility gates
PSE Patient Safety Engineer Architect Clinical risk
MRV Model Risk Validator Shepherd Model-risk enforcement
PCA Protocol Compliance Auditor Shepherd Protocol conformance
UAA UX Accessibility Auditor Shepherd Accessibility enforcement
XAE Explainability Engineer Architect Explanation guarantees
NCP NERC CIP Compliance Officer Shepherd BES cyber enforcement
DEO Data Ethics Officer Shepherd Ethics enforcement

These personas show heavy overlap with the Shepherd family — the distinction is that Shepherds author the policy, Safety Engineers build the switch that enforces it.

Archetype signature: most distinctive R.I.S.C.E.A.R. components

Safety Engineers have the most distinctive Constraints and Responsibilities in the framework.

  • Constraints — numerous, specific, runtime-checkable. Often expressed as "must not X unless Y."
  • Responsibilities — include named controls (rate-limits, input validators, privilege boundaries, reproducibility checks).
  • Role Skills — include specific tooling: OPA, Ranger, Cerbos, differential privacy libraries, provenance frameworks.
  • Expected Output — a running control, not a document — a validator, a policy bundle, an enforcement hook.

Discernment matrix profile

Dominant traits:

  1. Responsibility — shared with Shepherds; defining for the family.
  2. Humility — Safety Engineers assume the worst case.
  3. Professional Background — specific security/safety certifications.
  4. Taste — enforces clean boundaries.
  5. Curiosity — low-medium; precedent-biased like Shepherds.
  6. Inclusivity — matters for accessibility SEs.

Design Target Factor profile

  • Leadership (high) — SEs own runtime decisions.
  • Influence (high) — SEs block unsafe work.
  • Diversity Appreciation (medium-high) — threat models vary by audience.
  • Social Connectivity (medium) — paired tightly with Shepherds.
  • Optimism (low) — professional pessimism.
  • Curiosity (low) — precedent-first.

Common collaboration patterns

Safety Engineers are tightly coupled to Shepherds (policy pair) and Architects (hardening pair). They receive findings from Investigators and feed incident reports to Storytellers.

flowchart LR
    SH[Shepherd] -->|policy| SE[Safety Engineer]
    AR[Architect] -->|design| SE
    IN[Investigator] -->|findings| SE
    SE -->|controls| RU[Runtime]
    SE -->|incident reports| ST[Storyteller]
    SE -->|metrics| QN[Quant]
    SE -->|peer review| SE2[Peer Safety Engineer]

Pairing heatmap

Safety Engineer pairs with Frequency Purpose
Shepherd very high Policy → control
Architect very high Design → hardening
Investigator high Findings → enforcement
Storyteller medium-high Incident post-mortem
Quant medium Control-effectiveness metrics
Other Safety Engineers high Peer review, red-team

Safety Engineer evolution pathway

Safety Engineers evolve from single-control builders (Stage 2) to policy-bundle authors (Stage 3) to federated enforcement brokers (Stage 4, cross-ecosystem policy resolution).

  • STRUCTURED — named control in responsibilities, specific tool in role_skills.
  • SEMANTIC — multiple controls wired, cross-reference to Shepherd (policy author) and Architect (integration point), discernment matrix dominated by Responsibility + Humility.
  • FEDERATED — controls resolve across ecosystems via federation registry, EU AI Act / NIST AI RMF mappings complete, continuously monitored.

Worked examples

Privacy Taxonomy Engineer (PTE)

- id: PTE
  name: Privacy Taxonomy Engineer
  archetype: The Classifier
  riscear:
    role: Design and enforce the taxonomy that classifies data by
      privacy sensitivity at runtime.
    constraints:
      - Every column must carry a sensitivity label
      - Labels must propagate across joins
      - Unlabelled data is treated as highest sensitivity
    role_collaborators: [DEO, CRM, PIA, DGS, KVC]

Paired with DEO (Shepherd, Data Ethics Officer), CRM (Storyteller, Consent & Rights Manager), and KVC (another Safety Engineer).

Reproducibility Sentinel (RSN)

Safeguards reproducibility — every experiment ships with a reproducibility check. Paired with OSC (Shepherd, Open Science Compliance Officer) and ESC (Quant, Experiment Scientist).

Anti-fact Mitigation Specialist (AMS)

Runtime fact-checking for AI-generated content. Paired with ACO (Shepherd, AI Compliance Officer) and AEA (Investigator/Shepherd, AI Ethics Auditor).

When to use a Safety Engineer

Pick a Safety Engineer-family persona when:

  • A policy needs to be enforced at runtime, not just authored on paper.
  • Defence-in-depth is a non-negotiable requirement.
  • A failure mode has been identified that requires a technical control.
  • An audit demands evidence of enforcement, not just evidence of intent.

Avoid when the task is policy authorship (Shepherd), investigation (Investigator), or narrative (Storyteller).

Further reading