Turning Every Vehicle Requirement into Evidence

A requirement is not proof.

It is a claim about how the vehicle should behave.

For example:

The vehicle shall remain controllable during emergency braking on low-friction surfaces.

That statement may be well written.

It may be traceable to a real customer need.

It may have been reviewed by experienced engineers.

But until the system has been tested, measured, simulated, inspected, or otherwise evaluated, it remains an expectation.

ZenOps therefore extends the engineering chain one step further:

Need → Requirement → Verification → Evidence

The requirement defines what should become true.

Evidence tells us whether it actually did.

This distinction is central to the ZenOps automotive model.

Every Requirement Creates an Evidence Obligation

Suppose a requirement exists:

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

The moment this requirement is accepted, a second question appears:

How will we know?

That question should not be postponed until the end of development.

It should exist as part of the requirement itself.

The requirement therefore creates an evidence obligation.

Requirement
    ↓
Verification Method
    ↓
Test / Analysis / Inspection
    ↓
Result
    ↓
Evidence

If there is no credible way to verify a requirement, the requirement may not yet be well enough defined.

Requirements Should Be Verifiable by Design

A strong requirement should eventually permit an answer such as:

PASS

FAIL

PARTIAL

or:

UNKNOWN

A requirement like:

The vehicle shall feel premium.

may be useful at the level of customer intent, but it is difficult to verify directly.

It needs decomposition.

Perhaps “premium” implies:

• Defined interior noise levels
• Material quality criteria
• Seat comfort criteria
• Haptic response criteria
• Closure sound criteria
• Perceived acceleration quality

Now evidence can be gathered.

This does not mean every human experience must be reduced to one simplistic number.

It means the engineering organization must define how it intends to judge whether the need has been satisfied.

Evidence Can Take Many Forms

Not every automotive requirement should be verified in the same way.

Evidence may come from:

• Calculation
• Simulation
• Inspection
• Software test
• Hardware-in-the-loop test
• Component test
• Module test
• Environmental test
• Vehicle test
• Crash test
• Manufacturing measurement
• Supplier validation
• Field data

The correct method depends on the claim being made.

For example:

Requirement:
Component mass shall not exceed X.
Evidence:
Measured mass.

Another:

Requirement:
Structure shall withstand defined load.
Evidence:
Simulation + physical load test.

Another:

Requirement:
Vehicle shall recover after communication interruption.
Evidence:
Injected communication failure + recovery test.

The evidence method should fit the nature and risk of the requirement.

One Requirement May Need More Than One Kind of Evidence

High-risk requirements often deserve several independent sources of evidence.

Consider a battery crash-safety requirement.

Evidence might include:

Battery Crash Requirement
│
├── Structural Simulation
├── Cell-Level Tests
├── Module-Level Tests
├── Pack-Level Tests
├── Vehicle Crash Test
└── Post-Test Inspection

One source alone may not be sufficient.

The confidence comes from the body of evidence.

This is especially important when failure consequences are severe.

Evidence Has Context

A test result is meaningless without knowing the conditions under which it was produced.

Suppose:

Range test result: 510 km.

Useful?

Not yet.

We need context:

• Temperature
• Speed profile
• Vehicle load
• Tire configuration
• HVAC use
• Battery condition
• Test route
• Wind
• Test procedure

The actual evidence object should therefore include both result and context.

Evidence
│
├── Requirement Reference
├── Test Method
├── Conditions
├── Configuration
├── Measurement
├── Result
├── Pass Criteria
└── Timestamp / Version

Evidence without context can easily create false confidence.

StoryQ/Gherkin Defines the Question

StoryQ/Gherkin fits naturally into this process.

Suppose the requirement is:

The vehicle shall detect loss of a wheel-speed signal.

The scenario might be:

Scenario: Wheel-speed signal becomes unavailable
Given all wheel-speed signals are valid
And the vehicle is moving
When one wheel-speed signal becomes unavailable
Then the system shall detect the loss
Within the defined diagnostic time

The test implementation then asks this question of the system.

The result becomes evidence.

Requirement
↓
Gherkin Scenario
↓
Executable Test
↓
Observed Result
↓
Evidence

This creates a very clean chain.

Evidence Should Be a First-Class Object

In many engineering environments, evidence is buried inside:

• PDFs
• Spreadsheets
• Test reports
• Email attachments
• Laboratory systems
• Supplier documents

ZenOps treats evidence as part of the domain model.

For example:

EVIDENCE-00421
│
├── verifies → REQ-0217
├── produced by → TEST-882
├── executed on → VEHICLE-P017
├── configuration → SW-v4.18
├── condition → LOW-FRICTION-03
└── result → PASS

Evidence now has identity and relations.

It becomes navigable.

A Requirement Can Point Directly to Its Evidence

Imagine selecting:

REQ-0217

and immediately seeing:

REQ-0217
Status: PASS
Evidence:
- TEST-882
- TEST-901
- SIM-114
- FIELD-221
Affected Systems:
- Braking
- Tires
- Stability Control
- Software
QT:
Vehicle Control QT — PASS

Now the requirement is no longer just a sentence.

It is attached to the knowledge that justifies its status.

Evidence Can Expire

An important complication appears when the product changes.

Suppose a braking requirement passed using:

Brake Software v4.17

Then the software changes to:

v4.18

Is the old evidence still valid?

Maybe.

Maybe not.

The system should ask:

Did the change affect the conditions under which the requirement was proven?

This creates the concept of evidence validity.

Evidence
   valid for
Configuration A

If Configuration A changes, the evidence may require reevaluation.

Change Should Trigger Evidence Impact Analysis

Suppose:

Software Module
   changes

The object network can identify related requirements.

Those requirements point to scenarios.

Those scenarios point to tests.

Now the engineering system can ask:

Which tests must be rerun?

The chain becomes:

Change
↓
Affected Objects
↓
Affected Requirements
↓
Affected Scenarios
↓
Affected Evidence
↓
Reverification Work

This is much stronger than running an arbitrary test subset.

Evidence Can Be Reused

Not all changes invalidate all evidence.

Suppose a mechanical component changes but the communication software does not.

Some software-interface evidence may remain valid.

A good ZenOps domain model can help distinguish:

still valid

from:

potentially affected

from:

invalidated

This reduces unnecessary testing while preserving confidence.

Evidence Can Be Hierarchical

Component evidence can support module evidence.

Module evidence can support system evidence.

System evidence can support vehicle evidence.

For example:

Component Test
      ↓
Component Evidence
      ↓
Module Test
      ↓
Module Evidence
      ↓
System Integration Test
      ↓
System Evidence
      ↓
Vehicle Test
      ↓
Vehicle Evidence

The evidence structure can mirror the product structure.

But Integration Needs Its Own Evidence

There is a danger in assuming:

All components passed, therefore the vehicle will pass.

That does not follow.

Interfaces can fail.

Timing can fail.

Unexpected emergent behavior can appear.

Therefore the evidence chain must include integration.

Component PASS
+
Component PASS
≠
Automatically System PASS

The relationship itself must often be verified.

That is why interface and integration QTs are so important.

Requirements Can Be Verified at Different Levels

Some requirements belong to a component.

Some to a module.

Some to the full vehicle.

For example:

Component requirement

Sensor shall measure temperature within tolerance X.

Module requirement

Thermal module shall maintain battery temperature within range Y.

Vehicle requirement

Vehicle shall remain operational under winter condition Z.

Each level requires different evidence.

The ZenOps model should preserve that distinction.

Evidence Should Trace Back to Human Need

The complete chain should be navigable upward.

Suppose we have a crash-test result.

We should be able to trace:

Crash Test Result
      ↑
Crash Test
      ↑
Safety Requirement
      ↑
Protect Occupants
      ↑
NDD
      ↑
Human Need

This gives the result meaning.

Otherwise a test can become isolated technical data without visible purpose.

Evidence Should Trace Down to the Physical Object

The chain should also work the other way.

Suppose:

Requirement
↓
Test
↓
Vehicle Prototype
↓
Physical Components
↓
Software Configuration

Now we know exactly what configuration produced the evidence.

This is critical for reproducibility.

The Vehicle Instance Can Carry Its Own Evidence

Once production begins, each physical vehicle can carry evidence associated with it.

For example:

Vehicle #000142
│
├── Component Configuration
├── Software Configuration
├── Manufacturing Results
├── Calibration Results
├── End-of-Line Tests
└── Release Evidence

The factory produces not just a vehicle.

It produces a vehicle plus a body of evidence about that vehicle.

Manufacturing Requirements Become Evidence Too

Consider:

Every critical fastener shall be tightened within defined torque limits.

The factory can produce evidence:

Vehicle #000142
Fastener #F-8841
Specified Torque:
T
Measured Torque:
T_actual
Result:
PASS

Manufacturing quality becomes traceable at the vehicle-instance level.

Supplier Evidence Is Part of the Chain

Supplier components often arrive with their own evidence.

For example:

Supplier
   provides
Component
Component
   accompanied by
Inspection Evidence
Inspection Evidence
   supports
Component Requirement

ZenOps can integrate supplier evidence rather than treating it as a separate document universe.

Field Evidence Is the Strongest Reality Check

Development evidence is generated under controlled conditions.

Field evidence comes from actual use.

This might include:

• Diagnostic events
• Warranty claims
• Repair history
• Fleet failure rates
• Environmental exposure
• Customer reports
• Software telemetry where applicable

Field evidence can challenge assumptions that all development tests passed.

This is not a contradiction.

It is the next layer of learning.

A Requirement Can Reopen

Suppose:

REQ-441
Status: PASS

after development testing.

Then field evidence reveals repeated failures.

The requirement should not remain permanently green merely because it once passed.

The status may become:

REQ-441
Status: CHALLENGED

The new evidence creates new work.

This keeps the engineering model alive.

Evidence Is Not the Same as Confidence

Evidence supports confidence.

But confidence also depends on:

• Test coverage
• Measurement quality
• Relevance
• Repeatability
• Sample size
• Configuration match
• Risk level

A single successful test may be enough for a low-risk claim.

A safety-critical requirement may need much stronger evidence.

QT determines when the evidence body is sufficient for a decision.

Quality Thresholds Evaluate Evidence Sets

Suppose a system QT contains:

SYSTEM QT
Requirement A — PASS
Requirement B — PASS
Requirement C — PASS
Requirement D — PARTIAL
Requirement E — UNKNOWN

The QT asks:

Is the current evidence set sufficient to advance?

The answer may be no even if most requirements are green.

Criticality matters more than percentages.

Evidence Should Be Weighted by Importance

Not every requirement carries equal risk.

A cupholder requirement and a brake-safety requirement should not demand the same verification rigor.

The evidence strategy can consider:

Requirement
│
├── Criticality
├── Failure Consequence
├── Uncertainty
└── Required Evidence Strength

High criticality demands stronger evidence.

Evidence Strategy Should Be Designed Early

Waiting until the end of engineering to ask:

How do we verify this?

is too late.

Verification strategy should begin while requirements are written.

A mature requirement object might contain:

Requirement
Need Reference
Statement
Acceptance Criteria
Verification Method
Scenario References
Evidence Required
QT Contribution

Now implementation and verification evolve together.

Tests Become Part of the Architecture of Knowledge

Traditional engineering often treats tests as downstream activities.

ZenOps treats them as part of the reasoning structure.

A requirement implies a test.

A test implies evidence.

Evidence supports a QT.

The complete chain is designed from the start.

Every Important Claim Should Have an Answer

A vehicle program contains thousands of claims:

This component is strong enough.

This software responds quickly enough.

This battery is safe enough.

This charging system is compatible.

This factory process is capable.

This vehicle works in winter.

Each claim should eventually have an answer:

What evidence supports that?

If the answer is:

We believe it does,

then the work is not finished.

Evidence Can Become a Graph

The full automotive evidence model can be represented as an object network:

NDD Need
   ↓
Requirement
   ↓
Scenario
   ↓
Test
   ↓
Test Configuration
   ↓
Vehicle / Module / Component
   ↓
Result
   ↓
Evidence
   ↓
QT

Cross-relations can connect:

Evidence
   produced by
Supplier
Evidence
   invalidated by
Change
Evidence
   reused by
Vehicle Variant
Evidence
   challenged by
Field Failure

The evidence structure becomes dynamic.

From Document-Based Verification to Living Evidence

In a traditional environment, a test report may be signed, stored, and forgotten.

ZenOps aims for something more active.

Evidence remains connected to the requirement and configuration it supports.

When the requirement changes, the system knows.

When the component changes, the system knows.

When field evidence challenges it, the system knows.

The verification model stays alive.

A Simple Evidence State Model

A requirement might have states such as:

UNVERIFIED
PARTIAL
PASS
FAIL
CHALLENGED
REVERIFY

These states are much more informative than:

Done / Not Done

They reflect the actual lifecycle of engineering confidence.

Evidence Drives FLEXI Work

Suppose:

Requirement Status:
UNKNOWN

That creates a FLEXI question:

What is the smallest useful experiment that can reduce this uncertainty?

The team executes it.

Evidence is produced.

The requirement status changes.

Thus:

UNKNOWN
↓
FLEXI
↓
TEST
↓
EVIDENCE
↓
UPDATED STATUS

The project becomes a machine for converting unknowns into knowledge.

Evidence Also Drives Change

Suppose a test fails.

The result should not merely create a bug ticket.

It should connect back to the model.

FAIL
↓
Affected Requirement
↓
Affected Architecture
↓
Affected Object
↓
Corrective Work
↓
Re-Test
↓
New Evidence

Failure becomes part of the learning loop.

The Complete Requirement-to-Evidence Chain

We can now express the process as:

HUMAN NEED
      ↓
NDD
      ↓
REQUIREMENT
      ↓
ACCEPTANCE CRITERIA
      ↓
STORYQ / GHERKIN
      ↓
VERIFICATION METHOD
      ↓
TEST / ANALYSIS / INSPECTION
      ↓
RESULT
      ↓
EVIDENCE
      ↓
QT
      ↓
ENGINEERING DECISION

Every step has a distinct role.

The Requirement Is a Promise

A useful way to think about this is:

A requirement is a promise.

Engineering promises:

The vehicle will behave this way.

Verification asks:

Can you demonstrate that?

Evidence is the answer.

And QT asks:

Is the answer strong enough for us to proceed?

This makes requirements much more consequential.

They are not merely documentation.

They are commitments to produce evidence.

The Evidence Is the Final Engineering Language

At the beginning of development, we have ideas.

Then models.

Then requirements.

Then designs.

Then prototypes.

But the farther we move toward reality, the less important belief becomes.

At the end, the question is simple:

What can we demonstrate?

The finished vehicle is therefore supported not merely by a Bill of Materials or a set of requirements.

It is supported by a network of evidence.

Evidence that the brakes work.

Evidence that the battery survives.

Evidence that the software recovers.

Evidence that the factory can reproduce the product.

Evidence that the vehicle satisfies the needs that justified its existence.

That is the ZenOps transformation:

Every requirement should eventually become evidence.

Because a requirement says what we want reality to do.

Evidence tells us what reality actually did.