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.