Hazard-Aware System Card (HASC)
- Hazard-Aware System Card (HASC) is a dynamic, machine-readable framework that systematically documents AI system hazards, mitigations, and operational changes.
- It integrates diverse system components—from model details to serving layer operations—to support continuous risk tracking and regulatory compliance.
- HASC employs standardized hazard identifiers and version control to create an auditable, living record that improves transparency and accountability in AI deployments.
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 (Sidhpurwala et al., 23 Sep 2025).
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 (Sidhpurwala et al., 23 Sep 2025).
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 (Sidhpurwala et al., 23 Sep 2025).
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 (Sidhpurwala et al., 23 Sep 2025).
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 (Sidhpurwala et al., 23 Sep 2025).
| 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 (Sidhpurwala et al., 23 Sep 2025).
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 (Sidhpurwala et al., 23 Sep 2025).
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 (Sidhpurwala et al., 23 Sep 2025).
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
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 (Sidhpurwala et al., 23 Sep 2025).
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 (Sidhpurwala et al., 23 Sep 2025).
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 (Sidhpurwala et al., 23 Sep 2025).
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 (Sidhpurwala et al., 23 Sep 2025).
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” (Dardik et al., 29 May 2026). 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 (Dardik et al., 29 May 2026).
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 , the controller as the environment , and the invariant as the property , 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 (Dardik et al., 29 May 2026).
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 (Guiochet, 2016). 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 (Neurohr et al., 1 Aug 2025). 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 (Pandey et al., 15 Mar 2026).
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 (OpenAI et al., 2024). 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 (Singh et al., 19 Dec 2025). 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 (Sidhpurwala et al., 23 Sep 2025).
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 (Peiris, 9 Apr 2026).
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 (Sidhpurwala et al., 23 Sep 2025).
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 (Sidhpurwala et al., 23 Sep 2025). 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 (Dardik et al., 29 May 2026). 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 (Neurohr et al., 1 Aug 2025).
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 (OpenAI et al., 2024). 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 (Singh et al., 19 Dec 2025). 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.