Day 5: Generate the Development Structure

Day 1 defined x.

Day 2 constructed the NDD.

Day 3 built the ORIGIN model.

Day 4 identified reusable automotive Patterns.

Day 5 asks:

What work must now be done to turn this model into a vehicle that can earn evidence?

This is where the development structure begins.

The key ZenOps principle is:

Do not invent the Work Breakdown Structure independently of the engineering model. Generate it from what remains unresolved.

The Day 5 transformation is:

Need + OR Model + Pattern Status + UNKNOWNs → Questions → Work Packages → WBS → FLEXI Execution Structure

The project plan should become a consequence of the model.

Not the other way around.

Start With What Is Already Known

Suppose the AURORA vehicle architecture now contains:

Braking Pattern:
REUSE
Drive Unit Pattern:
REUSE
Battery Structural Pattern:
REUSE
Thermal Pattern:
MODIFY
Winter Preconditioning:
NEW
Charging Interface:
MODIFY

This already tells us something important.

Not every subsystem needs the same engineering effort.

The mature areas need confirmation.

The modified areas need impact analysis and revalidation.

The new areas need full development.

Stop Treating the Whole Car as Equally Unknown

A traditional WBS may decompose:

Vehicle Development
├── Battery
├── Brakes
├── Steering
├── Software
├── Body
└── Charging

and then assign large task structures under all of them.

But this hides the most important information:

Which parts are already well understood?

A ZenOps development structure should preserve the knowledge state.

Classify the Work by Pattern Status

A useful first rule is:

REUSE
→ confirm applicability
MODIFY
→ analyze impact + adapt + revalidate
REPLACE
→ remove old Pattern + introduce replacement + prove transition
NEW
→ full learning cycle

This immediately changes the WBS.

Example: Reused Brake Pattern

Suppose:

Brake Pattern v5
Status:
FIELD VALIDATED
Decision:
REUSE

The work might be:

Confirm AURORA mass within Pattern range
Confirm wheel/tire compatibility
Confirm software interface compatibility
Run required regression evidence

That is very different from:

Develop brake system from scratch.

Example: Modified Thermal Pattern

Suppose:

Thermal Pattern v4
Decision:
MODIFY

because AURORA requires more aggressive cold-weather charging.

The work may become:

Identify changed thermal requirements
Model additional heat demand
Modify control logic
Evaluate pump capacity
Prototype revised thermal strategy
Validate winter charging

The work follows the delta.

Example: New Preconditioning Pattern

Suppose:

Winter Preconditioning:
NEW

Then the team may need:

Understand customer preconditioning use case
Define thermal strategy
Define control architecture
Simulate energy consumption
Prototype software
Test in climate chamber
Validate in vehicle

This is full development because organizational knowledge is weak.

The WBS Should Be Knowledge-Weighted

Conceptually:

Mature Knowledge
↓
Small Confirmation Work
Changed Knowledge
↓
Moderate Revalidation Work
New Knowledge
↓
Large Learning Work

This concentrates resources where uncertainty is highest.

Start Day 5 by Listing Every Important UNKNOWN

From the previous days, AURORA may contain:

UNKNOWN:
Preconditioning energy budget
UNKNOWN:
Thermal response at -30°C
UNKNOWN:
Charging connector sealing durability
UNKNOWN:
Supplier separator resilience

These are the true seeds of development work.

UNKNOWN Should Produce a Question

For example:

UNKNOWN:
Thermal response at -30°C

becomes:

Question:
Can the selected thermal architecture bring the battery
into its required charging range within the target time
at -30°C?

This is much better than:

Task:
Thermal development

The question tells us what must be learned.

Questions Generate Work

The question may generate:

Create thermal simulation model
Define cold-soak boundary conditions
Run simulation
Analyze result
Prototype revised control strategy

Now the work has a clear reason.

Work Should Resolve Something

A useful Day 5 rule is:

Every significant work item should resolve a need, requirement, architectural uncertainty, Pattern gap, risk, or evidence gap.

If a task cannot answer:

Why does this exist?

challenge it.

A WBS Item Should Point Back Upstream

For example:

WORK-THERM-041
Validate -30°C battery warm-up performance

should link to:

NDD:
Winter Operation

Requirement:
REQ-WINTER-011

OR Objects:
Battery + Thermal System

Pattern:
Thermal Pattern v4 — MODIFY

The work becomes fully contextualized.

This Is Different From a Detached Project Schedule

A conventional schedule may say:

Task 511:
Thermal test
Owner:
Alice
Duration:
5 days

OPUS Delivery should additionally know:

Why:
Resolve Thermal Pattern applicability
Evidence Expected:
Cold-soak performance result
QT Dependency:
Battery Prototype QT

Now task completion has meaning.

Build the WBS From the Model

A top-level AURORA development structure might become:

AURORA DEVELOPMENT
│
├── 001 Need Resolution
├── 002 Architecture Confirmation
├── 003 New Pattern Development
├── 004 Modified Pattern Revalidation
├── 005 Supplier Development
├── 006 Prototype Development
├── 007 Verification
├── 008 Manufacturing Development
└── 009 Release Evidence

This is one possible structure.

The exact hierarchy is less important than its traceability.

Work Can Also Be Organized by Domain Object

For example:

Vehicle
├── Battery
│   ├── Confirm structural Pattern
│   ├── Modify thermal Pattern
│   └── Validate charging
│
├── Braking
│   └── Confirm mature Pattern applicability
│
└── Charging
    ├── Modify connector Pattern
    └── Develop preconditioning logic

Both views can be useful.

One Underlying Work Item, Multiple Views

This is important.

Do not create duplicate tasks simply because project managers and engineers want different views.

One work item can appear under:

Object View
Pattern View
WBS View
QT View

The underlying identity remains the same.

Work Package vs Work Item

Large unresolved questions may become:

Work Package

For example:

WP-THERM-001
AURORA Winter Thermal Capability

containing:

Simulation
Control Design
Prototype
Testing

Individual executable actions become Work Items.

Work Packages Should Have Clear Outcomes

For example:

WP-THERM-001
Outcome:
Enough evidence to determine whether the modified thermal Pattern
satisfies AURORA winter charging needs.

This is stronger than:

Complete thermal engineering.

Avoid Activity-Based Work Packages

Weak:

Battery Meetings

Stronger:

Resolve battery thermal architecture decision

The second describes a needed result.

Project Work Should Follow Decisions

Some work exists because an engineering decision has not yet been made.

For example:

Decision Needed:
Select cooling architecture

Then the work may include:

Compare Pattern A and Pattern B
Generate evidence
Record decision

The WBS should support decision resolution.

Candidate Architecture Work Can Be Explicit

Suppose:

Candidate A:
Liquid cooling
Candidate B:
Refrigerant direct cooling

The development structure may include:

Evaluate performance
Evaluate manufacturing
Evaluate serviceability
Evaluate supplier risk
Compare evidence
Select architecture

The decision object closes the work package.

Use FLEXI for Small Learning Cycles

Day 5 should not immediately convert every work item into multi-month tasks.

Large questions should be decomposed.

For example:

Can AURORA meet winter charging performance?

is still too large.

Break it into FLEXI questions:

What thermal energy is required after -20°C soak?
Can current heater capacity deliver it?
What is the energy penalty?
Does preconditioning timing solve the problem?

Each can produce evidence quickly.

The FLEXI Cycle

The structure remains:

Question
↓
Small Work Cycle
↓
Evidence
↓
Decision

The development structure becomes a series of learning loops.

This Reduces Large Hidden Tasks

A task such as:

Develop charging system — 120 days

can hide enormous uncertainty.

A series of explicit questions exposes it.

That makes progress more meaningful.

Work State and Knowledge State Are Different

A work item can be:

COMPLETE

while the result is:

FAIL

For example:

Task:
Run cold-charge test
Work Status:
COMPLETE
Evidence:
FAIL

The project should not interpret completed activity as successful engineering.

Day 5 Should Preserve This Separation

Useful dimensions include:

Work Status:
NOT STARTED
ACTIVE
COMPLETE

and separately:

Evidence State:
PASS
PARTIAL
FAIL
UNKNOWN

This is central to ZenOps project management.

Failed Work Can Create More Work

Suppose:

Cold-charge test:
FAIL

Then:

Root-cause investigation
Modify control strategy
Repeat test

may be generated.

The WBS evolves with evidence.

This Means the WBS Is Living

The complete development plan cannot always be known on Day 5.

That is acceptable.

The initial structure should represent current knowledge.

As evidence arrives:

New Work

may emerge.

ZenOps favors adaptive evidence-driven planning over pretending all future work is knowable.

Still Create a Program Backbone

A living WBS does not mean no structure.

A useful backbone might include:

Need Validation
Architecture
Pattern Qualification
Prototype
Supplier Readiness
Manufacturing Readiness
Verification
Release

The details evolve underneath.

Use QTs as Higher-Level Milestone Definitions

Instead of:

Milestone:
Prototype Complete
Date:
June 1

define:

Prototype QT

with evidence criteria.

The date remains a planning target.

The QT defines actual readiness.

WBS Items Should Feed QTs

For example:

Battery Prototype QT

depends on:

Thermal Evidence
Charging Evidence
Safety Evidence
Software Evidence

Work packages exist to produce those evidence objects.

The flow becomes:

Work
↓
Evidence
↓
QT

This Creates a Better Project Structure

The program can answer:

Which work items are blocking Prototype QT?

This is much more useful than:

Which tasks are late?

Both matter.

But blocking evidence is the deeper delivery question.

Example AURORA Prototype Structure

AURORA PROTOTYPE DEVELOPMENT
│
├── Battery
│   ├── Structural Pattern applicability
│   ├── Thermal modification
│   └── Safety verification
│
├── Charging
│   ├── Fast-charge definition
│   ├── Connector durability
│   └── Preconditioning development
│
├── Drive
│   └── Reuse confirmation
│
├── Software
│   ├── Thermal control
│   ├── Charging coordination
│   └── Diagnostic logic
│
└── Prototype Integration
    ├── Build Prototype P1
    ├── Integrate systems
    └── Execute Prototype QT evidence

The structure mirrors the engineering model.

Work Can Cross Multiple Objects

Not every work package belongs neatly under one subsystem.

For example:

Fast-Charging Winter Performance

may involve:

Battery
Thermal System
Charge Port
Navigation Software
Vehicle Controller

The work package should be cross-functional where the need is cross-functional.

Avoid Organizational WBS Silos

A weak WBS may be:

Mechanical Team
Electrical Team
Software Team

That mirrors the organization.

But the product problem may cut across all three.

A better work package is:

Resolve winter charging capability

with contributors from multiple teams.

Ownership Is Still Useful

Each work item should have a responsible owner.

But ownership should not define the engineering meaning.

For example:

Work:
Resolve charging connector environmental durability
Owner:
Connector Engineering

The problem remains a product problem.

Define Expected Evidence Before Starting Work

This is one of the strongest Day 5 practices.

For each major work item, ask:

What evidence should this produce?

Example:

Work:
Validate thermal warm-up strategy
Expected Evidence:
Measured or simulated warm-up time under defined cold-soak conditions

This keeps work outcome-focused.

A Work Item Without Expected Evidence Is Suspicious

If the output is only:

document produced

ask whether the document itself matters or whether it should support a claim.

Documents can be useful.

But evidence and decisions are the real goal.

Engineering Documents Can Be Outputs, Not Ends

For example:

Simulation Report

is useful because it supports:

Claim:
Thermal architecture satisfies warm-up need.

Keep the relationship explicit.

Generate Work From Pattern Gaps

Suppose Day 4 found:

Pattern:
Preconditioning
Status:
NEW

Then Day 5 should create a development package.

The Pattern gap itself is the source.

Generate Work From Pattern Modifications

Suppose:

Liquid Cooling Pattern v4:
MODIFY

Create:

Identify changed interfaces
Review inherited evidence
Define new evidence needs
Modify architecture
Revalidate

The work is delta-based.

Generate Work From Anti-Patterns

Suppose the old architecture triggered:

ANTI-PATTERN:
Critical connector without positive seating verification

The new development structure should explicitly contain:

Define positive connector verification
Validate manufacturing detection
Generate regression StoryQ

Negative knowledge creates preventive work.

Generate Work From FMEA Later

As failure analysis develops, high-priority failure modes may generate:

Mitigation design
Test
Evidence

The WBS can absorb these.

It remains connected to risk.

Generate Work From Supplier UNKNOWNs

Suppose:

Secondary cell source:
UNKNOWN

Then:

Identify candidate supplier
Assess interface compatibility
Assess capacity
Assess evidence
Qualify

Procurement work becomes part of the same development structure.

Generate Work From Manufacturing UNKNOWNs

Suppose the product requires:

Battery Installation Relation

but no production method has yet been proven.

Then:

Develop installation process
Select tooling
Create verification method
Run process trial

The factory WBS derives from the product model.

Day 5 Is Where Product and Factory Work Begin to Meet

The vehicle architecture creates manufacturing needs.

For example:

Vehicle
contains
Battery

means:

Factory must create
Vehicle-Battery relation

That generates manufacturing development work.

Do Not Wait Until Design Freeze to Think About Production

If an architecture is impossible or expensive to manufacture, early factory input should reveal that.

The development structure should include manufacturing evidence early.

Serviceability Work Can Be Generated Too

Suppose NDD requires:

Replace failed charging controller

but the architecture is new.

Create:

Define service access
Define replacement method
Define configuration recovery
Define repair verification

Service readiness becomes part of development.

Lifecycle Work Belongs in the WBS

For example:

Define OTA update method
Define persistent vehicle identity
Define service-history structure

if these are part of the product needs.

The development structure should cover the complete lifecycle, not just SOP.

Use Work Dependencies Carefully

Some tasks genuinely depend on others.

For example:

Select Thermal Architecture
↓
Build Prototype
↓
Physical Test

That dependency should be explicit.

Avoid Artificial Dependencies

Do not require:

All Battery Work Complete
before
All Software Work Begins

if software can develop against simulations or interface definitions.

FLEXI favors parallel learning where possible.

Work Can Be Parallelized by Questions

For example:

Thermal Simulation
Supplier Capability
Connector Durability

may run in parallel.

The program should exploit independence.

Dependency Comes From the Domain, Not the Gantt Chart

If object A depends on object B, work may inherit that dependency.

The OR model can help derive project dependencies.

This is another advantage of connecting engineering and project management.

The WBS Can Be Seen as an Action Projection of the Domain

The OR model says:

What exists?

The Pattern Network says:

What do we already know?

The WBS says:

What must we now do?

All three are views of one transformation.

Define a Work Item Model

A useful OPUS Delivery Work Item may contain:

Id
Title
Question
Owner
Upstream Need
Related Objects
Related Pattern
Expected Evidence
Status
QT Dependency

This is far richer than a simple task row.

Example

WORK-CHG-041
Title:
Validate cold fast-charging performance
Question:
Can AURORA meet the defined fast-charge need
after -20°C cold soak?
Related Need:
NDD-WIN-004
Related Objects:
Battery Pack
Thermal System
Charge Port
Pattern:
Thermal Pattern v4 — MODIFY
Expected Evidence:
Cold-charge test evidence
QT:
Battery Prototype QT

Now the entire reason for the work is visible.

Work History Matters

If the item fails and is repeated, preserve the history.

For example:

Run 1:
FAIL
Run 2:
PARTIAL
Run 3:
PASS

The learning path may be useful later.

WBS Should Not Hide Iteration

Traditional schedules may want one:

Validation Task

ZenOps can represent repeated learning cycles explicitly.

This creates better organizational memory.

Work Can Create New Questions

Suppose a test reveals:

Unexpected voltage drop

Then:

New Question:
Why?

The new question generates another work item.

This is legitimate.

The Development Structure Becomes Self-Extending

Conceptually:

Question
↓
Work
↓
Evidence
↓
New Question

until sufficient knowledge exists.

Stop When QT Has Enough Evidence

The objective is not infinite investigation.

Once the relevant QT criteria are satisfied:

PASS

the current development cycle can close.

This gives a stopping rule.

Cost and Schedule Still Matter

ZenOps does not remove:

Budget
Dates
Resources

They remain project constraints.

But they should be attached to meaningful work.

The engineering reality should not be reduced to those numbers.

Estimate Work Based on Knowledge State

A mature reused Pattern may have predictable effort.

A new Pattern may carry much wider uncertainty.

This should influence estimates.

The WBS Itself Can Learn Over Time

If every new thermal Pattern historically requires:

Simulation
Prototype
Climate Test

future projects can inherit that work Pattern.

Project execution becomes reusable knowledge too.

Work Patterns Can Exist

Examples:

New Pattern Development Work Pattern

Modified Pattern Revalidation Work Pattern

Supplier Qualification Work Pattern

The WBS can reuse proven project structures.

This Is Pattern Thinking Applied to Project Management

A project task sequence that repeatedly works can itself become a Pattern.

The organization learns how to engineer, not only what to engineer.

Day 5 Should Produce a Development Baseline

By the end of the day, AURORA should have:

Major Work Packages
Critical Questions
Pattern-Based Work Classification
Owners
Dependencies
Expected Evidence
QT Links

This becomes the initial execution structure.

Example Day 5 Development Baseline

AURORA DEVELOPMENT
│
├── WP-001 Customer / Need Resolution
│
├── WP-002 Reused Architecture Confirmation
│
├── WP-003 Winter Preconditioning — NEW
│
├── WP-004 Thermal System — MODIFY
│
├── WP-005 Charging Interface — MODIFY
│
├── WP-006 Supplier Qualification
│
├── WP-007 Prototype Integration
│
├── WP-008 Manufacturing Process Development
│
└── WP-009 Verification and QT

Each package contains explicit questions and evidence outputs.

Day 5 Development QT

A useful threshold could be:

DAY 5 DEVELOPMENT STRUCTURE QT
[ ] Major UNKNOWNs mapped to questions
[ ] REUSE work limited to applicability confirmation where appropriate
[ ] MODIFY / REPLACE / NEW areas generate explicit development work
[ ] Major work items linked to NDD and OR objects
[ ] Expected evidence defined for critical work
[ ] Important dependencies visible
[ ] Owners assigned
[ ] Relevant QT dependencies established
[ ] Major manufacturing / supplier / service work not omitted

If these conditions are satisfied:

DAY 5 DEVELOPMENT STRUCTURE QT:
PASS

The vehicle program now has an actionable execution model.

PASS Does Not Mean the WBS Is Frozen

The WBS will change.

New evidence will create new work.

Some planned work will become unnecessary.

Some reused evidence may prove sufficient.

That is normal.

The Development Structure Is a Living Projection

The stable foundation is:

Need
Objects
Relations
Patterns

The work structure changes as knowledge changes.

That is appropriate.

What Not to Do on Day 5

Do not:

• invent thousands of tasks merely to look complete
• treat every subsystem as equally uncertain
• copy an old WBS without checking the new context
• hide engineering questions inside vague activities
• confuse completed work with successful evidence
• freeze the project plan before learning begins

The purpose is not administrative detail.

The purpose is executable learning.

A Bad Day 5

A bad result might be:

Battery Development — 180 days
Software Development — 220 days
Testing — 90 days

with little explanation.

This describes calendar allocation.

It does not describe what must be learned.

A Good Day 5

A good result says:

Question:
Can modified Thermal Pattern v4 meet -30°C fast-charge requirements?
Work:
Simulation + prototype + climate test
Evidence:
Cold-charge performance
QT:
Battery Prototype QT

This is much stronger.

The Complete Day 5 Flow

The day can be summarized as:

DAY 4 PATTERN MODEL
↓
IDENTIFY REUSE / MODIFY / REPLACE / NEW
↓
COLLECT UNKNOWNs
↓
TURN UNKNOWNs INTO QUESTIONS
↓
TURN QUESTIONS INTO WORK PACKAGES
↓
DEFINE EXPECTED EVIDENCE
↓
ADD OWNERS + DEPENDENCIES
↓
CONNECT WORK TO QTs
↓
CREATE INITIAL WBS
↓
DAY 5 DEVELOPMENT STRUCTURE QT

The vehicle program is now ready to move from structured thinking into systematic execution.

Why Day 5 Matters

Before Day 5, the organization understands:

• why the vehicle should exist
• what needs it must satisfy
• what the main system objects are
• what knowledge can be reused

Day 5 converts that understanding into action.

But it does so without losing meaning.

The project plan is no longer an independent administrative artifact.

It is generated from the engineering domain.

From Domain Model to Delivery Model

The transition is:

NDD:
Why?
ORIGIN:
What?
Patterns:
What do we know?
WBS:
What must we do?

This is the practical bridge between ZenOps engineering and ZenOps project management.

Day 5: Generate the Development Structure

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

Take the NDD, ORIGIN model, Pattern Network, and visible UNKNOWNs from the first four days; turn every important uncertainty into a clear question; generate work only where a need, dependency, Pattern gap, risk, or evidence gap demands it; classify work according to REUSE, MODIFY, REPLACE, and NEW; define the evidence each important work item must produce; connect the work to Quality Thresholds; and build the initial WBS as a living projection of the vehicle model rather than as an isolated schedule.

Day 1 defined why.

Day 2 structured the need.

Day 3 modeled the system.

Day 4 separated known Patterns from genuine novelty.

Day 5 turns the remaining uncertainty into work.

And from this point forward, the most important question is no longer:

How many tasks have we completed?

It is:

What have those tasks taught us, and what evidence do we now have?

Day 4: Identify Automotive Patterns

Day 1 defined the need.

Day 2 constructed the NDD.

Day 3 built the first ORIGIN model.

Day 4 asks:

Which parts of this automotive object network have already been solved before?

This is where Pattern thinking begins.

The objective is not to copy the previous vehicle.

It is not to standardize everything.

It is not to force every new problem into an old solution.

The objective is to identify recurring structures that already contain useful engineering knowledge.

The Day 4 transformation is:

ORIGIN Model → Repeated Structures → Candidate Patterns → Pattern Context → Reuse Decision

The key idea is simple:

Do not spend new engineering effort rediscovering knowledge the organization already possesses.

Start With the Day 3 OR Model

Suppose the AURORA model contains:

Temperature Sensor
   reports to
Thermal Controller
Thermal Controller
   commands
Cooling Pump
Cooling Pump
   changes temperature of
Battery Pack

Look at the structure rather than only the object names.

The underlying pattern is:

Sense
↓
Decide
↓
Act
↓
Observe

That structure may already exist elsewhere in the vehicle.

Look for Repetition

Perhaps the brake system also contains:

Wheel Sensor
↓
Brake Controller
↓
Brake Actuator

Steering may contain:

Steering Sensor
↓
Steering Controller
↓
Steering Actuator

Now a recurring structure becomes visible.

This is a Pattern candidate.

Give the Pattern a Name

For example:

PATTERN:
Sense → Decide → Act

or more explicitly:

Closed-Loop Control Pattern

The name lets the organization talk about the structure as one reusable unit.

A Pattern Is More Than Similar Shapes

Two diagrams looking similar does not automatically make them the same Pattern.

Ask:

Are they solving the same type of problem?

Do the relations have comparable meaning?

Are the important constraints similar?

If yes, Pattern reuse may be justified.

Begin With the Problem the Pattern Solves

A strong Pattern should answer:

Problem:
What recurring need does this solve?

For example:

Pattern:
Closed-Loop Thermal Control
Problem:
Maintain a physical quantity within an acceptable operating range
despite changing conditions.

That is much more reusable than:

battery pump design.

Add Context

Patterns are never universally valid.

For example:

Context:
Continuous control
Sensor feedback available
Actuation available
Response time within defined range

Context defines where the Pattern makes sense.

Add the Structural Core

For example:

Measured Object
↓
Sensor
↓
Controller
↓
Actuator
↓
Measured Object

This is the reusable OR structure.

Add the Known Benefits

For example:

Benefits:
Automatic correction
Adaptation to changing conditions
Observable control state

The Pattern should explain why it is useful.

Add Known Risks

For example:

Known Risks:
Sensor failure
Controller instability
Actuator saturation
Communication failure

Reusable knowledge includes failure knowledge.

Patterns Should Carry More Than Architecture

A mature Pattern can contain:

Problem
Context
Objects
Relations
Requirements
Failure Modes
StoryQ
Evidence
Trade-offs

This is what makes Pattern reuse stronger than copying.

Start With Existing Patterns First

Day 4 should ask:

What do we already have?

Possible automotive Patterns might include:

Sense-Decide-Act Pattern
Install-Verify-Record Pattern
Redundant Sensor Pattern
Safe-Degradation Pattern
Diagnostic Monitor Pattern
Torque-Control Pattern
OTA Rollout Pattern
Dual-Source Supply Pattern

The Pattern Network becomes the organization’s memory.

Search by Need

Suppose the NDD contains:

Need:
Maintain battery temperature.

Search for Patterns addressing:

Thermal Control
Temperature Sensing
Cooling
Degraded Operation

Pattern retrieval should begin from need rather than from a favorite technology.

Search by OR Structure

Suppose the OR model shows:

Sensor
→
Controller
→
Actuator

Search for Patterns with the same structural logic.

This can reveal reusable solutions that engineers might otherwise miss.

Search by Failure Type

Suppose the system requires:

Continue operation after one sensor fails.

Search the Pattern Network for:

Redundancy
Fault Tolerance
Safe Degradation

Failure requirements can lead directly to relevant Patterns.

Identify Manufacturing Patterns Too

Day 4 is not limited to vehicle architecture.

Suppose manufacturing eventually needs:

Install Component
↓
Verify Installation
↓
Record Result

That can be a reusable:

Install-Verify-Record Pattern

This same Pattern may apply to:

• battery installation
• controller installation
• seat installation
• safety-critical fasteners

Supplier Patterns Can Also Be Reused

For example:

Critical Component
↓
Primary Supplier
+
Independent Secondary Supplier

This may become:

Independent Dual-Source Pattern

The Pattern Network can span engineering, manufacturing, procurement, and service.

Service Patterns Matter Too

For example:

Symptom
↓
Diagnostic Test
↓
Root Cause
↓
Repair
↓
Verification

This is a reusable service Pattern.

A vehicle program should reuse lifecycle knowledge, not only design knowledge.

Day 4 Is About Candidate Patterns First

Do not immediately declare:

Pattern:
APPROVED

The first task is:

Candidate Pattern

Then evaluate whether it actually fits the current context.

Compare the Current Need With Pattern Context

Suppose:

Pattern:
Liquid Cooling Pattern v3

was validated for:

Battery Power:
up to P1

AURORA requires:

Battery Power:
P2

Then the Pattern may be:

PARTIALLY APPLICABLE

not automatically reusable.

Reuse Has Four Useful States

For Day 4, classify each important candidate as:

REUSE
MODIFY
REPLACE
NEW

This creates a powerful architecture map.

REUSE

Use when:

Need sufficiently similar
Context sufficiently similar
Evidence still applicable

For example:

Brake Sensor Pattern:
REUSE

This is mature engineering knowledge.

MODIFY

Use when the Pattern is mostly applicable but something significant differs.

For example:

Thermal Pattern:
MODIFY

because AURORA introduces more aggressive winter charging.

The existing knowledge remains useful, but additional work is required.

REPLACE

Use when field or project evidence has challenged the existing Pattern.

For example:

Old Connector Pattern:
REPLACE

because previous fleet failures exposed a structural weakness.

Do not retain it simply because it is familiar.

NEW

Use when no suitable Pattern exists.

For example:

New Bidirectional Charging Coordination:
NEW

This is genuine novelty.

That means higher uncertainty.

Novelty Is Important Project Information

A vehicle architecture may become:

60% REUSE
25% MODIFY
10% REPLACE
5% NEW

This is far more useful than saying:

vehicle design is 20% complete.

It shows where engineering uncertainty actually sits.

The Pattern Map Can Guide Resources

For:

REUSE

the work may primarily be:

Confirm applicability

For:

MODIFY

the work becomes:

Impact analysis
Adaptation
Revalidation

For:

NEW

the work may be:

Full engineering cycle

This turns Pattern classification into WBS input.

Reuse Does Not Mean Zero Work

Even a mature Pattern must be checked against the new x.

Ask:

Does the same problem exist?
Is the context equivalent enough?
Has anything changed that invalidates the evidence?

Reuse is an engineering decision, not a shortcut.

Preserve Pattern Version

Suppose AURORA uses:

Thermal Pattern v4

Record that exact version.

Do not merely say:

Thermal Pattern

The version determines which structure, evidence, and known limitations were actually used.

Preserve Pattern Lineage

For example:

Thermal Pattern v3
↓
Modified because of field evidence FF-118
↓
Thermal Pattern v4

This gives future engineers causal context.

Field-Validated Patterns Deserve Special Attention

A Pattern with:

Simulation Evidence
Prototype Evidence
Production Evidence
Fleet Evidence

contains much more confidence than a conceptual Pattern.

Do not treat both equally.

Pattern Maturity Can Be Explicit

For example:

CONCEPT
SIMULATION VALIDATED
PROTOTYPE VALIDATED
PRODUCTION VALIDATED
FIELD VALIDATED

This helps determine how much additional evidence the new program needs.

Maturity Is Not a Universal Score

A Pattern may be field validated in one context but weak in another.

For example:

Field Validated:
Temperate Climate

but:

Extreme Cold:
UNKNOWN

AURORA’s Nordic context may still require work.

Add Applicability Range

A useful Pattern card might contain:

Pattern:
Liquid Cooling v4
Validated For:
Power Range P1–P2
Climate C1–C3
Vehicle Mass M1–M2
Not Validated For:
Heavy Commercial Duty

This makes reuse more disciplined.

Connect Patterns to NDD Needs

For example:

NDD-WIN-004
Maintain Charging Capability in Winter

connects to:

Thermal Pattern v4

and:

Battery Preconditioning Pattern v2

The solution remains traceable to the need.

Connect Patterns to OR Objects

For example:

Thermal Pattern v4

may instantiate:

Temperature Sensor
Thermal Controller
Pump
Heat Exchanger

and the relations between them.

Now Pattern knowledge and the OR model become directly connected.

A Pattern Can Instantiate Multiple Objects

Conceptually:

Pattern
↓
Object Network Fragment

This is stronger than treating the Pattern as a text document.

Avoid Copying Objects Without Pattern Lineage

If an engineer copies the old thermal architecture into AURORA but does not record the Pattern relation, the reuse becomes invisible.

Later nobody knows:

Was this intentional reuse or accidental duplication?

Preserve lineage.

Higher-Order Patterns Can Be Found

Suppose:

Battery Pattern
+
Thermal Pattern
+
Charging Pattern
+
HV Safety Pattern

always appear together.

That may become a higher-order:

EV Energy System Pattern

Patterns can compose into larger Patterns.

Day 4 Begins the Pattern Network

The organization may start with:

EV Energy System Pattern
├── Battery Pattern
├── Thermal Pattern
├── Charging Pattern
└── HV Safety Pattern

This is more than a Pattern Library.

It is a network of dependency.

Give Pattern Relations Meaning

For example:

EV Energy System Pattern
   uses
Thermal Pattern

or:

Fast-Charging Pattern
   requires
Thermal Pattern

or:

High-Performance Cooling Pattern
   specializes
Liquid Cooling Pattern

Explicit semantics make the network useful.

Identify Pattern Conflicts

Suppose:

Low-Cost Pattern

pushes toward:

One Supplier

while:

Supply Resilience Pattern

pushes toward:

Dual Source

These Patterns may conflict.

Day 4 should expose that.

Pattern Conflict Is a Decision Input

Do not hide the tension.

Represent:

Pattern A
conflicts with
Pattern B
under Context C

Trade-offs belong in engineering reasoning.

Identify Anti-Patterns

A previous vehicle may have taught:

ANTI-PATTERN:
Critical connector without positive engagement verification.

If the new OR model contains a similar structure, Day 4 should flag it.

This is one of the highest-value uses of organizational memory.

Anti-Patterns Prevent Repeated Failure

A good Pattern Network should answer not only:

What should we reuse?

but also:

What should we never casually repeat?

Negative knowledge is still knowledge.

Link Anti-Patterns to Their Replacement

For example:

Unverified Connector Anti-Pattern
↓
replaced by
Positive Engagement Verification Pattern

The system should lead the engineer toward the improved structure.

Field Evidence Should Affect Pattern Choice

Suppose two Patterns both satisfy the same need.

Pattern A has:

Prototype Evidence

Pattern B has:

500,000 vehicle-years of strong field evidence

All else equal, Pattern B carries stronger confidence.

Evidence should influence selection.

Cost Still Matters

The most mature Pattern may also be too expensive for the current x.

Pattern selection is multi-dimensional.

Consider:

Need Satisfaction
Evidence
Cost
Manufacturing
Serviceability
Supplier Risk

Pattern reuse does not remove trade-offs.

Manufacturing Fit Matters

A Pattern may perform technically but be difficult to industrialize.

For example:

Thermal Pattern A:
Strong performance
High assembly complexity

Pattern B:

Slightly lower performance
Much lower assembly complexity

The NDD decides which outcome matters.

Serviceability Matters Too

A Pattern may hide critical components behind difficult disassembly.

If serviceability is an accepted NDD need, that is part of Pattern selection.

This prevents local technical optimization.

Use Evidence to Reject Patterns

A rejected Pattern should have a reason.

For example:

Pattern:
Air Cooling v2
Decision:
REJECTED
Reason:
Insufficient thermal capacity under AURORA fast-charge need.

This is useful future knowledge.

Preserve Rejected Alternatives

Another program may have lower power requirements.

Air Cooling v2 may then become valid.

Do not delete the rejected candidate from organizational memory.

Pattern Decisions Should Be Explicit Objects

Conceptually:

PATTERN DECISION PD-041
Need:
Battery Thermal Management
Selected:
Liquid Cooling v4
Alternatives:
Air Cooling v2
Refrigerant Cooling v1
Rationale:
Best combination of thermal evidence,
manufacturability and serviceability.

Now architecture decisions become explainable.

Pattern Selection Can Expose Missing Evidence

Suppose:

Pattern A:
Promising

but:

Winter Evidence:
UNKNOWN

Then Day 4 produces a knowledge gap.

That gap later becomes work.

This Is How Pattern Work Pulls the WBS

The chain is:

Candidate Pattern
↓
Applicability Gap
↓
Question
↓
Work

For example:

Can Thermal Pattern v4 meet AURORA's -30°C charging requirement?

This becomes a FLEXI or test task.

Day 4 Should Not Finalize Every Pattern

Some decisions can remain:

CANDIDATE

or:

UNDER REVIEW

The purpose is to expose reusable knowledge and novelty, not force premature closure.

Pattern Reviews Can Be Cross-Functional

A strong Pattern decision may involve:

Engineering
Manufacturing
Supplier
Service

because a reusable solution spans the lifecycle.

This is especially important for high-level vehicle Patterns.

Example: Battery Pack Pattern Review

Candidate:

Battery Pack Pattern v4

Engineering says:

Performance:
PASS

Manufacturing says:

Assembly:
PASS

Service says:

Module replacement:
PARTIAL

Supplier analysis says:

Cell sourcing:
PASS

The Pattern is mostly strong but has a serviceability issue.

The decision may become:

MODIFY

rather than simple reuse.

Example: Control Pattern Review

Candidate:

Distributed Control Pattern v3

But AURORA’s cost target is aggressive.

The team compares:

Centralized Control Pattern
vs
Distributed Control Pattern

The Pattern Network helps structure the comparison.

Pattern Selection Should Remain Need-Driven

Do not say:

We always use distributed control.

Ask:

Which architecture best satisfies the current x with acceptable evidence and risk?

This keeps Pattern reuse from becoming dogma.

Day 4 Should Produce a Pattern Coverage View

For example:

AURORA PATTERN COVERAGE
Energy System:
REUSE + MODIFY
Braking:
REUSE
Steering:
REUSE
Winter Preconditioning:
NEW
Diagnostics:
REUSE
Battery Assembly:
REUSE
Connector Verification:
REUSE

This immediately shows where the program is mature and where it is exploratory.

Pattern Coverage Can Be Mapped to the OR Model

Imagine selecting:

Battery Controller

and seeing:

Pattern:
Battery Control Pattern v5
Maturity:
FIELD VALIDATED
Decision:
REUSE

Then select:

Preconditioning Coordinator

and see:

Pattern:
NONE
Decision:
NEW

The architecture gains knowledge metadata.

Pattern Gaps Are Valuable

A Pattern gap means:

We do not already know how to solve this sufficiently well.

That is exactly where engineering should concentrate.

Do Not Hide Gaps by Inventing Weak Patterns

A poorly understood solution should remain:

NEW

or:

UNKNOWN

rather than being promoted prematurely into the Pattern Library.

Pattern status must mean something.

Pattern Promotion Should Be Earned

A local solution may begin:

PROGRAM-SPECIFIC

After evidence:

PROGRAM-REUSABLE

Later:

ENTERPRISE-REUSABLE

Day 4 should respect Pattern maturity.

New Patterns Will Be Born Later

Suppose the AURORA winter-preconditioning work succeeds.

It may eventually become:

Nordic Preconditioning Pattern v1

Then a future vehicle can reuse what AURORA learned.

This is how the Pattern Network grows.

Day 4 Is the Start of Organizational Memory Reuse

Without Pattern thinking:

New Vehicle
↓
Rediscover Old Problems

With Pattern thinking:

New Vehicle
↓
Reuse Proven Knowledge
↓
Focus on Genuine Novelty

This can radically change development efficiency.

Review the Pattern Network for Common-Cause Risk

Reuse has another side.

If:

Pattern P4

is used by:

Brake System
Steering System
Thermal System

a Pattern defect may affect multiple domains.

Shared reuse increases leverage and exposure.

High-Reuse Patterns Need Stronger Governance

A Pattern used in:

1 subsystem

is one thing.

A Pattern used across:

10 vehicle programs

is strategically important.

Its maturity and history deserve stronger review.

Pattern Version Changes Need Impact Analysis

If:

Pattern v4
↓
v5

ask:

Which current vehicle programs use v4?
Which vehicle instances implement it?
Which regression tests depend on it?

Pattern traceability becomes portfolio traceability.

Day 4 Can Already Connect to OPUS Delivery

Inside OPUS Delivery, the user might select an OR object or relation and choose:

Find Candidate Patterns

The system can show:

Pattern Name
Context
Maturity
Evidence
Known Risks
Usage

The engineer then records the reuse decision.

The Pattern Network Is a Separate View of the Same Domain

The OR Model asks:

What exists?

The Pattern View asks:

What reusable knowledge explains why this structure exists?

The two should remain connected.

Do Not Duplicate the OR Model Inside the Pattern Tool

The Pattern should reference or instantiate the actual object-network structure.

One model.

Multiple views.

This is a core OPUS principle.

Pattern Status Can Feed QT

A future Architecture QT might require:

[ ] All critical OR structures mapped to:
    mature reused Pattern
    or explicit new engineering work

This prevents hidden novelty.

Day 4 Pattern QT

A useful Day 4 threshold might be:

DAY 4 PATTERN QT
[ ] Major OR structures reviewed for reuse
[ ] Candidate Patterns identified
[ ] Important Pattern contexts checked
[ ] Reuse decisions classified
[ ] Anti-Patterns reviewed
[ ] Pattern gaps visible
[ ] Rejected alternatives retain rationale
[ ] Pattern-to-NDD links established
[ ] Pattern-to-OR links established

If these conditions are satisfied:

DAY 4 PATTERN QT:
PASS

The vehicle program has a first usable reuse map.

PASS Does Not Mean Architecture Is Final

It means:

We now understand which parts of the architecture are based on known knowledge and which parts require new learning.

That is enough for the next step.

What Not to Do on Day 4

Do not:

• copy the entire old vehicle
• declare every repeated shape a Pattern
• assume field-valid in one context means valid everywhere
• force new needs into old Patterns
• ignore Anti-Patterns
• hide genuine novelty

Pattern reuse should increase clarity, not create false confidence.

Day 4 Output

A strong Day 4 produces:

Pattern Coverage Map
+
Candidate Pattern List
+
REUSE / MODIFY / REPLACE / NEW Decisions
+
Pattern Context
+
Maturity
+
Known Risks
+
Pattern Gaps

This is enough to transform the next stage of engineering.

The Complete Day 4 Flow

The practical sequence becomes:

DAY 3 ORIGIN MODEL
↓
SELECT MAJOR OBJECT / RELATION STRUCTURE
↓
ASK "HAVE WE SOLVED THIS BEFORE?"
↓
SEARCH PATTERN NETWORK
↓
COMPARE NEED + CONTEXT
↓
REVIEW EVIDENCE + MATURITY
↓
IDENTIFY ANTI-PATTERNS
↓
CLASSIFY
REUSE / MODIFY / REPLACE / NEW
↓
RECORD RATIONALE
↓
IDENTIFY GAPS
↓
DAY 4 PATTERN QT

The architecture now contains a map of organizational knowledge.

Why Day 4 Matters

Without Day 4, every new vehicle program risks behaving as though the company has never built a vehicle before.

Teams repeat old design work.

They repeat old failures.

They repeat old tests.

They repeat old supplier mistakes.

The organization has experience, but the experience remains trapped in people and project archives.

Patterns change that.

They convert experience into reusable engineering structure.

Day 4: Identify Automotive Patterns

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

Take the ORIGIN model from Day 3, identify recurring solution structures, search the existing Pattern Network, compare every candidate against the current need and context, preserve evidence and maturity, classify each major area as REUSE, MODIFY, REPLACE, or NEW, expose Anti-Patterns and Pattern gaps, and record the rationale for every important reuse decision.

Day 1 told us why the vehicle should exist.

Day 2 structured what it must achieve.

Day 3 showed what objects and relations may create it.

Day 4 asks:

Which of those structures do we already know how to build well?

The answer separates mature knowledge from genuine uncertainty.

And that means Day 5 can begin turning the remaining uncertainty into focused engineering work rather than treating the entire car as one giant unknown.