MBSE Recursive Architecture Wave Pattern

The MBSE Recursive Architecture Wave Pattern (RAWP) is a SysML v2 reference model for requirements-driven behavioral modeling with recursive decomposition. It is machine-readable, structurally executable where current SysML v2 tooling supports execution, and intended for reuse as a practical MBSE project baseline.

Overview

The pattern combines:

• Recursive requirement decomposition across model levels.
• Structural allocation using explicit budget attributes.
• Behavioral realization via action execution and value propagation.
• Verification cases bound to integrated model contexts.
• Layered interface/stack-port modeling for interaction semantics.

How to Read and Use RAWP

RAWP intentionally combines two kinds of content:

• Normative pattern content defines the reusable relationships and invariants that make the recursion work.
• Illustrative reference content instantiates those rules with a fictitious payload example and synthetic values so practitioners can understand the complete information flow.

The example demonstrates correct application of the pattern; it does not prove the fitness of a real system. Synthetic analysis values, model-computed results, and reference-mode verification records are explicitly ineligible for project acceptance. A project creates eligible evidence by tailoring the example, justifying its targets and parameters, retaining reproducible analysis results, and implementing acceptance criteria appropriate to the real system.

In this sense, RAWP reduces dependence on a separately interpreted method by encoding the method's recurring structure and guardrails in the model. It does not replace the engineering judgment needed to tailor and substantiate a real design.

Pattern Architecture

Decomposition Levels

Framework Level

Framework provides reusable definitions for all decomposition levels:

• Common semantics and reusable types.
• Layered stack-port/interface definitions.
• Cross-level modeling conventions.
• Verification intent categories.

Standards Encoding and Use

Standards are modeled as machine-readable contractual constraint overlays in the framework standard package. A standard defines its normative constraints once and groups them into requirements that apply to parts in scope.

When a contract, regulation, or policy makes a standard applicable, the responsible SEIT constrains the system blackbox by subsetting MyStandard::myStandardConstrainedPart. This attaches the complete standard obligation and an inherited satisfaction claim without copying clauses or values into operational concerns or local requirements. Subsetting means "governed by this standard"; it does not mean "compliance has already been demonstrated."

Responsibility is deliberately separated:

• The operational SEIT frames operationalComplianceWithMyStandard in each provider need, rebinding the concern to that operational constituent. An L0 inspection verifies that this contractual handoff is present.
• Each provider's system SEIT transforms its inherited need into a system-level requirement. The framed concern communicates the contractual binding without copying MyStandard's clauses or normative values.
• The system SEIT analyzes the inherited blackbox obligation at graybox, derives internal realization requirements for its constituents, and retains traceability to the original standard requirement.
• The original boundary obligation is not divided or copied into every constituent. Internal derived requirements are design decisions that collectively realize it. A constituent subsets myStandardConstrainedPart only when it is independently within the contractual scope.
• In this reference model, the system SEIT verifies compliance by analyzing the executable integrated system whitebox. A terminal or supplier-owned blackbox is analyzed at its highest available boundary. A realized product may reuse the same verification intent through a separate test or demonstration case.

The fictitious MyStandard illustrates this route. Its normative qualityGain constraint is bound to each governed system's realized qualityContribution. For the System of Interest, the existing graybox payload-quality decomposition provides the constituent realization needs for a stronger operational target; the inherited MyStandard boundary obligation remains separately intact and is analyzed on systemOfInterest_wb. The InteractingSystem illustrates the terminal-provider variant by transforming its L0 need and retaining a boundary-analysis case at interactingSystem_bb. Syntax validation checks the attachment structure; constraint evaluation and verification determine whether the inherited satisfaction claim is supported.

Development Roles and Requirements Traceability

RAWP uses the INCOSE development-team names appropriate to each modeled level:

These stakeholder usages do not own requirements, configurations, or evidence. They hold requirements-traceability concerns. At each level, a corresponding viewpoint frames the local concern, and a requirements-traceability view exposes the received need, transformed and derived requirements, contextual architecture satisfaction, and verification relationships.

The framework provides reusable frameworkRequirementsTraceability, RequirementsTraceability, and RequirementsTraceabilityView definitions. Each modeled L0–L3 branch specializes that chain for its SEIT, PIT, or PDT stakeholder.

How to Read a Requirements-Traceability View

Each requirements-traceability view makes one recursive handoff visible in textual SysML:

stakeholder → concern → viewpoint → view → received need → transformed requirement → derived requirement → contextual satisfaction → verification

Read the exposed elements as follows:

1. The received need is the child requirement handed down by the parent architecture level.
2. The transformed requirement subsets that need and establishes the local blackbox obligation.
3. A derived requirement, when the element is decomposed, subsets the transformed requirement and records the analyzed constituent allocation.
4. The named satisfy requirement usage contextualizes the requirement on the applicable _bb, _gb, or _wb architecture subject.
5. The verification case contains the verify relationship to that contextual satisfaction claim.

The view does not create substitute trace links. The existing subsets, satisfy, and verify relationships remain the authoritative semantics. Exposing both ends of an unnamed subsetting relationship makes the relationship discoverable in the textual view without adding a redundant dependency. Rendering tools may choose how to present those semantics, but RAWP does not encode tool-specific visualization workarounds in the reference model.

COTS Library Encoding and Use

COTS products are modeled as reusable library packages in the framework COTS library package. Each product package contains its exchange items, ports, interfaces, product part definition, integration connector category, and supplier evidence attributes. Project architectures use these definitions by selecting and integrating the COTS boundary as a terminal supplier-owned element, rather than decomposing it as internally designed structure.

Abstraction Views per Level

Naming pattern:

• Original requirement: payloadQualityGain{Level}
• Derived requirement: payloadQualityGain{Level}Derived

Attribute Placement and Immutable Values

RAWP separates the abstraction where an attribute becomes visible from the abstraction where its value becomes justified:

The placement rule is:

Declare a feature where the concept first becomes visible. Assign its value once, where the source of that value first becomes known and justified.

A selected parent-graybox allocation becomes a normative need at the child blackbox boundary. It is not automatically evidence of the child's realized capability. A decomposed child declares its design-dependent capability at _bb and commits it after its own _gb analysis. A terminal child commits an independent illustrative supplier or design seed at its terminal _bb.

Design iteration does not reassign an immutable feature in a more detailed abstraction. It creates another analysis scenario or alternative and, once a decision is selected, a controlled revision of the committed value.

Recommended Modeling Sequence

Use this sequence to minimize rework and keep decisions evidence-based:

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

Default policy:

• Prefer analysis on _gb.
• Use analysis on _bb only by explicit exception.
• In this pattern, L3 analysis cases are intentionally omitted; L2 Subsystem2 is the explicit _bb exception.

Analysis Aspect

Analysis is a first-class part of the pattern and is used to derive and calibrate decomposition decisions before interface hardening and final verification.

Primary analysis intent:

• Calibrate budget attributes and allocation splits.
• Produce selected allocation outputs that derived requirements bind to.
• Test sensitivity to assumption changes.
• Evaluate degradation and boundary scenarios.
• Compare alternatives and trade-offs before structural lock-in.

Modeling policy for analysis:

• Prefer analysis at graybox (_gb) where constituent behavior is visible.
• Use blackbox (_bb) analysis only when explicitly justified by uncertainty, alternatives, or context constraints.
• Keep analysis focused on decision support, not on duplicating verification cases.
• Use analysis cases as the model-side interface to external analysis tools: declare inputs, capture returned outputs, and record provenance metadata.

Expected analysis outcomes:

• Analysis-derived allocation values and assumptions bound into derived requirements.
• Clear rationale for requirement decomposition choices.
• Better confidence before refining connectors/ports and running integrated verification.

Analysis placement by level:

• L0, L1, and L2 can host analysis cases where decomposition decisions are active.
• L3 analysis can be intentionally omitted for leaf-level reference branches.

Core Recursive Mechanism

1. Requirement Decomposition

Pattern characteristics:

• Derived requirement subsets parent requirement.
• Subject is redefined from _bb context to decomposed (_gb) context.
• Budget attributes bind to selected allocation outputs from analysis cases.
• Child requirements represent allocated needs for next-level constituents.
• Assumption gates control whether frame/require obligations are evaluated.

2. Allocation Closure and Realized Quality

RAWP deliberately separates allocated capability from realized contribution:

• Derived requirements bind budget attributes to selected analysis outputs.
• Requirement constraints check that constituent allocations close against the parent target.
• A decomposed blackbox declares its capability input without assigning it.
• Its graybox commits the design seed selected with decomposition knowledge.
• A terminal blackbox may commit an independent supplier or component-design seed because no deeper abstraction exists.
• Behavior computes the realized qualityContribution; derived requirements do not rebind that realized result to their budget sum.

This preserves two related but distinct flows:

normative target -> graybox analysis -> selected allocation -> child need

blackbox declaration -> graybox design commitment -> behavioral transformation
                     -> realized contribution -> whitebox observation

3. Configuration Realization

• Blackbox part satisfies the original requirement.
• Graybox part subsets blackbox and introduces constituents.
• Whitebox part (when present) integrates interfaces/ports/flows.
• Satisfaction links connect each requirement to the realization context.
• When a whitebox exists, it redefines the same named satisfaction feature so the satisfaction claim remains continuous from graybox to whitebox context.

4. Behavioral Realization

• Blackbox parts bind qualityContribution to action outputs.
• Action execution computes quality values used by requirement evaluation.
• Reference scenarios use model-computed illustrative results; real projects shall replace or independently justify their seeds and evidence.

5. Verification Realization

• Verification objective targets the local satisfy usage on the selected subject, not the external requirement definition directly.
• Verification subject is _wb when available, otherwise _gb/_bb for terminal branches.
• Stimulus is routed to actions that execute behavior, avoiding empty shells.
• Reusable verification definitions return an inconclusive verdict in reference mode and classify their evidence as illustrative and project-ineligible.
• A real project must provide evidence-adequacy rules and acceptance logic before a verification can report pass or fail.

Layered Stack Port Pattern

The framework defines a layered stack-port model (MyStackPort) and the SoI applies it through explicit directional flows.

Key usage rules:

• Choose one connector-facing abstraction layer per connector usage.
• Keep flow declarations direction-compatible with selected nested ports.
• Use conjugation intentionally where consumer-facing orientation requires inversion.
• Avoid accidental mixed-layer declarations unless explicitly intended.

Design Principles

1. Requirement duality: each requirement is both a child need from parent perspective and a requirement at its own level.
2. Action-output traceability: quality values come from executable behavior bindings.
3. Explicit allocation: budget attributes are model values, not hidden assumptions.
4. Allocation closure: derived requirements constrain budget sums against their parent targets.
5. Assumption gating: frame and require clauses are evaluated only when assumptions hold.
6. Design/environment separation: designed elements are behavior-driven; external elements can remain blackbox defaults.

Cross-Level Consistency Rules

Maintain consistency through:

• Subject chain integrity from parent level to child level.
• Action subsetting integrity from parent action to child actions.
• Requirement satisfaction chain integrity from original to derived and onward.
• Verification objective integrity from selected subject to its local satisfy usage.

Project Adoption and Tailoring Checklist

RAWP is a reference pattern, not evidence that a particular system is fit for purpose. Its payload example and numerical values are synthetic: they make the pattern concrete, traceable, and understandable, but they are not empirical evidence and shall not be reused as project evidence without independent justification.

When adopting RAWP for a real project, preserve the recursive relationships and replace or justify the illustrative content below.

Project scope and terminology

• Replace the payload-domain terminology with the project's domain concepts.
• Define the operational boundary, System of Interest, interacting systems, decomposition levels, and terminal branches.
• Tailor the ontology, taxonomy, stakeholder roles, concerns, viewpoints, and lifecycle scope.
• Decide which branches are internally designed, externally supplied, COTS, or intentionally retained as blackboxes.
• Identify the applicable SEIT, PIT, and PDT stakeholders and tailor their requirements-traceability concerns, viewpoints, and views without assigning model-element ownership to the stakeholder usages.

Requirements and allocation

• Replace illustrative stakeholder thresholds and requirement values with approved project targets.
• Establish the provenance and rationale for every normative target.
• Replace example allocation values with outputs from project-specific engineering analysis and decisions.
• Check allocation closure at every decomposition boundary and document any margin, reserve, overlap, or non-additive contribution.
• Preserve the subject-redefinition and child-need handoff chain across decomposition levels.
• Tailor assumption gates, frame clauses, and required constraints to the project's operational conditions.

Architecture and behavior

• Replace illustrative parts, actions, items, ports, interfaces, and connectors with the project's architecture.
• Bind capability-setting inputs to justified design parameters rather than retaining RAWP example seeds.
• For decomposed parts, declare design-dependent inputs at _bb and assign them only at _gb after analysis makes the value available.
• For terminal parts, replace illustrative _bb seeds with independent supplier, component-design, contractual, or observed knowledge.
• Keep scenario assumptions and perturbations in analysis usages rather than assigning them as intrinsic values of canonical configurations.
• Implement the behavioral transformations that produce the project's computed results.
• Confirm that graybox behavior represents the intended decomposition and that whitebox connectivity realizes it.
• Tailor COTS boundaries and supplier evidence to the selected products and their actual interface-control documentation.

Analysis and provenance

• Replace all synthetic scenarios, sensitivities, degradation factors, trade-study weights, and selected outputs.
• Identify the analysis method, tool, version, model or script, assumptions, input dataset, execution identifier, timestamp, and retained result artifact.
• Classify values consistently as normative targets, executable seeds, computed results, or observed evidence.
• Confirm that analysis outputs used by requirements are genuine selected project decisions rather than unchanged reference values.
• Retain reproducible analysis artifacts under the project's configuration and change control.

Verification and evidence

• Replace reference-mode inconclusive verdict logic with project-specific acceptance criteria.
• Select verification methods appropriate to each claim, such as analysis, inspection, demonstration, or test.
• Define nominal, boundary, degraded, and failure scenarios required by the project's assurance strategy.
• Bind verification cases to the highest appropriate integrated subject and its contextual satisfy usage.
• Record observed evidence independently from requirement targets, capability seeds, and predicted results.
• Define evidence adequacy, repeatability, uncertainty, independence, and pass/fail/inconclusive rules.
• Ensure that no verification can pass solely because a reference-mode verdict remains unchanged.

Standards, assurance, and release readiness

• Replace illustrative standards with applicable contractual, regulatory, organizational, and technical standards.
• Identify which operational participants are contractually governed and frame the standard-applicability concern in each provider need.
• Inspect that each provider need rebinds the concern to the intended constituent and that the contractual handoff reaches a transformed system-level requirement.
• Constrain each governed system blackbox through the applicable standard part without copying the standard's clauses.
• Assign each governed system's SEIT responsibility for analyzing inherited obligations and deriving internal realization requirements.
• Keep original standard constraints at the governed boundary; do not copy or divide them among constituents unless those constituents are independently within the standard's contractual scope.
• Bind compliance attributes to the project properties or evidence they are intended to assess.
• Review inherited satisfy declarations and confirm that their constraints evaluate successfully in the adopted context.
• Analyze decomposed-system compliance on the executable integrated whitebox; for terminal or supplier-owned blackboxes, define acceptable boundary-analysis and supplier evidence.
• When a realized product, prototype, or test bench becomes available, specialize the same verification intent with appropriate test or demonstration evidence.
• Remove, replace, or explicitly disposition every reference-only placeholder and synthetic evidence record.
• Run syntax and semantic validation, constraint evaluation, project verification, and independent model review.
• Baseline the tailored pattern, its external evidence, unresolved limitations, and tailoring decisions before using it for project claims.

Implementation Checklist

For each added decomposition level, include:

• Requirements file:
  • Original requirement on _bb subject.
  • Derived requirement with budget attributes and closure logic.
  • Assumption gate and frame/require obligations.
  • Child requirements for allocated needs.
• Configuration file:
  • _bb and _gb parts, plus _wb where decomposition exists.
  • Satisfaction links to original and derived requirements.
  • Part structure and connectivity aligned with taxonomy.
• Behavior file:
  • Action structure for _bb and derived behavior paths.
  • Value-producing actions for quality computation.
• Analysis file:
  • Analysis cases for sensitivity, degradation, and trade-off exploration.
  • Assumption and allocation calibration scenarios for decision support.
  • Selected allocation outputs and external-tool provenance metadata.
• Verification file:
  • Cases for original and derived requirements.
  • Subjects chosen by highest integrated level available.
  • Stimulus routed to executable action chains.
• Stakeholder/taxonomy views:
  • Concerns and constraints aligned with frame/require semantics.

Scalability

The pattern scales by:

• Horizontal expansion: add additional subsystems.
• Vertical expansion: insert intermediate levels.
• Terminal variation: keep some branches at blackbox leaf form.

Repository Structure

RecursiveArchitectureWavePattern/
|-- Framework/
|-- Level 0 - Operational/
|-- Level 1 - Systems/
|-- Level 2 - Subsystems/
|-- Level 3 - Components/
|-- Credits/
|-- CHANGELOG.md
|-- RECURSIVE_PATTERN_GUIDE.md
|-- VERIFICATION_REFERENCE_BASELINE.md
`-- README.md

Suggested Learning Path

For a first reading, follow one recursive thread instead of reading every file:

1. Start with this README to understand the pattern/evidence boundary.
2. Read Framework/Framework.sysml for the normative recursive, behavioral, analysis, and verification rules.
3. Follow the root decomposition in Level 0 - Operational/Operational_Requirements.sysml.
4. Follow its child need into Level 1 - Systems/SystemOfInterest/SystemOfInterest_Requirements.sysml.
5. Compare the L1 requirement with its blackbox, graybox, and whitebox realizations in SystemOfInterest_Configuration.sysml.
6. Follow the L1 child needs into the decomposed Subsystem1 branch and the terminal COTS Subsystem2 branch.
7. Read the corresponding verification cases to see contextual satisfaction continuity and safe reference-mode verdict behavior.
8. Use RECURSIVE_PATTERN_GUIDE.md for the detailed modeling recipe and VERIFICATION_REFERENCE_BASELINE.md for verification policy.

Validation

From a source checkout, validate both SysML semantics and RAWP-specific policy invariants:

syside check RecursiveArchitectureWavePattern
python scripts/check_rawp_conformance.py

The Syside check validates SysML syntax and language semantics. The RAWP conformance check validates reference safety, evidence classification, recursive handoffs, allocation closure, abstraction-aligned attribute placement, compliance bindings, and contextual verification objectives. Neither command substitutes for evaluating tailored project constraints and evidence.