INSIDE AEGISSAFEFORGE: FROM ITEM DEFINITION TO AN APPROVED HARA ARTIFACT

In our previous post, we explained the principle behind AegisSafeForge: AI proposes, the platform governs, and humans decide. That principle matters most when it leaves the architecture diagram and enters a real engineering workflow.

Hazard Analysis and Risk Assessment under ISO 26262 is a good place to show what it means in practice.

The challenge is turning scattered project information into structured functions, malfunctions, operational situations, hazardous events, classifications, rationales, and downstream safety decisions.

A generic AI assistant can produce a plausible table quickly. Plausibility, however, does not make the table reviewable, traceable, or accepted engineering work.

HARA begins with engineering context, not a blank prompt

The current workflow begins with a project and, where relevant, a system. Teams can add a Requirements Brief and supporting project or system documents when they are available. They then create or select a structured Item Definition before generating HARA candidates.

That distinction is important. The model is not given an isolated instruction such as “create a HARA for an automated braking system.” The generation request contains the selected Item Definition as structured data. Depending on what the team has provided, that can include functions, operating modes, system boundaries, interfaces, environmental conditions, assumptions, and other safety-relevant context.

Existing HARA rows are included as well. This gives the generation process continuity with the table already under review and helps it focus on missing scenarios instead of treating every request as a blank page.

The platform can also retrieve relevant passages from project and system documents that have been successfully ingested and enabled for retrieval. Shared organizational knowledge and industry-relevant standards context can contribute additional grounding.

Not every uploaded file is automatically used. It must be successfully ingested, enabled for retrieval, relevant to the request, and selected within retrieval limits. This boundary makes the workflow explainable instead of treating “grounded AI” as a vague promise.

From context to AI-suggested HARA rows

With that context assembled, AegisSafeForge can draft candidate rows for the HARA workspace. For an ISO 26262 analysis, the AI can help propose the function, malfunctioning behaviour, operational situation, hazard, hazardous event, consequence, Severity, Exposure, Controllability, and the rationale behind those suggestions.

It can also attach row-level reasoning, field-level reasoning, confidence information, and references to supporting passages where the retrieval context provides them.

The result is not a finished safety analysis. It is a structured starting point that an engineer can inspect, challenge, edit, and improve.

Generated rows enter the workspace as AI suggested and are persisted as engineering artifacts. They do not disappear with a chat session, and they do not silently become approved decisions. Their origin, reasoning, references, state, and later changes remain associated with the row.

Teams can generate an initial set, request incremental candidates, add rows manually, and review or approve suitable rows individually or in bulk. The workflow reduces the blank-page burden without transferring authority to the model.

ASIL is not accepted from the model

One of the most important boundaries in the workflow concerns ASIL.

The AI may propose Severity, Exposure, and Controllability values and explain why it considers those classifications appropriate. But the ASIL stored by AegisSafeForge is derived deterministically from the S, E, and C values using the platform’s ISO 26262 matrix.

The calculation is reapplied when HARA content is saved or updated and checked again during approval. The same inputs therefore produce the same platform-derived result; ASIL is not accepted as an unrestricted model opinion.

This creates a deliberate separation of responsibilities.

AI handles semantic drafting. It proposes scenarios, descriptions, classifications, and rationales from the available context.

The platform handles repeatable controls. It derives ASIL, validates required data, enforces lifecycle conditions, records provenance, and governs whether an artifact can move downstream.

The engineer handles judgment. The engineer decides whether the scenario is credible and complete, whether S, E, and C are justified for the real item, and whether the row should be approved.

Deterministic calculation does not remove engineering responsibility. It makes the consequence of the engineer’s accepted inputs consistent, inspectable, and reproducible.

Review is part of the artifact

In AegisSafeForge, review is not a disclaimer placed beneath generated content. It is part of the artifact lifecycle.

HARA rows can move through states including AI suggested, user created, edited, needs review, changes requested, clarification requested, changes implemented, approved, and stale. Those states affect what the platform permits next.

AI-generated rows require source references before approval. A row with requested changes must pass through the changes-implemented state before approval. Approved rows cannot be directly edited. Stale rows cannot be manually edited as though nothing changed. Open impact tasks or traceability blockers can prevent approval.

Approval identity, timestamps, state-transition history, and reasons can be retained with the artifact. The platform does not currently present every row as a full threaded discussion, but it does preserve the review decisions that determine the row’s engineering status.

This is the practical meaning of “humans decide.” The final authority is not a sentence in an AI policy. It is represented by explicit actions, stored state, identifiable reviewers, and workflow consequences.

From approved HARA rows to traceable Safety Goals

Approving a HARA row does more than change a status badge. It determines whether the row can become trusted input to the next stage.

Once at least one HARA row is approved, the Safety Goal workspace becomes available. Safety Goals are created as separate work products from approved HARA rows associated with the selected Item Definition—not from unreviewed suggestions elsewhere in the table.

The HARA-to-Safety Goal relationship is stored as explicit artifact links. Before a Safety Goal can be approved, the platform requires real links to approved HARA rows and checks that its ASIL matches the highest ASIL among those linked rows.

Those links allow a reviewer to trace a Safety Goal back to the HARA decisions that justify it: the contributing hazards and hazardous events, their S/E/C classifications, the derived ASIL, and the review state of each source row.

The chain continues from Safety Goals to Functional Safety Requirements, Technical Safety Requirements, and verification-evidence work. Approval gates at each stage preserve the distinction between draft content and accepted upstream decisions, making it possible to inspect which safety decision supports a requirement or evidence plan.

An illustrative automated emergency braking example

Consider a simplified automated emergency braking function. This is an illustrative example, not customer data or a complete project analysis.

The function detects an imminent collision and commands emergency deceleration. The malfunction is that required emergency braking is not commanded. The operational situation is urban driving at 50 km/h while a pedestrian enters a crossing.

The hazardous event is the loss of automatic emergency braking during an imminent pedestrian collision. The potential consequence is life-threatening or fatal injury to the pedestrian.

An engineer might propose Severity S3, Exposure E4, and Controllability C3. From those accepted inputs, the platform deterministically derives ASIL D.

An illustrative Safety Goal could then state: “Loss of required emergency braking during an imminent collision shall be prevented or controlled so that the vehicle reaches a driver-controllable safe condition.”

The example shows the division of work, but it does not make the ratings universal. Severity, Exposure, and Controllability remain project-specific engineering judgments that require expert justification against the real item, operating context, assumptions, and evidence.

Traceability from Item Definition to Safety Goals—and beyond

A HARA table is only one view of a connected engineering artifact.

AegisSafeForge retains the project and Item Definition association, HARA row identity, AI-generation provenance, reasoning, source references, review status, user identity, timestamps, content hash, and row version. Retrieved evidence can retain its source document, section, page, chunk, and supporting snippet.

Item Definition → HARA row → Safety Goal → Functional Safety Requirement → Technical Safety Requirement → verification evidence

Explicit links carry the accepted decision forward. A reviewer can inspect which HARA rows support a Safety Goal, which requirements descend from that goal, and which evidence is intended to verify those requirements. Link-history events, impact events, remediation tasks, and table-baseline comparisons add governance when those relationships or their source content change.

One current boundary remains: every HARA row retains its Item Definition association, but automatic creation of the canonical Item Definition-to-HARA trace link is not yet consistent. We are completing that wiring rather than claiming fully automatic end-to-end traceability today. The downstream HARA-to-Safety Goal and requirements links are the controlled trace chain we can already build on.

Building toward governed change impact

Safety work does not stop changing after approval. Functions evolve, operating modes change, assumptions are revised, and engineers discover new information.

AegisSafeForge already contains the foundation for governed change-impact propagation across linked artifacts. The impact engine can traverse active downstream relationships, mark links stale, record dependency paths, create impact events, preserve approved artifacts, create impacted successor drafts, and open remediation tasks. Relevant unresolved impacts can prevent approval or downstream generation.

The preservation behaviour matters. Approved work is not silently overwritten because an upstream value changed. The approved record remains available while the resulting impact is handled through a new controlled workflow.

However, automatic propagation from an Item Definition change into HARA currently depends on the Item Definition-to-HARA link that is not yet created consistently. For that reason, we describe change impact as an implemented foundation that we are continuing to connect and validate across the full lifecycle—not as a fully closed loop today.

What we are strengthening next

Introducing AI into safety engineering requires transparency about limitations as well as capabilities.

Document grounding currently depends on successful ingestion and relevance ranking. Structured requirement objects are not yet passed directly into HARA generation. Semantic duplicate detection is not yet a deterministic control, and allowed rating-value validation needs further strengthening beyond the existing required-field and ASIL checks.

We are also improving selected-row regeneration in the active HARA interface, server-side enforcement of approval roles, consistent readiness rules across generic and official exports, and clearer UI support for new versions and impact remediation.

Finally, the HARA tool-qualification package has a defined baseline and evidence plan, but manual execution evidence and independent functional-safety approval are still in progress. We do not describe the workflow as tool-qualified today.

These are not footnotes to hide. They are part of preparing the platform for real safety-engineering environments, where product claims must be as reviewable as the artifacts the product creates.

Acceleration without transferring authority

Our objective is not to make HARA automatic. It is to make the path from project context to a reviewable and traceable HARA more structured, while preserving expert judgment at every safety-relevant decision.

AI can help teams move beyond the blank page. Deterministic logic can make repeatable controls consistent. Workflow states and traceability can prevent a suggestion from quietly becoming accepted truth. But the engineer must still understand the item, challenge the scenario, justify the ratings, and own the decision.

That is how we are applying our product principle inside AegisSafeForge: AI proposes, the platform governs, and humans decide.

We are looking for pilot partners to test AegisSafeForge with representative project data, evaluate how the governed workflow fits existing safety-engineering processes, and measure its effect on drafting, review, change control, and traceability effort.