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.