Author specifications with CREATE

CREATE is exida's five-viewpoint methodology for structuring engineering work products. STIG represents those work products as typed Kotlin content conforming to the Highway metamodel in com.stigway.metamodels.highway. The consumer project owns the engineering intent, evidence, and rationale; STIG supplies the metamodel, checks, IDE support, and generated report.

Start with the element tree and typed links. Each element can have the viewpoints relevant to its role in the product:

Viewpoint	Engineering question	Authoring guide
C — Context	What is the element's role, boundary, and interface?	Context and interfaces
R — Requirements	What shall the element do at that boundary?	Requirements
E — dEsign	How does its internal structure and behavior realize those requirements?	Design
A — Analysis	What can fail, propagate, or violate an engineering constraint?	Analysis
TE — TEsts	What verifies the linked requirements and behavior?	Tests

The Analysis viewpoint contains authored engineering analyses, such as failure modes, propagation assumptions, and safety measures. Automated source analysis computes implementation evidence from native code and LLVM. That evidence can support the specification, but its setup and checking have their own workflow. NEXY is an implementation complexity metric.

Author one element

Identify the element, its parent, and the available engineering evidence. Initialize a model-only element if it does not exist.
Define its Context before writing black-box Requirements.
Link the Design that realizes those requirements, the Analysis that examines it, and the Tests that verify it. Use the viewpoint guides above for syntax and examples.
Run the element's model checks while editing:
./gradlew :path:to:element:stigCheckModel
Run ./gradlew stigCheckModel for checks across the project and generate the report for integrated review. Resolve findings against the engineering intent and evidence.

The logical element hierarchy is independent of repository folders. Gradle project structure explains leaf modules, source placement, packages, and task selection. The Highway model API describes exact types; the model-rule catalog describes the current checks and semantic contracts.

Each viewpoint has its own forbidden-word check, using one shared vocabulary for placeholders and vague wording. It checks model string attributes such as name, description, argument, comment, and verificationCriteria, including strings in collections and nested metadata. Findings identify the entity and attribute in its logical viewpoint, so checking Analysis does not also report Requirements findings. KDoc and source comments are outside this check. The separate repository checkRestrictedKeywords task uses the environment-configured sensitive-name list; it does not supply the model-writing vocabulary.

To reuse externally supplied specifications, configure file conversion, import, and export jobs. Converters construct Kotlin exchange records; native JSON files connect them to the source-writing import task.

Reference identifiers and display names

Choose Kotlin declaration identifiers that express the represented engineering role or behavior, for every entity kind and in examples and test models. A Failure can be referenced as lossOfSignal and have name = "Loss of signal". The declaration identifier is used in Kotlin references; the human-facing name is a separate engineering label. Changing one does not require changing the other. Keep intentionally bad names when their spelling is the test input, as described in the fixture policy.

Authoring tools share com.stigway.metamodels.create.ModelReferenceNames for editable starting suggestions: failure(name) uses a Failure's proposed label, and interfacePointAnalysis(interfacePointReferenceName) uses the referenced interface point's declaration name. The Kotlin implementation owns normalization; tools and agents reuse it rather than maintaining a second conversion rule. A missing suggestion leaves the author to supply a meaningful identifier.

Review or replace the suggestion before applying it. The source editor checks Kotlin identifier validity and member collisions against the actual declaration owner. An accepted spelling does not establish engineering meaning, and a suggestion does not allocate an entity identity or rename existing declarations when their display labels change. Existing resolved references and authored names remain under the user's control.

Model instance identity and declaration provenance

A model member's canonical id follows its actual owning authored instance. For example, controllerAnalysis.outputSignal.incorrectOutput identifies the failure under that particular output analysis. Its declarationId can remain OutputSignalAnalysis.incorrectOutput, identifying the shared Kotlin declaration for navigation and declaration checks. Package prefixes are omitted here for readability.

Two instances of OutputSignalAnalysis retain their own authored reference names and member paths. STIG preserves both instances and their shared declaration provenance; it does not generate suffixes or discard one instance to make identities appear unique. An explicit exchange/DSL identity supplied through bindToId remains authoritative.

Instance-aware identity deliberately changes IDs for class-backed members that previously used only their declaring class scope. Refresh derived snapshots/reports and review persisted references to those old member IDs when adopting the change. Explicitly bound exchange IDs retain their specified identity.

Several instances can share one source declaration. The instance editor keeps its scalar, relationship, quick-fix and lifecycle writes read-only in that case. Edit the shared definition explicitly in Code, where its effect on all instances can be reviewed together. Distinct instance IDs do not authorize separate source edits to one shared definition.

For an editable named class, place fixed metadata in its direct metamodel superclass constructor and create one explicitly owned instance, for example val torqueCommand = TorqueCommandAnalysis() inside the root Analysis. The class and its owning property must be in the same Kotlin file, and the class must have no constructor parameters. The instance editor then edits that superclass constructor while retaining the property's instance identity. This applies to a leaf interface-point analysis, a class that owns Failures, and a port analysis that owns member analyses. The root can be an object or a named class with one explicit root instance. Constructor parameter forwarding, inherited definitions, and definitions used by several instances remain Code edits. Use constructor metadata rather than init assignments or attribute overrides; see the Analysis example.

An owned declaration such as val torqueCommand = TorqueCommandAnalysis() prevents assigning a different instance to that Kotlin property during execution. It does not prevent editing its constructor metadata in the UI. The editor changes the Kotlin source and reloads the model; it does not assign values to the running model instance. Supported constructor metadata remains editable when the metamodel declares it as val. Use var when the Kotlin model needs reassignment, not to enable UI editing. Structured or computed values and shared definitions can still require Code edits; changing val to var does not add those editor capabilities.

Review with the IDE or Codex

The IntelliJ IDEA plugin supports navigation, refactoring, and live model-rule inspections. Inspection names, severities, and help come from the same Kotlin rules as the batch checks. Gradle supplies the batch verification and SARIF output. See the IDE tour for the editing experience.

Use $stig:specification for CREATE authoring and review:

Use $stig:specification to review the requirements and linked CREATE viewpoints
for <module path>. This is review-only: do not modify Kotlin model sources. Run
or reuse the relevant model checks and report broken links, missing evidence,
and semantic gaps separately.

For authoring, state the intended behavior and request the edit explicitly. The skill reuses established decisions and asks for missing engineering intent. Source-analysis setup and evidence checking use $stig:source-analysis; installation, general Gradle configuration, and ordinary reports use $stig:project. See the plugin's skill boundaries.

23 October 2026