Recursive MBSE Architecture Weave Pattern

A machine-readable and executable MBSE pattern demonstrating recursive requirements decomposition across four levels (L0-L3) with three abstraction layers (blackbox/graybox/whitebox) at each level. The pattern establishes clear mechanics for requirements duality (original vs. derived), needs allocation via budget attributes, and satisfaction closure through constraint binding and verification.

Pattern Structure

The recursive pattern is implemented in four levels:

• L0 (Operational) — Root operational context; establishes stakeholder concerns and assumptions
• L1 (System of Interest) — Transforms operational needs into system-level requirements; allocates to two subsystems
• L2 (Subsystems) — Subsystem1 further decomposes to components (Subsystem2 is terminal)
• L3 (Components) — Atomic leaf requirements; terminal decomposition

Each level follows the same pattern:

• *_Requirements.sysml — Original requirement (bb) → Derived requirement (gb) with budget allocation and nested child needs
• *_Configuration.sysml — Realizes requirements across abstraction layers; action bindings define quality contributions
• *_Behavior.sysml — Behavioral actions that produce quality values for blackbox context
• *_StakeholdersViews.sysml — Stakeholder concerns, assumptions, and frames

Model as Source of Truth

The pattern structure, constraint flow, and design rationale are embedded directly in the SysML model:

• Requirements naming convention — {requirement} (original/bb) vs {requirement}Derived (derived/gb)
• Subject redefinition chain — Each level narrows focus: operationalContext → systemOfInterest → payloadBuilder → component
• Budget allocation — Named attributes with design decision rationales embedded as SysML comments
• Constraint inheritance — Original requirements inherit constraints via subsetting; redundant hardcoding eliminated
• Nested child needs — Decomposition bridge; constraints reference budget attributes (not hardcoded values)

To understand the pattern, explore the model files directly. AI tools and engineers alike will find the structure self-explanatory through consistent L0-L3 repetition and explicit model semantics.

Recommended Modeling Sequence

Use the pattern in this order to maximize decision value and minimize rework:

1. Define behavior at graybox (_gb) level first.
2. Execute analysis cases at graybox (_gb) level to calibrate assumptions and attributes.
3. Refine connectivity after behavior and analysis assumptions are stable.
4. Verify integrated behavior at whitebox (_wb) level when available.

Default policy:

• Prefer analysis on _gb subjects.
• Use analysis on _bb subjects only by explicit exception when rich local dynamics or alternatives are modeled.
• In this reference pattern, L3 analysis cases are intentionally omitted; L2 Subsystem2 is the documented _bb exception showcase.

Validation

Validate the entire pattern (syntax and semantic consistency):

PowerShell -ExecutionPolicy RemoteSigned -File ../scripts/syside.ps1 check RecursiveArchitecturePattern

Expected result: Exit code 0 (all levels compile cleanly; all interconnections verified)

Pattern Highlights

✅ Machine-readable — Syside validates syntax and semantics
✅ Executable — Constraints and attribute bindings enforce requirements
✅ Traceable — Design decisions documented in model comments
✅ DRY — No redundant hardcoded values; subsetting handles inheritance
✅ Interchange-safe — Comments are part of the model; survive XMI/JSON export
✅ Scalable — Pattern repeats uniformly L0-L3; extends to arbitrary levels

File Organization

RecursiveArchitecturePattern/
├── Level 0 - Operational/
│   ├── Operational_Requirements.sysml
│   ├── Operational_Configuration.sysml
│   ├── Operational_Behavior.sysml
│   ├── Operational_Taxonomy.sysml
│   ├── Operational_StakeholdersViews.sysml
│   └── VerificationCases_Operational.sysml
├── Level 1 - SystemOfInterest/
│   ├── SystemOfInterest_Requirements.sysml
│   ├── SystemOfInterest_Configuration.sysml
│   ├── SystemOfInterest_Behavior.sysml
│   ├── SystemOfInterest_StakeholdersAndConcerns.sysml
│   └── VerificationCases_SystemOfInterest.sysml
├── Level 2 - Subsystems/
│   ├── Subsystem1_Requirements.sysml
│   ├── Subsystem1_Configuration.sysml
│   ├── Subsystem1_Behavior.sysml
│   ├── Subsystem2_Requirements.sysml
│   ├── Subsystem2_Configuration.sysml
│   ├── StakeholdersAndConcerns_Subsystem1.sysml
│   └── VerificationCases_Subsystems.sysml
├── Level 3 - Components/
│   ├── Component1_1_Requirements.sysml
│   ├── Component1_1_Configuration.sysml
│   ├── Component1_2_Requirements.sysml
│   ├── Component1_2_Configuration.sysml
│   └── VerificationCases_Components.sysml
├── Credits/
│   └── Credits.sysml
└── README.md (this file)

Next Steps

To learn the pattern:

1. Start with Level 0 - Operational/Operational_Requirements.sysml — the root pattern
2. Follow the recursion to L1, L2, L3 — observe consistent structure at each level
3. Examine budget attributes and their rationale comments
4. Trace constraint inheritance via subsetting
5. Run validation to confirm pattern integrity

The model itself is the documentation.

Reference Baseline

To use this pattern as a reusable reference profile:

• Verification Reference Baseline
• Verification Benchmark Matrix