Designing Safety into the Object Network

Automotive safety is often discussed as though it belongs to a dedicated subsystem.

Airbags.

Brakes.

Crash structures.

Driver-assistance systems.

Safety controllers.

These are all important.

But a vehicle is not safe because it contains a collection of “safety components.”

A vehicle is safe because the relationships between its objects continue to produce acceptable behavior, including when parts of the system fail.

That is a much stronger idea.

In ZenOps, safety can therefore be designed directly into the automotive object network.

The chain becomes:

x → NDD → Requirements → ORIGIN → Safety Relations → FMEA → StoryQ → Evidence → QT

The goal is not merely to ask:

Which objects are safety-critical?

It is to ask:

Which object relations must remain trustworthy for the human need to remain protected?

Safety Begins With Human Need

The highest-level safety requirement is not:

Install airbags.

Nor:

Use redundant controllers.

Those are solutions.

The need is closer to:

Protect human life and reduce unacceptable harm during vehicle operation.

That can be decomposed through the NDD:

Protect Human Life
│
├── Avoid Preventable Accidents
├── Maintain Vehicle Control
├── Detect Dangerous Conditions
├── Protect Occupants During Collision
├── Protect Other Road Users
├── Manage Failures Safely
└── Support Emergency Response

These needs then become engineering requirements.

Only after that should architecture and technology enter.

Safety Is Distributed Across the Vehicle

Consider emergency braking.

The safety outcome may depend on:

Driver
↓
Brake Pedal
↓
Sensor
↓
Controller
↓
Software
↓
Actuator
↓
Brake
↓
Wheel
↓
Tire
↓
Road

If any critical part of this chain behaves incorrectly, braking performance can degrade.

Safety therefore exists across the network.

It is not localized in one object.

This leads to a central principle:

A safety property belongs to a path through the object network.

Safety Requirements Can Attach to Relations

Suppose:

Wheel-Speed Sensor
   reports to
Brake Controller

That relation may carry safety constraints such as:

• Maximum acceptable latency
• Signal validity rules
• Error detection
• Timeout behavior
• Recovery behavior

The relation itself becomes safety-relevant.

This is important because many failures occur not because an object stops existing, but because communication or interaction becomes incorrect.

Model Safe and Unsafe Relations

A normal relation might be:

Sensor
   reports
Wheel Speed
   to
Controller

A failure relation might be:

Sensor
   reports
Incorrect Wheel Speed
   to
Controller

The second relation may drive unsafe behavior unless detection exists.

Therefore the object network should not model only intended relations.

It should also model:

• Missing relations
• Delayed relations
• Corrupted relations
• Contradictory relations
• Unintended relations

This connects naturally to FMEA.

Safe Behavior Must Exist Under Failure

A robust vehicle is not one where components never fail.

That is unrealistic.

A robust vehicle is one where important failures are anticipated and the system responds appropriately.

Suppose one wheel-speed sensor fails.

The intended response might be:

Sensor Failure
↓
Detect Invalid Data
↓
Isolate Failed Signal
↓
Use Degraded Control Strategy
↓
Limit Function if Required
↓
Record Diagnostic Event
↓
Inform Driver if Necessary

The safety architecture therefore includes both:

normal behavior

and:

failure behavior.

Safety Can Be Modeled as State Preservation

Another useful perspective is to define acceptable system states.

For example:

NORMAL
↓
DEGRADED
↓
SAFE STOP

A failure should not allow the system to jump unpredictably into an unsafe state.

Instead, the architecture should define permissible transitions.

For example:

Normal
   ↓ sensor failure
Degraded
   ↓ multiple failures
Restricted Operation
   ↓ critical condition
Safe Stop

Safety becomes a controlled state-transition problem.

Safety Patterns Belong in the Pattern Library

Many safety structures repeat.

For example:

Detect → Isolate → Degrade → Report → Recover

Another:

Observe → Cross-Check → Reject Invalid → Continue Safely

Another:

Command → Verify Actuation → Detect Mismatch → Enter Safe State

These can become reusable ZenOps patterns.

Each pattern can contain:

Safety Pattern
│
├── Purpose
├── Context
├── Objects
├── Relations
├── Failure Modes
├── Required Responses
├── StoryQ Scenarios
├── Tests
└── Evidence

Safety knowledge becomes reusable.

Redundancy Is a Relation Strategy

Redundancy is often treated as “adding another component.”

But in object-network terms, redundancy changes the relation structure.

For example:

Sensor A
    ↘
    Controller
    ↗
Sensor B

Now the controller can compare independent information sources.

The safety logic might be:

Sensor A
+
Sensor B
↓
Cross-Check
↓
Agreement?
├── Yes → Continue
└── No → Degraded / Diagnostic

The safety benefit comes not from merely having two sensors.

It comes from the relations between them.

Diversity Can Improve Robustness

Two identical sensors may fail for the same reason.

A stronger architecture may use diverse information sources:

Wheel-Speed Sensor
+
Vehicle Acceleration Estimate
+
Motor-Speed Estimate
↓
Plausibility Evaluation

Now one source can challenge another.

This may reduce common-cause risk.

Again, the important property exists in the network.

Safety Boundaries Must Be Explicit

Modular architecture can help safety if boundaries are well defined.

Suppose:

Brake Module

exposes:

• Command interface
• Status interface
• Diagnostic interface
• Safe-state behavior

Other systems can then rely on a defined contract.

But if safety assumptions remain hidden inside the module, integration becomes dangerous.

A safe module should explicitly state:

What do I guarantee?

Under what conditions?

What happens when those conditions are violated?

This turns the module boundary into a safety contract.

Safety Contracts Connect Modules

Consider:

Vehicle Controller
   commands
Brake Module

The interface may require:

Controller promises:

• Commands remain within defined range
• Communication timing remains within limits

Brake Module promises:

• Valid commands are executed
• Invalid commands are rejected
• Communication loss triggers defined fallback

This creates bidirectional responsibility.

The interface is no longer just a data connection.

It becomes a behavioral contract.

FMEA Tests the Safety Network

FMEA asks:

What happens when an object or relation fails?

For each safety-relevant relation, we can ask:

What if the message is missing?
What if it is late?
What if it is wrong?
What if the sender fails silently?
What if two failures occur together?

This systematically explores the safety network.

The results can generate requirements, mitigations, scenarios, and tests.

Safety Requirements Should Generate StoryQ Scenarios

Suppose the safety requirement says:

The vehicle shall prevent unsafe propulsion after a critical inverter fault.

A Gherkin scenario might be:

Scenario: Critical inverter fault during propulsion
Given the vehicle is producing propulsion torque
When a critical inverter fault is detected
Then propulsion torque shall be reduced according to the defined safe strategy
And the fault shall be recorded
And the driver shall be informed according to the defined warning strategy

Now the safety claim becomes observable behavior.

Failure Injection Is Essential

A safety mechanism that has never been tested under failure is only a design intention.

If the architecture says:

Sensor failure is detected,

then deliberately create sensor failure.

If it says:

Communication timeout leads to safe degradation,

then interrupt communication.

If it says:

Actuator mismatch is detected,

then inject a mismatch.

The loop becomes:

Safety Claim
↓
Failure Scenario
↓
Failure Injection
↓
Observed Behavior
↓
Evidence

Safety becomes demonstrated rather than assumed.

Safety QTs Should Be Evidence-Based

A safety QT might include:

SAFETY QT
[ ] Critical hazards identified
[ ] Safety-relevant relations identified
[ ] Failure modes modeled
[ ] Safety mechanisms implemented
[ ] Degraded states defined
[ ] Failure scenarios tested
[ ] Safety interfaces verified
[ ] Residual risks evaluated
[ ] Evidence accepted

The safety threshold is not crossed because the safety document exists.

It is crossed because the evidence is sufficient.

Safety Should Be Recursive

The same reasoning applies at multiple levels.

At component level:

Sensor
↓
Failure Detection
↓
Safe Output

At module level:

Brake Module
↓
Degraded Mode
↓
Safe Control

At vehicle level:

Vehicle
↓
Critical Failure
↓
Restricted Operation
↓
Safe Stop

Safety can therefore be analyzed recursively.

Safety Is Not Only Crash Safety

Automotive safety is broader than collision protection.

It includes:

• Vehicle controllability
• Electrical safety
• Battery safety
• Thermal safety
• Software behavior
• Charging safety
• Diagnostic integrity
• Manufacturing quality
• Service correctness
• Human-machine interaction

Each area can be represented through objects and relations.

The same ZenOps model applies across all of them.

Human-Machine Relations Are Safety-Critical

Consider a warning.

Vehicle
   communicates
Warning
   to
Driver

The technical system may detect danger correctly.

But if the warning is confusing, delayed, or invisible, the safety mechanism may still fail.

The human-machine relation must therefore be analyzed like any other critical interface.

StoryQ might express:

Scenario: Critical thermal warning
Given a critical thermal condition has been detected
When driver action is required
Then the defined warning shall be presented
Within the required response time
And the warning shall clearly communicate the required action

The human becomes part of the safety network.

Manufacturing Safety Begins With Process Relations

A design can be safe in theory and unsafe when manufactured incorrectly.

Suppose:

Workstation
   installs
Brake Line

Safety-related manufacturing questions include:

• Can the line be incorrectly routed?
• Can the connector be partially seated?
• Can torque be insufficient?
• Can the wrong component be installed?

PFMEA identifies these risks.

Manufacturing controls then become part of the safety architecture.

Production Evidence Belongs to Safety

Suppose a critical connector must be fully engaged.

The factory may verify:

Vehicle #000142
↓
Connector #C-922
↓
Installation Verification
↓
PASS

Now the safety chain extends into production.

The vehicle does not merely inherit design safety.

It must also acquire manufacturing evidence.

Software Configuration Is Part of Safety

A physical vehicle may be mechanically correct but run the wrong software.

Therefore:

Controller
   executes
Approved Software Version

is a safety relation.

Production QT should verify software identity.

Service updates should preserve compatibility.

A mismatched software version is not simply a configuration issue.

It can become a safety issue.

Safety Traceability Should Be Bidirectional

From a hazard, we should be able to navigate downward:

Hazard
↓
Safety Requirement
↓
Safety Pattern
↓
Module
↓
Component
↓
Software
↓
Test
↓
Evidence

From a failed field component, we should be able to navigate upward:

Failed Component
↑
Safety Function
↑
Safety Requirement
↑
Hazard
↑
Human Consequence

This makes safety knowledge navigable.

Field Evidence Must Challenge Safety Assumptions

Suppose development testing predicts a failure to be extremely rare.

Field evidence later shows otherwise.

The safety model must change.

The loop becomes:

Field Event
↓
Diagnostic Analysis
↓
Failure Model Update
↓
Safety Requirement Review
↓
New Scenario
↓
Corrective Work
↓
Regression Test
↓
New Evidence

Safety is therefore not frozen at launch.

It remains connected to reality.

Safety Patterns Improve With Every Vehicle

Suppose a safe-degradation pattern is used across several vehicle platforms.

Each implementation produces:

• Test results
• Failures
• Diagnostic experience
• Service data
• Field evidence

The pattern can improve.

Safety Pattern v1
↓
Vehicle A
↓
Evidence
↓
Safety Pattern v2
↓
Vehicle B
↓
More Evidence

Safety engineering becomes cumulative knowledge.

Common-Cause Failures Must Be Visible

Network modeling is particularly valuable when several systems depend on the same object.

For example:

12V Power Supply
│
├── Sensor A
├── Controller B
├── Communication Gateway
└── Brake Support System

The components may appear independent in separate subsystem analyses.

The object network reveals a shared dependency.

A single power failure may affect all of them.

This exposes common-cause risk.

Safety Is About Controlling Propagation

A small failure is not always dangerous.

The danger often lies in propagation.

For example:

Sensor Error
↓
Incorrect Controller Decision
↓
Incorrect Actuator Command
↓
Unexpected Vehicle Motion
↓
Human Harm

Safety mechanisms attempt to break the chain.

Sensor Error
↓
Plausibility Check
↓
Error Detected
↓
Command Blocked
↓
Degraded Mode

Safety design can therefore be understood as interrupting dangerous propagation paths.

Safety Objects Can Include Hazards

Hazards themselves can become domain objects.

For example:

HAZARD-018
Unintended Propulsion
Threatens:
Occupant Safety
Pedestrian Safety
Related Objects:
Motor Controller
Accelerator Sensor
Vehicle Software
Mitigated By:
Torque Plausibility Pattern
Safe-State Pattern

Now hazards participate in the same knowledge network as requirements and tests.

The Object Network Can Become a Safety Map

Imagine selecting a hazard and seeing:

Hazard
│
├── Causes
├── Affected Objects
├── Affected Relations
├── Safety Requirements
├── Mitigations
├── Failure Modes
├── StoryQ Scenarios
├── Tests
└── Evidence

The domain model becomes a safety navigation system.

This is far more useful than isolated documents.

Safety Is a Property of the Whole Transformation

Quality failures can enter the vehicle at many stages.

A misunderstood need can create the wrong safety requirement.

A bad requirement can create the wrong architecture.

A poor architecture can create dangerous coupling.

A manufacturing defect can invalidate a safe design.

A service error can introduce a new hazard.

Therefore safety must extend through:

Need
↓
Requirement
↓
Architecture
↓
Component
↓
Software
↓
Manufacturing
↓
Vehicle
↓
Service
↓
Field Evidence

Safety is a lifecycle property.

Designing Safety Means Designing the Failure Paths

The normal engineering path asks:

How does the vehicle succeed?

Safety engineering must also ask:

How does the vehicle fail?

And then:

How does it fail safely?

That produces a more complete architecture:

Normal Operation
      ↓
Failure
      ↓
Detection
      ↓
Containment
      ↓
Degraded Operation
      ↓
Recovery / Safe Stop

The failure path is not an exception.

It is part of the design.

The Complete ZenOps Safety Loop

The full model can now be expressed as:

HUMAN NEED
      ↓
NDD
      ↓
SAFETY REQUIREMENTS
      ↓
ORIGIN
      ↓
OBJECTS + RELATIONS
      ↓
HAZARDS
      ↓
FMEA
      ↓
SAFETY PATTERNS
      ↓
MODULES + INTERFACES
      ↓
STORYQ / GHERKIN
      ↓
FAILURE INJECTION
      ↓
EVIDENCE
      ↓
SAFETY QT
      ↓
VEHICLE
      ↓
FIELD EVIDENCE
      ↓
UPDATED SAFETY MODEL

The loop continues throughout the vehicle’s life.

Safety Is Not Added at the End

A dangerous engineering pattern is:

Design the vehicle first, then ask the safety team to prove that it is safe.

ZenOps suggests the opposite.

Safety should influence:

• Needs
• Requirements
• Object relations
• Patterns
• Module boundaries
• Interfaces
• Failure modes
• Software states
• Manufacturing controls
• Test strategy

before the finished vehicle exists.

The goal is not to inspect safety into the final product.

It is to build safety into the model that creates the product.

A Safe Vehicle Is a Safe Network

The deepest conclusion is simple.

A safe component does not automatically create a safe vehicle.

A safe module does not automatically create a safe vehicle.

Even a collection of individually verified systems does not automatically create a safe vehicle.

Safety emerges from their relationships.

A sensor must report correctly.

A controller must interpret correctly.

Software must respond correctly.

An actuator must behave correctly.

A human must receive the right information.

And when one of these fails, the rest of the network must react in a controlled way.

That is why ZenOps treats safety as a property of the object network.

Safety is not merely what each object does when everything works.

Safety is what the complete network does when reality stops behaving as expected.

Design those relations deliberately.

Model their failure modes.

Test them.

Collect the evidence.

And keep learning from every vehicle that enters the real world.

That is how safety becomes part of the architecture itself.

StoryQ/Gherkin for Automotive Requirements

Automotive requirements are often written as statements.

For example:

The vehicle shall remain stable during emergency braking.

That sounds precise enough.

But several questions immediately remain.

Under what road conditions?

At what speed?

With what vehicle load?

What does “stable” mean?

What event triggers the requirement?

What observable result proves that the requirement has been satisfied?

ZenOps treats this as a problem of transformation.

A human need must eventually become something that reality can answer.

The chain is:

Human Need → NDD → Requirement → Scenario → Test → Evidence

StoryQ/Gherkin provides a particularly useful bridge between the requirement and the test.

Its simple structure is:

Given → When → Then

The syntax is easy to read, but its implications for automotive engineering are significant.

It turns a static requirement into a description of behavior under defined conditions.

From Human Need to Scenario

Suppose the original human need is:

I need the vehicle to remain controllable when I brake on an icy road.

The Need Definition Document might contain:

Maintain vehicle controllability on low-friction surfaces.

An engineering requirement might refine that into:

The vehicle shall maintain defined directional-control performance during braking under specified low-friction conditions.

StoryQ/Gherkin can then express the intended behavior:

Scenario: Emergency braking on a low-friction surface
Given the vehicle is travelling within the specified speed range
And the road surface has the defined low friction condition
When the driver applies emergency braking
Then the vehicle shall decelerate within the defined performance limits
And directional controllability shall remain within the accepted limits

We now have something much more useful than an isolated sentence.

We have a situation that can eventually be reproduced.

Given Describes Reality Before the Event

Automotive behavior depends heavily on context.

A battery behaves differently at -25°C than at +20°C.

A tire behaves differently on dry asphalt than on ice.

A vehicle behaves differently when fully loaded.

Therefore the Given part of a scenario is extremely important.

Examples might include:

Given the ambient temperature is within the specified cold-test range

or:

Given the battery state of charge is within the defined operating window

or:

Given the vehicle is travelling on a road surface with the specified friction level

The Given statement describes the starting state of the relevant part of reality.

Without it, many automotive requirements are incomplete.

When Defines the Trigger

The When statement defines what happens.

This might be a human action:

When the driver presses the brake pedal

an environmental event:

When the outside temperature falls below the defined threshold

a system event:

When communication with the wheel-speed sensor is lost

or a physical failure:

When the coolant pump stops operating

The trigger provides an explicit transition from one state to another.

This is especially useful in systems containing many sensors, controllers, software states, and actuators.

Then Defines What Must Become True

The Then statement expresses the expected outcome.

For example:

Then the braking system shall enter the defined degraded mode

or:

Then the battery temperature shall remain within the specified safe range

or:

Then a diagnostic event shall be recorded

The strongest Then clauses describe something that can eventually be observed or measured.

This is where the scenario begins connecting directly to evidence.

A Requirement Becomes a Question

This reveals an important ZenOps interpretation.

A StoryQ/Gherkin scenario is essentially a question to the system:

Given this state of reality, when this event happens, will the vehicle produce the expected result?

The test later asks that question.

Reality provides the answer.

The chain becomes:

Requirement
    ↓
Scenario
    ↓
Question to the System
    ↓
Test
    ↓
Result
    ↓
Evidence

This turns requirements into something much more active.

Example: Cold-Weather Start

Suppose the NDD contains:

Provide reliable winter transportation.

One resulting scenario might be:

Scenario: Start vehicle after cold soak
Given the vehicle has remained at the defined cold-soak temperature
And the battery is within the permitted state-of-charge range
When the driver requests vehicle start
Then the vehicle shall reach the defined ready state
Within the specified maximum time
And no safety-critical fault shall prevent normal operation

This can later be verified using:

• Simulation
• Hardware-in-the-loop testing
• Environmental chamber testing
• Full-vehicle testing

The test technology may change.

The behavioral intent remains the same.

Example: Windshield Defrost

Consider the need:

Maintain driver visibility during winter operation.

A scenario could become:

Scenario: Restore windshield visibility after frosting
Given the vehicle has been exposed to the defined cold condition
And the windshield has the specified frost coverage
When the driver activates the defrost function
Then the defined visibility area shall become clear
Within the specified maximum time

The requirement now has context, trigger, and measurable result.

Example: Battery Overtemperature

Failure behavior is especially important.

Scenario: Battery exceeds normal operating temperature
Given the battery is operating within the normal temperature range
When the measured battery temperature exceeds the defined threshold
Then the thermal system shall request the required cooling response
And battery power shall be limited according to the defined strategy
And the diagnostic system shall record the event

This scenario crosses several domain objects:

Battery

Temperature Sensor

Battery Controller

Thermal System

Diagnostic System

StoryQ therefore naturally fits the ORIGIN object-and-relation model.

Example: Sensor Failure

Suppose one wheel-speed sensor becomes unavailable.

Scenario: Wheel-speed sensor becomes unavailable
Given all wheel-speed sensor signals are initially valid
And the vehicle is moving
When one wheel-speed signal becomes unavailable
Then the system shall detect the loss of the signal
And the affected control function shall enter the defined degraded mode
And the diagnostic system shall record the fault
And no unsafe control command shall be generated

This is much more useful than simply writing:

The vehicle shall tolerate wheel-speed sensor failure.

The scenario forces us to define what tolerance actually means.

Gherkin Exposes Ambiguity

Consider the requirement:

The driver shall be warned when battery energy is low.

Try to write the scenario.

Immediately questions appear.

What is “low”?

How is available energy calculated?

When exactly should the warning appear?

What happens if temperature temporarily changes the estimated range?

Does the warning disappear again?

The requirement might become:

Scenario: Low usable-energy warning
Given the vehicle is operating normally
And usable energy is above the defined warning threshold
When usable energy falls below the defined threshold
Then the low-energy warning shall be presented to the driver
Within the specified response time

StoryQ/Gherkin therefore does not merely document requirements.

It helps discover where requirements are incomplete.

One Requirement Can Produce Many Scenarios

Consider:

The vehicle shall charge safely.

One scenario is not enough.

The requirement might generate scenarios for:

• Normal charging
• Cold-weather charging
• High-temperature charging
• Communication failure
• Loss of grid power
• Connector removal
• Battery fault
• Thermal-system failure
• Interrupted charging
• Recovery after interruption

Each scenario explores a different part of the same requirement space.

This creates systematic coverage.

Scenario Outlines Handle Variation

Some behavior must be tested under several conditions.

Gherkin can express this using a scenario outline.

Scenario Outline: Vehicle startup at low temperature
Given the vehicle has stabilized at <temperature>
When the driver requests vehicle start
Then the vehicle shall reach the ready state
Within <maximum_start_time>
Examples:
| temperature | maximum_start_time |
| T1          | S1                 |
| T2          | S2                 |
| T3          | S3                 |

The precise values can remain controlled engineering parameters.

The behavioral pattern remains readable.

Keep Engineering Parameters Separate

Gherkin should not become a replacement for engineering data.

A poor scenario might contain dozens of values:

Voltage
Current
Pressure
Temperature
Torque
Speed
Timing

until the behavioral logic disappears.

It is often better to write:

Given the battery is in the defined nominal operating condition

and allow the referenced test or requirement definition to specify the detailed numeric ranges.

StoryQ captures behavior.

Engineering data defines exact limits.

Requirements and Scenarios Are Different Objects

The requirement should still have its own identity.

For example:

REQ-02841
Loss of valid wheel-speed information shall
be detected within the defined diagnostic time.

The corresponding scenario might be:

Scenario: Detect missing wheel-speed information
Given the wheel-speed signal is initially valid
When the signal becomes unavailable
Then the system shall detect the missing signal
Within the defined diagnostic time

The relationship can be modeled as:

Requirement
   verified by
Scenario

The scenario does not erase the requirement.

It makes the required behavior explicit.

Connect StoryQ to ORIGIN

Because ZenOps already models the vehicle as objects and relations, the scenario can reference the same domain.

For example:

Wheel-Speed Sensor
    reports to
Vehicle Controller
Vehicle Controller
    controls
Brake System
Diagnostic System
    observes state of
Wheel-Speed Sensor

The Gherkin scenario then describes a change propagating through that object network.

This creates consistency between:

domain model

and:

behavior model.

Patterns Can Contain Scenario Templates

The ZenOps Pattern Library can also store reusable StoryQ/Gherkin patterns.

Suppose the engineering pattern is:

Detect → Isolate → Report → Recover

It may carry scenario templates such as:

Scenario: Detect failure
Given the component is operating normally
When the defined failure occurs
Then the system shall detect the failure

followed by:

Scenario: Enter degraded mode
Given the failure has been detected
When normal operation can no longer be maintained
Then the system shall enter the defined degraded state

and:

Scenario: Recover after failure condition disappears
Given the system is in the defined degraded state
When the recovery conditions become valid
Then the system shall recover according to the defined strategy

Now the Pattern Library carries not only architectural knowledge but verification knowledge.

Gherkin Can Generate WBS Work

Once a scenario exists, work becomes visible.

Suppose the scenario says:

When the temperature sensor fails, the thermal system shall enter degraded control.

That may generate work to:

• Implement failure detection
• Implement degraded control
• Create diagnostic reporting
• Create test instrumentation
• Inject the failure
• Verify the response
• Record evidence

The behavioral scenario therefore helps generate the Work Breakdown Structure.

StoryQ and FLEXI

StoryQ also fits naturally with FLEXI micro-sprints.

Instead of assigning:

Work on charging software.

a micro-sprint can say:

Make charging scenario SCN-042 pass.

The work becomes bounded:

Scenario
↓
Implementation
↓
Test
↓
Result
↓
Evidence

This gives the engineer an explicit target.

StoryQ and Quality Thresholds

Scenarios can also contribute directly to QT.

Suppose the Winter Operation QT requires:

Cold Start
Windshield Visibility
Traction
Braking
Battery Heating
Charging

Each item may have several StoryQ scenarios.

The evidence hierarchy becomes:

NDD
↓
Requirement
↓
Scenario
↓
Test
↓
Evidence
↓
QT

A Quality Threshold PASS is therefore backed by specific behavior that has been demonstrated.

PASS Becomes More Meaningful

Compare:

Winter operation: 90% complete.

with:

Cold Start                 PASS
Windshield Defrost         PASS
Low-Friction Braking       PASS
Battery Heating            PASS
Cold Fast Charging         FAIL
Sensor Icing               UNKNOWN

The second representation gives the team useful engineering knowledge.

StoryQ/Gherkin makes this possible because the expected behavior has been broken into explicit scenarios.

Manufacturing Can Use the Same Approach

StoryQ/Gherkin need not stop at vehicle behavior.

Consider a battery installation process:

Scenario: Install correct battery pack
Given the vehicle identity is known
And the approved battery pack for the vehicle configuration is available
When the battery pack is installed
Then the mechanical connections shall satisfy the defined specification
And electrical connections shall be verified
And thermal connections shall be verified
And the battery identity shall be associated with the vehicle identity

The same behavioral logic can describe manufacturing.

Supplier Requirements Can Become Scenarios

Suppose a supplier provides a controller.

Instead of only specifying interfaces in prose, a behavioral scenario might state:

Scenario: Recover after communication interruption
Given the controller is operating normally
When communication is interrupted for the defined duration
And communication is restored
Then the controller shall return to the defined operational state
Without requiring a complete vehicle restart

The supplier now receives an observable behavioral expectation.

Service Can Use StoryQ Too

Consider component replacement:

Scenario: Replace failed drive module
Given diagnostics identify the drive module as faulty
When an approved replacement module is installed
Then the replacement identity shall be recorded
And the required software configuration shall be applied
And the verification procedure shall pass
And the vehicle service history shall be updated

The same conceptual method now spans engineering, manufacturing, and service.

Field Failures Should Become New Scenarios

One of the most valuable uses of StoryQ is regression learning.

Suppose field vehicles reveal a failure nobody anticipated.

The organization investigates.

The cause is understood.

Then a new scenario should often remain behind:

Field Failure
↓
Root Cause
↓
Requirement Update
↓
New Scenario
↓
Regression Test
↓
Permanent Organizational Knowledge

A failure should not merely be repaired.

It should teach the engineering system something.

Every Important Bug Can Become Memory

Suppose charging fails only after:

• Cold soak
• Communication interruption
• Recovery attempt

Once discovered, the condition can become:

Scenario: Charging recovers after cold communication interruption
Given the vehicle is at the defined low temperature
And charging is operating normally
When the charging communication is interrupted
And communication is restored
Then charging shall recover according to the defined recovery behavior

Future vehicle versions can rerun this scenario.

The mistake becomes less likely to return.

Scenario Identity Enables Traceability

Each scenario can receive its own identity:

SCN-001 Cold Start
SCN-002 Windshield Defrost
SCN-003 Sensor Failure
SCN-004 Low-Friction Braking

Relations can then connect:

NDD Need
   ↓
Requirement
   ↓
Scenario
   ↓
Test
   ↓
Evidence
   ↓
QT

Now the scenario becomes a first-class object in the ZenOps domain model.

A Shared Language Across Disciplines

Perhaps the greatest advantage of Given/When/Then is its readability.

Automotive programs include:

• Domain experts
• Systems engineers
• Mechanical engineers
• Electronics engineers
• Software developers
• Test engineers
• Manufacturing engineers
• Suppliers
• Product owners
• Project managers

Not everyone can read control software.

Not everyone can interpret a detailed mechanical specification.

But many people can understand:

Given this condition, when this happens, then the vehicle must behave like this.

This creates a common behavioral language across disciplines.

StoryQ Turns Stories Into Questions

StoryQ can be interpreted as a progression:

Story
↓
Question
↓
Scenario
↓
Experiment
↓
Evidence

A customer says:

I need the car to work reliably in winter.

ZenOps structures that through the NDD.

Engineering produces requirements.

StoryQ asks:

What situation would demonstrate whether the requirement is actually true?

Gherkin expresses the situation.

Testing asks the question physically.

Reality answers.

The Complete ZenOps Chain

The automotive ZenOps flow can now become:

HUMAN REALITY
      ↓
      x
      ↓
     NDD
      ↓
REQUIREMENTS
      ↓
 STORYQ
      ↓
GIVEN / WHEN / THEN
      ↓
   TEST
      ↓
 EVIDENCE
      ↓
     QT
      ↓
 RELEASE

The crucial transformation happens in the middle.

Requirements stop being passive statements.

They become questions that can be asked of the system.

Reality Gets the Final Word

This may be the most important reason for using StoryQ/Gherkin in automotive ZenOps.

A requirement can look convincing on paper.

A design can look correct in CAD.

Software can compile.

Simulation can predict success.

But sooner or later we need to ask:

Given the real conditions the vehicle must face, when the relevant event occurs, does the system actually behave as intended?

StoryQ/Gherkin gives us a disciplined way of writing that question.

Testing provides the experiment.

Evidence provides the answer.

And ZenOps keeps the entire chain connected back to the original human need.

That is the purpose of StoryQ/Gherkin for automotive requirements:

to transform what we hope the vehicle will do into behavior precise enough for reality to confirm or reject.

Quality Thresholds Instead of Arbitrary Progress

A vehicle program can appear to be progressing very well.

The battery system is 80% complete.

The braking system is 75% complete.

The software is 60% complete.

Manufacturing preparation is 70% complete.

The project dashboard is green.

Then integration begins.

A critical interface does not work.

The battery overheats under an unexpected condition.

A supplier cannot maintain the required tolerance.

Software behaves incorrectly during communication failure.

A manufacturing process cannot achieve the required cycle time.

Suddenly the project that was supposedly 75% complete is nowhere near 75% ready.

The problem is not necessarily that anybody lied.

The problem is that percentage completion can be a poor representation of engineering reality.

ZenOps approaches progress differently.

Instead of asking primarily:

How much work have we completed?

we ask:

What has been demonstrated to be true?

This leads to the ZenOps concept of the Quality Threshold — QT.

Progress Is Not the Same as Activity

Imagine two engineering teams.

Team A spends three months designing a battery cooling system.

Team B spends two weeks building a crude prototype and discovers that the proposed cooling concept cannot satisfy the thermal requirement.

Which team has progressed further?

If progress is measured by activity, Team A may appear ahead.

If progress is measured by knowledge, Team B may have produced the more valuable result.

It eliminated a false solution before the organization invested further resources in it.

This gives us the first principle:

Engineering progress should be measured by increased justified confidence, not merely by accumulated activity.

The Problem With “80% Complete”

Suppose an engineer reports:

Thermal system: 80% complete.

What does that mean?

Perhaps:

• 80% of drawings exist.
• 80% of planned tasks are closed.
• 80% of the budget has been spent.
• 80% of the calendar duration has passed.

None of these necessarily tells us whether the thermal system works.

The remaining 20% may contain the hardest unresolved problem.

Engineering risk is rarely distributed evenly across task lists.

One unresolved assumption can invalidate months of completed work.

A Quality Threshold Asks a Different Question

Instead of:

How complete is the battery system?

QT asks:

What evidence must exist before we are willing to treat the battery system as sufficiently mature for the next decision?

For example:

BATTERY SYSTEM QT
[ ] Need traceability established
[ ] Requirements defined
[ ] Architecture defined
[ ] Interfaces defined
[ ] Thermal behavior verified
[ ] Electrical behavior verified
[ ] Safety behavior verified
[ ] Diagnostic behavior verified
[ ] Failure modes evaluated
[ ] Manufacturing feasibility demonstrated
[ ] Evidence accepted

The threshold is explicit.

Progress becomes observable.

QT Is Not Perfection

A Quality Threshold does not mean:

Everything must be perfect before anything can continue.

That would make development impossible.

Instead, QT means:

For this decision, at this point in the program, what level of evidence is sufficient?

An early concept QT may require only:

• Need alignment
• Plausible architecture
• Major risks identified
• Initial simulation

A production-release QT may require far more:

• Complete requirements
• Verified interfaces
• Validated safety behavior
• Production-capable suppliers
• Manufacturing evidence
• Vehicle-level validation

The threshold becomes stronger as commitment increases.

Different Decisions Need Different Thresholds

Consider a battery system moving through development.

Concept QT
     ↓
Architecture QT
     ↓
Prototype QT
     ↓
Integration QT
     ↓
Production QT
     ↓
Field QT

Each threshold answers a different question.

Concept QT

Is this idea credible enough to investigate further?

Architecture QT

Is the system sufficiently defined to begin detailed implementation?

Prototype QT

Is the implementation sufficiently mature to justify integration?

Integration QT

Does it behave acceptably as part of the vehicle?

Production QT

Can it be manufactured repeatedly at acceptable quality?

Field QT

Does real-world evidence support our assumptions?

Quality is therefore progressive.

QT Connects Directly to the NDD

A Quality Threshold should never become an arbitrary checklist.

It must remain connected to the original problem.

Suppose the NDD contains:

Maintain reliable transportation during Norwegian winter conditions.

This generates requirements involving:

• Cold starting
• Battery performance
• Cabin heating
• Visibility
• Traction
• Charging
• Material behavior

A winter-readiness QT might therefore contain:

WINTER OPERATION QT
[ ] Cold-start requirement verified
[ ] Required winter range demonstrated
[ ] Battery heating verified
[ ] Cabin heating verified
[ ] Windshield visibility verified
[ ] Low-friction control verified
[ ] Charging behavior verified
[ ] Relevant failure modes verified

The QT exists because the human need exists.

Requirements Become Evidence Obligations

Every important requirement creates a simple question:

What evidence would convince us that this requirement is satisfied?

Suppose:

REQ-0217
Vehicle shall maintain defined braking
performance under specified
low-friction conditions.

Then:

REQ-0217
    ↓
Verification Method
    ↓
Test
    ↓
Test Result
    ↓
Evidence
    ↓
QT Decision

The requirement does not become complete because somebody marks it “implemented.”

It becomes sufficiently trusted when evidence supports it.

FLEXI Produces the Evidence

This connects directly to the previous entry on FLEXI micro-sprints.

FLEXI asks:

What small piece of work can produce useful evidence now?

QT asks:

Is the accumulated evidence sufficient to cross the threshold?

Together:

WBS
 ↓
FLEXI
 ↓
Work
 ↓
Verification
 ↓
Evidence
 ↓
QT

FLEXI creates evidence.

QT evaluates evidence.

The two mechanisms complement each other.

A Failed FLEXI Sprint Can Move QT Forward

Suppose the current battery cooling architecture fails a high-load thermal test.

At first glance, this appears to be negative progress.

But the evidence may reveal exactly why the architecture is insufficient.

The team modifies the model.

A better architecture is selected.

The QT has not been crossed.

But the organization is closer to crossing it because an important uncertainty has been removed.

This reveals a deeper definition of progress:

Progress is movement from uncertainty toward justified knowledge.

QTs Can Exist at Multiple Levels

The vehicle program can contain nested Quality Thresholds.

VEHICLE QT
│
├── Energy System QT
│   ├── Battery QT
│   ├── Charging QT
│   └── HV Distribution QT
│
├── Propulsion QT
│
├── Chassis QT
│   ├── Steering QT
│   ├── Braking QT
│   └── Suspension QT
│
├── Software QT
│
├── Manufacturing QT
│
└── Vehicle Integration QT

A high-level threshold can depend upon lower-level thresholds.

This makes quality recursive.

Interfaces Need Their Own QTs

A component can work perfectly alone and fail during integration.

Therefore interface maturity should not be inferred from component maturity.

Suppose:

Energy Module
      ↕
Propulsion Module

The interface QT might require:

ENERGY–PROPULSION INTERFACE QT
[ ] Electrical limits agreed
[ ] Communication contract defined
[ ] State transitions verified
[ ] Timing verified
[ ] Fault behavior verified
[ ] Recovery verified
[ ] Integration evidence accepted

The relationship itself has a quality threshold.

This is important because complexity often lives in relations.

Software Needs Evidence-Based QTs

Software can easily create misleading progress metrics.

Thousands of lines of code may be written.

Hundreds of tasks may be closed.

Features may appear to work under nominal conditions.

But production readiness requires much more.

A software QT might include:

SOFTWARE QT
[ ] Functional requirements verified
[ ] Interface behavior verified
[ ] Timing requirements verified
[ ] Fault handling verified
[ ] Recovery behavior verified
[ ] Diagnostic behavior verified
[ ] Hardware integration verified
[ ] Regression tests passed
[ ] Evidence accepted

The amount of code written is irrelevant to the threshold.

Behavior matters.

Suppliers Need QTs

Supplier status is often reported using milestones:

Supplier selected.

Prototype delivered.

Tooling complete.

ZenOps asks for evidence.

A supplier production QT might include:

SUPPLIER QT
[ ] Specification accepted
[ ] Interface compliance verified
[ ] Prototype performance verified
[ ] Manufacturing process demonstrated
[ ] Process capability acceptable
[ ] Traceability operational
[ ] Quality controls verified
[ ] Production samples accepted

The supplier becomes “ready” because evidence supports readiness.

Manufacturing Needs QTs

A design is not production-ready simply because engineering has released drawings.

The factory must demonstrate that it can repeatedly create the product.

MANUFACTURING QT
[ ] Process defined
[ ] Workstations operational
[ ] Tooling verified
[ ] Material flow demonstrated
[ ] Assembly tolerances achieved
[ ] Software loading verified
[ ] Calibration verified
[ ] Inspection operational
[ ] End-of-line testing verified
[ ] Required cycle time demonstrated
[ ] Traceability operational

Manufacturing readiness becomes measurable through evidence.

The Vehicle Itself Has a QT

Eventually the entire product must cross a threshold.

VEHICLE RELEASE QT
[ ] Critical needs traced
[ ] Critical requirements verified
[ ] Safety evidence accepted
[ ] System QTs crossed
[ ] Interface QTs crossed
[ ] Software QT crossed
[ ] Manufacturing QT crossed
[ ] Vehicle validation complete
[ ] Known residual risks accepted

Only then does the organization have a justified basis for release.

QT Does Not Mean Zero Risk

No complex engineering system reaches absolute certainty.

There will always be residual risk.

A QT therefore does not say:

Nothing can go wrong.

It says:

We have enough relevant evidence to justify this decision while explicitly understanding the remaining uncertainty.

That is a much more realistic engineering standard.

Make Unknowns Visible

A powerful QT system should explicitly expose unknowns.

For example:

Battery QT
Thermal performance: PASS
Electrical performance: PASS
Crash behavior: PASS
Cold charging: PARTIAL
Long-term degradation: UNKNOWN
Supplier process capability: FAIL

This is useful information.

“Unknown” should not be treated as embarrassing.

Hidden unknowns are dangerous.

Visible unknowns can generate work.

UNKNOWN Generates FLEXI Work

Suppose:

Long-term degradation: UNKNOWN

That creates an evidence gap.

The evidence gap generates work:

UNKNOWN
   ↓
Question
   ↓
FLEXI Micro-Sprint
   ↓
Experiment
   ↓
Evidence
   ↓
QT Update

The project-management system begins driving work directly from uncertainty.

FAIL Generates Learning

Likewise:

Supplier Process Capability: FAIL

should generate a response:

FAIL
 ↓
Investigate Cause
 ↓
Correct Process
 ↓
Re-Test
 ↓
Evidence
 ↓
Re-Evaluate QT

Failure is not hidden to protect a dashboard.

Failure becomes input to the learning process.

PASS Must Mean Something

A dangerous project culture allows “green” status to mean:

Nobody has raised a serious problem.

ZenOps requires stronger semantics.

PASS should mean:

The defined threshold has been evaluated against identified evidence and found sufficient for the intended decision.

That makes green expensive.

But it also makes green meaningful.

Evidence Should Be Traceable

A QT result should not be merely a person’s opinion.

Suppose:

Thermal Performance: PASS

The system should allow us to navigate:

PASS
 ↓
Evidence Package
 ↓
Test Results
 ↓
Test Definition
 ↓
Requirement
 ↓
NDD Need

Now the status is auditable.

Someone asking:

Why is this green?

can receive an engineering answer.

QT Creates a Better Dashboard

Instead of:

Battery      85%
Software     70%
Factory      65%

imagine:

BATTERY QT
Requirements        PASS
Architecture        PASS
Interfaces          PASS
Thermal             PASS
Safety              PASS
Diagnostics         PARTIAL
Manufacturing       FAIL
SOFTWARE QT
Core Functions      PASS
Interfaces          PASS
Fault Handling      PARTIAL
Regression          PASS
Vehicle Integration UNKNOWN

Management immediately sees where uncertainty exists.

The dashboard becomes a decision instrument rather than a progress decoration.

Time and Cost Still Matter

ZenOps does not claim that schedule and budget are irrelevant.

A vehicle delivered ten years late at ten times the intended cost is not a successful program.

We still need:

Time

Cost

Resources

Dependencies

Capacity

Quality

The difference is that time and cost should not be confused with technical truth.

A deadline cannot make an unverified requirement true.

A budget cannot make an interface work.

Reality retains veto power.

QTs Improve Schedule Forecasting

Paradoxically, stronger quality measurement can improve schedule management.

If a program knows exactly which evidence gaps remain, it can estimate remaining work more intelligently.

Instead of:

We are 90% complete.

we can say:

Five critical thresholds remain unresolved, two depend on supplier evidence, and one requires a new prototype.

That is actionable scheduling information.

QTs Reduce False Progress

False progress occurs when work creates the appearance of advancement without reducing meaningful uncertainty.

Examples include:

• Producing documents nobody has validated
• Closing tasks whose outputs do not work
• Completing designs before interfaces are understood
• Writing software before requirements are stable
• Building prototypes without clear questions
• Passing milestones without evidence

QT challenges this.

The question is always:

What evidence did this work produce?

QTs Can Stop Bad Ideas Early

Suppose an architectural concept repeatedly fails its early QT.

The organization can stop.

That may feel like failure.

But consider the alternative:

Continue for another eighteen months.

Design components around it.

Commit suppliers.

Buy tooling.

Build prototypes.

Then discover the same fundamental flaw.

An early QT failure may save enormous amounts of money and time.

Stopping the wrong solution is progress.

QTs Protect the Original Need

The most important role of QT may be to protect x.

As the project grows, thousands of technical details appear.

Teams become focused on their subsystems.

Budgets and schedules exert pressure.

The original human problem can disappear.

Traceability keeps the threshold connected:

QT
 ↑
Evidence
 ↑
Test
 ↑
Requirement
 ↑
NDD
 ↑
x

Quality therefore means more than technical correctness.

It means confidence that the implemented system still contributes to solving the original problem.

Quality Is a Chain

A finished vehicle cannot be high quality if the chain underneath it is broken.

Human Need
↓
NDD Quality
↓
Requirement Quality
↓
Model Quality
↓
Pattern Quality
↓
Architecture Quality
↓
Component Quality
↓
Interface Quality
↓
Software Quality
↓
Manufacturing Quality
↓
Vehicle Quality
↓
Field Evidence

Quality is not something inspected into the car at the end.

It exists throughout the transformation.

From Milestone Culture to Evidence Culture

Traditional milestone thinking often asks:

Did we reach the gate?

ZenOps asks:

What evidence justifies crossing the gate?

That small change has large consequences.

Meetings change.

Dashboards change.

Work packages change.

Prototype strategy changes.

Testing changes.

Risk management changes.

Leadership changes.

The organization begins optimizing for knowledge rather than appearances.

The Complete QT Loop

The ZenOps automotive quality loop can be represented as:

x
↓
NDD
↓
Requirements
↓
Model
↓
WBS
↓
FLEXI
↓
Implementation
↓
Verification
↓
Evidence
↓
QT
├── PASS → Integrate / Advance
│
├── PARTIAL → Generate More Evidence
│
├── FAIL → Correct / Redesign
│
└── UNKNOWN → Investigate
        ↓
      FLEXI
        ↓
     New Evidence
        ↓
        QT

The loop continues until the evidence is sufficient for the decision being made.

Progress Is What We Can Justify

This leads to a different definition of project progress.

Progress is not:

How much time have we spent?

It is not:

How many tasks have we closed?

It is not even:

How much of the design exists?

Progress is:

How much uncertainty have we transformed into evidence-backed knowledge?

At the beginning of a vehicle program, almost everything is uncertain.

At the end, the organization should possess enough evidence to justify manufacturing thousands or millions of physical vehicles.

That transformation is the real project.

So instead of saying:

The vehicle is 87% complete.

ZenOps would rather ask:

Which claims about this vehicle can we now support with evidence, which remain uncertain, and what must we learn next?

That is the purpose of Quality Thresholds.

Not arbitrary progress.

Demonstrated progress.