AI PROPOSES, PLATFORM GOVERNS, HUMANS DECIDE

AI can generate safety and cybersecurity artifacts quickly. The harder question is whether those artifacts can be reviewed, governed, traced, and defended.

A language model can draft a convincing HARA row, threat scenario, safety requirement, or technical rationale in seconds. But convincing is not the same as correct.

A proposed classification may not fit the operating situation. A requirement may not trace back to an approved decision. A rationale may sound reasonable while overlooking important system context.

In regulated engineering, these are not minor drafting mistakes. They can affect downstream requirements, verification effort, risk treatment, and the wider safety or cybersecurity argument.

This is why one of the core principles behind Aegis SafeForge is:

It is not a slogan placed beside an AI assistant. It shapes how work is generated, reviewed, approved, connected, exported, and maintained across the platform.

A suggestion should remain a suggestion

Consider a generated TARA or HARA row.

The AI may propose a scenario, classification values, rationale, and links to relevant system information. But that row does not automatically become approved engineering evidence.

It begins in an AI suggestion state.

Before it can move forward, an engineer must review it, inspect the cited sources, correct or expand the content where necessary, and submit it for review. The platform then applies the required workflow states, permissions, relationships, and deterministic checks.

Only after the responsible reviewer approves it can the decision become trusted context for downstream work.

This boundary matters because the main risk is not only that AI might produce a wrong answer.

The greater risk is that a plausible suggestion may lose its status as a suggestion. It might be copied into a spreadsheet, included in a report, reused in another analysis, or passed downstream without anyone being able to determine where it came from or who accepted it.

Aegis SafeForge is designed to keep that distinction visible.

The AI works inside the engineering context

Safety engineering is not a sequence of isolated prompts.

Requirements influence the system definition. The system definition provides context for hazard, failure, and threat analysis. Approved analysis results lead to goals, requirements, controls, and verification activities.

Every stage depends on decisions made earlier.

In Aegis SafeForge, users begin by creating a project and selecting the relevant industry. The platform currently includes automotive, medical, rail, and process-industry contexts.

Inside the project, the user creates the system being analyzed and provides its basic information. Existing information can also be imported from systems in other projects where appropriate.

The user then selects the standards that will guide the analysis. An automotive system can, for example, be configured around ISO 26262, ISO/SAE 21434, or both.

Supporting documents can be uploaded during setup and added throughout the engineering process.

Using the available context, the AI can suggest a process model for the system. The platform includes V-model and waterfall structures and can adapt the suggested process based on the industry, selected standards, system context, and available documents.

The user remains in control and can switch between a standard template and a customized model.

This means the AI is not being asked to produce engineering work from a blank prompt. It operates inside a workspace that already contains the system context, applicable standards, supporting documents, requirements, and approved upstream work.

This does not guarantee that every suggestion will be correct. It gives the engineer a more relevant and reviewable starting point.

Approved context moves the process forward

Human approval is not added only at the end of the workflow. It controls what the platform can use at each subsequent stage.

Users can create high-level requirements manually or extract candidate requirements from uploaded documents. AI can assist with preparing the content, but only approved high-level requirements can be used to generate low-level requirements.

The same principle applies to item definitions.

An item definition can be created manually or generated from approved requirements, supporting documents, and project context. Aegis SafeForge provides standard-specific templates so the result follows the expected structure instead of becoming an unrestricted block of generated text.

Only an approved item definition can become the basis for downstream safety analysis.

The same pattern continues through the artifact chain:

The platform also brings connected workflows for FMEA, FMEDA, FTA, ETA, ISO/SAE 21434 TARA, HAZOP, and LOPA into the same engineering environment.

The goal is not simply to place many artifact types in one interface. It is to preserve the relationships between them and control which decisions are trusted enough to move forward.

AI proposes where reasoning is useful

Inside an artifact workspace, engineers can add rows manually or ask the AI to prepare draft content using the system context, approved upstream artifacts, and supporting documents.

For a HARA, the AI may propose hazards and hazardous events, operational situations, Severity, Exposure, and Controllability values, supporting rationale, and links to relevant upstream information.

The engineer can review each row, edit it, or select it for regeneration with instructions explaining what should change.

The same approach applies across other workflows. AI can assist with drafting requirements, threat scenarios, failure modes, goals, controls, and related engineering content.

It provides a structured starting point. It does not provide final approval.

Deterministic logic handles repeatable rules

Not every part of safety engineering should be left to a language model.

Some tasks benefit from contextual interpretation. Others must produce a consistent and reproducible result whenever the same inputs are provided.

Aegis SafeForge separates these responsibilities.

In a HARA, the AI may suggest Severity, Exposure, and Controllability values together with supporting rationale. The ASIL is then determined through a defined lookup table instead of being freely generated by the model.

Similarly, the ASIL of a Safety Goal is derived from the approved HARA rows linked to it.

This creates a practical division of responsibility.

AI handles drafting and contextual suggestions.

Deterministic logic handles defined and repeatable rules.

Engineers decide whether the inputs, rationale, and resulting decision are appropriate for the real system.

The deterministic layer does not remove engineering judgment. It ensures that rule-based outcomes are calculated consistently after the responsible humans have evaluated the inputs.

Human review is a real workflow

AI-generated rows begin in an AI suggestion state.

When an engineer modifies a suggestion, the row moves into an edited state, and the changes are attributed to the person who made them.

The engineer can then submit the row for review, moving it into needs review.

Under the default permission model, engineers generate and prepare the work, while team leads review and approve it. The person who created the row cannot approve their own work by default.

A reviewer can approve the row, request changes, or escalate it to a manager.

When changes are requested, the row moves into changes requested. After the engineer responds, it becomes changes implemented and returns to the reviewer.

The reviewer can then approve the revised row or request further changes.

These permissions can be configured by the organization administrator, but the default workflow preserves a separation between creation and approval.

Human oversight is not a checkbox placed beside generated content. It has states, responsibilities, permissions, and consequences.

Sources remain available for review

Saying that an AI system is source-grounded is not enough. Reviewers need to see which information influenced a suggestion.

Aegis SafeForge divides uploaded documents according to their structure, including headings, subheadings, deeper section levels, table rows, figures, and page locations.

When a retrieved passage contributes to a generated suggestion, it is displayed as a source link. The engineer can open the relevant location in the original uploaded document.

This allows the reviewer to ask practical questions.

Which requirement supports this proposal?

Which part of the item definition was used?

Does the cited source justify the suggested classification?

Is important information missing?

Was the suggestion based on approved project context?

The platform does not ask engineers to trust that grounding happened somewhere behind the interface. It keeps the supporting material available for inspection.

Every change leaves a history

AI-assisted work is not expected to be correct on the first attempt.

Each edit in Aegis SafeForge creates a new version. Users can view the version history, compare differences, and revert to an earlier version when necessary.

This preserves the path from the original AI suggestion to the approved engineering decision.

A reviewer can determine what the AI originally proposed, what the engineer changed, which version was submitted for review, what changes the reviewer requested, and which version was ultimately approved.

Review actions, comments, edits, state changes, and approvals are attributed in the audit history.

The approved result is not presented as though it appeared fully formed. The process behind the decision remains visible.

Traceability must continue after approval

Traceability is not complete simply because two artifacts were linked once.

Those relationships must remain useful as the project changes.

Suppose an approved high-level requirement is modified.

Does the linked low-level requirement remain valid?

Does the item definition need to be reviewed again?

Which HARA rows, Safety Goals, requirements, or verification activities relied on the previous information?

Who is responsible for reviewing the affected work?

Aegis SafeForge propagates the impact of upstream changes through connected artifacts. Affected downstream work is invalidated or marked for renewed attention so that an earlier approval is not treated as current after its supporting context has changed.

Responsible users can see affected work through the dashboard.

The product direction also includes notifications that make important changes harder to miss during active projects.

The platform does not decide what the replacement engineering answer should be. It identifies which existing decisions may no longer be reliable and returns them to the responsible people for review.

Draft work should remain visibly draft

Teams sometimes need to export work before the complete approval process has finished.

Aegis SafeForge is designed so draft rows remain visibly marked when included in export workflows.

Unapproved work should not be presented as accepted engineering evidence simply because it has left the platform.

The status of a decision should remain visible both inside the engineering workspace and in the material shared outside it.

The questions the platform must answer

For every important engineering decision, teams should be able to answer the following questions.

What did the AI originally propose?

Which results came from deterministic logic?

What did the engineer change?

What concerns did the reviewer raise?

Which sources supported the decision?

Who approved the final version?

What was allowed to move downstream?

Did a later change affect the approval?

Answering these questions does not make AI infallible.

It makes its use visible, controlled, and governable.

What this means for Aegis SafeForge

We are not building Aegis SafeForge to replace safety reviews with generated content.

We are building it to help teams reach the right review faster, with stronger context, clearer ownership, better traceability, and a defensible record of how each decision was made.

AI can reduce the effort required to move from an empty table to a structured proposal.

The platform can preserve context, apply rules, manage permissions, enforce relationships, record versions, and surface the impact of change.

But the final judgment remains with the engineers and reviewers responsible for understanding the system.

For pilot teams, this means AI acceleration can be introduced without losing the review discipline required for regulated engineering.

That is the principle we intend to preserve as Aegis SafeForge develops: