Day 10: Capture Evidence and Improve the Model

Day 1 defined x.

Day 2 constructed the NDD.

Day 3 built the ORIGIN model.

Day 4 identified reusable automotive Patterns.

Day 5 generated the development structure.

Day 6 built and validated the prototype.

Day 7 designed the manufacturing system.

Day 8 validated production.

Day 9 manufactured the first series vehicle.

Day 10 asks:

What does reality teach us now that the vehicle actually exists?

This is where the entire ZenOps cycle closes.

The first nine days moved mostly forward:

Need → Model → Work → Evidence → Factory → Vehicle

Day 10 adds the return path:

Vehicle → Reality → Evidence → Learning → Better Model

That return path may be the most important part of the whole framework.

Without it, ZenOps would merely be another development process.

With it, the system becomes capable of learning.

The Vehicle Is Now an Evidence Source

AURORA-000001 leaves the factory with:

Vehicle Identity:
AURORA-000001
As-Built:
Verified
Release QT:
PASS

At that moment, development evidence is no longer the only source of truth.

The vehicle begins encountering:

Real Roads
Real Weather
Real Drivers
Real Charging
Real Maintenance
Real Time

Reality starts testing the model.

A Release PASS Is Not the End of Evidence

The release QT means:

We had sufficient evidence to trust the vehicle for release.

It does not mean:

Every engineering belief is now permanently true.

Field experience can challenge previous PASS states.

That is expected.

The Physical Vehicle Is the Final Arbiter

The model may say:

Connector Pattern:
Validated

But reality may later show:

Unexpected corrosion after three winters.

When this happens, reality wins.

The model must change.

Day 10 Begins With Observation

Possible evidence sources include:

Vehicle Diagnostics
Service Events
Warranty Claims
Software Events
Customer Feedback
Manufacturing Data
Fleet Statistics

These are different kinds of evidence.

All can contribute to learning.

Do Not Collect Data Without a Question

A modern vehicle can generate enormous amounts of data.

More data does not automatically mean more understanding.

ZenOps asks:

Which claim, Pattern, risk, or need are we trying to evaluate?

Evidence should remain meaningful.

Example: A Charging Failure

Suppose after several months AURORA-000001 reports:

DTC:
CHG-114

Customer symptom:

Charging stops intermittently.

This is a field observation.

It is not yet a root cause.

Preserve the Event

Create:

FIELD EVENT:
FE-CHG-0001

with links to:

Vehicle:
AURORA-000001
Software:
SW-1.2
Battery:
B4-100001
Charge Port:
CP-100001

The field event now has configuration context.

Add Time and Conditions

For example:

Ambient:
-8°C
Vehicle Age:
11 months
Odometer:
18,400 km
Charging Type:
DC Fast Charging

Evidence without context is weaker.

The Backend Should Preserve Current and Historical State

At failure time, the vehicle may no longer match its factory configuration.

Perhaps:

As-Built Software:
SW-1.0
Current Software:
SW-1.2

Both matter.

Root-cause analysis must use the configuration that actually existed when the failure occurred.

Compare the Event to the Object Network

The relevant OR structure may be:

Charge Port
↓
Charge Controller
↓
Vehicle Controller
↓
Battery

The model gives the investigation a starting structure.

Diagnostics Produce More Evidence

The service system may read:

Connector Temperature:
Normal
Battery:
Normal
Software Communication:
Normal
Charge Port Contact:
Intermittent

Knowledge state becomes:

Battery:
PASS
Software:
PASS
Charge Interface:
CHALLENGED

The investigation narrows.

Do Not Jump From DTC to Root Cause

A diagnostic trouble code says:

Something was observed.

It does not always say:

This component is the cause.

ZenOps keeps:

Symptom

separate from:

Root Cause

This prevents weak reasoning.

Generate a Root-Cause Question

For example:

Question:
Why is the charging interface intermittently losing continuity?

Then generate focused work.

Service Work Becomes a FLEXI Loop

Inspect connector
↓
Measure resistance
↓
Inspect seal
↓
Compare against known-good vehicle
↓
Evidence

Result:

Seal degradation observed.

This is stronger evidence.

One Vehicle Is Not Yet a Fleet Pattern

Do not immediately conclude:

All AURORA connectors are defective.

One vehicle may have:

• unusual damage
• service history
• manufacturing anomaly

The next question is population.

Search the Fleet

Query:

Find all AURORA vehicles
with DTC CHG-114

Suppose:

127 vehicles

are found.

Now the evidence becomes more interesting.

Compare Common Attributes

Analyze:

Factory
Process Revision
Supplier
Component Batch
Software Version
Climate
Vehicle Age

The object network makes these relationships navigable.

A Pattern Emerges

Suppose:

118 of 127 affected vehicles

were built under:

Connector Installation Process P4

while later vehicles built under:

P5

have far fewer failures.

This is strong manufacturing evidence.

Correlation Is Still Not Root Cause

The team should not stop at:

P4 vehicles fail more.

Ask:

What is different about P4?

Maybe:

Connector seating verification margin

changed.

Now reproduce the failure.

Recreate the Relevant Configuration

Use:

Connector Revision
Process P4
Environmental Exposure

Run a controlled test.

Suppose the failure is reproduced.

Knowledge strengthens.

Root Cause Can Now Be Confirmed

For example:

ROOT CAUSE:
Process P4 allowed marginal connector seating,
which caused seal degradation under repeated thermal cycling.

This is far stronger than:

bad connector.

The causal chain matters.

Link Root Cause to the Relevant Relation

The problem may not lie solely in:

Charge Port

It may lie in:

Charge Connector
   installed into
Vehicle Interface

The relation itself was weak.

This is one reason ORIGIN matters.

Update the FMEA

Existing failure mode:

Connector Not Fully Seated

may have had:

Occurrence:
LOW

Fleet evidence may now justify:

Occurrence:
HIGHER THAN ASSUMED

The FMEA learns from reality.

Update Detection Assumptions

Perhaps the original control assumed:

Visual Check:
Sufficient

Field evidence shows:

Visual Check:
Insufficient

That control should be changed.

Create an Anti-Pattern

For example:

ANTI-PATTERN:
Critical sealed connector
without positive seating verification.

This preserves the negative lesson.

Create the Improved Pattern

New:

PATTERN:
Position
↓
Connect
↓
Positive Engagement Verification
↓
Seal Confirmation
↓
Record

The company now knows more than it did on Day 4.

Pattern Versioning Preserves Learning

Old:

Connector Installation Pattern v3

New:

Connector Installation Pattern v4

Do not silently overwrite v3.

Vehicles built under v3 still exist.

Historical interpretation depends on the old definition.

Link the Pattern Change to Evidence

Pattern v4 should know:

Triggered By:
Field Failure Pattern FP-CHG-114
Supporting Evidence:
Fleet Analysis
Environmental Test
Service Inspection

The Pattern has provenance.

Update StoryQ

A new regression scenario becomes:

Scenario: Charge connector remains correctly seated after environmental aging
Given the connector has been installed using the approved process
And the assembly has completed defined thermal and environmental exposure
When charging continuity and seating integrity are evaluated
Then connector engagement shall remain within the approved limit
And charging continuity shall remain valid

A field failure becomes future test coverage.

This Creates a Quality Ratchet

Generation 1 failure:

Field Failure

becomes:

Regression StoryQ

Future vehicle generations inherit it.

The same failure becomes progressively harder to repeat.

Update the Requirement if Necessary

Perhaps the original requirement only said:

Connector shall maintain electrical continuity.

Field evidence reveals that durability context was insufficiently defined.

Update:

Connector shall maintain required electrical and sealing performance
after defined environmental aging conditions.

Reality improves the requirement.

The Requirement Was Not “Wrong”

It may have been incomplete.

This is normal engineering learning.

The goal is not to pretend the first specification was perfect.

The goal is to improve it.

Evidence Can Update the NDD Too

Suppose many customers report:

Winter charging uncertainty creates significant anxiety.

Perhaps the original NDD contained:

Support winter charging.

But reality suggests a deeper need:

Provide predictable winter charging confidence.

The need model itself improves.

This Is a More Powerful Feedback Loop

Most engineering systems allow:

Field Failure
→
Component Fix

ZenOps allows:

Field Evidence
→
Pattern
→
Requirement
→
NDD

The company can improve its understanding of the problem as well as the solution.

Update the Factory

Once Pattern v4 is approved:

Factory F-NO-01

must update the process.

Old:

Process P4

New:

Process P6

The transition should be controlled.

Define Process Effectivity

For example:

P6 effective from:
AURORA-084221

This creates a clean field-analysis boundary.

Validate the New Factory Process

Before full deployment:

Pilot P6
↓
StoryQ
↓
Process Evidence
↓
Manufacturing QT

The fix itself must earn evidence.

Do Not Assume Root-Cause Fix Equals Successful Fix

A plausible change can still fail.

Validate:

Does P6 actually prevent the field failure mechanism?

The learning loop closes only when outcome evidence supports the change.

Service Existing Vehicles

Affected vehicles may require:

Inspection
Replacement
Repair

Create a service Pattern.

For example:

Identify affected connector
↓
Inspect
↓
Replace if required
↓
Verify charging
↓
Update vehicle history

The field problem creates service knowledge too.

Use Persistent Vehicle Identity to Target the Campaign

Instead of recalling every vehicle, the backend can identify:

Vehicles built with:
Process P4
+
Affected Connector Revision

This can reduce unnecessary service actions.

Traceability has economic value.

Service Events Update As-Maintained State

Suppose AURORA-000001 receives:

New Charge Port:
CP-200019

Then:

METHOD:
ReplaceChargePort()
EVENT:
ChargePortReplaced

Current configuration updates.

Historical configuration remains.

As-Built and As-Maintained Now Diverge

As-built:

Charge Port:
CP-100001

Current:

Charge Port:
CP-200019

Both states remain meaningful.

Verify the Repair

Service QT:

[ ] Correct replacement part
[ ] Correct installation
[ ] Software compatibility
[ ] Charging test PASS
[ ] Vehicle history updated

Only then does the vehicle return to trusted state.

Feed Service Results Back Too

Suppose the repair procedure takes:

3.5 hours

when design target was:

1.5 hours

That is serviceability evidence.

It may challenge the architecture.

A Field Failure Can Reveal More Than One Weakness

The connector case might reveal:

Manufacturing weakness
+
Service access weakness
+
Requirement weakness

One event can update multiple layers.

This is why whole-system analysis matters.

Software Evidence Follows the Same Pattern

Suppose fleet data reveals:

SW-1.2 causes excessive battery drain.

Then:

Field Evidence
↓
Root Cause
↓
Software Change
↓
StoryQ Regression
↓
OTA Release
↓
Fleet Outcome

Software closes the loop faster than hardware.

OTA Creates a Second Evidence Cycle

Release:

SW-1.3

to a controlled population first.

Then compare:

SW-1.2 Fleet
vs
SW-1.3 Fleet

Outcome evidence tells us whether the correction worked.

Do Not Stop at Deployment

A software update being installed successfully proves:

Deployment:
PASS

It does not necessarily prove:

Problem Solved:
PASS

Those are different claims.

Validate Improvement in Reality

For the connector fix, compare:

Failure Rate Before P6

with:

Failure Rate After P6

Suppose:

After P6:
92% lower failure incidence

Now the improvement has field support.

Pattern Maturity Can Increase

Connector Installation Pattern v4 may move:

PRODUCTION VALIDATED

toward:

FIELD VALIDATED

after enough exposure.

Again, maturity is earned.

Successful Evidence Matters Too

Day 10 should not only capture failures.

Suppose the brake Pattern shows:

1,000,000 vehicle-years
with very strong field performance.

That strengthens the Pattern.

Future programs can reuse it with greater confidence.

Reality Can Confirm the Model

The loop is not always:

Model
↓
Failure

Often it is:

Model
↓
Reality
↓
Confirmation

This is valuable evidence too.

Update Evidence Maturity

For example:

Brake Pattern v5
Prototype:
PASS
Production:
PASS
Field:
PASS

This becomes highly mature reusable knowledge.

The Fleet Becomes the Largest Test Program

With:

500,000 AURORA vehicles

the company gains enormous exposure to:

Different Climates
Different Drivers
Different Charging Behavior
Different Roads
Different Aging

This field variation cannot be fully recreated in development.

But Fleet Evidence Is Messy

Unlike controlled tests, field data contains confounding variables.

For example:

Supplier
Climate
Usage
Software
Manufacturing
Service History

may all differ.

The object network is essential for context.

Compare Like With Like

If analyzing battery degradation, compare populations with similar:

Battery Revision
Climate
Charging Pattern
Mileage

Otherwise conclusions may be misleading.

Evidence Quality Still Matters in the Fleet

A large dataset does not automatically guarantee a correct conclusion.

ZenOps still asks:

Does this evidence actually support the claim?

The same discipline applies.

Build Fleet Questions From Engineering Claims

For example:

Claim:
Battery Pattern B4 maintains 80% capacity after X usage.

Fleet query can evaluate that claim.

The field becomes part of the verification architecture.

The Fleet Can Validate Simulation Models

Compare:

Predicted Battery Degradation

against:

Observed Battery Degradation

Then recalibrate.

The next vehicle’s simulations start stronger.

FMEA Can Become Empirical

Predicted:

Failure Mode occurrence:
2

Field:

Observed occurrence:
5

Update the risk model.

FMEA becomes a living evidence system.

Diagnostic Models Can Learn

Suppose:

DTC X

frequently resolves to:

Root Cause Y

The service diagnostic Pattern can incorporate that probability or decision path.

Future diagnosis becomes faster.

Predictive Maintenance Can Learn From Outcome

Prediction:

Pump likely to fail within 30 days.

Later inspection finds:

Pump healthy.

The prediction was wrong.

That is evidence for model improvement.

Both False Positives and False Negatives Matter

A predictive system that alerts constantly creates service waste.

A system that misses failures creates reliability risk.

Field outcome calibrates both.

Manufacturing Models Can Learn From Fleet Evidence

Suppose failure probability correlates with:

Tool T-771

used during a certain production period.

The factory history makes that visible.

Field reliability becomes factory evidence.

Supplier Models Can Learn Too

Suppose component failures correlate with:

Supplier Plant SP-4

but not SP-2.

Procurement now has lifecycle evidence.

Supplier decisions become stronger.

Cost Models Can Learn

Suppose a component saved:

€15 at purchase

but created:

€120 average warranty cost.

Then the lifecycle cost model must update.

Field evidence can overturn procurement assumptions.

Customer Evidence Can Challenge Feature Value

Suppose a feature required significant engineering effort.

Fleet usage shows:

Feature activation:
0.8% of vehicles

That may trigger a next-generation review.

But usage alone does not determine need importance.

Context still matters.

Combine Quantitative and Qualitative Evidence

A feature may be rarely used but strongly valued.

For example:

Emergency Assistance

Low usage does not imply low need.

The NDD remains the interpretive frame.

Day 10 Improves the Pattern Network

Every meaningful outcome should ask:

Does this strengthen an existing Pattern?
Challenge a Pattern?
Create a new Pattern?
Create an Anti-Pattern?

This is where organizational memory grows.

Do Not Let Learning Stay Inside a Field Report

A report titled:

AURORA Charging Issue Analysis Final v2.pdf

may be useful.

But if the learning does not update:

Pattern
StoryQ
Requirement
Process

future teams may repeat the same mistake.

Learning must modify the reusable model.

Reports Explain; Models Remember

This is an important distinction.

Documents communicate analysis.

The ZenOps model should preserve the resulting knowledge structurally.

Update the Relevant Objects

A field case might update:

Requirement R17
Pattern P4
StoryQ S9
FMEA FM22
Process P6

The evidence itself should remain linked.

Now the learning is navigable.

Decision Objects Preserve Why

For example:

DECISION:
Adopt Connector Pattern v4
Reason:
Field failures linked to insufficient seating verification.
Evidence:
E-441
E-442
Fleet Analysis FA-17

Years later, a future engineer knows why the Pattern exists.

This Prevents Regression Through Forgetting

Without rationale, someone may later say:

Why are we doing this extra verification? It costs time. Remove it.

The decision history answers:

Because the previous process caused field failures.

Organizational memory protects quality.

Update Work Patterns Too

Suppose root-cause resolution took too long because:

Service data was not linked to process revision.

Improve the investigation process.

For example:

Field Failure Resolution Pattern v2

now requires:

Vehicle Configuration
Factory Revision
Supplier Batch
Software

from the beginning.

The company learns how to learn.

This Is Second-Order Improvement

First-order:

Fix Connector Problem

Second-order:

Improve How Connector Problems Are Detected and Resolved

The second loop makes the manufacturer more capable over time.

Day 10 Should Review the Original x

This may sound extreme, but it is important.

Ask:

Did the vehicle actually solve the need we started with?

For AURORA:

x:
Provide safe, reliable, practical and affordable Nordic family mobility.

Field evidence can now evaluate parts of that statement.

x Can Be Partially Validated

For example:

Safety:
Strong
Reliability:
Strong
Winter Charging Experience:
PARTIAL
Service Cost:
Higher than expected

This tells the organization where the product is succeeding and where the original solution still falls short.

Need Satisfaction Is the Highest-Level Evidence

A technically perfect component is irrelevant if the product does not satisfy the human need.

Day 10 reconnects the entire engineering system to that purpose.

Create a Need-to-Field View

For example:

NDD-WIN-004
Winter Charging Confidence
Field Evidence:
Customer complaints elevated
State:
CHALLENGED

This is powerful.

The NDD is no longer merely a development artifact.

It becomes a lifecycle knowledge model.

Some Needs Become Strongly Confirmed

For example:

Daily Range Need:
CONFIRMED

because most customers complete daily travel comfortably.

The next generation may not need expensive additional range.

Evidence can prevent unnecessary overengineering.

Some Needs Become More Important

For example:

Fast Charging Predictability:
Higher importance than expected.

The next generation NDD changes priority.

Build the Next Generation From This Evidence

When AURORA Generation 2 begins, it should not start from:

Blank NDD

It starts from:

Generation 1 NDD
+
Field Evidence
+
Pattern Maturity
+
Failures
+
Customer Evidence

The entire Day 1–10 cycle becomes cumulative.

Reuse What Reality Confirmed

For example:

Brake Pattern:
REUSE

because fleet evidence is excellent.

Modify What Reality Challenged

For example:

Charging Interface Pattern:
MODIFY

because winter field evidence exposed limitations.

Replace What Failed Structurally

For example:

Connector Installation Pattern v3:
REPLACE

Create New Work Only Where Needed

The next development structure can focus on:

Challenged Needs
Modified Patterns
New Technology
Remaining UNKNOWNs

Validated knowledge is inherited.

This Is the Knowledge Ratchet

Generation 1 creates:

Evidence

Generation 2 begins with it.

Generation 2 produces more.

Then Generation 3 begins even stronger.

The organization should not return to zero.

Day 10 Evidence States

A useful high-level view might show:

Customer Need Satisfaction:
PARTIAL
Vehicle Reliability:
PASS
Winter Charging:
CHALLENGED
Manufacturing Quality:
PASS
Serviceability:
PARTIAL
OTA Capability:
PASS

This is a much richer picture than sales volume alone.

Program Completion Does Not Mean Learning Completion

The development project may be officially closed.

But field learning may continue for:

10–20 years

depending on vehicle life.

ZenOps separates project lifecycle from product knowledge lifecycle.

The Product Outlives the Project

The vehicle remains:

In Service

long after the original project team moves on.

The knowledge system must preserve continuity.

Persistent Identity Enables Long-Term Learning

AURORA-000001 can still be queried years later:

As-Built
Current Configuration
Service History
Software History
Field Events

The digital history follows the physical product.

Day 10 Connects Every Previous Day

A field failure may navigate backward:

Field Event
↓
Vehicle Instance
↓
Manufacturing Process
↓
Pattern
↓
Requirement
↓
NDD
↓
x

This is the complete ZenOps trace.

And Improvement Travels Forward Again

Root Cause
↓
Updated Pattern
↓
Updated StoryQ
↓
Updated Factory Process
↓
New Vehicle Instances

The loop is closed.

Day 10 Is Not Really the Last Day

It is the first day of the next loop.

After learning:

Better Model

creates:

Better Work

which creates:

Better Product

which generates:

New Evidence

The cycle continues.

Day 10 Field Learning QT

A useful threshold for a resolved field issue might be:

FIELD LEARNING QT
[ ] Field symptom captured
[ ] Exact affected configuration known
[ ] Population scope analyzed
[ ] Root cause supported by evidence
[ ] Requirement / Pattern / process impact assessed
[ ] Corrective change implemented
[ ] StoryQ regression added where appropriate
[ ] Existing affected products addressed
[ ] Improvement outcome validated
[ ] Learning stored in reusable model

When all are satisfied:

FIELD LEARNING QT:
PASS

The problem has not merely been fixed.

It has been learned from.

This Distinguishes Correction From Learning

Correction:

Replace failed connector.

Learning:

Understand why it failed
↓
Change the Pattern
↓
Change the process
↓
Add regression evidence
↓
Validate future performance

The second is what prevents recurrence.

Day 10 Should Produce a Learning Package

For a major issue:

Field Event
Fleet Analysis
Root Cause
Corrective Decision
Updated Requirement
Updated Pattern
Updated FMEA
Updated StoryQ
Factory Change
Service Change
Outcome Evidence

This becomes reusable organizational knowledge.

Example AURORA Day 10 Result

Suppose the connector problem is fully resolved.

The system might show:

Field Failure:
FF-CHG-114
Root Cause:
Confirmed
Connector Pattern v3:
CHALLENGED
Connector Pattern v4:
FIELD VALIDATED
Factory Process P6:
PASS
Service Campaign:
Complete
Post-Fix Failure Rate:
Strongly Reduced

This is a closed learning loop.

The Complete Day 10 Flow

The practical sequence becomes:

DAY 9 RELEASED VEHICLE
↓
REAL-WORLD OPERATION
↓
CAPTURE FIELD EVENT
↓
PRESERVE VEHICLE CONFIGURATION + CONTEXT
↓
DIAGNOSE
↓
SEARCH FLEET
↓
IDENTIFY PATTERN
↓
ROOT-CAUSE ANALYSIS
↓
REPRODUCE / VALIDATE CAUSE
↓
UPDATE FMEA
↓
UPDATE REQUIREMENT
↓
UPDATE STORYQ
↓
UPDATE PATTERN
↓
UPDATE FACTORY / SOFTWARE / SERVICE
↓
DEPLOY CORRECTION
↓
MEASURE OUTCOME
↓
PROMOTE LEARNING
↓
FEED NEXT VEHICLE GENERATION

Then:

RETURN TO x

and ask what reality has taught us.

Why Day 10 Matters

A manufacturer can build a good car without Day 10.

But it cannot become a systematically self-improving manufacturer without it.

The difference is whether evidence remains downstream as:

Warranty Data
Service Data
Telemetry

or travels upstream into:

Needs
Requirements
Patterns
Tests
Processes

That upstream movement is learning.

Day 10 Completes the ZenOps Car Factory

The ten-day structure can now be summarized:

DAY 1
Define x
DAY 2
Construct the NDD
DAY 3
Build the ORIGIN Model
DAY 4
Identify Patterns
DAY 5
Generate Development Structure
DAY 6
Build + Validate Prototype
DAY 7
Design Manufacturing System
DAY 8
Validate Production
DAY 9
Manufacture First Vehicle
DAY 10
Capture Evidence + Improve Model

This is not meant to imply that a real vehicle program takes ten literal calendar days.

Each “day” represents a focused stage of the complete logic.

The Full Formula

The whole practical automotive cycle becomes:

x
↓
NDD
↓
ORIGIN
↓
PATTERNS
↓
WORK
↓
PROTOTYPE
↓
EVIDENCE
↓
FACTORY
↓
PRODUCTION
↓
VEHICLE INSTANCE
↓
FIELD REALITY
↓
EVIDENCE
↓
LEARNING
↓
BETTER NDD / ORIGIN / PATTERNS

Then repeat.

The Deeper Formula

Even more compactly:

NEED
↓
MODEL
↓
BUILD
↓
PROVE
↓
USE
↓
LEARN
↓
BETTER MODEL

This is the complete ZenOps manufacturing loop.

Day 10: Capture Evidence and Improve the Model

That is the tenth practical step in the ZenOps Car Factory.

Take the persistently identifiable vehicle produced on Day 9, capture real-world events in their exact hardware, software, manufacturing, environmental, and lifecycle context, separate symptom from root cause, compare individual failures against the fleet, trace meaningful patterns back through components, suppliers, factory processes, requirements, and NDD needs, convert confirmed failures into updated FMEA, StoryQ, Patterns, and processes, deploy corrective changes through controlled QTs, verify that those changes actually improve field outcomes, and preserve the resulting lesson so that the next vehicle generation begins with stronger knowledge than the previous one had.

Day 1 began with a question:

What do people need?

Day 9 produced a vehicle intended to satisfy that need.

Day 10 asks reality:

Did we understand the need correctly, and did our solution actually work?

Reality answers with evidence.

ZenOps feeds that evidence back into the model.

The model improves.

The factory improves.

The product improves.

And the manufacturer learns.

That is the moment the ten-day exercise stops being a linear vehicle-development process and becomes a closed, self-improving engineering and manufacturing system.