component-authoring

Component Authoring

Author the durable component and application design in textual SysML v2 under model/. Treat generated Markdown as a view, never as an independent contract.

Goal

Model enough contract-significant structure and behavior that a human or agent can:

• understand what the component owns and exposes;
• invoke and compose its public contracts;
• reason about abstract state changes and invariant preservation;
• substitute another conforming realization;
• derive black-box verification scenarios.

Leave private helpers, algorithms, implementation data structures, performance strategy, and language-specific type hierarchies to realizations.

Conformance Hierarchy

Treat every chosen abstraction boundary as an engineered black box. A component realization conforms when its public structure, behavior, abstract state effects, failures, invariants, and verification obligations match the model, regardless of implementation language or internal design. A composed subsystem or application is another modeled black box: its internal roles must conform to their component contracts, and its own external actions, behavior, state, invariants, and use cases must conform at the higher boundary.

Model downward into algorithms, deployment, hardware, or implementation structure only when that layer is itself an intentional engineering subject or affects an observable contract. Do not make implementation fidelity the default completeness criterion.

Required Resources

• Use the sysml-reference skill before making or reviewing a SysML/KerML syntax or semantics decision. Cite the relevant specification section and page for consequential choices.
• Read references/component-modeling-pattern.md before authoring or materially revising a model.
• Read references/behavior-detail.md when deciding how much behavior to formalize.
• Read references/model-organization.md when creating or changing a model library, package boundary, shared vocabulary, application/library dependency, or runtime realization.
• Read references/application-composition.md for application, controller, adapter, or use-case work.
• Read references/boundary-quality.md when reviewing ownership or considering a split or merge.
• Read references/examples.md when a representative storage, query, or controller pattern helps.