Architecture Cockpit

Executive Takeaway

The architecture cockpit presents a working system/security allocation for the Electric Clutch Actuator ECU. It is strong enough for proposal review and planning, but not final baseline approval because customer decisions remain open for diagnostics, update, PKI, secure communication, TARA, and responsibility ownership.

Confirmed items are tied to Markdown-derived requirements.
Inferred allocations remain explicitly marked by confidence and open-decision fields.
Customer confirmation is required before shared security responsibilities become committed scope.

1. System Snapshot

System NameElectric Clutch Actuator (ECA) Control ECU - TRATON GW AMT Gearbox PlatformWorking

Vehicle ContextTRATON GW Automated Manual Transmission (AMT) Gearbox PlatformConfirmed

System TypeSafety-related drivetrain actuator ECU with integrated power-electronics actuation, carrying an automotive cybersecurity engineering scope (ISO/SAE 21434-style concept and TARA input).Inferred

Requirement Count1790Confirmed

Feature Count3Confirmed

Interface Count10Confirmed

Security Capability Count13Confirmed

P1 Decision Count6Open

Traceability GateWARN - Customer Clarification NeededWARN

Customer ReadinessReady for customer clarification workshopWorkshop

OCR StatusfalseConfirmed

PDF Downstream AnalysisfalseConfirmed

2. Product Identity

This table is horizontally scrollable. Use the bottom scrollbar to view all columns.

Item	Value	Confidence	Evidence
Working system name	Electric Clutch Actuator (ECA) Control ECU - TRATON GW AMT Gearbox Platform	Medium	source document
Vehicle platform context	TRATON GW Automated Manual Transmission (AMT) Gearbox Platform	High	source document page 3-4
Main controlled function	CAN/PWM-commanded clutch engagement and disengagement	High	source document
ECU involvement	ECA ECU application, boot/update and security services	High	source document
Cybersecurity scope	Diagnostics, update, key/certificate, secure communication and evidence lifecycle	Medium	source document

3. One-Screen Architecture

Architecture Cockpit Overview

flowchart LR subgraph Vehicle["Vehicle / drivetrain domain"] Drivetrain["GW AMT drivetrain"] Network["Vehicle network (CAN / PWM)"] end subgraph ECA["ECA ECU domain"] App["Clutch actuation application"] Sec["Security services"] Boot["Bootloader / update logic"] end subgraph Diagnostic["Diagnostic / service domain"] Tester["Diagnostic tester"] end subgraph OEM["OEM backend / security operations domain"] Backend["Update and evidence backend"] PKI["Key and certificate provisioning"] SecOps["Security operations"] end subgraph Supplier["Supplier engineering domain"] Engineering["Supplier ALM / CI / evidence"] end Drivetrain --> Network Network <-->|commands, status, freshness| App Tester -->|authenticated UDS| Sec Backend -->|signed software / IVD| Boot PKI -->|trust material| Sec Boot --> App Sec --> App App -->|events| SecOps Engineering -->|software and evidence| Backend

Mermaid source

flowchart LR
  subgraph Vehicle["Vehicle / drivetrain domain"]
    Drivetrain["GW AMT drivetrain"]
    Network["Vehicle network (CAN / PWM)"]
  end
  subgraph ECA["ECA ECU domain"]
    App["Clutch actuation application"]
    Sec["Security services"]
    Boot["Bootloader / update logic"]
  end
  subgraph Diagnostic["Diagnostic / service domain"]
    Tester["Diagnostic tester"]
  end
  subgraph OEM["OEM backend / security operations domain"]
    Backend["Update and evidence backend"]
    PKI["Key and certificate provisioning"]
    SecOps["Security operations"]
  end
  subgraph Supplier["Supplier engineering domain"]
    Engineering["Supplier ALM / CI / evidence"]
  end
  Drivetrain --> Network
  Network <-->|commands, status, freshness| App
  Tester -->|authenticated UDS| Sec
  Backend -->|signed software / IVD| Boot
  PKI -->|trust material| Sec
  Boot --> App
  Sec --> App
  App -->|events| SecOps
  Engineering -->|software and evidence| Backend

Vehicle Domain

GW AMT drivetrain, CAN/PWM command path, actuator status and faults.

ECA ECU Domain

Application software, boot/update logic, diagnostics and security services.

Diagnostic Domain

UDS tester, authenticated service sessions, programming and audit path.

OEM Backend Domain

Update, PKI, security operations, approval and residual-risk workflow.

Supplier Engineering Domain

ALM, CI/test, software release, traceability and evidence package.

4. Main System Capabilities

This table is horizontally scrollable. Use the bottom scrollbar to view all columns.

Capability	Purpose	Main Interfaces	Security Relevance	Status
Clutch Actuation Control	Core actuator control	Vehicle Network Interface (CAN)	Safety-relevant command/status handling	Confirmed
Vehicle Integration and CAN Communication	Vehicle command/status exchange	Vehicle Network Interface (CAN), PWM wake-up	Message authenticity/freshness allocation	Confirmed
Secure Diagnostics and Role-Based Access	Controlled service and engineering access	Diagnostic Tester Interface	Privileged access control	Inferred
Secure Software Update and Flash	Maintain trusted ECU software	Update / Flash Interface, Diagnostic Tester Interface	Software authenticity and integrity	Inferred
Key and Certificate Handling	Trust-material lifecycle	PKI / Provisioning Interface	Root of trust for diagnostics, update and secure communication	Inferred
Secure Data Transfer / Communication Boundary	Protected security-relevant data exchange	Vehicle Network Interface, Secure Data Transfer Interface	Authenticity, integrity and freshness	Inferred
Security Logging and Event Handling	Security evidence and response input	Logging / Event Reporting Interface	Auditability and incident support	Inferred
Cybersecurity Lifecycle and Evidence	Approval-ready security case	Supplier Evidence, OEM Approval Interface	Traceable residual-risk argument	Confirmed

5. Interfaces and Trust Boundaries

This table is horizontally scrollable. Use the bottom scrollbar to view all columns.

Interface	Connected Parties	Data / Control Flow	Trust Boundary	Protection Needed	Status
Vehicle Network Interface (CAN)	Transmission control / vehicle ECUs -> ECA application software	CAN demand, PWM wake-up, actuator status and DTCs	Vehicle network to ECU	Signal validation, freshness, authenticity where allocated	Requires Confirmation
Diagnostic Tester Interface	Service / engineering tester -> ECA diagnostic server	UDS requests, Auth 0x29, sessions and programming	External service tool to ECU	Authentication, authorization, lockout, rate limiting and audit	Requires Confirmation
Software Update / Flash Interface	Programming tool or update backend -> Bootloader / update logic	Signed packages, IVD data and programming results	Offboard update source to ECU	Signature validation, integrity checks, rollback control and logging	Requires Confirmation
Key and Certificate Provisioning Interface	PKI / provisioning authority -> ECA security services	Keys, certificates and trust anchors	Trust authority to ECU	Protected storage, certificate validation and lifecycle control	Requires Confirmation
Secure Data Transfer Interface	Vehicle network peers -> ECA security/application services	SecOC/SDT protected messages, counters and MACs	ECU-to-ECU data boundary	Freshness, replay protection, MAC verification and discard rules	Requires Confirmation
Security Logging / Event Reporting Interface	ECA ECU -> Backend / security operations	Security events, diagnostic attempts and update results	ECU to offboard operations	Event integrity, retention, access control and privacy treatment	Requires Confirmation
Supplier Development / Evidence Interface	Supplier ALM / CI / test environment -> Evidence repository and release process	Requirements, tests, builds, traceability and release artifacts	Engineering environment to evidence baseline	Access control, artifact integrity and audit trail	Requires Confirmation
OEM Approval / Evidence Interface	Supplier security engineering -> TRATON / OEM review board	Cybersecurity concept, V&V evidence, risks and decisions	Supplier to OEM governance boundary	Controlled evidence handoff and decision logging	Requires Confirmation

6. Security Capability Map

This table is horizontally scrollable. Use the bottom scrollbar to view all columns.

Security Capability	Protects	Applied To	Evidence Strength	Open Decision
Secure Diagnostics and RBAC	Diagnostic access state and privileged services	Diagnostic Tester Interface / Diagnostic Server	Strong	Confirm final role model and service list
Secure Software Update	ECU software and firmware authenticity	Bootloader / Update Logic	Strong	Confirm signing chain, rollback and campaign ownership
Data Authenticity and Integrity Verification	Security-relevant vehicle data	Vehicle Network / Secure Data Transfer Interface	Moderate	Confirm protected signal allocation
Key and Certificate Handling	Keys, certificates and trust anchors	Security Services / Hardware Platform / PKI	Strong	Confirm HSM capability and PKI ownership
Communication Boundary Control	Vehicle and offboard interface boundaries	External Interfaces / Security Services	Moderate	Confirm exact boundaries and failure policy
Security Logging	Security event evidence	Logging / Event Reporting Interface	Moderate	Confirm event set and reporting channel
Vulnerability and Incident Handling	Field security posture	Security Operations / Compliance Process	Strong	Confirm reporting channels and responsibilities
Cybersecurity Evidence and DIA	Approval and residual-risk case	Engineering Toolchain / OEM Approval Interface	Strong	Confirm DIA split and authority

7. Requirement Evidence Coverage

Total Requirements1790Markdown-derived baseline

Security Requirements166Cybersecurity category

Architecture Drivers1127Architecture mapping rows

Interface-Related Requirements74Interface category

Assumptions1Tracked, not confirmed

Clarifications472Customer decision queue

This table is horizontally scrollable. Use the bottom scrollbar to view all columns.

Coverage Item	Count	Interpretation
Total Requirements	1790	Markdown-derived baseline
Security Requirements	166	Cybersecurity category
Architecture Drivers	1127	Architecture mapping rows
Interface-Related Requirements	74	Interface category
Assumptions	1	Tracked, not confirmed
Clarifications	472	Customer decision queue

7.1 Supplier System Requirement Coverage

Customer Requirements1789total

Active Requirements1790in baseline

Derived Supplier System Requirements73many-to-many

Customer Requirements Mapped to SSRs698derivable mapped

Unmapped Active Requirements0derivable gap

Blocked by Clarification238open

Derivation Coverage %100.0%of derivable

This table is horizontally scrollable. Use the bottom scrollbar to view all columns.

Coverage Item	Count	Interpretation
Customer Requirements	1789	total
Active Requirements	1790	in baseline
Derived Supplier System Requirements	73	many-to-many
Customer Requirements Mapped to SSRs	698	derivable mapped
Unmapped Active Requirements	0	derivable gap
Blocked by Clarification	238	open
Derivation Coverage %	100.0%	of derivable

8. Open Decisions

This table is horizontally scrollable. Use the bottom scrollbar to view all columns.

Decision	Priority	Question	Area	Owner
CQ-BOUNDARY-03	P1	Confirm the customer decision needed to baseline this requirement item: Term Definition Shall This word, or the term "Required", means that the definition is an absolute requirement of the specification. Threat Analysis and Risk Assessment A structured approach to identify possible threats and evaluate risks with respect to the potential damages and the effort needed for successful attack. Cybersecurity concept A cybersecurity concept is a work product that documents cybersecurity relevant aspects of the product. The cybersecurity concept shall describe the scope of the risk analysis, risks that were identified during the risk analysis, cybe rsecurity goals, cybersecurity requirements, mitigation strategies, validation, and verification strategies, etc. Table 1: Definition of terms. This affects product/system boundary scope, supplier positioning, and traceability status.	System boundary / item definition	Joint
CQ-BOUNDARY-05	P1	Confirm the customer decision needed to baseline this requirement item: Note: The vehicle manufacturer and supplier shall collaboratively define the context of the system or function to enable the supplier performing the risk assessment.. This affects product/system boundary scope, supplier positioning, and traceability status.	System boundary / item definition	Joint
CQ-BOUNDARY-127	P1	Confirm the customer decision needed to baseline this requirement item: Table 1 – Definition of Terms Term Definition Shall This word, or the terms "Required" or "Must", means that the definition is an absolute requirement of the specification. Shall not This phrase, or the phrase "Must not", means that the definition is an absolute prohibition of the specification. Should This word, or the adjective “Recommended”, means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications shall be understood and carefully weighed before choosing a different course. Should not This phrase, or the phrase “Not recommended”, means that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. May This word, or the adjective “Optional”, means that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option shall be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option shall be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides).. This affects product/system boundary scope, supplier positioning, and traceability status.	System boundary / item definition	Joint
CQ-BOUNDARY-158	P1	Confirm the customer decision needed to baseline this requirement item: Byte Description Range Resolu tion This byte shall be set to value 2 and is used to identify the response structure variant #9 Occurrence counter OCC, as described in section 5.7.2 [unsigned integer] 0..127 0 M #10 DTC priority 1 – Highest priority 2 - Second highest priority 3 – Lowest priority 255 – Unknown 1..3, 255 0xFF M #11..#16 Time/Date of the first DTC activation See Table 98 but without byte #7 and #8 M #17..#22 Time/Date of the latest DTC activation M #23..#26 ECU Operational hours at the first DTC activation [4-byte int, big endian] as described in section 5.7.5.2.. This affects product/system boundary scope, supplier positioning, and traceability status.	System boundary / item definition	Joint
CQ-BOUNDARY-199	P1	Confirm the customer decision needed to baseline this requirement item: The server shall have support for the ASN.1 contents as defined: DataSecurityContainer ::= SEQUENCE { version OCTET STRING (SIZE(2)), id OCTET STRING (SIZE(16)), verificationEntries SEQUENCE (SIZE(0..MAX)) OF VerificationEntry, encryptionEntries SEQUENCE (SIZE(0..MAX)) OF EncryptionEntry, itemEntries SEQUENCE (SIZE(0..MAX)) OF ItemEntry } VerificationEntry ::= CHOICE { hashCmp [0] EXPLICIT HashCmp }. This affects product/system boundary scope, supplier positioning, and traceability status.	System boundary / item definition	Joint
CQ-BOUNDARY-201	P1	Confirm the binding diagnostic behavior and service authorization expected for this item: The purpose of this document is to clarify vehicle manufacture specific extensions and exceptions to the Authentication 0x29 service specified in ISO 14229-1:2020. CVS150 Cryptographic Specification CVS32 SecuredDataTransmis sion 0x84 CVS151 RBAC CVS33 Entity Management Protocol (EMP) CVS31 Authenticate 0x29 CVS124 Traton Specification on Unified diagnostic services (UDS) CVS30 X.509 Specification CVS34 EMP – Basic Entities Figure 1 – Overview of relation between specifications The following documents are normative and indispensable for the application of this document: • Traton Specification on Unified diagnostic Services (UDS) requirements (CVS124) • ISO 14229-1:2020, Road vehicles — Unified diagnostic services (UDS) — Part 1: Specification and requirements Whenever a requirement in this specification or the Traton Specification on Unified diagnostic Services (UDS) requirements (CVS124) is non-compliant with one or more requirements in ISO 14229-1:2020 the requirements in this specification and (CVS124) take precedence. Any deviations from this specification shall be documented and must be reviewed by the vehicle manufacturer. It is the vehicle manufacturer that decides if a deviation can be accepted or not. Multiple security concepts are available in the Authentication (ISO 14229-1:2020) service, however, only APCE (ISO 14229-1:2020) is supported by the concept described in this document, see Figure 2.. This affects UDS service allocation, security-access roles, safe-state checks, and verification scope.	System boundary / item definition	Joint
CQ-BACKEND-02	P2	Confirm whether this software-update/bootloader item is binding for the ECA ECU baseline or informative guidance: It should be possible to reuse the generic bootloader for future currently unknown purposes/applications without a need to create a new part number for the platform.. This affects bootloader/update design scope, diagnostic programming behavior, verification evidence, and supplier effort estimation.	Backend and IT Systems / Security Operations	Joint

9. Review Navigation

Review Board Summary System Overview Architecture Security Architecture Traceability Dashboard Customer Workshop

Architecture cockpit evidence markdown

1. System Snapshot

Metric	Value	Status
System Name	Electric Clutch Actuator (ECA) Control ECU - TRATON GW AMT Gearbox Platform	Working interpretation
Vehicle Context	TRATON GW Automated Manual Transmission (AMT) Gearbox Platform	Confirmed function context
System Type	Safety-related drivetrain actuator ECU with integrated power-electronics actuation, carrying an automotive cybersecurity engineering scope (ISO/SAE 21434-style concept and TARA input).	Inferred security scope
Requirement Count	1790	Markdown-derived
Feature Count	3	Generated from requirement clusters
Interface Count	10	Generated from interface model
Security Capability Count	13	Generated from security model
P1 Decision Count	6	Open customer decisions
Traceability Gate	WARN - Customer Clarification Needed	Do not force PASS while decisions are open
Customer Readiness	Ready for customer clarification workshop	Workshop-ready
OCR Status	false	Must remain false
PDF Downstream Analysis	false	Markdown-derived only

2. Product Identity

Item	Value	Confidence	Evidence
Working system name	Electric Clutch Actuator (ECA) Control ECU - TRATON GW AMT Gearbox Platform	Medium	source document; function wording in cleaned Markdown
Vehicle platform context	TRATON GW Automated Manual Transmission (AMT) Gearbox Platform	High	source document page 3-4and source document
Main controlled function	CAN/PWM-commanded clutch engagement and disengagement	High	RFQX-1001379436-P10-000-01-0002; RFQX-1001379436-P10-000-01-0058; RFQX-3299216-1-0002; RFQX-3299216-1-0003; RFQX-3299216-1-0004; RFQX-3299216-1-0005; RFQX-3299216-1-0006; RFQX-3299216-1-0007 (sample: 8 of 162)
ECU involvement	ECA has its own embedded ECU/control scope	High	RFQX-1001379436-P10-000-01-0001; RFQX-1001379436-P10-000-01-0002; RFQX-1001379436-P10-000-01-0003; RFQX-1001379436-P10-000-01-0004; RFQX-1001379436-P10-000-01-0005; RFQX-1001379436-P10-000-01-0006; RFQX-1001379436-P10-000-01-0007; RFQX-1001379436-P10-000-01-0008 (sample: 8 of 337)
Cybersecurity scope	Diagnostics, update/flash, key/certificate, secure communication, evidence and residual-risk workflow	Medium	RFQX-1001379436-P10-000-01-0001; RFQX-1001379436-P10-000-01-0003; RFQX-1001379436-P10-000-01-0005; RFQX-1001379436-P10-000-01-0006; RFQX-1001379436-P10-000-01-0007; RFQX-1001379436-P10-000-01-0008; RFQX-1001379436-P10-000-01-0012; RFQX-1001379436-P10-000-01-0013 (sample: 8 of 166)

3. One-Screen Architecture

Diagram source: generated RFQX evidence.

Conclusion: the review baseline is an ECA ECU security architecture with vehicle, diagnostic, OEM/backend and supplier engineering boundaries kept explicit.

4. Main System Capabilities

Capability	Purpose	Main Interfaces	Security Relevance	Status
Clutch Actuation Control	Core actuator control	Vehicle Network Interface (CAN)	Safety-relevant command/status handling	Confirmed
Vehicle Integration and CAN Communication	Vehicle command/status exchange	Vehicle Network Interface (CAN), PWM wake-up	Message authenticity/freshness allocation	Confirmed
Secure Diagnostics and Role-Based Access	Controlled service and engineering access	Diagnostic Tester Interface	Privileged access control	Inferred
Secure Software Update and Flash	Maintain trusted ECU software	Update / Flash Interface, Diagnostic Tester Interface	Software authenticity and integrity	Inferred
Key and Certificate Handling	Trust-material lifecycle	PKI / Provisioning Interface	Root of trust for diagnostics, update and secure communication	Inferred
Secure Data Transfer / Communication Boundary	Protected security-relevant data exchange	Vehicle Network Interface, Secure Data Transfer Interface	Authenticity, integrity and freshness	Inferred
Security Logging and Event Handling	Security evidence and response input	Logging / Event Reporting Interface	Auditability and incident support	Inferred
Cybersecurity Lifecycle and Evidence	Approval-ready security case	Supplier Evidence, OEM Approval Interface	Traceable residual-risk argument	Confirmed

5. Interfaces and Trust Boundaries

Interface	Connected Parties	Data / Control Flow	Trust Boundary	Protection Needed	Status
Vehicle Network Interface (CAN)	Transmission control / vehicle ECUs -> ECA application software	CAN demand, PWM wake-up, actuator status and DTCs	Vehicle network to ECU	Signal validation, freshness, authenticity where allocated	Requires Confirmation
Diagnostic Tester Interface	Service / engineering tester -> ECA diagnostic server	UDS requests, Auth 0x29, sessions and programming	External service tool to ECU	Authentication, authorization, lockout, rate limiting and audit	Requires Confirmation
Software Update / Flash Interface	Programming tool or update backend -> Bootloader / update logic	Signed packages, IVD data and programming results	Offboard update source to ECU	Signature validation, integrity checks, rollback control and logging	Requires Confirmation
Key and Certificate Provisioning Interface	PKI / provisioning authority -> ECA security services	Keys, certificates and trust anchors	Trust authority to ECU	Protected storage, certificate validation and lifecycle control	Requires Confirmation
Secure Data Transfer Interface	Vehicle network peers -> ECA security/application services	SecOC/SDT protected messages, counters and MACs	ECU-to-ECU data boundary	Freshness, replay protection, MAC verification and discard rules	Requires Confirmation
Security Logging / Event Reporting Interface	ECA ECU -> Backend / security operations	Security events, diagnostic attempts and update results	ECU to offboard operations	Event integrity, retention, access control and privacy treatment	Requires Confirmation
Supplier Development / Evidence Interface	Supplier ALM / CI / test environment -> Evidence repository and release process	Requirements, tests, builds, traceability and release artifacts	Engineering environment to evidence baseline	Access control, artifact integrity and audit trail	Requires Confirmation
OEM Approval / Evidence Interface	Supplier security engineering -> TRATON / OEM review board	Cybersecurity concept, V&V evidence, risks and decisions	Supplier to OEM governance boundary	Controlled evidence handoff and decision logging	Requires Confirmation

6. Security Capability Map

Security Capability	Protects	Applied To	Evidence Strength	Open Decision
Secure Diagnostics and RBAC	Diagnostic access state and privileged services	Diagnostic Tester Interface / Diagnostic Server	Strong	Confirm final role model and service list
Secure Software Update	ECU software and firmware authenticity	Bootloader / Update Logic	Strong	Confirm signing chain, rollback and campaign ownership
Data Authenticity and Integrity Verification	Security-relevant vehicle data	Vehicle Network / Secure Data Transfer Interface	Moderate	Confirm protected signal allocation
Key and Certificate Handling	Keys, certificates and trust anchors	Security Services / Hardware Platform / PKI	Strong	Confirm HSM capability and PKI ownership
Communication Boundary Control	Vehicle and offboard interface boundaries	External Interfaces / Security Services	Moderate	Confirm exact boundaries and failure policy
Security Logging	Security event evidence	Logging / Event Reporting Interface	Moderate	Confirm event set and reporting channel
Vulnerability and Incident Handling	Field security posture	Security Operations / Compliance Process	Strong	Confirm reporting channels and responsibilities
Cybersecurity Evidence and DIA	Approval and residual-risk case	Engineering Toolchain / OEM Approval Interface	Strong	Confirm DIA split and authority

7. Requirement Evidence Coverage

Coverage Item	Count	Interpretation
Total Requirements	1790	Markdown-derived extracted baseline
Security Requirements	166	Security-relevant requirement class
Architecture Drivers	1127	Mapped architecture rows
Interface-Related Requirements	74	Interface category
Assumptions	24	Tracked, not treated as confirmed
Clarifications	472	Customer-decision queue

8. Open Decisions

Decision	Priority	Area	Impact	Owner
CQ-BOUNDARY-03	P1	System boundary / item definition	Blocks architecture baseline	Joint
CQ-BOUNDARY-05	P1	System boundary / item definition	Blocks architecture baseline	Joint
CQ-BOUNDARY-127	P1	System boundary / item definition	Blocks architecture baseline	Joint
CQ-BOUNDARY-158	P1	System boundary / item definition	Blocks architecture baseline	Joint
CQ-BOUNDARY-199	P1	System boundary / item definition	Blocks architecture baseline	Joint
CQ-BOUNDARY-201	P1	System boundary / item definition	Blocks architecture baseline	Joint
CQ-BACKEND-02	P2	Backend and IT Systems / Security Operations	Blocks implementation planning	Joint

View	Use
Architecture Cockpit	Board-level architecture/security summary
System Overview	Concise product and security definition
High-Level Architecture	Component and flow diagrams
Security Architecture Map	Security controls, assets and attack surfaces
Traceability Dashboard	Coverage and gap summary
Review Board Summary	Management review one-screen summary