# CrisisResponse V2 — guided SysML v2 pilot

`CrisisResponse_V2` is ASysT Rendering's bundled newcomer model: a compact, LSP-clean SysML v2 model
of a cyber-physical crisis-response system. It is deliberately a **focused 10-file pilot**, not a claim to
cover every SysML v2 construct or every renderer.

Open `Model/CrisisResponse.sysml` first, then use the package explorer to follow the suggested journey.
ASysT reads the model; saved arrangements live only under `Rendering/`.

## First ten minutes

1. Open `Model/CrisisResponse.sysml` and inspect the `CrisisSystem` composition.
2. Drill into `CrisisSystem` to distinguish part usages from their definitions.
3. Open `10_core/Core.sysml` to inspect typed ports, units, metadata and the shared state/action links.
4. Follow a `SensorReading` from `05_items/Items.sysml` through the Interfaces and Behavior packages.
5. Open `40_behavior/Behavior.sysml` and select `IncidentLifecycleStateMachine`.
6. Open `30_requirements/Requirements.sysml`, then use the requirements and traceability tables.
7. Switch to a named model view in `80_views/Views.sysml`, especially `missionDashboard`.
8. Validate the model. Treat ASysT graph warnings separately from LSP diagnostics.

## Pilot contract

| Fact | Contract |
|---|---|
| SysML source files | **10** |
| Alpha / Free model limit | **10 files / 300 graph elements** |
| Current unified graph | 98 nodes / 70 edges |
| Bundled-LSP diagnostics | 0 errors / 0 warnings |
| Expected default-tier truncation | none |

“Element” means an ASysT unified-graph node—the same counter enforced by the tier—not a source line or
every parsed SysML declaration. A real-LSP engine test keeps this pilot within both the 10-file and
300-element default budget.

## What this model teaches

| Package | Main topic |
|---|---|
| `CrisisResponse.sysml` | One `CrisisSystem`, its variation point, and a usage-level satisfy relationship. |
| `05_items/Items.sysml` | Shared `item def`s used by ports, flows, action pins and messages. |
| `10_core/Core.sysml` | Parts, composition, ports, units, enums, specialization, metadata, state and action links. |
| `20_domain/Domain.sysml` | Hazards, cyber threats, specialization, subsetting, variants and configurations. |
| `30_requirements/Requirements.sysml` | Requirements, constraints and type-level satisfy relationships. |
| `40_behavior/Behavior.sysml` | Actions, typed pins, state definitions, transitions and lifecycle behavior. |
| `40_behavior/UseCases.sysml` | Use cases, actors, include and a generic case. |
| `50_interfaces/Interfaces.sysml` | Interfaces, typed connections and flows. |
| `80_views/Views.sysml` | Viewpoints, views, `expose`, filtering and render styles. |
| `90_relations/Relations.sysml` | The connector-style gallery used as an ASysT canvas legend. |

## Deliberately outside the starter

The former Analysis and Integration packages are no longer bundled with the pilot. They taught
calculations, occurrences, individuals, parametrics, analysis/verification definitions, connection
definitions, allocations and dependencies. Those are valid SysML v2 modelling topics, but they are not
SysML views or alternate BDD/state renderings, and this product did not have end-to-end real-LSP graph
contracts for them.

They may return as a separately verified advanced example. Until then, the bundled pilot makes no claim
that those specialised shapes are fully rendered.

## Known viewer limitations

The model remains LSP-clean, but parser acceptance is not a rendering-fidelity guarantee. Two valid
constructs are retained deliberately as named product gaps:

- The typed item flow in `50_interfaces/Interfaces.sysml` currently produces no graph edge or warning
  (DB11).
- The usage-level satisfy in `CrisisResponse.sysml` currently produces no graph edge or warning (DB6).

The requirements package also contains type-level satisfy relationships, which are the appropriate
traceability example until DB6 is fixed. Do not infer complete support from zero LSP diagnostics alone.

## Folder structure

```
Demo/CrisisResponse_V2/
├── CrisisResponse.md
├── CHANGELOG.md
├── asyst.manifest.json
├── Rendering/…                  ← ASysT-owned rendering sidecars
└── Model/
    ├── CrisisResponse.sysml
    ├── 05_items/Items.sysml
    ├── 10_core/Core.sysml
    ├── 20_domain/Domain.sysml
    ├── 30_requirements/Requirements.sysml
    ├── 40_behavior/Behavior.sysml
    ├── 40_behavior/UseCases.sysml
    ├── 50_interfaces/Interfaces.sysml
    ├── 80_views/Views.sysml
    └── 90_relations/Relations.sysml
```

The manifest makes this one package-first model. File boundaries are an authoring convenience; the
explorer and graph identify elements by fully qualified name.

## Rendering the views

`missionDashboard` mixes structure, behavior and requirements in one SysML view. Export it headlessly:

```bash
./asyst.cmd export Demo/CrisisResponse_V2/Model/80_views/Views.sysml --view missionDashboard -o dashboard.svg
```

The V1→V2 modelling history and the reason the advanced packages were removed live in
[CHANGELOG.md](CHANGELOG.md). Keep this page focused on opening the model, the expected result and known
ASysT limits.
