STIG Help

Describe the design

Context and Requirements describe an element as a black box. The Design viewpoint explains its white-box realization: decomposition, child elements, interactions, behavior, allocation, and the engineering decisions that satisfy those requirements.

Model the realization

A Design identifies its subject through element, selects architectural children, and can contain subDesigns. The design has no ASIL of its own: read the element's classification from element.asil. Passing asil to a Design constructor, overriding Design.asil, or reading it directly is a Kotlin compilation error. Use normal Kotlin properties and typed references to connect design content to the element tree and other CREATE viewpoints. Put DocumentMetadata on the top-level design work product, not every nested section.

val fusionDesign = Design( name = "Fusion design", description = "Timestamp alignment, object association, motion estimation, and health monitoring.", element = fusionActivity, children = listOf(inputAlignment, objectAssociation, motionEstimation), )

children references elements declared in their own Contexts. Each child keeps its own identity and declares parent = fusionActivity. subDesigns contains design sections; children declared in those sections also contribute to the owning element's decomposition.

Declare the decomposition before allocating requirements. The model index checks allocation membership and coverage against the declared Design children, and checks the two authored hierarchy directions independently. Incoming usedIn and propagatesTo coverage and the report's reverse links use the child models even when the parent Requirements viewpoint is empty or absent. Missing requirements remain visible as allocation gaps.

isBottomLevel = true identifies an element with no Design children. An element with the default isBottomLevel = false needs at least one child. Similarly, isTopLevel = true excludes a parent; the default isTopLevel = false requires one. These flags describe the modeled boundary and default to false for every element type, including Item.

For references across Gradle projects, see Context compilation.

A useful Design should make these decisions reviewable:

  • which child elements realize the parent behavior;

  • how interface data moves between them;

  • which state, sequence, or control behavior is intentional;

  • where requirements and safety measures are allocated;

  • which assumptions are external to the current design scope.

Declare every SafetyMeasure, including SafetyMechanism and ProcessLevelSafetyMeasure, as a named property in a Design subclass. Nested design sections are allowed. The containment rule checks the declaration, so a top-level measure in a .design package is insufficient. Failures may reference measures in another element's design.

class FusionDesign : Design(element = fusionActivity, name = "Fusion design") { val outputCrossCheck = SafetyMechanism( name = "Output cross-check", description = "Compares the output with an independent estimate.", asil = ASIL.B, ) } val fusionDesign = FusionDesign() // A failure uses mitigatedBy = listOf(fusionDesign.outputCrossCheck).

The five viewpoint containers are Context, Requirements, Design, Analysis, and Tests. Their named Kotlin properties retain ordinary property access. Module introspection derives viewpoint roots and typed collections over all nested content from those declarations.

Check and render

./gradlew :path:to:element:stigCheckModel ./gradlew :path:to:element:stigGenerateHtml

The Design section of the generated model-rule catalog is the exact contract checked by IDEA and Gradle.

Ask $stig:specification

Use $stig:specification to review the Design viewpoint for <module path>. Trace its element and cross-viewpoint links, compare it with allocated requirements, and report missing or contradictory realization decisions. Do not edit the model.
23 October 2026