AegisSafeForge did not begin with a plan to build a multi-industry safety engineering platform.
It began in September 2025 as a collaborative Master’s thesis between the University of Kassel and Melster Consulting.
The thesis, completed by our founder and CEO, Muhammad Aashir, focused on a specific question:
Could AI help engineers classify hazards for automotive battery management systems?
The initial goal was to build a prototype that could use an automotive item definition to support the generation of a Hazard Analysis and Risk Assessment, or HARA, and the resulting Safety Goals.
At the time, the scope was deliberately narrow. It was an academic project focused on one use case, one industry, and a limited set of safety artifacts.
But very early in the process, we began to see the possibility of something larger.
From thesis project to product idea
Waleed Aman joined the project in September 2025 as an advisor, initially supporting the general architecture and technical direction while Aashir developed the first prototype.
The prototype used item-definition content to generate HARA results and Safety Goals. It included an early vector-based retrieval-augmented generation system with fixed document chunking.
It was still an academic prototype, but it demonstrated that AI could do more than generate generic text. With the right context and structure, it could assist with activities that normally require engineers to interpret product information, apply safety methodologies, and document their reasoning.
We demonstrated the prototype to Ronald Melster of Melster Consulting and to several professionals working in functional safety.
The technical results were encouraging. More importantly, the conversations around the prototype exposed a much broader problem.
Safety engineering still depends heavily on Excel
During and after the thesis, we spoke with approximately 15 to 20 engineers, consultants, managers, and technical leads.
Their experience ranged from engineers with one or two years in the field to professionals with more than 20 years of safety experience. Most worked in or around the automotive industry.
Although their roles and experience levels differed, the same themes appeared repeatedly.
Specialized tools existed for individual parts of the safety lifecycle, but adoption was inconsistent. Teams often had to work across several disconnected systems, while significant portions of the safety process continued to live in Excel.
Even in 2026, spreadsheets remained central to safety work.
Many of the tools being used were also not originally designed around safety engineering processes. Requirements-management platforms such as DOORS could support important parts of the workflow, but they were general-purpose tools rather than complete environments built around the relationships between safety artifacts.
The problem was therefore not simply that teams lacked tools.
The problem was fragmentation.
Requirements might be managed in one system, hazard analysis performed in a spreadsheet, safety requirements documented elsewhere, and verification evidence stored in another location. Processes also begin at different points in a project, meaning teams working on related artifacts may not always progress at the same time.
Yet those artifacts depend on one another.
A change in a requirement may affect the item definition. That change may then affect the HARA, Safety Goals, safety requirements, verification activities, and other downstream analyses.
When the information is spread across disconnected tools, maintaining those relationships becomes difficult. It also becomes harder to introduce AI safely because the knowledge, context, and process history required by the AI are fragmented across multiple systems.
This became the larger opportunity behind AegisSafeForge:
Bring safety knowledge, processes, and artifacts into one connected environment so engineers can use AI without losing traceability, structure, or control.
In February 2026, while the thesis was still being completed, we began formalizing AegisSafeForge as a product.
The thesis concluded in March 2026, but the work had already moved beyond its original academic scope.
The principles we agreed on early
As we started turning the prototype into a platform, we established several principles that still guide our development decisions.
The first principle was that the platform must provide value without AI.
We did not want AegisSafeForge to be a thin interface around a language model. The underlying platform needed to provide enough value that engineers would prefer using it over spreadsheets for structured safety work.
That meant building real engineering workflows: artifact registries, process models, requirements management, traceability, collaboration, review controls, and evidence management.
AI should improve the engineering process, but the platform should not depend on AI to justify its existence.
The second principle was that AI outputs must be constrained and source-grounded.
Safety engineering is too consequential for unconstrained AI generation. At the same time, constraining a model too aggressively can remove the reasoning capabilities that make it useful. Finding the right balance has been one of our most important technical challenges.
We have therefore focused on combining source grounding, structured templates, deterministic checks, and workflow-specific guardrails.
The objective is not to allow an AI model to generate anything it wants. It is to give the model the relevant engineering context, define the expected output structure, check what can be checked deterministically, and preserve the reasoning needed for expert review.
Trust does not come from presenting an AI answer confidently. It comes from making the source, reasoning, relationships, and review status visible.
The third principle was that humans must remain in control.
AegisSafeForge is based on a simple governance principle: AI proposes. Engineers review and approve.
AI-generated outputs remain suggestions until a qualified person reviews and accepts them.
Approval is permission-based. Managers can approve work directly or delegate approval rights to appropriate team members. Actions are attributed to individual users and recorded so teams can understand who generated, modified, reviewed, or approved an artifact.
AI can accelerate the work, but it does not replace engineering responsibility.
Growing into a connected safety engineering platform
Since the original prototype, AegisSafeForge has developed into a multi-artifact and multi-industry platform.
The platform now includes industry-specific standards and artifact registries, along with integrated process models such as the V-model and waterfall.
Supported workflows and artifacts include HARA, Safety Goals, Functional Safety Requirements, Technical Safety Requirements, verification evidence, FMEA, FMEDA, Fault Tree Analysis, Event Tree Analysis, HAZOP, LOPA, and the complete ISO/SAE 21434 TARA analysis chain.
We have also introduced basic requirements management for high-level and low-level requirements.
The process can begin with requirements, which are used to derive item definitions based on relevant standard templates. Those item definitions can then provide the foundation for HARA, FMEA, FTA, ETA, and other analyses.
The important part is not simply that these artifacts can be created in one system. It is that they are connected.
A change to a requirement can invalidate the relevant item definition and flag the downstream artifacts that may need to be reviewed. This allows teams to assess the impact of a change rather than discovering inconsistencies much later in the project.
Traceability is therefore not treated as a report created at the end. It is built into the working process.
Collaboration and governance for real engineering teams
Safety engineering is collaborative, so we also had to move beyond single-user document generation.
AegisSafeForge now supports real-time collaboration with field-level locking to reduce conflicting edits.
Role-based access currently includes organisation administrator, manager, team lead, and engineer.
Approval authority can be controlled and delegated based on project responsibilities. Actions are attributed and traced, giving teams a clearer history of how an artifact developed and who was responsible for important decisions.
These may sound like ordinary enterprise features, but they are essential if AI-assisted engineering is going to move from prototypes into real safety projects.
Generating an artifact is only one part of the process. Teams must also be able to review it, challenge it, revise it, approve it, and understand how it connects to the rest of the safety case.
Building without external funding
We have built AegisSafeForge so far without external funding.
That has created limitations, but it has also shaped how we think.
We have had to look carefully for practical solutions, prioritize the features that create real engineering value, and avoid building technology simply because it appears impressive.
Turning an academic prototype into software that engineers can rely on has required far more than expanding the number of AI prompts.
We have had to work on architecture, retrieval, permissions, collaboration, traceability, artifact relationships, deterministic validation, and user experience.
User experience has been particularly important.
Safety tools are often powerful but difficult to adopt. If a platform introduces more friction than the spreadsheet it is intended to replace, engineers will return to the spreadsheet.
Our goal is therefore not only to build a technically capable system. It is to create an environment in which structured safety work becomes clearer, more connected, and easier to maintain.
Where we are today
The AegisSafeForge MVP is now in a strong state, and we are moving into a phase of hardening and refinement.
We are improving reliability, expanding workflow depth, strengthening our AI guardrails, and preparing the platform for real pilot environments.
We are also looking for pilot partners who can evaluate the platform against real safety engineering workflows and help us understand where it creates meaningful value and where it still needs to improve.
Alongside pilot partnerships, we are preparing for pre-seed funding. Funding would allow us to accelerate feature development, deepen our industry coverage, and build the go-to-market capabilities needed to bring the product to more engineering teams.
The longer-term vision
Our long-term ambition is for AegisSafeForge to become a core working environment for safety engineering.
Not another isolated tool that solves one step of the process.
Not an AI assistant operating without project context.
And not a replacement for the engineers responsible for safety decisions.
We want to build the place where requirements, analyses, safety decisions, evidence, and approvals remain connected throughout the lifecycle, and where AI creates meaningful productivity gains within the processes engineers already understand.
The journey began with a thesis about classifying hazards for automotive battery management systems.
That narrow problem helped us discover a much larger one: safety teams need a better way to connect their knowledge, processes, and decisions.
We are still early in that journey, but the direction is clear.
Safety work should not remain fragmented across spreadsheets and disconnected tools. AI should not operate without context or oversight. And engineers should not have to choose between productivity and trust.
That is the problem we are building AegisSafeForge to solve.
Design Partners
We are currently accepting selected pilot and design-partner applications.