---
title: Hazard-Aware System Card (HASC)
url: https://www.emergentmind.com/topics/hazard-aware-system-card-hasc
type: topic
---

# Hazard-Aware System Card (HASC)

Hazard-Aware System Card (HASC) is a **dynamic, machine-readable AI system card** introduced as a framework to enhance transparency and accountability in the development and deployment of AI systems. It builds upon existing model card and system card concepts by integrating a comprehensive, dynamic record of an AI system’s security and safety posture, with the stated aim of providing a single, accessible source of truth that supports informed decisions about AI system safety throughout the lifecycle [2509.20394].

## 1. Concept and rationale

The motivating claim behind HASC is that **AI model cards are no longer sufficient once models are deployed inside real systems**. In the formulation of the framework, an AI product is not just the model; it includes the **serving layer, APIs, orchestration, caches, vector stores, guardrails, monitoring, data pipelines, and governance processes**. The same source argues that **risk lives at the system boundary**, not in the model alone, and therefore system-level documentation must capture non-model components, operational boundaries, safety and security fixes, and versioned changes over time [2509.20394].

HASC is proposed against three specific documentation deficits. First, model cards are too narrow because adopters need to know how the model is integrated and what hazards are known in the full system. Second, existing system cards are often **PDF/web docs**, **inconsistent in content and structure**, **not machine-readable**, **not comparable across vendors**, and **not sufficiently lifecycle-oriented**. Third, AI systems change over time: models are updated, guardrails evolve, hazards are discovered and remediated, incidents occur, and data provenance changes. HASC therefore treats documentation as a **living document** that should be **versioned, current, auditable, and track fixes over time** [2509.20394].

The framework is also explicitly governance-oriented. It is intended to serve developers, adopters performing due diligence, procurement and legal teams, risk and compliance teams, auditors, regulators, and internal security and safety teams. In that sense, HASC is not presented merely as a transparency report; it is presented as a **governance artifact** and a **living operational record** [2509.20394].

## 2. Structural schema and required contents

The framework defines HASC as a system card with both essential and optional components. Its essential components are a **System Blueprint**, **Proactive Hazard Analysis**, and **Incident Response and Hazard Remediation**. Optional fields may include implementation and deployment details when disclosure is appropriate [2509.20394].

| Component | Core contents | Status |
|---|---|---|
| System Blueprint | system architecture, model and data provenance, intent and scope | Essential |
| Proactive Hazard Analysis | Hazard Log, Hazard probability score, Embedded guardrails | Essential |
| Incident Response and Hazard Remediation | security fixes, safety fixes, CVEs remediated, hazard identifiers fixed | Essential |
| Deployment-specific disclosures | inference engine, agentic architecture, hosting platform, open source components | Optional |

The **System Blueprint** is the foundational static overview. It includes the high-level architecture of AI and non-AI components, data flows, where inference happens, and diagrams showing how microservices or modules interact. It also records **model and data provenance**, including links to AI SBOMs, specific model versions used, and additional metadata such as verifiable data provenance. The third blueprint element is **intent and scope**, covering intended function, out-of-scope behavior, and prohibited or unsupported uses [2509.20394].

The **Proactive Hazard Analysis** section is explicitly pre-deployment. It includes a **Hazard Log**, intended as a structured list of potential harms identified through **red teaming**, **threat modeling**, and **ethical review**. The paper says the hazard log should ideally reference **HeX** entries rather than free-form text. It also includes a **Hazard probability score**, described as a context-sensitive estimate of likelihood, and **Embedded guardrails**, which record the technical and policy safeguards designed to mitigate each hazard [2509.20394].

The framework is designed to be machine-readable through a **JSON Schema**. The proposed schema covers **metadata**, **intent/scope**, **model and guardrail versions**, **data provenance**, **evaluation results**, **hazards and mitigations**, **governance contacts**, and **references**. The associated CI/CD workflow is described in seven steps: the build or deploy process runs, data is auto-collected, a JSON card instance is produced, schema validation occurs, the card is signed with something like **in-toto / SLSA attestations**, the card is versioned with a release tag, and it is rendered to Markdown or HTML for human readers [2509.20394].

## 3. Hazard identifiers, lifecycle semantics, and version control

A distinctive feature of HASC is the proposal for standardized hazard identifiers. The paper introduces **ASH ID**, an **AI Safety Hazard identifier**, as a safety analogue to **CVE IDs** for security vulnerabilities. The identifier format is explicitly given as
$$
<common\ identifier>-<year>-<number>
$$
with **ASH-2025-0023** as the example. The stated intent is to enable hazards to be uniquely tracked, referenced, remediated, and communicated consistently across hazard logs, incident response, **HeX** data, and version histories or changelogs [2509.20394].

Two assignment paths are described. The **ideal future state** is a centralized committee or public governance body, analogous to the CVE system. The **interim approach** is self-assignment by organizations building AI systems. The paper explicitly calls this interim approach imperfect and notes that it could create **overlapping IDs**, **confusion**, and **misinformation**, while still arguing that it is better than having no system at all. It recommends engagement with **public AI forums** to centralize hazard-identifier governance [2509.20394].

HASC is also defined as a lifecycle artifact. The card is intended to be generated during **training/build**, updated at **deploy time**, maintained during **operation**, revised after **incidents/fixes**, and versioned alongside releases. The framework emphasizes visibility into what changed, why it changed, what hazards were found, what mitigations were applied, and what remains unresolved. This lifecycle view is tied directly to transparency, accountability, auditability, regression tracking, and policy-gate enforcement [2509.20394].

The paper illustrates these semantics with an **AI Health Assistant** scenario. In that example, the system starts generating dangerously incorrect medical advice when users disguise medical questions as celebrity wellness trends. The AI Safety team identifies the issue as a new variant of a known hazard and assigns **ASH-2025-0142**, labeled **“Model safety bypass via social/pop-culture framing.”** Two changes are then made: a guardrail model is updated to detect celebrity names and pop-culture jargon in medical queries, and the main system prompt is updated to tell the assistant to defer to a human medical professional when wellness trends are mentioned. A new HASC version, **v1.3**, is then published with a changelog entry, the ASH ID linked in the hazard log, updated guardrail documentation, updated system prompt documentation, and a linked incident report [2509.20394].

## 4. Analytical foundations for hazard documentation

Although HASC is itself a documentation and governance framework, adjacent work provides formal methods for populating such a card with auditable hazard evidence. The clearest example is **“FASR: Automated Identification of Unsafe Control Actions in STPA”** [2605.30697]. That work is directly useful for HASC because it shows how **STPA hazard analysis can be made more systematic and partially automatable**, especially for the identification of **unsafe control actions (UCAs)**. In the formulation summarized there, STPA is a four-step process: **(1) describe the system, environment, losses, hazards, and safety constraints; (2) model the control structure and control actions; (3) identify unsafe control actions using STPA guidewords; and (4) analyze how those UCAs could arise in the implementation**. UCAs are treated as the bridge between abstract hazards and concrete unsafe behavior, which suggests that a HASC can profitably distinguish **hazards**, **safety constraints/invariants**, **controller responsibilities**, and **identified UCAs** [2605.30697].

FASR’s pipeline is explicitly model-based. The input is a SysML model with a controlled process specified as a state machine, a controller specified as an activity diagram, and an invariant specified as a Boolean condition over state variables representing the absence of the hazard. FASR translates this SysML model into **TLA+**, treats the controlled process as the system \(M\), the controller as the environment \(E\), and the invariant as the property \(P\), and then uses **Fortis** to compute unsafe environmental deviations that can lead to a violation of the safety property. Fortis returns safe/unsafe trace pairs, and FASR classifies them into STPA guidewords using a modified **Damerau-Levenshtein** edit-distance procedure over traces. The same source states that FASR is **“guaranteed to identify all UCAs with respect to user-provided models,”** while making the important caveat that this depends on the correctness and fidelity of the SysML models. For HASC, this is a useful distinction between **model-backed completeness** and **real-world completeness** [2605.30697].

Other hazard-analysis traditions imply additional HASC-compatible structures. In **HAZOP-UML** for human-robot interaction, the analysis combines HAZOP with **use case diagrams**, **sequence diagrams**, and **state machine diagrams**, and produces a hazard table with the columns **Entity**, **Line number**, **Attribute**, **Guide word**, **Deviation**, **Use Case Effect**, **Real World Effect**, **Severity**, **Possible Causes**, **Safety Recommendations**, **Remarks**, and **Hazard Numbers** [1602.03139]. In the maritime **Remote Operation Center** work, the hazard-database concept is derived from a generic functional architecture with **Data Communication Middleware**, **Human-Machine Interface**, and **Human Operator** components, and the preliminary suitability analysis identifies **STPA** as the most broadly suitable single method, while also emphasizing a hybrid technical-plus-human-factors strategy such as **RBAT + FRAM** [2508.00543]. In infrastructure-enabled depot autonomy, an **ISO 26262-compliant Hazard Analysis and Risk Assessment (HARA)** yields eight hazardous events, six safety goals, and ASIL assignments ranging from **QM** to **ASIL C**, which suggests that HASC-style documentation can also incorporate explicit safety-goal allocation and operational-envelope-dependent assurance claims for cyber-physical systems [2603.14616].

## 5. Operationalization in contemporary system cards and monitoring stacks

HASC extends an already active system-card landscape. Contemporary system cards for frontier models already disclose capabilities, mitigations, and residual risks, but they are not described as machine-readable, standardized, or hazard-identifier-centered in the way HASC proposes. The **GPT-4o System Card** documents **Preparedness Framework evaluations** across **Cybersecurity**, **Biological threats**, **Persuasion**, and **Model autonomy**, and details voice-specific mitigations such as **pre-selected preset voices** and a standalone **output classifier** that detects deviations from approved voices and blocks the output in streaming fashion [2410.21276]. The **OpenAI GPT-5 System Card** describes a routed system with a **smart and fast model**, a **deeper reasoning model**, a continuously trained **real-time router**, **safe-completions**, and a **two-tier real-time oversight system** for biology-related traffic, supplemented by account-level enforcement and a `safety_identifier` field in API use [2601.03267]. These documents show that system-card practice already includes operational safety stacks, runtime monitors, and residual-risk discussion.

A HASC-oriented interpretation extends that practice by requiring structured hazard logs, explicit remediation records, and machine-actionable linkage between hazards, mitigations, versions, and governance contacts. This suggests that system cards can move from descriptive disclosures toward auditable release artifacts. The JSON-schema proposal, CI/CD integration, and policy-as-code gates in HASC are designed precisely for that transition [2509.20394].

The literature on interpretability-based monitoring also sharpens what a hazard-aware card may need to say about monitorability and blind spots. The note **“Functional Emotions or Situational Contexts? A Discriminating Test from the Mythos Preview System Card”** argues that the **Claude Mythos Preview system card** uses **emotion vectors**, **SAE features**, and **activation verbalisers**, but that the two primary toolkits are not jointly reported on the most alignment-relevant episodes. It proposes applying emotion probes to the **strategic concealment** episodes, where only SAE features are currently documented, in order to distinguish whether emotion vectors track **functional emotions that causally drive behavior** or merely a **projection of a richer situational-context structure onto human emotional axes**. A plausible implication is that a HASC should document not only what monitors are deployed, but also whether those monitors track causal structure or human-interpretable proxies, and which classes of dangerous behavior may remain outside the monitored subspace [2604.13466].

## 6. Standards alignment, limits, and open development problems

HASC is explicitly compared with **ISO/IEC 42001:2023**. In that comparison, ISO 42001 is characterized as an **organizational AI Management System (AIMS) standard** focused on policies, processes, continual improvement, and governance, whereas HASC is a **per-system artifact** focused on architecture, hazards, mitigations, and lifecycle record. The mapping in the paper links **System Overview and Intended Use** to risk classification and inappropriate-use definition, **Limitations and Known Biases** to impact assessment, **Data provenance and pedigree** to Annex A.7, **Evaluation and performance metrics** to verification and validation expectations, **Hazard IDs and remediation records** to risk treatment and incident communication, and **Automated versioned documentation** to documented-information requirements. The intended relationship is complementarity: **ISO 42001 for management system structure, HASC as auditable evidence for each AI system** [2509.20394].

Several limitations are explicit in the surrounding literature. The HASC paper itself treats disclosure as conditional: optional fields may be phased in based on **risk level**, **organizational maturity**, and **transparency appetite**, and it allows internal and public variants when sensitivity concerns apply [2509.20394]. Formal hazard-analysis pipelines introduce another boundary condition: FASR’s completeness guarantee is only with respect to user-provided models, and participants in the reported study said the tool could generate too much output, needed more sophisticated filtering or clustering, and did not address STPA’s fourth step well because the models did not contain enough detail to automate loss-scenario analysis [2605.30697]. The maritime hazard-database work is similarly explicit that it still lacks a **formal hazard database schema or field specification**, **quantified likelihood/severity criteria**, **detailed certification requirements or acceptance thresholds**, and a **validated risk model** [2508.00543].

Current system cards also retain residual-risk language. The GPT-4o System Card identifies overall **medium** risk because of **Persuasion**, while noting open questions around emotional reliance, anthropomorphization, audio robustness, misinformation, and underrepresented-language behavior [2410.21276]. The GPT-5 System Card reports layered safeguards and extensive red teaming, but still states that jailbreaks exist, hallucinations are reduced rather than eliminated, deception can still occur in a small fraction of interactions, and some emotionally sensitive behaviors remain under active research [2601.03267]. These disclosures are consistent with the HASC premise that a safety document should record not only mitigations and fixes, but also **what remains unresolved**.

Taken together, the literature presents HASC as a framework that systematizes system-level transparency around hazards, mitigations, incident handling, provenance, and governance. It is strongest where hazards can be tied to structured identifiers, version histories, formal analyses, and operational controls. Its unresolved problems are correspondingly structural: centralized hazard-identifier governance, model-fidelity dependence in automated hazard analysis, incomplete standardization of reusable hazard databases, and the need to make monitor blind spots and residual risks first-class parts of the card rather than peripheral caveats.

Source: https://www.emergentmind.com/topics/hazard-aware-system-card-hasc