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:
MobilitySafetyEnergyWinter OperationServiceabilityLifecycle
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:
VehicleEnergy Storage SystemDrive System
Then ask:
How are they related?
For example:
Vehicle containsEnergy Storage SystemEnergy Storage System supplies energy toDrive 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:
BatteryMotorBrake SystemSteering SystemControllerSensor
Useful.
But it still does not explain the vehicle.
The ORIGIN model adds meaning:
Battery supplies energy toMotorDriver commandsSteering SystemSensor reports toControllerController commandsActuator
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 controlsVehicle
Vehicle transportsPassenger
Energy System suppliesDrive System
Brake System deceleratesVehicle
Thermal System controls temperature ofEnergy System
The architecture becomes visible.
Use Domain Language
Prefer:
Battery supplies energy toDrive Unit
rather than:
Battery relates toDrive Unit
The relation should explain itself.
Good relation names reduce ambiguity.
Keep the Relation Direction Explicit
For example:
Sensor reports toController
is different from:
Controller commandsActuator
Direction matters.
The graph should express it.
Do Not Confuse Containment With Interaction
These are different relations.
For example:
Vehicle containsBrake Controller
is structural.
While:
Brake Controller commandsBrake Actuator
is behavioral or functional.
Use the correct relation.
One Object Can Have Many Relations
For example:
Battery Pack contained inVehicleBattery Pack supplies energy toDrive UnitBattery Pack monitored byBattery ControllerBattery Pack cooled byThermal 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:
BatteryThermal SystemCharge PortSoftwareVehicle 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:
VehicleDriverPassengerBattery PackDrive UnitBrake SystemSteering SystemThermal SystemVehicle ControllerSensorSoftware ModuleSupplierFactoryService 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?
CellsThermal SystemBattery Controller
What depends on it?
Drive SystemCharging SystemVehicle Range
The object quickly becomes connected.
Decompose Objects Only When Needed
Start with:
Battery Pack
Do not immediately model:
CellBusbarModuleFuseContactorCooling 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 containsBattery PackBattery Pack containsBattery ModulesBattery Pack monitored byBattery ControllerBattery Pack cooled byThermal SystemCharge Port transfers energy toBattery 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 onBattery Controller
and:
Battery Control Software interpretsTemperature Sensor
and:
Battery Control Software commandsCooling Pump
Hardware and software remain part of one system.
This Is a Cyber-Physical Domain
Modern vehicles are combinations of:
Mechanical objectsElectrical objectsElectronic objectsSoftware 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 commandsVehicle
Vehicle provides information toDriver
Passenger occupiesVehicle
The human interaction belongs in the domain.
Add External Objects Only Where Useful
For example:
Charging Station supplies energy toVehicle
or:
Service Center maintainsVehicle
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 suppliesBattery 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:
PhysicalSoftwareHumanOrganizationInformation
For example:
Battery PackType:Physical
Battery Control SoftwareType:Software
DriverType:Human
These types help navigation without changing the underlying object concept.
Add Relation Types
Likewise, relation categories may include:
containscontrolssuppliescommunicates withdepends onverifiesmaintainsproduces
The semantics matter more than formal notation.
Use Cardinality Where It Adds Meaning
For example:
Vehicle1contains1Battery Pack
or:
Battery Pack1containsmanyBattery 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:
VehicleBattery Pack
are definitions.
Later we will instantiate:
Vehicle V142Battery 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 containsBattery Pack
Manufacturing later creates:
INSTANCE MODELVehicle V142 containsBattery B77124
This is how design becomes physical traceability.
Connect NDD Nodes to the ORIGIN Model
Suppose:
NDD-WIN-004Maintain Charging Capability in Winter
relates to:
Battery PackThermal SystemCharge PortSoftware
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:
DriverBrake PedalBrake ControllerBrake ActuatorWheel SensorVehicle
The OR model makes this cross-system nature explicit.
One Object Can Support Many Needs
For example:
Vehicle Controller
may support:
DrivingSafetyDiagnosticsEnergy 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 withVehicle 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 withController B
But if the interface needs:
- protocol
- timing
- version
- tests
promote it:
Controller A usesInterface IF-041Interface IF-041 connectsController 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 byThermal 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 SystemCriticality:HIGH
or:
Ambient LightingCriticality: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 controlsVehicleVehicle containsBattery PackVehicle containsDrive UnitVehicle containsBrake SystemBattery Pack supplies energy toDrive UnitCharge Port supplies charging energy toBattery PackThermal System controls temperature ofBattery PackVehicle Controller coordinatesDrive UnitVehicle Controller communicates withBattery ControllerService Center maintainsVehicle
This is already enough to support important architectural discussion.
Connect Objects Back to Need
For example:
Battery Pack↑supportsNDD Energy Need
Brake System↑supportsNDD Safety Need
The graph should never lose upstream meaning.
Identify Missing Objects Through Relation Questions
Take:
Battery Pack supplies energy toDrive 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 withVehicle 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:
HVACWindshieldDefrost 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 objectshould eithersupport 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 ACandidate Architecture B
Pattern and evidence work can decide later.
Separate Current Model From Candidate Models
A model can distinguish:
SELECTEDCANDIDATEREJECTED
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.
