Day 6: Build and Validate the Prototype

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 asks:

Can the emerging vehicle actually behave as the model predicts?

This is where the project crosses an important boundary.

Until now, much of the work has existed as:

• needs
• models
• requirements
• Pattern decisions
• simulations
• work packages

Day 6 begins turning those ideas into a physical or sufficiently realistic integrated prototype.

The Day 6 transformation is:

Model → Prototype → StoryQ → Test → Evidence → Model Correction

The prototype is not built to impress anyone.

It is built to answer questions.

Start With the Questions From Day 5

Suppose the AURORA development structure contains:

Question 1:
Can the modified thermal Pattern support fast charging after cold soak?
Question 2:
Can the new preconditioning Pattern achieve acceptable warm-up time?
Question 3:
Can the charging interface remain reliable after environmental exposure?

These questions should determine the prototype.

Do not begin with:

Let us build the most complete car possible.

Instead ask:

What is the smallest prototype capable of resolving the important uncertainties?

That is a much stronger engineering objective.

Prototype Scope Should Follow Evidence Need

If the current uncertainty concerns only battery thermal behavior, perhaps the prototype needs:

Battery Pack
Thermal System
Battery Controller
Charging Interface
Representative Software

It may not need:

Final Interior
Production Seats
Final Paint
Audio System

The prototype should be sufficient for the question.

Nothing more is automatically better.

A Prototype Is an Evidence Instrument

This is the central Day 6 idea.

The prototype exists to convert:

Assumption

into:

Observation

For example:

Assumption:
Modified Thermal Pattern v4 can meet AURORA winter charging needs.

The prototype allows us to ask reality.

Define the Prototype Before Building It

Create a prototype object:

PROTOTYPE P1
Purpose:
Validate cold-weather charging architecture.
Includes:
Battery B4
Thermal System T5
Charge Interface C3
Controller Software SW-0.7
Excludes:
Final cabin systems
Production trim
Final body package

This prevents people from interpreting P1 as a nearly finished vehicle.

Record the Prototype Configuration

This is essential.

A result such as:

Cold-charge test:
PASS

means very little unless we know what was tested.

The configuration should preserve:

Battery Version
Thermal Hardware
Software Version
Calibration
Sensors
Mechanical Build

For example:

Prototype:
P1
Battery:
B4.2
Thermal System:
T5.1
Software:
SW-0.7
Calibration:
CAL-0.4

Evidence belongs to this configuration.

Prototype Identity Matters

Give the prototype persistent identity.

For example:

Prototype P1
Id:
PROTO-AURORA-001

Later, evidence can point back to the exact prototype.

This avoids confusion when P2 and P3 appear.

Do Not Mutate Prototype History Invisibly

Suppose a pump is replaced halfway through testing.

Do not keep calling it simply:

P1

without recording the change.

Use configuration history.

For example:

P1 Revision 1
↓
Pump changed
↓
P1 Revision 2

Evidence before and after the change may not be equivalent.

Prototype Changes Should Use CRUDME Thinking

For example:

READ:
Prototype P1 configuration
METHOD:
ReplaceCoolingPump()
UPDATE:
Prototype configuration
EVENT:
CoolingPumpReplaced

Even early engineering prototypes benefit from traceable change.

Select the Most Important StoryQ Scenarios

Day 6 should not attempt every future validation scenario.

Choose scenarios that attack the largest uncertainties.

For example:

Scenario: Fast charging after cold soak
Given Prototype P1 has been stabilized at -20°C
And the battery is at 10% state of charge
When a compatible fast charger is connected
Then the battery preconditioning strategy shall execute
And charging shall reach the required performance
Without exceeding the defined thermal limits

This scenario connects the prototype directly to the requirement model.

StoryQ Prevents Test Drift

Without explicit behavioral intent, a prototype session can become:

Let us try some things and see what happens.

Exploration has value.

But critical validation should preserve the question.

StoryQ tells everyone:

What exactly are we trying to prove?

Define Acceptance Criteria Before the Test

Do not wait until after seeing the result to decide whether it is good.

For example:

Acceptance:
10–80% charging <= 28 minutes
Maximum cell temperature <= defined limit
No critical DTC
Preconditioning energy <= target

These criteria should derive from requirements and QTs.

Do Not Move the Goalposts Afterward

Suppose the result is:

29m 12s

If the requirement says:

<= 28m

the result is:

FAIL

not:

close enough, let us call it PASS.

If the requirement itself was unreasonable, challenge the requirement explicitly.

Do not disguise the mismatch.

Separate Requirement Failure From Prototype Failure

A test can fail because:

Prototype design is weak.

But it can also reveal:

Requirement was based on a poor assumption.

Day 6 should allow both possibilities.

Evidence can challenge the solution or the upstream model.

Prepare the Test Environment

For a cold-charge prototype:

Climate chamber
Compatible charger
Instrumentation
Power measurement
Temperature sensors
Diagnostic logging

The test method should be sufficient to answer the question.

Instrumentation Is Part of Evidence Quality

If the measurement system cannot resolve the relevant behavior, the result may remain:

UNKNOWN

even though a test physically occurred.

Running a test is not the same as producing useful evidence.

Verify the Instrumentation First

Before the main test:

Sensor plausibility:
PASS
Time synchronization:
PASS
Data acquisition:
PASS

This prevents invalid evidence.

Run the Baseline First

If possible, begin with a known reference condition.

For example:

Ambient:
+20°C
Charging:
Normal

If the prototype fails under baseline conditions, there is little value in moving immediately to -20°C.

The baseline validates the test setup.

Then Move to the Critical Condition

For example:

Cold Soak:
-20°C
Soak Duration:
Defined
Battery SOC:
10%

The environmental state should be recorded.

Execute the Scenario

The test run gets its own identity:

TEST-RUN-001

It references:

Prototype P1 Revision 1
StoryQ S-CHG-004
Test Definition T-CHG-002

Now provenance is complete.

Capture Raw Observations

For example:

Start battery temperature:
-19.4°C
Time to charging temperature:
14m 10s
10–80% charge:
27m 34s
Peak cell temperature:
within limit
Preconditioning energy:
3.9 kWh

Do not reduce everything immediately to PASS/FAIL.

Preserve the observations.

Convert Observations Into Evidence

For example:

EVIDENCE-E001
Claim:
Charging duration requirement
Observation:
27m 34s
Result:
PASS

Another:

EVIDENCE-E002
Claim:
Preconditioning energy target
Observation:
3.9 kWh
Result:
FAIL

One test run can produce multiple evidence states.

Avoid One Overall Test Result When Reality Is Mixed

Instead of:

Test:
FAIL

use:

Charging Time:
PASS
Thermal Safety:
PASS
Energy Efficiency:
FAIL

This tells the team what actually needs improvement.

Day 6 Is About Learning, Not Scorekeeping

A prototype FAIL is useful if it resolves uncertainty.

For example:

Question:
Can the current strategy meet energy budget?
Answer:
No.

That is knowledge.

The project has progressed even though the design did not pass.

A Failed Prototype Can Be a Successful Experiment

This distinction is extremely important.

Work status:

COMPLETE

Evidence status:

FAIL

Learning status:

QUESTION RESOLVED

The system now knows what to change.

Perform Root-Cause Analysis Immediately

Suppose preconditioning energy is too high.

Do not simply write:

Need optimization.

Ask:

Where is the energy going?

Possible causes:

Heater efficiency
Thermal losses
Preconditioning starts too early
Target temperature too high
Control logic inefficient

The ORIGIN model helps locate the issue.

Use the OR Model for Failure Navigation

Suppose:

Battery warm-up too slow.

Trace:

Battery
← heated by
Thermal System
← controlled by
Thermal Controller
← receives
Temperature Data

The graph guides investigation.

Use the Pattern Model Too

The current structure is:

Thermal Pattern v4
Decision:
MODIFY

If the test fails, ask:

Which part of the inherited Pattern is no longer valid in AURORA’s context?

This prevents random local fixes.

Compare Expected and Observed Behavior

For example:

MODEL:
Warm-up = 11 minutes
OBSERVED:
Warm-up = 14 minutes

Difference:

+3 minutes

Now investigate why the model was wrong.

This is model calibration.

Simulation and Prototype Should Inform Each Other

The loop becomes:

Simulation
↓
Prototype Test
↓
Difference
↓
Model Update
↓
New Simulation

Do not treat simulation and physical testing as competing methods.

They can strengthen each other.

Update the Model Before Retesting

Suppose thermal losses were underestimated.

Update:

Thermal Model

and perhaps:

Pattern Context

before blindly running the same test again.

The next experiment should reflect new learning.

Generate the Next FLEXI Cycle

For example:

Question:
Can reducing target battery preheat temperature by 4°C
meet charging performance while reducing energy use?

Work:

Modify calibration
Simulate
Retest

This is a focused learning loop.

Prototype P1 Revision 2

After the change:

Calibration:
CAL-0.5

Run:

TEST-RUN-002

Results:

Charging:
27m 50s
Energy:
3.1 kWh
Thermal Safety:
PASS

Now:

Charging:
PASS
Energy:
PASS
Thermal:
PASS

The modified Pattern is stronger.

Preserve Both Runs

Do not delete:

TEST-RUN-001

because it failed.

The sequence shows how the engineering improved.

This can later become organizational knowledge.

The Failure Can Improve the Pattern

Pattern history might become:

Thermal Pattern v4
↓
AURORA cold-climate failure
↓
Control modification
↓
Thermal Pattern v4.1

If the improvement proves reusable, it may later become a new enterprise Pattern version.

Day 6 Can Create New Requirements

Suppose testing reveals an unmodeled failure:

Cooling pump cavitates
under specific low-temperature condition.

This may create:

New Requirement

or:

New FMEA Failure Mode

The prototype can improve the specification.

It Can Also Challenge the NDD

Suppose the energy cost required to hit the charging target makes the affordability need significantly worse.

Then the organization may need to reconsider:

28-minute charging target

against:

Energy efficiency
Cost

Prototype evidence can propagate all the way back to the need model.

ZenOps Allows Upstream Correction

The loop is not:

NDD
→ irreversible downstream execution

It is:

NDD
↔
ORIGIN
↔
Patterns
↔
Prototype Evidence

This is how the model learns.

Validate Interfaces Aggressively

Prototype testing should focus heavily on relations.

For example:

Battery Controller
   communicates with
Vehicle Controller

Test:

Scenario: Communication interruption during battery preconditioning
Given preconditioning is active
When communication is interrupted
Then the system shall enter the defined safe behavior
And the fault shall be recorded

Interfaces are frequent sources of unexpected behavior.

Test Failure Modes, Not Only Happy Paths

A prototype that only works when everything is healthy proves little.

Include:

Sensor failure
Communication loss
Low voltage
Actuator failure
Unexpected shutdown

where critical.

This connects Day 6 with FMEA.

FMEA Should Pull Prototype Tests

Suppose FMEA identifies:

Failure Mode:
Temperature sensor stuck high

Then StoryQ can generate:

Scenario: Temperature sensor stuck high during charging
Given the actual battery temperature is below target
When the temperature sensor reports an implausibly high value
Then the controller shall detect the abnormal condition
And charging behavior shall enter the defined safe state

Risk becomes executable evidence.

Build Physical Prototypes Where Physical Reality Matters

Simulation may not expose:

Connector fit
Vibration
Noise
Leakage
Thermal contact resistance
Assembly difficulty

Those require physical evidence.

Choose the evidence method appropriate to the uncertainty.

Use Virtual Prototypes Where They Are Stronger

For example:

Crash parameter exploration
Thermal architecture comparison
Software state-space testing

may begin virtually.

The prototype concept includes more than physical hardware.

A Prototype Can Be a Mixed System

For example:

Real Battery
Real Controller
Simulated Vehicle
Simulated Driver Inputs

Hardware-in-the-loop or software-in-the-loop can answer many questions efficiently.

ZenOps cares about evidence fitness, not one particular prototype form.

Prototype Architecture Should Remain Traceable to Patterns

For every major subsystem:

Object
↓
Pattern
↓
Prototype Implementation

This allows the project to know what exactly is being validated.

Prototype Evidence Should Update Pattern Maturity

For example:

Nordic Preconditioning Pattern v1
Before:
SIMULATION VALIDATED
After Day 6:
PROTOTYPE VALIDATED

Maturity should be earned through evidence.

Do Not Promote Too Fast

One successful prototype run does not automatically mean:

FIELD VALIDATED

Maturity levels should remain meaningful.

Day 6 may earn prototype confidence only.

Validate the Prototype Configuration as a System

Before subsystem tests, check:

Hardware identities
Software versions
Calibration
Network communication
Instrumentation

If the starting configuration is wrong, all later evidence becomes questionable.

Prototype Configuration QT

A small QT might be:

PROTOTYPE CONFIGURATION QT
[ ] Required hardware installed
[ ] Software identity verified
[ ] Calibration verified
[ ] Sensors operational
[ ] Critical interfaces healthy
[ ] Test instrumentation valid

Only then run critical tests.

Use a Prototype Test Matrix

For example:

Normal Condition
Cold Condition
Hot Condition
Low SOC
High SOC
Communication Failure
Sensor Failure

But keep the matrix tied to important claims.

Do not generate thousands of combinations without reason.

Evidence Coverage Matters More Than Test Count

A prototype program with:

300 tests

may still miss one critical requirement.

A stronger question is:

Which important claims remain UNKNOWN?

That drives the next run.

Create an Evidence Coverage View

For example:

Battery Thermal Safety:
PASS
Fast Charging:
PASS
Energy Efficiency:
PASS
Sensor Failure Behavior:
UNKNOWN
Communication Recovery:
PARTIAL

This shows what remains.

Day 6 Should End With Fewer UNKNOWNs

The goal is not necessarily that everything is PASS.

A strong Day 6 may move:

UNKNOWN

to:

FAIL

That is progress because the uncertainty is gone.

FAIL can be acted upon.

UNKNOWN cannot.

Convert FAIL Into a Root-Cause Loop

For example:

FAIL
↓
Root Cause
↓
Model Change
↓
Prototype Change
↓
Retest

Repeat until sufficient evidence exists.

Convert PARTIAL Into Targeted Work

If:

Charging:
PASS at -20°C
UNKNOWN at -30°C

do not repeat everything.

Add only:

-30°C test

The WBS follows the evidence gap.

Preserve Test Provenance

Evidence should know:

Who / what executed the test
Which prototype
Which method
Which instruments
Which software
Which conditions

This makes evidence auditable and reusable.

Prototype Results Should Be Visible in OPUS Delivery

Selecting:

REQ-WINTER-011

should reveal:

StoryQ
Test Runs
Evidence
Current State

The engineer should not need to search across folders and spreadsheets.

The OR Model Should Show Status Too

For example:

Battery Pack:
PASS
Thermal Controller:
PASS
Battery ↔ Thermal Interface:
PARTIAL

The graph becomes an evidence map.

Pattern View Should Also Update

For example:

Thermal Pattern v4.1
Prototype Status:
PASS
Extreme Cold:
PARTIAL

The Pattern Network learns from the prototype.

Run Cross-Domain Integration Tests

Many subsystem tests may pass independently.

Then the integrated prototype fails.

For example:

Thermal:
PASS
Charging:
PASS
Navigation:
PASS

but:

Navigation-triggered preconditioning:
FAIL

Integration relations matter.

Integration Should Follow the OR Network

Test critical paths such as:

Driver
↓
Navigation
↓
Vehicle Controller
↓
Thermal Controller
↓
Battery
↓
Charging

The object network provides the integration map.

Test Timing and Sequence

Automotive behavior often depends on when things happen.

For example:

Preconditioning begins too late.

Every object may technically work, but the system still misses the need.

Relations can include temporal semantics.

Prototype Serviceability Too

Even at P1, ask:

Can we diagnose this thing?

Can we replace critical components?

If engineers cannot access the pump on the prototype, production service may be worse.

Prototype learning should include lifecycle considerations.

Prototype Manufacturability

Ask:

Can this architecture actually be assembled?

For example:

Battery connector inaccessible after body assembly.

This is valuable early evidence.

The prototype can expose factory problems before tooling is frozen.

Invite Manufacturing and Service Into Day 6

Prototype validation should not be purely an engineering-team activity.

Manufacturing can inspect:

Assembly feasibility
Tool access
Process verification

Service can inspect:

Diagnostic access
Replacement access
Configuration recovery

The complete lifecycle benefits.

Supplier Evidence Can Enter Too

A supplier may provide component evidence.

But the integrated prototype should verify the component in the actual system context.

A supplier PASS does not automatically equal vehicle-level PASS.

Prototype QT Is the Main Day 6 Gate

Once the critical evidence exists, evaluate:

AURORA PROTOTYPE QT

For example:

[ ] Critical architecture functions demonstrated
[ ] Major new Patterns prototype-validated
[ ] Modified Patterns revalidated sufficiently
[ ] Major interfaces exercised
[ ] Critical failure behavior demonstrated
[ ] Important manufacturability risks understood
[ ] No unresolved blocking safety failure
[ ] Evidence traceability complete

Possible Outcome: PASS

If:

PROTOTYPE QT:
PASS

the program can advance toward more mature prototype, supplier industrialization, or production development.

PASS means:

Enough evidence exists for the next state.

It does not mean the final vehicle is complete.

Possible Outcome: PARTIAL

Perhaps:

Core Function:
PASS
Extreme Cold:
UNKNOWN

Then:

PROTOTYPE QT:
PARTIAL

The exact blocking criteria should be explicit.

Possible Outcome: FAIL

If a critical safety behavior fails:

PROTOTYPE QT:
FAIL

Do not proceed simply because the schedule says to.

Generate the required corrective work.

This Is Why QT Replaces Arbitrary Progress

The calendar can say:

Prototype phase finished.

Reality can say:

Critical failure unresolved.

ZenOps trusts reality.

Day 6 Should Produce a Prototype Knowledge Package

At the end of the day or cycle:

Prototype Identity
Configuration
StoryQ Scenarios
Test Definitions
Test Runs
Evidence
Failures
Root Causes
Pattern Updates
QT Status

This becomes reusable engineering knowledge.

Build the Smallest Useful Package

Do not bury the result in a 500-page report if structured evidence already contains the important meaning.

Reports can summarize.

The object network should preserve the underlying trace.

Example Day 6 Result

AURORA may end with:

Thermal Pattern v4.1:
PROTOTYPE VALIDATED
Preconditioning Pattern v1:
PROTOTYPE VALIDATED
Charging Connector Pattern:
PARTIAL
Cold Charging:
PASS
Sensor-Failure Behavior:
PASS
Extreme Cold -30°C:
UNKNOWN

This is a useful state.

The project knows exactly what remains.

Day 6 Can Generate Day 7 Work

From:

Extreme Cold:
UNKNOWN

generate:

Prepare -30°C validation

From:

Connector Durability:
PARTIAL

generate:

Environmental aging test

The next development structure is evidence-driven.

The Prototype Is Not a Demo

This distinction should remain strong.

A demo asks:

Does it look like it works?

A prototype validation asks:

Which claims does the evidence support?

ZenOps cares about the second.

A Beautiful Prototype Can Still Be Weak

If:

Paint:
Perfect
Interior:
Perfect

but:

Charging:
UNKNOWN

the program has not resolved the important technical uncertainty.

Visual completeness is not evidence completeness.

An Ugly Prototype Can Be Extremely Valuable

A rough mule containing:

Battery
Thermal Hardware
Controllers
Instrumentation

may resolve the critical system question.

That is good engineering.

Day 6 Builds the Bridge to Reality

Before the prototype:

Need
Model
Pattern
Requirement

are representations of expected reality.

The prototype introduces:

Observed Reality

for the first time at meaningful system scale.

That changes the program.

The Model Must Now Earn Its Claims

Day 6 asks:

Did the architecture actually behave as predicted?
Did the Pattern actually apply?
Did the requirement make sense?
Did the interfaces work?
Did the failure behavior work?

The answers come from evidence.

The Complete Day 6 Flow

The practical sequence becomes:

DAY 5 DEVELOPMENT STRUCTURE
↓
SELECT HIGHEST-VALUE QUESTIONS
↓
DEFINE PROTOTYPE SCOPE
↓
BUILD TRACEABLE CONFIGURATION
↓
VERIFY PROTOTYPE CONFIGURATION
↓
SELECT STORYQ SCENARIOS
↓
DEFINE TEST + ACCEPTANCE CRITERIA
↓
EXECUTE TEST
↓
CAPTURE RAW OBSERVATIONS
↓
CREATE EVIDENCE
↓
PASS / PARTIAL / FAIL / UNKNOWN
↓
ROOT CAUSE
↓
MODEL / PATTERN / PROTOTYPE UPDATE
↓
RETEST
↓
PROTOTYPE QT

The loop repeats until the program has earned enough confidence.

Day 6: Build and Validate the Prototype

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

Take the most important questions generated by the development structure, build the smallest prototype capable of answering them, preserve the exact hardware and software configuration, execute StoryQ-derived tests under defined conditions, capture raw observations as structured evidence, separate work completion from evidence status, preserve failures rather than hiding them, use root-cause analysis to update the OR model and Pattern Network, and repeat the cycle until the relevant Prototype Quality Threshold is satisfied.

Day 1 defined why.

Day 2 structured the need.

Day 3 modeled the domain.

Day 4 identified reusable knowledge.

Day 5 generated the work.

Day 6 asks reality whether that work produced a viable system.

The prototype is where opinion begins losing authority.

The model makes a prediction.

The prototype answers.

And from Day 6 onward, the vehicle program can increasingly be driven by what has been demonstrated rather than what people merely hope is true.