WCGW Safety Suite feature rundown

We'd rather you go and see, but the full feature list available in the public beta version is as follows.

Projects, Work items and Concepts

This is the core content model of the product. A project contains one or more work items, and each work item acts as a container for a safety-related artifact such as an item definition, hazard analysis, safety requirement, verification result, or validation evidence. Inside each work item, you create concepts and link them to build a traceability graph.

Once the initial model is in place, engineers use completeness metrics and AI-assisted refinement reports to identify missing concepts, relationships, and inconsistencies. Accepted changes become signed revisions, can be captured in a baseline, and continue to participate in future traceability analysis as the project evolves.

In practice, the workflow usually looks like this:

1. Create a project for the system or product boundary you are assessing.
2. Create one or more work items for the relevant lifecycle phase, such as HARA, functional safety, technical safety, verification, or validation.
3. Add concepts to each work item to capture hazards, requirements, architectures, tests, assumptions, or evidence.
4. Link concepts with relations so the graph becomes a navigable safety argument.
5. Refer to completeness metrics and refinement reports

Traceability queries

Traceability queries let you explore the graph. Queries are useful for engineers who need to understand ripple effects, review whether requirements are adequately covered, or explain how a safety argument is supported by the connected concepts and evidence.

Baselines

Baselines are the product's way of preserving a point-in-time snapshot of the work. They are especially useful when a project is changing quickly, when a review milestone is approaching, or when you want to compare a current version against a previously approved state.

In the UI, a baseline can be used to inspect historical revisions of concepts inside a work item. Think git for safety requirements; an engineer will be asking questions such as:

• What changed between the previous review and today?
• Which concept revision should be used as the basis for a discussion?
• Which earlier version should be preserved for audit purposes?

Work item templates

Work item templates help you combat the blank-page problem. Instead of starting from nothing, you can begin with a pre-structured pattern that is already suited to a common safety-engineering task, such as a hazard mitigation workflow, a linear safety chain, or a validation-oriented structure.

Typical use:

• Use prompt search or template selection to find a pattern that fits your use case
• Start from a template for the lifecycle phase or problem you are solving
• Fill in the actual safety content and adapt the structure as needed

Templates are most useful when you want consistency across multiple work items or when the team needs a repeatable starting point for something like HARA, requirement decomposition, or traceability setup.

Refinement reports

Refinement reports are the product's AI-assisted review feature. Along with the completeness metrics, they help you check whether a work item has the expected safety content and whether important concepts or links may be missing.

In the UI, this is exposed through the "Evaluate work item with LLM" feature. The system generates a report containing suggestions such as:

• Create new concepts
• Link existing concepts
• Revise existing content

You then get to act or discard suggestions, signing work for the audit trail.

Try it in the beta

If this all, or some of it, sounds useful for your own safety workflow, the best way to understand it is to try it directly. Open the beta, create a small project, and explore how the graph, templates, baselines, and completeness reports work together in practice.

Try the beta