Day 3: Build the ORIGIN Model

Day 1 defined the need.

Day 2 structured that need into the NDD.

Day 3 asks:

What actually exists in the domain, and how are those things related?

This is where ORIGIN begins.

The Day 3 transformation is:

NDD → Objects → Relations → Automotive Domain Model

The NDD tells us why the vehicle exists.

ORIGIN begins telling us what the system contains.

That distinction is fundamental.

Start From the NDD, Not From a Blank Diagram

Suppose the NDD contains:

Mobility
Safety
Energy
Winter Operation
Serviceability
Lifecycle

Do not immediately draw every automotive component you can think of.

Instead, take one need at a time.

For example:

Need:
Store sufficient propulsion energy.

Ask:

What objects must exist for this need to be satisfied?

Possible answer:

Vehicle
Energy Storage System
Drive System

Then ask:

How are they related?

For example:

Vehicle
   contains
Energy Storage System
Energy Storage System
   supplies energy to
Drive System

Now the domain has begun to emerge.

ORIGIN Is About Objects and Relations

The core model is deliberately simple:

Object
+
Relation

An object is something meaningful in the domain.

A relation describes how two objects are connected.

For example:

[Vehicle]

is an object.

[Battery Pack]

is another.

And:

[Vehicle] ──contains──> [Battery Pack]

is the relation.

The Car Is a Network, Not a List

A parts list might contain:

Battery
Motor
Brake System
Steering System
Controller
Sensor

Useful.

But it still does not explain the vehicle.

The ORIGIN model adds meaning:

Battery
   supplies energy to
Motor
Driver
   commands
Steering System
Sensor
   reports to
Controller
Controller
   commands
Actuator

The relations turn the catalogue into a system.

Build Only the First-Level Model First

Day 3 does not require the complete car.

Start with the major objects.

For example:

Vehicle
│
├── Driver
├── Passenger
├── Energy System
├── Drive System
├── Brake System
├── Steering System
├── Body
├── Thermal System
├── Software
└── Service System

This is enough to begin.

Then Add the Main Relations

For example:

Driver
   controls
Vehicle

Vehicle
   transports
Passenger

Energy System
   supplies
Drive System

Brake System
   decelerates
Vehicle

Thermal System
   controls temperature of
Energy System

The architecture becomes visible.

Use Domain Language

Prefer:

Battery
   supplies energy to
Drive Unit

rather than:

Battery
   relates to
Drive Unit

The relation should explain itself.

Good relation names reduce ambiguity.

Keep the Relation Direction Explicit

For example:

Sensor
   reports to
Controller

is different from:

Controller
   commands
Actuator

Direction matters.

The graph should express it.

Do Not Confuse Containment With Interaction

These are different relations.

For example:

Vehicle
   contains
Brake Controller

is structural.

While:

Brake Controller
   commands
Brake Actuator

is behavioral or functional.

Use the correct relation.

One Object Can Have Many Relations

For example:

Battery Pack
   contained in
Vehicle
Battery Pack
   supplies energy to
Drive Unit
Battery Pack
   monitored by
Battery Controller
Battery Pack
   cooled by
Thermal System

This is why the object network becomes richer than a hierarchy.

The NDD Tree and ORIGIN Graph Are Different

The NDD might say:

Winter Operation
↓
Maintain Charging Capability

The ORIGIN model may connect that need to:

Battery
Thermal System
Charge Port
Software
Vehicle Controller

The need remains one node.

The solution domain may involve many objects.

Tree for Why, Graph for What

This remains a useful rule:

NDD
=
Why?

ORIGIN
=
What exists and how is it related?

Day 3 is the transition between them.

Begin With Objects That Have Clear Meaning

Useful top-level automotive objects may include:

Vehicle
Driver
Passenger
Battery Pack
Drive Unit
Brake System
Steering System
Thermal System
Vehicle Controller
Sensor
Software Module
Supplier
Factory
Service Center

Do not create dozens of abstract technical categories without purpose.

Ask Four Questions for Each Object

For every object, ask:

What is it?
Why does it exist?
What does it depend on?
What depends on it?

These questions reveal missing relations.

Example: Battery Pack

What is it?

Energy-storage object.

Why does it exist?

To satisfy vehicle energy needs.

What does it depend on?

Cells
Thermal System
Battery Controller

What depends on it?

Drive System
Charging System
Vehicle Range

The object quickly becomes connected.

Decompose Objects Only When Needed

Start with:

Battery Pack

Do not immediately model:

Cell
Busbar
Module
Fuse
Contactor
Cooling Plate

unless the current questions require that detail.

Day 3 should stay manageable.

Expand One Subsystem as a Worked Example

Suppose we expand the energy domain:

Vehicle
   contains
Battery Pack
Battery Pack
   contains
Battery Modules
Battery Pack
   monitored by
Battery Controller
Battery Pack
   cooled by
Thermal System
Charge Port
   transfers energy to
Battery Pack

Now we have enough structure to reason about charging and thermal behavior.

Add Software Into the Same Model

Do not create a separate conceptual universe for software.

For example:

Battery Control Software
   executes on
Battery Controller

and:

Battery Control Software
   interprets
Temperature Sensor

and:

Battery Control Software
   commands
Cooling Pump

Hardware and software remain part of one system.

This Is a Cyber-Physical Domain

Modern vehicles are combinations of:

Mechanical objects
Electrical objects
Electronic objects
Software objects

ORIGIN does not need to divide them artificially.

They coexist in one object network.

Add the Human Objects Too

The vehicle does not exist independently of people.

For example:

Driver
   commands
Vehicle

Vehicle
   provides information to
Driver

Passenger
   occupies
Vehicle

The human interaction belongs in the domain.

Add External Objects Only Where Useful

For example:

Charging Station
   supplies energy to
Vehicle

or:

Service Center
   maintains
Vehicle

The car is part of a larger ecosystem.

The ORIGIN model can expand beyond the vehicle boundary.

Define the System Boundary Deliberately

Day 3 should decide:

Which objects are inside the current model?

For example:

Current Focus:
Vehicle + Charging + Service

Not necessarily:

Entire global automotive industry

Start with the domain needed for the current decisions.

The Boundary Can Expand Later

A supplier may initially be outside the graph.

Later procurement work may add:

Supplier
   supplies
Battery Cell

That is fine.

The model can grow.

Avoid Modeling Everything Because You Can

The purpose is understanding.

If an object or relation does not help answer the current need, it may not belong yet.

ZenOps should reduce complexity, not create decorative complexity.

Add Object Types

A useful early classification might be:

Physical
Software
Human
Organization
Information

For example:

Battery Pack
Type:
Physical

Battery Control Software
Type:
Software

Driver
Type:
Human

These types help navigation without changing the underlying object concept.

Add Relation Types

Likewise, relation categories may include:

contains
controls
supplies
communicates with
depends on
verifies
maintains
produces

The semantics matter more than formal notation.

Use Cardinality Where It Adds Meaning

For example:

Vehicle
1
contains
1
Battery Pack

or:

Battery Pack
1
contains
many
Battery Modules

Cardinality helps clarify structure.

But do not turn Day 3 into a full data-modeling exercise.

Add Persistent Identity Concepts Early

At the type-model stage:

Vehicle
Battery Pack

are definitions.

Later we will instantiate:

Vehicle V142
Battery B77124

It is useful to keep this distinction visible from the start.

Type Model vs Instance Model

Day 3 primarily builds:

TYPE MODEL

For example:

Vehicle
   contains
Battery Pack

Manufacturing later creates:

INSTANCE MODEL
Vehicle V142
   contains
Battery B77124

This is how design becomes physical traceability.

Connect NDD Nodes to the ORIGIN Model

Suppose:

NDD-WIN-004
Maintain Charging Capability in Winter

relates to:

Battery Pack
Thermal System
Charge Port
Software

Create those links.

The need and solution remain separate, but traceable.

One Need Can Map to Many Objects

For example:

Need:
Safe Braking

may involve:

Driver
Brake Pedal
Brake Controller
Brake Actuator
Wheel Sensor
Vehicle

The OR model makes this cross-system nature explicit.

One Object Can Support Many Needs

For example:

Vehicle Controller

may support:

Driving
Safety
Diagnostics
Energy Management

This is normal.

It shows why the solution network does not mirror the NDD tree.

Requirements Can Wait a Little Longer

Some requirements may already exist.

But Day 3 should still concentrate on structure.

The goal is:

identify what needs to exist before detailing exactly how each thing must perform.

Requirements will become much easier to place once the object model exists.

Identify Interfaces

Look for every important relation that crosses a subsystem boundary.

For example:

Battery Controller
   communicates with
Vehicle Controller

This is an interface.

Interfaces deserve attention because they frequently create failures.

A Relation Can Be More Important Than Either Object

Suppose:

Controller A:
PASS

Controller B:
PASS

but:

A ↔ B Communication:
FAIL

The vehicle still fails.

The OR model keeps the relationship visible.

Promote Important Interfaces to Objects if Necessary

A simple relation may be enough:

Controller A
   communicates with
Controller B

But if the interface needs:

• protocol
• timing
• version
• tests

promote it:

Controller A
   uses
Interface IF-041
Interface IF-041
   connects
Controller B

This gives the interface its own identity.

Do Not Over-Promote Relations

If a relation is simple, keep it simple.

The rule is:

create more structure only when more structure provides useful meaning.

Identify Dependencies

For every critical object:

What must work before this can work?

For example:

Fast Charging
↓
Charge Port
↓
Battery
↓
Thermal System
↓
Software

Dependency paths expose risk.

Draw at Least One Critical Dependency Chain

For example:

Driver requests acceleration
↓
Vehicle Controller
↓
Drive Controller
↓
Inverter
↓
Motor
↓
Wheel Torque

This makes system behavior easier to reason about later.

Identify Feedback Loops

Some systems are loops, not chains.

For example:

Temperature Sensor
↓
Thermal Controller
↓
Cooling Pump
↓
Battery Temperature
↓
Temperature Sensor

This is a control loop.

The ORIGIN model should preserve that cyclic structure.

Patterns Will Become Easier to See

Once the graph exists, repeated structures emerge.

For example:

Sensor
↓
Controller
↓
Actuator

appears repeatedly.

That is a candidate:

Sense → Decide → Act Pattern

Day 3 begins preparing Day 4 Pattern work.

Do Not Force Patterns Yet

Recognize them.

Do not prematurely standardize everything.

Day 3 is still about discovering the domain.

Mark UNKNOWN Relations

Suppose the team knows:

Battery
   cooled by
Thermal System

but does not yet know:

Thermal System
   controlled by
?

Mark:

UNKNOWN

This is valuable.

UNKNOWN Objects Can Exist Too

Perhaps the NDD says:

Need:
Provide redundant steering capability.

but the team has not yet decided which architecture provides it.

Represent:

Redundant Steering Solution:
UNKNOWN

Do not invent an object merely to fill the diagram.

Model Assumptions

For example:

Assumption:
One central vehicle controller coordinates energy management.

That assumption can later be challenged.

The OR model should not disguise architecture hypotheses as certainty.

Add Criticality

For example:

Brake System
Criticality:
HIGH

or:

Ambient Lighting
Criticality:
LOW

This can guide later evidence effort.

Add Ownership Later, Not Meaning

You may note:

Responsible Team:
Battery Engineering

But the object is not defined by its department.

The vehicle domain should survive organizational changes.

Build the Model in OPUS Delivery

The Automotive OR Model Designer can conceptually show:

[Vehicle]
   │ contains
   ▼
[Battery Pack]
   │ cooled by
   ▼
[Thermal System]

The engineer can select an object and inspect its properties.

The Diagram Should Be a View of the Domain Model

Do not create:

Pretty Drawing

with no structured model behind it.

Ideally, drawing:

[Vehicle] ──contains──> [Battery Pack]

creates actual:

Object Definitions
+
Relation Definition

in OPUS Delivery.

The model is the truth.

The drawing is the view.

Start With a Small Graph

A useful Day 3 target might be:

10–30 major objects

with the most important relations.

Not 50,000 nodes.

The model will grow later.

Example Day 3 AURORA Model

A first practical graph might contain:

Driver
   controls
Vehicle
Vehicle
   contains
Battery Pack
Vehicle
   contains
Drive Unit
Vehicle
   contains
Brake System
Battery Pack
   supplies energy to
Drive Unit
Charge Port
   supplies charging energy to
Battery Pack
Thermal System
   controls temperature of
Battery Pack
Vehicle Controller
   coordinates
Drive Unit
Vehicle Controller
   communicates with
Battery Controller
Service Center
   maintains
Vehicle

This is already enough to support important architectural discussion.

Connect Objects Back to Need

For example:

Battery Pack
↑
supports
NDD Energy Need

Brake System
↑
supports
NDD Safety Need

The graph should never lose upstream meaning.

Identify Missing Objects Through Relation Questions

Take:

Battery Pack
   supplies energy to
Drive Unit

Ask:

How is this controlled?

Maybe the graph is missing:

Inverter

Then add it.

Model growth should be question-driven.

Identify Missing Relations Through Object Questions

Take:

Vehicle Controller

Ask:

What does it control?

What reports to it?

This exposes missing edges.

The OR Model Becomes a Thinking Surface

The value is not merely documentation.

Looking at the network should provoke questions:

Why is this object here?

What depends on it?

What happens if it fails?

Which need does it satisfy?

This is active modeling.

Run a First Dependency Review

Pick a critical object:

Battery Controller

Ask:

What happens if this object fails?

Follow the graph.

For example:

Battery Controller
↓
Battery Availability
↓
Drive System
↓
Vehicle Mobility

The OR model begins supporting risk analysis.

Run a First Interface Review

Pick:

Battery Controller
   communicates with
Vehicle Controller

Ask:

What information crosses this relation?
What happens if communication is lost?
Is the relation safety-critical?

These questions prepare later FMEA and StoryQ.

Run a First Need-Coverage Review

Take an NDD branch:

Winter Operation

Ask:

Which objects currently support it?

If nothing maps to:

Maintain Visibility

perhaps the OR model is missing:

HVAC
Windshield
Defrost Control

Need coverage helps reveal incomplete domain structure.

Run the Reverse Review Too

Take an object:

Ambient Light Controller

Ask:

Which accepted need requires this?

If none:

Potential Feature Without Need

This helps expose unnecessary solution complexity.

Do Not Delete Immediately

The need may simply be missing.

Investigate first.

The purpose is traceability, not automatic rejection.

Object Creation Should Follow a Reason

A useful rule:

Every major object
should either
support a need,
enable another required object,
or satisfy a constraint.

This keeps architecture intentional.

Day 3 Can Generate New NDD Insights

While modeling, the team may discover:

We never defined diagnostic capability as a need.

Then return to Day 2 and add:

Serviceability
↓
Detect and Isolate Faults

This is not backtracking.

It is iteration.

ZenOps Is Not Strictly Linear

The practical loop is:

NDD
↔
ORIGIN

Each can improve the other.

The days describe focus, not rigid isolation.

Day 3 Can Expose Architectural Alternatives

Suppose the need could be satisfied by:

One Central Controller

or:

Distributed Controllers

Do not force one immediately.

Represent alternatives where useful.

For example:

Candidate Architecture A
Candidate Architecture B

Pattern and evidence work can decide later.

Separate Current Model From Candidate Models

A model can distinguish:

SELECTED
CANDIDATE
REJECTED

This preserves architectural reasoning.

Avoid Treating the First Graph as Truth

Day 3 is still exploratory.

The graph is:

Current Best Model

not:

Final Architecture

That distinction matters.

Preserve Rationale for Important Choices

If the team chooses:

Central Vehicle Controller

instead of another architecture, record why.

Later evidence may challenge the choice.

Day 3 ORIGIN QT

A useful threshold might be:

DAY 3 ORIGIN QT
[ ] Major NDD needs have candidate domain objects
[ ] Primary vehicle objects identified
[ ] Critical relations explicitly named
[ ] Major interfaces visible
[ ] Hardware and software represented together
[ ] Important external objects included where needed
[ ] Major UNKNOWNs visible
[ ] Need-to-object links established
[ ] No obvious solution object without rationale

If satisfied:

DAY 3 ORIGIN QT:
PASS

The domain model is mature enough for Pattern work.

PASS Does Not Mean the Model Is Complete

It means:

The major structure is explicit enough to begin systematic reuse, requirements refinement, and engineering work.

The graph will continue evolving.

What Not to Do on Day 3

Do not try to:

• model every bolt
• finalize the BOM
• design every ECU interface
• write every requirement
• complete the factory model

The objective is not completeness.

It is structural clarity.

Day 3 Output

A strong Day 3 produces:

Automotive OR Model
+
Major Objects
+
Named Relations
+
Need Links
+
Interfaces
+
Dependencies
+
UNKNOWNs

That is enough.

The Complete Day 3 Flow

The day can be summarized:

DAY 2 NDD
↓
SELECT ONE NEED BRANCH
↓
IDENTIFY DOMAIN OBJECTS
↓
CONNECT OBJECTS WITH NAMED RELATIONS
↓
EXPAND CRITICAL SUBSYSTEMS
↓
ADD HARDWARE + SOFTWARE + HUMANS
↓
IDENTIFY INTERFACES
↓
MAP NEEDS TO OBJECTS
↓
MARK UNKNOWNs
↓
REVIEW DEPENDENCIES
↓
DAY 3 ORIGIN QT

Why Day 3 Changes the Program

Before ORIGIN, the program is mainly a hierarchy of needs.

After ORIGIN, the team can see the emerging system.

They can point to:

this object

and ask:

What does it depend on?

They can point to:

this relation

and ask:

How do we know it will work?

Those questions will drive Patterns, requirements, StoryQ, FMEA, work, and evidence.

Day 3: Build the ORIGIN Model

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

Take the structured NDD from Day 2, identify the major domain objects required to satisfy it, connect those objects with explicit named relations, model hardware and software as one cyber-physical system, expose important interfaces and dependencies, link every major object back to the needs it serves, and keep unresolved architectural questions visible as UNKNOWN rather than disguising guesses as structure.

Day 1 answered:

Why should the vehicle exist?

Day 2 answered:

What needs must it satisfy?

Day 3 begins answering:

What exists in the system, and how must those things relate for the vehicle to work?

Once that network is visible, the next practical step is powerful:

identify which parts of the network have already been solved before.

That is where the Pattern Network begins.