Conceptual vs Logical vs Physical Architecture — Comparison Table
📊 Core Comparison Table
| Dimension | Conceptual Architecture | Logical Architecture | Physical Architecture |
|---|---|---|---|
| Primary Purpose | Define intent and meaning of the system | Define structure and behavior of the system | Define deployment and realization |
| Key Question Answered | What & Why | How (design) | Where & With what |
| Level of Abstraction | Very high | Medium | Low (concrete) |
| Technology Dependency | None | Technology-neutral | Technology & vendor-specific |
| Focus | Business capabilities & domain concepts | Components, services, data flows | Infrastructure, network, runtime |
| Audience | Business stakeholders, product owners | Solution architects, lead engineers | DevOps, infra, operations |
| Stability Over Time | Very stable | Moderately stable | Changes frequently |
| Typical Artifacts | Capability maps, domain diagrams | Component diagrams, API contracts | Deployment diagrams, IaC |
| Contains Hardware Details | ❌ No | ❌ No | ✅ Yes |
| Contains Software Components | High-level only | Detailed | Mapped to infra |
| Performance / HA Details | ❌ No | Conceptual only | ✅ Yes |
| Security Definition | Policy intent | Logical boundaries & roles | Firewalls, IAM, NSGs |
| Cost Visibility | ❌ No | Approximate | ✅ Accurate |
| Failure Impact | Business-level | Service-level | Node / pod / VM-level |
🧠 Same System — Viewed at 3 Levels
| Layer | Example Statement |
|---|---|
| Conceptual | “Collect machine data and provide operational insights.” |
| Logical | “PLC adapters publish events to a broker; analytics consumes streams.” |
| Physical | “Jetson → MQTT → Kafka on AKS → Azure Data Explorer.” |
Domain Mapping Table
| Domain | Conceptual | Logical | Physical |
|---|---|---|---|
| Software | User stories, capabilities | Microservices, APIs | Containers, VMs |
| Database | Business entities | Tables & relations | Storage engine, disks |
| Cloud | Scalable platform | Event-driven design | Regions, clusters |
| IIoT | Digital factory | Asset twins, pipelines | Edge gateways, GPUs |
| Security | Zero-trust intent | Auth flows, RBAC | Firewalls, IAM rules |
🔁 Change Impact Matrix
| Change Type | Conceptual | Logical | Physical |
|---|---|---|---|
| Switch cloud provider | ❌ | ❌ | ✅ |
| Change data model | ❌ | ✅ | ✅ |
| Add GPU acceleration | ❌ | ❌ | ✅ |
| Change business goal | ✅ | ✅ | ✅ |
⚠️ Common Industry Errors (Quick Check)
| Mistake | Why It’s Wrong |
|---|---|
| Kafka in conceptual diagram | Tech belongs to physical/logical |
| VM size in logical architecture | Infra detail = physical |
| Skipping conceptual layer | Leads to wrong system design |
📝 One-Line Exam Definitions
- Conceptual Architecture: Defines what the system is and why it exists.
- Logical Architecture: Defines how the system is structured and behaves.
- Physical Architecture: Defines where and with what the system is implemented.
Detailed Overview
Difference between Conceptual, Logical, and Physical Architecture
This is a core abstraction principle used everywhere: software design, databases, cloud, IoT, digital twins, PLM, enterprise architecture, and even ISA-95.
Think of it as three zoom levels of the same system.
1️⃣ Conceptual Architecture — The “What & Why”
🔹 What it is
- High-level mental model
- Describes what the system does, why it exists, and who uses it
- No technology, no protocols, no servers
🔹 Key questions answered
- What problem are we solving?
- Who are the actors?
- What are the major capabilities?
- How do parts conceptually interact?
🔹 Characteristics
- Technology-agnostic
- Business / domain-focused
- Stable over time
- Communicates vision
🔹 Example (simple)
“We need a system that collects machine data, analyzes performance, and shows insights to operators.”
🔹 Conceptual blocks
[ Machines ] → [ Data Collection ] → [ Analysis ] → [ Insights ]
🔹 Used by
- Architects
- Product owners
- Business stakeholders
- Early design discussions
2️⃣ Logical Architecture — The “How (Design)”
🔹 What it is
- Structured design of components
- Defines functions, services, data flows, and interfaces
- Still independent of hardware or vendors
🔹 Key questions answered
- How will the system work internally?
- What components exist?
- How do components communicate?
- What data models are used?
🔹 Characteristics
- Technology-neutral (but technical)
- Shows dependencies & responsibilities
- Blueprint for implementation
🔹 Example
[ PLC Adapter ] → [ Message Broker ] → [ Stream Processor ]
↓
[ Time-Series DB ]
↓
[ Analytics Engine ]
↓
[ Dashboard Service ]
🔹 What appears here
- Microservices
- APIs
- Event flows
- Data schemas
- Security boundaries (logical)
🔹 Used by
- Solution architects
- System designers
- Lead engineers
3️⃣ Physical Architecture — The “Where & With What”
🔹 What it is
- Concrete deployment model
- Maps logical components to real infrastructure
🔹 Key questions answered
- Where does it run?
- Which servers, cloud services, networks?
- How is it deployed and scaled?
- How is high availability achieved?
🔹 Characteristics
- Technology-specific
- Vendor-specific
- Environment-specific (edge, cloud, on-prem)
- Changes more often
🔹 Example
Edge:
Jetson Nano → MQTT → 5G
Cloud:
AKS Cluster
- Ingestion Pods
- Kafka
- Flink
- ADX
- Grafana
Storage:
Azure Blob (Private Endpoint)
🔹 Includes
- VM sizes
- Kubernetes clusters
- GPUs
- Subnets
- Firewalls
- Regions & zones
🔹 Used by
- DevOps
- Infra teams
- Cloud architects
- Operations
🔁 Relationship Between the Three (Golden Rule)
Conceptual → Logical → Physical
WHAT HOW WHERE
- One conceptual architecture
- Many logical designs
- Multiple physical deployments
🧠 Very Important
🏠 Building a House
| Layer | Meaning |
|---|---|
| Conceptual | “I want a house with 3 bedrooms and good ventilation” |
| Logical | Floor plan, room layout, plumbing design |
| Physical | Concrete, bricks, steel, electrical wiring |
Changing paint color = physical
Changing room layout = logical
Changing purpose (home → hospital) = conceptual
🧩 Example Across Domains
📦 Database
| Layer | Example |
|---|---|
| Conceptual | Customer places orders |
| Logical | Tables, relationships, keys |
| Physical | MySQL on SSD, indexes, sharding |
☁️ Cloud
| Layer | Example |
|---|---|
| Conceptual | Scalable analytics platform |
| Logical | Event-driven microservices |
| Physical | AWS EKS / Azure AKS / GCP GKE |
🏭 IIoT / Digital Twin (Your domain)
| Layer | Example |
|---|---|
| Conceptual | Digital representation of factory |
| Logical | Asset twins, telemetry, simulations |
| Physical | Edge gateways, GPUs, cloud regions |
⚠️ Common Mistakes (Very Common in Industry)
❌ Mixing layers
“Kafka cluster is part of conceptual architecture”
❌ Jumping directly to physical
“Which GPU should we buy?” before defining logic
❌ Over-engineering logical layer
Logical ≠ vendor diagram
🧪 Sequence View (Flow Across Layers)
[Business Goal]
↓
[Conceptual Model]
↓
[Logical Components & Data Flow]
↓
[Physical Deployment & Infra]
↓
[Runtime Operations]
📄 One-Page Cheat Sheet
| Aspect | Conceptual | Logical | Physical |
|---|---|---|---|
| Focus | Meaning | Design | Deployment |
| Answers | What / Why | How | Where |
| Technology | None | Neutral | Specific |
| Audience | Business | Architects | Ops |
| Stability | Very high | Medium | Low |
| Examples | Capabilities | Services | Servers |
Mapping Conceptual / Logical / Physical Architecture to ISA-95 & Industry 4.0
🔷 ONE DIAGRAM — ALL LAYERS, ALL FLOWS
(Textual / ASCII version — blog-safe + redraw-ready)
┌────────────────────────────────────────────────────────────┐
│ BUSINESS & STRATEGY │
│ ERP | Finance | Supply Chain | Sales | Planning │
│ (Orders, Cost, Forecast, KPIs) │
│ ──────────────── ISA-95 LEVEL 4 ──────────────── │
└───────────────▲───────────────────────────────┬───────────┘
│ │
│ Business Context │
│ │
┌───────────────┴───────────────────────────────▼───────────┐
│ MANUFACTURING OPERATIONS │
│ MES | MOM | Quality | Maintenance | Scheduling │
│ (Work Orders, Production Rules, Recipes) │
│ ──────────────── ISA-95 LEVEL 3 ──────────────── │
│ │
│ ◉ Digital Twin (Process + Asset + KPI Twin) │
│ ◉ Contextualization & State Management │
└───────────────▲───────────────────────────────┬───────────┘
│ │
│ Operational Commands │
│ │
┌───────────────┴───────────────────────────────▼───────────┐
│ CONTROL & SUPERVISION │
│ SCADA | HMI | Batch Control | Line Control │
│ (Setpoints, Alarms, Supervisory Logic) │
│ ──────────────── ISA-95 LEVEL 2 ──────────────── │
│ │
│ ◉ Real-time Operational Twin │
│ ◉ Event & Alarm Intelligence │
└───────────────▲───────────────────────────────┬───────────┘
│ │
│ Signals / Telemetry │
│ │
┌───────────────┴───────────────────────────────▼───────────┐
│ SENSING & ACTUATION │
│ PLC | CNC | Robots | Drives | Sensors │
│ (Temperature, Speed, Pressure, Vibration) │
│ ──────────────── ISA-95 LEVEL 1 / 0 ──────────────── │
│ │
│ ◉ Physical Asset Twin │
│ ◉ Edge Intelligence │
└─────────────────────────────────────────────────────────────┘
══════════════════════════════════════════════════════════════
CROSS-CUTTING (VERTICAL) CAPABILITIES
══════════════════════════════════════════════════════════════
• IoT Platform (MQTT, OPC UA, Kafka, Event Streaming)
• Data Pipeline & Historian
• AI / ML (Predictive, Prescriptive, Optimization)
• PLM (Product, Recipe, Process Models)
• Security, Governance, Identity
• Cloud / Edge / Hybrid Deployment
1️⃣ Big Picture: How They Intersect
Abstraction (WHY → HOW → WHERE)
──────────────────────────────▶
ISA-95 L4 ┆ Conceptual ┆ Logical ┆ Physical
ISA-95 L3 ┆ Conceptual ┆ Logical ┆ Physical
ISA-95 L2 ┆ Conceptual ┆ Logical ┆ Physical
ISA-95 L1 ┆ Conceptual ┆ Logical ┆ Physical
ISA-95 L0 ┆ Conceptual ┆ Logical ┆ Physical
Key insight:
ISA-95 defines WHAT level of operations,
Architecture layers define HOW deeply you describe it.
2️⃣ Core Mapping Table (Most Important)
🔹 Conceptual vs Logical vs Physical × ISA-95
| ISA-95 Level | Conceptual Architecture (WHAT / WHY) | Logical Architecture (HOW – design) | Physical Architecture (WHERE – deployment) |
|---|---|---|---|
| Level 4 – Business Planning | Demand planning, ERP intent, supply chain goals | Order mgmt services, planning workflows | SAP S/4HANA, Oracle ERP Cloud |
| Level 3 – Manufacturing Ops (MES) | Production execution, quality, maintenance concepts | MES modules, workflows, APIs | MES servers, AKS/EKS clusters |
| Level 2 – Supervisory Control | Monitoring & coordination intent | SCADA services, alarm mgmt logic | SCADA servers, HMIs |
| Level 1 – Control | Control strategies | PLC programs, control logic | PLC hardware, RTUs |
| Level 0 – Process | Physical process intent | Sensor models, actuation logic | Sensors, motors, robots |
3️⃣ Industry 4.0 View (Digital Thread)
Industry 4.0 introduces:
- Cyber-Physical Systems (CPS)
- Digital Twins
- AI/ML
- Edge + Cloud continuum
Mapping Table
| Industry 4.0 Concept | Conceptual | Logical | Physical |
|---|---|---|---|
| Digital Twin | Virtual representation of assets | Twin models, telemetry bindings | ADT / Twin platform, GPUs |
| IIoT Platform | Unified data backbone | Ingestion, streaming, storage | Edge gateways, cloud services |
| AI / Analytics | Predictive & prescriptive goals | Feature pipelines, ML services | GPUs, ML runtimes |
| Interoperability | Vendor-neutral vision | OPC UA, MQTT schemas | Brokers, endpoints |
| Automation | Autonomous factory | Closed-loop logic | Robots, PLCs |
4️⃣ Example: One Use Case Across All Layers
Use case: Predictive Maintenance
Conceptual (ISA-95 L3/L4)
“Prevent unplanned downtime and optimize maintenance schedules.”
Logical
Sensors → Stream Processor → Feature Store
↓
ML Inference Service
↓
Maintenance Work Orders
Physical
Level 0–1: Vibration sensors, PLCs
Level 2: SCADA + OPC UA
Level 3: AKS + Kafka + ML
Level 4: ERP integration
5️⃣ Why This Mapping Matters (Real Industry Pain)
❌ Common mistake
Putting Kafka, GPUs, AKS directly into ISA-95 diagrams
✅ Correct approach
- ISA-95 = Operational responsibility
- Conceptual/Logical/Physical = Design discipline
6️⃣ Architecture Decision Flow (Sequence View)
Business Goal
↓
ISA-95 Level Identification
↓
Conceptual Definition (WHAT)
↓
Logical Design (HOW)
↓
Physical Deployment (WHERE)
7️⃣ Exam + Interview One-Liners
- ISA-95 answers “Which operational layer?”
- Conceptual architecture answers “What capability?”
- Logical architecture answers “How is it designed?”
- Physical architecture answers “Where is it deployed?”
8️⃣ One-Page Cheat Sheet
| Axis | Purpose |
|---|---|
| ISA-95 | Functional responsibility |
| Conceptual | Business meaning |
| Logical | System design |
| Physical | Infrastructure reality |
Bottom Line (Architect-level clarity)
ISA-95 defines the factory hierarchy.
Conceptual, Logical, and Physical architectures define how clearly and correctly you design each level.
Overlaying Digital Twin + PLM on ISA-95 using Conceptual / Logical / Physical Architecture
1️⃣ Mental Model (Very Important)
PLM ──▶ Digital Twin ──▶ MES / SCADA / PLC
▲ │
└────────────── Feedback ◀────────┘
- PLM = Design truth
- Digital Twin = Living system model
- ISA-95 = Operational execution
Architecture layers control clarity, ISA-95 controls responsibility.
2️⃣ Master Overlay Table (Core Answer)
Digital Twin + PLM × ISA-95 × Architecture Layers
| ISA-95 Level | Conceptual (WHAT / WHY) | Logical (HOW – design) | Physical (WHERE – deployed) |
|---|---|---|---|
| L4 – Business / PLM / ERP | Product intent, BOM, lifecycle, compliance | PLM services, product structures, change mgmt workflows | PLM system, ERP system |
| L3 – Manufacturing Ops (MES) | How product is built & maintained | Process plans, routings, work instructions | MES apps, orchestration clusters |
| L2 – Supervisory (SCADA) | Operational visibility | State models, alarms, KPIs | SCADA servers, HMIs |
| L1 – Control | Control strategies | PLC logic, recipes | PLCs, controllers |
| L0 – Physical Process | Physical behavior | Physics & constraints | Machines, sensors, robots |
3️⃣ Where PLM Lives vs Digital Twin
Clear separation (often misunderstood)
| Capability | PLM | Digital Twin |
|---|---|---|
| Product definition | ✅ Primary | ❌ |
| As-designed BOM | ✅ | ❌ |
| As-built / As-operated | ❌ | ✅ |
| Real-time telemetry | ❌ | ✅ |
| Physics simulation | Partial | ✅ |
| Closed-loop feedback | ❌ | ✅ |
Key rule
PLM is static truth, Digital Twin is dynamic truth.
4️⃣ Digital Twin Overlay by Architecture Layer
🔹 Conceptual Layer
- “A virtual representation of assets and processes across lifecycle”
- Supports:
- Design → Manufacture → Operate → Maintain
Conceptual Digital Thread
PLM → Manufacturing → Operations → Feedback → PLM
🔹 Logical Layer (This is where architects work)
PLM (BOM, CAD, Specs)
↓
Asset Model / Twin Model
↓
Telemetry + State + Events
↓
Analytics / Physics / AI
↓
Insights → MES / ERP / PLM
Logical constructs:
- Asset hierarchy
- Twin types
- Relationships (part-of, connected-to)
- State machines
- Simulation bindings
🔹 Physical Layer (Execution reality)
Edge:
Sensors, PLCs, Robots
Platform:
Twin runtime
Stream processing
Simulation engines
ML inference
Enterprise:
PLM system
MES system
ERP system
5️⃣ Mapping to Industry 4.0 Pillars
| Industry 4.0 Pillar | PLM Role | Digital Twin Role |
|---|---|---|
| Interoperability | Product standards | Live system integration |
| Information transparency | As-designed data | Real-time truth |
| Technical assistance | Documentation | Predictive insights |
| Decentralized decisions | ❌ | Autonomous decisions |
6️⃣ Example Walkthrough (Predictive Maintenance)
Step-by-step across layers
Conceptual
“Reduce downtime by predicting failures.”
Logical
PLM: Design limits
DT: Real-time vibration + thermal
AI: Degradation model
MES: Maintenance scheduling
Physical
Sensors → Edge Gateway → Twin Platform → MES → ERP
Feedback loop:
Failure pattern → PLM design improvement
7️⃣ Common Industry Mistakes (Reality Check)
❌ Treating PLM as a Digital Twin
❌ Storing live telemetry inside PLM
❌ Skipping logical modeling and jumping to tools
❌ Mixing ISA-95 levels with architecture layers
✅ Correct view:
- ISA-95 = where responsibility sits
- Architecture layers = how clearly you design
- PLM + Digital Twin = digital continuity
8️⃣ One-Page Cheat Sheet (Exam + Interview)
| Term | Meaning |
|---|---|
| PLM | Lifecycle design authority |
| Digital Twin | Live operational mirror |
| ISA-95 | Operational hierarchy |
| Conceptual | Business & lifecycle intent |
| Logical | Models, flows, relationships |
| Physical | Systems, hardware, infra |
Bottom Line (Architect-level statement)
PLM defines what should exist,
Digital Twin shows what actually exists,
ISA-95 defines where it operates,
and Conceptual–Logical–Physical architecture ensures it is designed correctly.
Closed-Loop Control with Physics-Based AI
(Digital Twin + PLM + ISA-95 + Conceptual → Logical → Physical)
🧠 HOW TO READ THIS DIAGRAM
- Vertical axis → ISA-95 levels (L0–L4)
- Horizontal flow → Closed-loop control
- Three lenses overlaid:
- Conceptual = WHY / WHAT
- Logical = HOW (models, flows)
- Physical = WHERE (deployment)
┌─────────────────────────────────────────────────────────────────────────────┐
│ L4 – PLM / ERP (Business) │
│ │
│ CONCEPTUAL: Product intent, limits, lifecycle │
│ LOGICAL: Design models, BOM, change mgmt │
│ PHYSICAL: PLM / ERP systems │
│ │
│ ▲────────────── Learning / Feedback ────────────────┐ │
└──────────────┼────────────────────────────────────────────────────┼─────────┘
│ │
│ │
┌──────────────┼────────────────────────────────────────────────────┼─────────┐
│ L3 – MES / Operations │
│ │
│ CONCEPTUAL: Optimize production, maintenance, energy │
│ LOGICAL: Workflows, optimization goals, constraints │
│ PHYSICAL: MES services, orchestration platforms │
│ │
│ │ Optimization Targets / Policies │
│ ▼ │
└──────────────┼────────────────────────────────────────────────────┼─────────┘
│ │
│ │
┌──────────────┼────────────────────────────────────────────────────┼─────────┐
│ DIGITAL TWIN + PHYSICS-AI CORE (L2–L3) │
│ │
│ CONCEPTUAL: Living virtual representation │
│ │
│ LOGICAL: │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ Twin State │ → │ Physics │ → │ AI Residual │ │
│ │ Estimation │ │ Model │ │ / ML Model │ │
│ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │
│ │ │ │ │
│ └─────────────── Combined Prediction ──┘ │
│ │ │
│ ▼ │
│ ┌──────────────────┐ │
│ │ Controller │ │
│ │ (MPC / Hybrid) │ │
│ └────────┬─────────┘ │
│ │
│ PHYSICAL: Edge server / GPU / real-time runtime │
└──────────────┼────────────────────────────────────────────────────┼─────────┘
│ │
│ Control Commands │
▼ │
┌──────────────┼────────────────────────────────────────────────────┼─────────┐
│ L1 – Control │
│ │
│ CONCEPTUAL: Safe & stable control │
│ LOGICAL: Control logic, recipes │
│ PHYSICAL: PLCs / Controllers │
│ │
│ │ Actuation │
│ ▼ │
└──────────────┼────────────────────────────────────────────────────┼─────────┘
│ │
│ │
┌──────────────┼────────────────────────────────────────────────────┼─────────┐
│ L0 – Physical Process │
│ │
│ CONCEPTUAL: Real-world physics │
│ LOGICAL: State variables │
│ PHYSICAL: Machines, sensors, robots │
│ │
│ │ Telemetry │
│ └───────────────▶─────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────────────────┘
🔑 WHAT THIS SUPER-DIAGRAM CAPTURES (WHY IT’S POWERFUL)
✔ Closed-Loop Control
- Sensors → Twin → Physics → AI → Controller → Actuators → Sensors
✔ Physics-Based AI
- Physics model = governing laws
- AI model = residual / uncertainty correction
- Controller = safe decision making
✔ Digital Thread
- PLM (as-designed)
- Digital Twin (as-operated)
- Feedback to PLM (as-learned)
✔ ISA-95 Alignment
- Fast loops: L0–L2 (edge)
- Optimization: L3
- Learning & redesign: L4
🧪 ONE-LINER
This diagram shows how physics-based AI enables safe closed-loop control by embedding digital twins between ISA-95 operational layers, while maintaining architectural separation across conceptual, logical, and physical views.
Definitions & Comparisons
-
Conceptual, Logical, Physical Data Models — ThoughtSpot
Explains high-level meaning, structure, and implementation levels of data models. Conceptual vs Logical vs Physical Data Models (ThoughtSpot) -
Logical vs Physical Architecture (general IT comparison)
Defines logical vs physical with purpose and differences. Logical Architecture vs Physical Architecture (Simplicable) -
Conceptual, Logical, Physical Data Modeling — SQLDBM
Short clear summary of all three model types in data design. Conceptual, Logical, Physical Data Modeling (SQLDBM) -
Logical vs Physical Architecture — .NET Architecture Guide (Microsoft)
Describes logical architecture components and how they relate to physical deployment. Logical vs Physical Architecture (Microsoft) -
Data Models Explanation — Couchbase
Good breakdown of how conceptual → logical → physical models build on each other. Data Modeling Explained (Couchbase)
↪️ Additional Context or Framework Support
-
Integrated Architecture Framework (IAF)
Enterprise architecture framework that uses conceptual, logical, and physical viewpoints. Integrated Architecture Framework (Wikipedia) -
Enterprise Architecture Overview (Wikipedia)
General EA context where multiple abstraction layers are organized logically/physically. Enterprise Architecture (Wikipedia) -
Data Architecture Description (Wikipedia)
Shows how conceptual/logical/physical stages appear in data architecture modeling. Data Architecture (Wikipedia)
Last updated: June 8, 2026.
Frequently asked questions
What is the difference between conceptual, logical, and physical architecture?
A conceptual architecture describes what the system does and its major capabilities in business terms, with no technology choices. A logical architecture refines that into components, interfaces, and data flows independent of any specific product. A physical architecture binds those components to concrete technologies, servers, and deployment topology. Each level adds detail and constraints while staying traceable to the level above it.
Which architecture view should you create first?
Start with the conceptual view so stakeholders agree on scope and capabilities before any technology debate. Move to the logical view once the capabilities are stable, then to the physical view only when you are ready to commit to platforms. Working top-down keeps decisions traceable and prevents premature technology lock-in.
Is logical architecture the same as a software design?
No. Logical architecture defines components, responsibilities, and interfaces at a system level and stays implementation-neutral. Detailed software design specifies classes, modules, and algorithms inside those components. The logical view sets the boundaries that the detailed design fills in.
Do you always need all three architecture levels?
Not always. Small projects may collapse conceptual and logical into one document, while large, regulated, or multi-team systems benefit from keeping all three distinct for traceability and governance. The deciding factor is how many stakeholders must align and how long the system must be maintained.
