Rule Reference¶

VALIDATION · RULES

Warnings are advisory by default (exit 0). Promote them to CI gate failures (exit 2) with validate --deny <CODES> / --max-warnings <N> / --warnings-as-errors, or with a named, SIL/ASIL-scopable validate --profile <name> policy declared in .syscribe.toml — see CI severity gating. Errors always exit 1.

This page groups every finding code by feature area, with context. The same codes, one row each, are the machine-readable catalogue printed by syscribe spec validation (source: prompts/spec/validation.md, also returned by the MCP explain_finding tool). A test (crates/syscribe/tests/validation_docs_catalogue.rs) fails the build if a code the tool can emit is missing here or in that catalogue, or if a row's stated severity contradicts its prefix (E = error, W = warning, I = informational).

Parse-time errors (E000–E027)¶

Parse-time and source-drift warnings (W001–W010, I010)¶

Cross-reference errors (E101–E106, E110–E128)¶

E110–E114 (REQ-TRS-XREF-007) use the §11.5 resolution order: id / qualified name / name, then the referencing element's enclosing-package scope chain, a ./ sibling, imports: and aliases: of the element or any enclosing package, and an inline (non-file) feature of a resolvable owner — Owner::feature, or a bare feature of the element's owner, including one inherited through supertype:/typedBy:. Standard-library references are never flagged: the built-in ScalarValues/Base packages (an unknown member is W043), the curated ISQ/SI names, any reference into a SysML v2 library package (ISQ::…, Parts::Part::…, Links::…) whose top-level name the model does not declare itself, and the bare library root types (Link, Part, Real, …). SysML v2-, plugin- and annotation-synthesized elements resolve like any other — including an ingested SysML v2 allocation usage's typedBy:, now that ingestion maps allocation def to AllocationDef (GH #142; the former exemption is gone). With [repos] configured an unresolved reference is E512 instead (never both). Like E102–E106, they take the model-root-name hint and are suppressed under --config.

Coverage warnings (W002–W005)¶

Cycle detection errors (E016–E018, E107)¶

PLE errors (E200–E209)¶

The parameter-binding rules below (E203–E206, E222, W017) are enforced by both validate and feature-check, so a product line checked holistically also gets range/binding enforcement (GH #14).

PLE warnings (W015–W017)¶

The variability dimension is opt-in: it is dormant — and these checks do not fire — unless the model has at least one FeatureDef and something linking to it (a Configuration, or any element/TestCase with appliesWhen:).

A TestCase runs in a Configuration iff its appliesWhen: is satisfied by that configuration's features: selections; a TestCase with no appliesWhen: runs in every configuration. The same relationship powers syscribe matrix.

Feature-model check (feature-check command)¶

These holistic feature-model rules are not run by validate — they are emitted only by the explicit syscribe feature-check command (exit 0 if no errors, 1 otherwise; dormant with a notice when no FeatureDef is present).

Deep analysis (feature-check --deep)¶

--deep adds SAT-backed analysis over a propositional encoding of the feature model (Boolean layer only; deterministic; engine is batsat (pure-Rust CDCL, no external process) — see ADR-FM-002). It guards against blow-up by skipping (with a notice) above a feature-count limit.

Core features (present in every valid configuration) are reported informationally in the --json coreFeatures list and the text summary. Not implemented: configuration counting and numeric/parameter (SMT) reasoning.

Configuration projection (the --config lens, ADR-PROJ-001)¶

validate --config <C> projects the 150% model onto a configuration (or ad-hoc feature set) and re-validates that variant; feature-check --deep proves variability integrity across all variants; validate --all-configs gates every stored configuration.

On a model that declares no FeatureDef, --config must name a stored Configuration (e.g. a MagicGrid parametric variant — the lens is then the identity); anything else is a usage error rather than a silent whole-model fallback. Cross-reference-resolution codes (E102–E106, E110–E114) are suppressed under --config because escaping refs (E226/W019) are authoritative there.

Transitive package appliesWhen (§9.10, REQ-TRS-VAR-006)¶

A Package may declare appliesWhen: to gate its whole subtree; an element's effective condition is its own appliesWhen:, else the nearest ancestor package's. To keep that unambiguous, at most one node per root-to-leaf path may declare it. Checked by validate (dormant without a FeatureDef).

ADR errors (E300–E304)¶

Traceability warnings (W300–W307)¶

§12 Traceability errors (E310–E316, E319)¶

§12.8 Implementation trace (W023)¶

The optional implementedBy: field on a Part, PartDef, Interface, or InterfaceDef records the source artifact(s) that realise an architecture element — the downstream leg of the V-model (Requirement ─satisfies→ Architecture ─implementedBy→ Code ─verifies→ Test). For interface-typed elements this typically points to a header file, IDL file, or protocol spec document.

• Opt-in — the check runs only when implementedBy: is present; elements without it are never flagged.
• Draft-suppressed — elements with status: draft are skipped (the implementation may not exist yet).
• Path resolution is identical to sourceFile (classify_source): model-/repo-relative, model:/repo: prefixes, absolute, and file:// paths are checked on disk; remote URIs (scheme://) and package-registry references (crates.io:tokio@1.38.0, npm:lodash@4.17.21, github:org/repo@v1 — the forms sbom turns into purls) are accepted as external pointers and not verified locally. implementedBy: accepts a single string or a list; each entry is checked independently.
• Gateable — validate --deny W023 exits non-zero when any W023 is present.

§3 External references (W028)¶

The optional common field extRef: (string or list) marks an element as the representation of an artifact in another tool — a requirement in DOORS Next, an element in a SysML tool, a ticket. Look up the element(s) carrying a reference with syscribe -m <root> extref <ref>.

• Opt-in — the check runs only when some element declares extRef:.
• Allowed but flagged — duplicates are permitted (extref returns all matches), but usually signal a stray copy or bad merge.
• Not a cross-reference — extRef is an external pointer; it is never a target for supertype:/verifies:/derivedFrom: etc.
• Gateable — validate --deny W028 exits non-zero when any W028 is present.

Diagram errors (E400–E405)¶

Diagram warnings (W400–W421, W080)¶

State machine warnings (W070–W079, W929, §22.1)¶

SysMLv2-faithful state-machine checks on StateDef/State. All draft-suppressed and gateable with --deny W07x / --deny W929.

The checks apply recursively over the state hierarchy: each level's substates are checked by W070–W074 (composite substates as nodes), inline-subStates: substates are recursed into, and parallel (isParallel) levels are checked per region plus W077/W078. W076 covers transition endpoints that resolve to no state.

Budget expression validation (E866–E868, W060, §22.2)¶

For a CalculationDef with bodyLanguage: budget, the body: is a restricted arithmetic expression (+ - * /, parentheses, number literals, and feature_ref operands resolving to inline attribute value:/default:). An optional evaluate: names a ConstraintDef bounding the result.

Trade studies (E869–E877, W061–W064, §15)¶

A TradeStudy (TRD-*) is a weighted-criteria evaluation; the tool computes normalised/weighted scores and rankings (never written to disk). Codes drafted as E400–E408/W400–W403 were reassigned (they collide with the Diagram codes).

Behavioural model trace (E990–E992, W990–W993, §12.11)¶

Dormant unless some part declares models:, except E992, which checks every role:. See spec §12.11 and docs/model-guide/behaviour-models.md.

Executable evidence (W994–W995, §12.12)¶

Scenario-level @verifies claims, checked against the TestCase's verifies:. requirement-coverage and exec-coverage report the evidence itself.

Fault-injection campaigns and residual risk (E942–E944, W940–W946, §12.14)¶

Decisions on the defeats of recorded inject campaigns (GH #341). See Safety analysis.

System context (W996, §12.13)¶

Opt-in: only a part that holds a role: external usage is checked.

IEC 62443 Zone/Conduit (E950–E956, E925, E926, W950–W953, §13)¶

Documentation linting (W099–W103, lint-docs)¶

The lint-docs command scans external .md and .svg docs for references to model elements that no longer resolve. Any W099–W102 finding makes it exit 1 (CI-gateable as-is); --deny W103 also makes the advisory W103 fail the run. A nonexistent path is a usage error (exit 1).

Review records (E700–E705, W700, W704, §19)¶

A ReviewRecord (RR-*) is a baselined, thin traceability anchor for a formal review; the discussion lives in the external tool named by recordedAt:.

Native PlanningItem (E706–E717, E719–E723, W308–W311, W315, §23, ADR-SYS-PLANITEM-001)¶

A PlanningItem (PI-*) is the model's native representation of planning/tracking work — a strict single-parent tree (parent:), with a top-level item required to set achieves: (the Requirement(s) — or goal, ADR, argument, plan or baseline — it exists to realise) and, optionally, blockedBy: (what it's waiting on) and evidence: (proof of completion).

blockedBy: is resolved permissively, like evidence.ref: — any model element, not restricted to PlanningItem — since an undecided ADR or any other unmet dependency is an equally legitimate blocker. It is graded the opposite way from evidence:: status: blocked with an empty blockedBy: raises nothing (being blocked needs no proof), while status: done on a leaf with no evidence does (E719).

assignedTo: is a plain username, not a cross-reference. Format (E723) is always checked; roster membership (E722) only when [users] (<username> = "<display name>" in .syscribe.toml) is non-empty — a value already flagged E723 is not also reported as undeclared. syscribe show <PI-id> prints the declared display name alongside the username when the roster is configured.

claimedBy:/claimedAt: (issue #115) are advisory ownership markers, not validated fields in their own right — syscribe claim <PI-id> --by <agent-id> sets both (refusing on an already- done item, or one already claimed by a different claimant), syscribe release <PI-id> clears both regardless of status:. Both are visible in show <PI-id> and list PlanningItem --json. W311 is the validator-side counterpart: it fires whether or not anything was ever actually claimed, since status: in_progress alone already signals active work.

No dedicated CLI subcommand or MCP tool — queried via the generic list/show/ls/find/refs commands; written via the generic MCP element tools. See examples/planning-item/ for a worked example.

User-defined link types (E630–E636, W630, W631, §12.10, ADR-SYS-LINKTYPE-001)¶

A project declares its own relationship types in [linkTypes.<name>] tables of the model-root .syscribe.toml, and elements author instances under a links: map (<type>: <ref | [refs]>, resolved like satisfies:). Active only when [linkTypes] or links: is used — a model with neither is unaffected. See the Link Types guide.

A type with extends = "satisfies" | "verifies" | "derivedFrom" | "refines" is also checked by every rule of its base link, minus the codes it lists in relax — satisfies → E312, E313; verifies → E104; derivedFrom → E105, E310, W303; refines → E316. Relaxation never applies to the built-in field itself. Custom links participate in suspect-link detection (W090) unless the type sets suspect = false.

Multi-repository composition (E510–E515, W510–W512, §14)¶

A model composes peer repositories declared in the [repos] table of the model-root .syscribe.toml and imports their namespaces via repoImports: on a Package _index.md. Cross-repo verifies:/derivedFrom:/satisfies:/allocatedTo: (and structural supertype:/typedBy:/subsets:/redefines:) references resolve against the local model first, then each loaded repo in declaration order (by global stable ID, peer qualified name, or a repoImports: mount path <package>::<as>::X). Active only when [repos] is configured — single-repo models are unaffected.

Foreign-format ingestion via stdio-subprocess plugins (E550–E553, W550–W553, E108, ADR-SYS-PLUGIN-002)¶

Reserved, never emitted: E530–E532 and W530–W534 are reserved for the parked sandboxed-WASM plugin design (ADR-SYS-PLUGIN-001, never merged). No shipped code emits them; they stay unassigned so a future finding cannot be misattributed to that mechanism. Stdio plugins use their own range below.

A package _index.md may declare foreignFormat: <alias>, handing its subtree to an external process named by the [plugins.<alias>] table of the model-root .syscribe.toml. Syscribe spawns it, sends one JSON request on stdin, and reads one JSON {elements, diagnostics} envelope from stdout; the elements are merged into the graph as ordinary RawElements. Active only when a package declares foreignFormat: — a model with none is unaffected.

A plugin failure never aborts the rest of validate — it downgrades only that package's contribution, the same graceful-degradation posture multi-repo composition's RefState::Unknown and native SysMLv2 ingestion's W541 already established. Gate CI on any of these with validate --deny W550, etc. E108 is origin-agnostic — the sibling of E101 (duplicate id) for qualified names — and fires regardless of which pass produced the collision.

Cross-references between a plugin-synthesized element and the native model resolve in both directions with no special handling: a plugin-emitted element's satisfies:/derivedFrom:/ allocatedTo:/typedBy:/supertype: pointing at a native id/qname, or a native element's own field pointing back into a plugin-emitted qname, both resolve like any other reference. The one exception is verifies: (E104, above) — a plugin-synthesized element only qualifies as a legal target when it is one of the fixed requirement/architecture-shaped kinds.

A stdio plugin is a plain OS subprocess with no sandbox: configuring [plugins.<alias>].command means trusting that command, the same trust level already accepted for [plantuml] jar/plantuml on PATH and the [remote] sh -c hook. See docs/model-guide/stdio-plugins.md and ADR-SYS-PLUGIN-002 for the full wire protocol and trust-model rationale.

Annotated-source ingestion (E560, E561, W560–W563, ADR-SYS-ANNOTATE-001)¶

A package _index.md may declare annotationFormat: <label> with inline marker: (a regex), include: and exclude: (globs); Syscribe scans the matched source files for comment blocks starting with the marker and parses each block with the ordinary frontmatter schema. Active only when a package declares annotationFormat:. See the annotated-source guide.

Annotation-synthesized elements take part in E108 and in the E104 widening above, exactly like plugin-synthesized ones.

Native SysML v2 submodel ingestion (W540–W544, ADR-SYS-SYSMLV2-001)¶

A package marked sysmlSubmodel: true is populated from the .sysml/.kerml files in its subtree. See the SysML v2 submodel guide.

Suspect links (W090, ADR-SYS-SUSLINK-001)¶

A trace-link source may store traceBaselines: — target id → content hash of the target's normative projection (body + normative frontmatter, editorial fields excluded). Opt-in: un-baselined links stay silent in validate and are listed only by suspect list. See Suspect links.

Stale results (W091, REQ-TRS-RESJOIN-001)¶

A result recorded with ingest-results --format records is joined to its TestCase and stores a hash of that TestCase and of each requirement it verifies, taken with the suspect-link projection (editorial fields excluded). validate recomputes them. Opt-in by data: records ingested without hashes stay silent.

Release baselines (E520–E522, W520, ADR-SYS-BASELINE-001)¶

A Baseline (BL-*) seals a frozen scope of the model with an aggregate content hash and a JSON manifest (syscribe baseline create). Whenever a Baseline exists, validate recomputes the aggregate and grades drift by the baseline's status: — released is an error, approved a warning, draft silent, superseded not checked.

Hierarchical product-line composition (E516–E518, REQ-TRS-HPLE-001, ADR-SYS-HPLE-001)¶

A Configuration may declare subConfigurations: naming one or more other Configuration elements it consolidates — reachable locally or, in the common case, via a peer repo mounted through [repos] (§14). Each entry resolves like any other cross-reference: the local model first, then each loaded repo in declaration order. Dormant unless some Configuration declares subConfigurations: — a model with none anywhere is unaffected.

For a peer entry, E518 genuinely walks and parses that repo's model (not just the existence-only qname/id index [repos] otherwise uses) and validates it independently, so "internally valid" means what it says — a peer Configuration with its own validation errors, or that fails its own SAT check, is caught, not just confirmed to exist by name.

Cross-tier parameterBindings: (E519, E523, REQ-TRS-HPLE-002/003)¶

A Configuration.parameterBindings: dotted key resolves through subConfigurations: at any depth, using the parameter's ordinary, already-mounted qname — a local target's FeatureDefs are already visible (same model, one shared feature model per repo, so E203/E204/W017 already apply unchanged); a peer target's are genuinely loaded and parsed (mirroring E518's peer walk). The usual per-parameter checks (E204 fixed, E205 range, E206 enum, W027 runtime bindingTime:) apply identically whether the target is local or transitively resolved; E203 (feature not selected) stays scoped to a Configuration's own local selection — a transitively-reached parameter's selection state is checked against its own owning tier instead, via E519 below.

Dormant under the same condition as E516–E518 (some Configuration declares subConfigurations:), and further gated to bindings that actually resolve transitively — a purely local hierarchy never triggers E519/E523 (its FeatureDefs stay governed by ordinary E203).

Open-parameter completeness across a consolidated subtree (W513, REQ-TRS-HPLE-004)¶

For a Configuration with subConfigurations:, the transitive closure of every isRequired: true, no-default: parameter — of every FeatureDef actually selected anywhere in the subtree, at any depth — that remains unbound after applying every parameterBindings: entry from that Configuration down through every tier already resolved beneath it.

Opt-in and --deny-gateable, never a hard error — following the same posture as W510/W511/W512/W023/W090. An open required parameter at an intermediate tier is not a defect on its own; it is the mechanism by which staged, multi-party configuration across independently-developed product lines works. Only the repo actually positioned as the point of final assembly can correctly decide, via its own CI's --deny W513, that "still open" now means "genuinely incomplete." Dormant for a purely local subConfigurations: chain (one shared feature model per repo has no "some tier's job to eventually decide" concept — an unbound required local parameter there is already W017, unconditionally).

Build-system integration (E050, W050, §9.9)¶

A FeatureDef or Configuration may declare buildExports: mapping selected features to build-system variables, with buildOverrides: resolving conflicts. Opt-in — the pass runs only when at least one element declares buildExports: or buildOverrides:.

Allocation errors (E500–E503)¶

Declarative derive errors (E504–E506)¶

Emitted by the derive: evaluator (crates/syscribe-model/src/derive.rs, REQ-TRS-DERIVE-004/005).

Derived fields evaluate in dependency order, so a field always sees the computed value of every derived field it reads. derive: is a recognised frontmatter field and never raises W047 (GH #141).

The derive pass previously emitted E501/E502 and reserved E500, colliding with the Allocation codes; since GH #127 the two families are disjoint.

Structural warnings (W500–W503, W930)¶

Documentation warnings (W600–W601)¶

Safety / ASPICE warnings (W701–W703, W807, W029)¶

These warnings apply to requirements carrying safety integrity level fields (asilLevel, silLevel, dalLevel).

Tier 2 safety element errors (E800–E830)¶

Tier 2 element types support ISO 26262 HARA and ISO/SAE 21434 TARA workflows. Each type carries a stable opaque ID and required fields validated at parse time.

HazardousEvent (E800–E804, E833–E836)¶

SafetyGoal (E805–E806, E837, W801, W806)¶

DamageScenario (E807–E810)¶

ThreatScenario (E811–E814, E845)¶

CybersecurityGoal (E815–E818)¶

SecurityControl (E819–E821)¶

VulnerabilityReport (E822–E824, W803)¶

Tier 2 cross-reference errors (E825–E832)¶

Tier 2 coverage and traceability warnings (W800–W808)¶

Asset identification — ISO/SAE 21434 §15.3 (E861–E864, W810)¶

An Asset (ASSET-*) is a model element worth protecting; DamageScenario.assets: links a damage scenario to the assets it endangers. See docs/model-guide/safety-analysis.md.

Security test methods — ISO/SAE 21434 §13 (W809)¶

Safety↔security co-engineering (E844, W030)¶

ISO 26262 ⇄ ISO/SAE 21434 cross-domain checks. A DamageScenario/ThreatScenario may declare hazardRef: (string or list) pointing to the HazardousEvent/SafetyGoal it endangers. See docs/model-guide/safety-analysis.md and syscribe -m <root> co-analysis.

Cybersecurity risk determination (E845, W031, W032)¶

ISO/SAE 21434 §15.8 / §15.9 risk determination and treatment. Per ThreatScenario, risk is computed from severity and feasibility:

• severity rank — negligible=0, moderate=1, major=2, severe=3 — the max damageSeverity over the threat's resolved damageScenarios.
• feasibility rank — very_low=0, low=1, medium=2, high=3 (from attackFeasibility).
• if either rank is unknown, the risk is unknown (the threat is listed but never gated).
• else score = severity + feasibility (0..6) → level: 0–1 low, 2–3 medium, 4 high, 5–6 critical.

ThreatScenario carries riskTreatment: (avoid/reduce/share/retain; invalid → E845) and a free-text residualRisk:. See docs/model-guide/safety-analysis.md and syscribe -m <root> cyber-risk.

Quantitative HW safety metrics and safety targets (E846, W033, E985, E986, W988, W989)¶

ISO 26262-5 §8–9 hardware architectural metrics, rolled up per SafetyGoal from its contributing FaultTreeEvents — the events under the FaultTree(s) whose topEvent resolves to the goal. Each event may carry diagnosticCoverage: (DC, 0.0–1.0) and latentDiagnosticCoverage: (DCl, 0.0–1.0). Over the events that declare a failureRate (λ, /h):

Σλ      = Σ λ_i
λ_RF    = Σ λ_i · (1 − DC_i)              DC_i defaults to 0 when absent
SPFM    = 1 − λ_RF / Σλ                    (Σλ = 0 → undefined / n/a)
λ_MPFL  = Σ λ_i · DC_i · (1 − DCl_i)       over events that DECLARE DCl
LFM     = 1 − λ_MPFL / (Σλ − λ_RF)         (n/a unless ≥1 event sets DCl)
PMHF    = λ_RF + λ_MPFL                     (/h)

Opt-in. A goal's metrics are computed and gated only if at least one contributing event declares diagnosticCoverage; otherwise they are n/a and never gated. This keeps models without coverage data silent (zero W033). Targets by ASIL: SPFM ≥ {B 0.90, C 0.97, D 0.99}; LFM ≥ {B 0.60, C 0.80, D 0.90}; PMHF < {B/C 1e-7, D 1e-8} /h (ASIL A: not gated). SIL-only goals gate PMHF/PFH < {SIL2 1e-6, SIL3 1e-7, SIL4 1e-8} /h; SPFM/LFM are reported but not gated for SIL. This is a first-order FMEDA approximation — verify independently. See docs/model-guide/safety-analysis.md and syscribe -m <root> metrics.

Safety targets (GH #343). A goal without coverage data still gets a figure from its fault tree, labelled as rate only: the exact top-event probability over missionTime, divided by it (PFH). A goal's target: ({mode: continuous|demand, value, unit, proofTestInterval}) overrides the table; in demand mode the figure is PFDavg = Σ over the minimal cut sets of Π λ·(1−DC)·TI^k/(k+1). [reliability.targets.asil.<A-D>] / [reliability.targets.sil.<1-4>] (spfm, lfm, pmhf/pfh, pfd) in .syscribe.toml override the built-in defaults, and [reliability] plausibleProbability sets the plausibility bound. A figure whose events fail with a probability above the bound over the mission time is "not credible". rateSource:/rateStatus: record where a rate comes from; a verdict resting on rates that are not verified/secondary says so. A rate-only or PFDavg figure gates W033 only when the goal declares its own target: or .syscribe.toml sets the limit.

Freedom From Interference / dependent-failure analysis (W034)¶

ISO 26262-9 §7 dependent-failure analysis. Two elements share a resource when both are allocated to the same target element. The allocation edges (source → target) are the §12.9 unified edge set — an element's allocatedTo: [T, …] (source = the element), a legacy allocatedFrom: [S, …] authored on a non-Allocation element (target = the element), and an Allocation element's allocatedFrom/allocatedTo, top-level or per features: entry (source → target; the Allocation element itself is never an endpoint) — resolved via the Resolver, then inverted into a target → { sources } map.

Each element gets an integrity tag: asilLevel if present, else silLevel (→ SIL<n>), else QM. Two sources on the same target are mixed-criticality when their tags differ (including classified vs QM). A mixed pair is excused when the target OR at least one of the two sources declares a non-empty ffiRationale: string, OR carries a breakdownAdr: that resolves to an accepted ADR.

Opt-in. The whole check is dormant unless at least one element in the model declares asilLevel or silLevel; a non-safety model emits zero W034 and unchanged exit codes.

Deferred: the issue's cross-domain "attack surface" bonus (reusing the shared resources for the cybersecurity co-analysis view) is not implemented.

See docs/model-guide/safety-analysis.md.

Confirmation measures & DIA/CIA responsibility (E847–E851, E860, E924, W038, W039)¶

ISO 26262-2 §6 confirmation measures, ISO 26262-8 §5 Development Interface Agreement (DIA), and ISO/SAE 21434 §7 Cybersecurity Interface Agreement (CIA). Both checks are opt-in.

responsibility: (common field, any element) — the accountable party/organisation for a work product (the DIA/CIA split, e.g. OEM / Supplier-X).

ConfirmationMeasure (type: ConfirmationMeasure, CM-* id) — a confirmation review, FS audit, FS assessment, or cybersecurity assessment, with measureType:, independenceLevel: (I1/I2/I3), status: (planned/in_progress/completed), and confirms: (work-product ref(s) resolved via the Resolver).

The integrity → independence mapping is intentionally minimal: asilLevel: D or silLevel: 3/4 → an I3 functional_safety_assessment; calLevel: CAL4 → an I3 cybersecurity_assessment; calLevel: CAL3 → an I2-or-I3 cybersecurity_assessment (REQ-TRS-SEC-007). Lower integrity levels are not gated.

See docs/model-guide/safety-analysis.md.

GSN safety-argument layer (E852–E859, E718, W040)¶

The Goal Structuring Notation (GSN) argument layer (issue #20). Argument (ARG-*) nodes argue for a SafetyGoal or a parent Argument, discharged by evidence (Requirement / TestCase / sub-Argument / AssumptionOfUse). AssumptionOfUse (AOU-*) records a safety-related application condition (SRAC). Render the tree with syscribe safety-case.

Argument (E852–E855, E718, W040)¶

AssumptionOfUse (E856–E859)¶

See docs/model-guide/safety-analysis.md.

SafetyMechanism (E896–E897, W894)¶

SafetyMechanism (SM-*, GH #236) records what a mechanism covers, its coverages and reaction time; list them with syscribe mechanisms.

DependentFailureAnalysis (E890–E892, W890)¶

The ISO 26262-9 clause 7 independence argument as a model element (DFA-*). An approved analysis silences W034 for every pair of its analyses.

Behaviour / executable models (E882–E889, E930–E939, E966, W933, W935, W936)¶

Executable state machines, actions, composites, in-process plants and fault injection (GH #277–#306, #291; §8.8, §22.1). Several of these need the opt-in fmi Cargo feature (plants backed by an FMU).

Integrity level propagation errors and warnings (E841–E843, W808)¶

Once any element in the traceability chain carries asilLevel or silLevel, all downstream elements must inherit the same field. A lower level is permitted only when accompanied by a breakdownAdr documenting the ASIL/SIL decomposition rationale (ISO 26262-9 / IEC 61508-2 §7.4.9).

Tier 4 — Fault Tree Analysis (E900–E909, E927, W900–W901)¶

FaultTree (E900–E902, W900)¶

FaultTreeGate (E903–E906, W901)¶

FaultTreeEvent (E907–E909, E927)¶

Fault-tree structure and analysis (E980–E984, W980–W984, W987)¶

Checked once per FaultTree with the same graph builder fault-tree analyze and metrics use.

Tier 4 — FMEA (E911–E914, E922, E923, W902–W904, W928)¶

FMEASheet (E911–E912, E923, W902, W928)¶

FMEAEntry (E913–E914, E922, W903–W904)¶

FMEAEntry elements are synthesised at parse time from each row in a FMEASheet.entries: list. They are not authored as standalone files.

The canonical severity key is fmeaSeverity: (camelCase, integer 1–10). The deprecated alias severity: is accepted and silently mapped for backward compatibility. RPN is computed automatically as fmeaSeverity × occurrence × detection when rpn: is absent; an explicit rpn: overrides the computed value.

Tier 4 — TARA container (E940–E941, W905)¶

TARASheet is an Option-B container whose four section tables (damageTable, threatTable, goalTable, controlTable) are each exploded at parse time into the corresponding Tier 2 element types.

Once rows are exploded, all existing Tier 2 validation rules (E807–E821, E825–E830, W800–W803) apply to the synthesised elements exactly as they would to hand-authored files.

Tier 4 — Attack path analysis (E915–E921, W035–W037)¶

ISO/SAE 21434 §15.7 attack trees, mirroring the Fault Tree Analysis family. An AttackTree (AT-*) substantiates a ThreatScenario via threatRef and decomposes it into AttackTreeGates (ATG-*, gateType AND/OR) and AttackSteps (ATS-*, leaf with attackFeasibility), with the gates/steps nested in a subdirectory named after the tree file. Feasibility is rolled up with the weakest-link rule (rank very_low=0 … high=3): an AttackStep is its attackFeasibility rank; an AND gate (a sequential path) is the MIN of its children; an OR gate (alternatives) is the MAX of its children; the tree's feasibility is the value of its root node — the one gate/step that no other gate of the tree lists in inputs:, independent of file order (no unique root → not computed) — mapped back to a label.

AttackTree (E915–E917, W035–W036)¶

AttackTreeGate (E918–E920, W037)¶

AttackStep (E921)¶

Coverage policy (E898)¶

The [coverage] table of .syscribe.toml (GH #253) sets how W305 judges a parent requirement (both by default; rollup accepts a parent whose every leaf descendant has an active verifying TestCase; direct needs the parent's own test). W305 names the rule applied.

Timing quantities and budgets (E895, W893)¶

quantities: (GH #237) states FTTI, latency, WCET and reaction time as {kind, value, unit}; a SafetyGoal's ftti: string counts as an ftti quantity.

Test environments (E893–E894, W891–W892)¶

TestEnvironment (TE-*, GH #238) models the rig an L4/L5 test runs on; runsOn: and requiresCapabilities: on a TestCase/TestPlan tie tests to it.

TestPlan (E600–E606, W610–W616)¶

A duplicate TestPlan id is the generic E101.

Custom fields (W041)¶

Unrecognized frontmatter fields, locale variants and about comments (W047, W049, W051, W052)¶

The frontmatter schema is fixed. A top-level key that is not a recognized schema field lands in the parser's catch-all — it round-trips through writes but takes no part in validation or semantics. Every such key is flagged so silent data loss (most often a typo like reqDomian for reqDomain) becomes visible. Author-defined data belongs under custom_fields: (which is exempt). Advisory; gate with --deny W047.

MagicGrid overlay (E316, W307, MG010–MG070)¶

The MagicGrid method is supported as a custom_fields: overlay — see the MagicGrid guide. The MG### namespace is opt-in: these checks fire only under the MagicGrid profile ([profiles.<name>] magicgrid = true, e.g. validate --profile magicgrid). They validate mg_-prefixed custom_fields: and the base actors: field, all of which stay inert in the base format. The MG010–MG070 findings are Error severity; the coverage checks MG080–MG083 are warnings. E316 (above) is a base-format check that always runs; W307 (above) is advisory until promoted.

The MG080–MG083 checks are the completeness / gap-analysis half of MagicGrid validation: advisory warnings (draft-suppressed where applicable, gateable with --deny, promotable via the profile). They are rolled up, with a readiness summary and a PASS/FAIL verdict, by magicgrid --audit (--json for CI).

Root-name cross-reference hint (REQ-TRS-XREF-006). Qualified names are derived relative to the model root, so the root package (_index.md) contributes no segment — a reference starts at the first sub-namespace (e.g. ProblemDomain::WhiteBox::…), never <RootName>::ProblemDomain::…. When an unresolved cross-reference begins with the root package's name: followed by :: and the stripped remainder resolves, the tool appends a diagnostic hint naming the corrected reference. The hint augments the existing unresolved-reference finding (E102/E103/E311/E316/E502/E503/E506/E632 and the structural supertype/typedBy/subsets/redefines and satisfies resolution errors E110–E114); it is advisory only — it never changes resolution and never rewrites the model. It does not fire when the root package has no name:, nor when stripping the prefix still does not resolve.

Naming (W042)¶

Additional stable-ID prefixes (W046)¶

Each id-identified element type accepts a built-in prefix (REQ for Requirement, TC for TestCase, … FEAT for FeatureDef). A project may declare additional prefixes per type in the [ids.prefixes] table of <model_root>/.syscribe.toml — keyed by element-type name, each value a list of extra prefixes. Extras are strictly additive (the built-in always stays valid) and pure identity (they affect only id validation and id-based resolution — reqClass, domain, etc. are untouched). Each prefix must match ^[A-Z][A-Z0-9]{1,11}$.

[ids.prefixes]
Requirement = ["STK", "SYS"]   # STK-SCHED-001 and SYS-SCHED-001 are now valid Requirement ids
TestCase    = ["QT"]

Built-in standard-library types (W043, W044)¶

Stereotypes — metadata applications (E317, E318, E322–E329, E650, E651, W045, W316, W650)¶

SysMLv2 has no UML stereotypes; a stereotype is a MetadataDef applied to an element via its metadata: field (bare reference, or a map whose apply/def names the def and whose other keys are tagged values).

Audit policy configuration (W934)¶

GH #222. The [cyber] table of .syscribe.toml selects and tunes the ISO/SAE 21434 risk/CAL method (see the ISO/SAE 21434 guide). The built-in annex tables are example tables, not normative.

Security-analysis completeness (E960–E965, E967, W960–W979)¶

Completeness and consistency checks for the ISO/SAE 21434 / IEC 62443 analysis elements (GH #219, #220, #221). Weakest-link note: an AND attack-tree gate rolls up as the MIN of its inputs' feasibility and an OR gate as the MAX; there is no attack-potential sum mode.