Components

Components are the fundamental building blocks of models in Latch‑X. Each component represents a part of your system that can fail and (optionally) be repaired.

Component Types Overview

Latch‑X supports three main component types:

Normal Components

Standard system components that can fail and be repaired. These represent physical infrastructure, software services, or risk events modeled as components.

Latch Components

Special components that model failover success (or a generic time‑delay transition) under specified timing constraints.

Logical Components

Components that represent logical relationships in system architecture; they have no independent failure modes. They define how dependencies interact (AND, OR, n‑of‑k).

Inverted Logical Components (ilogical)

Partialy implemented (experimental).

Root

The root marks the top‑level component of your model. Every model must define a root, and that component must exist in components. A minimal valid model is:

root: top_component
components:
  top_component:
    type: logical
dependencies: {}

Cost

Cost on normal components (defaults to 0.0). Internal cost unit is $.

Normal Components

Standard system components that can fail and be repaired. Most infrastructure elements are normal components.

Key parameters

MTTF (Mean Time To Failure): average time until failure (hours).
MTTR (Mean Time To Repair): average time to restore after failure (hours).
prob: direct availability; use either prob or mttf+mttr (never both).
Distributions (experimental):
mttf_dist: exp | norm | lognorm
mttr_dist: exp | norm | lognorm | delta
If norm/lognorm, provide sigma. Default is exponential if unspecified.

Units

MTTF and MTTR are in hours.

Dependency rule

For a normal target node, use do: dependencies. See Dependencies.

Examples

Typical examples

Web servers, databases, load balancers
Network switches, routers, firewalls
Storage systems, disk arrays
Power supplies, cooling systems
Cloud services, third‑party APIs

Parameter guidelines

Typical component values (replace with your data)

components:
  hw_server:
    type: normal
    category: infra
    tags: [compute, server]
    mttf: 40000        # ≈4.6 years (single box)
    mttr: 6            # 24x7x4 on-site typical; mid (4–8 h)
    mttf_dist: exp
    mttr_dist: exp

  db_service:
    type: normal
    category: infra
    tags: [software, database, single-instance]
    mttf: 20000        # 18k–24k h typical; mid for single-instance outages
    mttr: 1            # restart + WAL replay ~0.5–2 h
    mttf_dist: exp
    mttr_dist: delta   # fixed-time restart acceptable

  human_config_error:
    type: normal
    category: risk
    tags: [human, config, change-monthly]
    mttf: 7200         # monthly changes (~10% CFR) → 720 h / 0.10
    mttr: 3
    mttf_dist: exp
    mttr_dist: exp

  natural_disaster:
    type: normal
    category: risk
    tags: [disaster, natural]
    mttf: 876000       # ≈100-year return period (1% AEP)
    mttr: 1440         # ≈2 months to full restoration
    mttf_dist: exp
    mttr_dist: norm
    sigma: 240         # spread of restoration times (example)

Risk nodes and prob

Risk nodes are normal components distinguished only by category: risk.
prob is the probability the node is UP (i.e., the risk does not materialize) over the analysis window.
Example: natural_disaster: { prob: 0.90 } → 90 % chance no disaster occurs (10 % chance it does).
This can feel counterintuitive and is a common source of mistakes (including in LLM‑generated models). To reduce confusion, consider a not_ prefix (e.g., not_natural_disaster) or model frequency/duration via mttf/mttr instead of prob.
Don’t mix prob with mttf/mttr on the same component—use one approach.

Latch Components

Latch components model failover success (or a generic time‑delay transition) that is activated by a parent failure.

Latch example

components:
  db_failover:
    type: latch
    # Mode 1 (probability):
    # prob: 0.95
    # Mode 2 (time-based):
    mttf: 0.5       # average 30 min to failover
    max_delay: 1.0  # must complete within 1 hour
    mttf_dist: exp

Key characteristics

Two modes: use either prob or mttf + max_delay (if mttf is present, max_delay is required).
Activation: triggered by failure of dependent components.
Distributions (experimental): default exp; norm/lognorm require sigma.
Latches represent one‑time transitions (no mttr).

mttf vs prob

Use either prob or (mttf and max_delay). If mttf is present, max_delay is required.

Use cases

Database hot standby systems
Backup data centers
Redundant network paths
Emergency power systems
Failover load balancers

Configuration modes

Probability mode

Set prob (0.0–1.0) to directly specify failover success probability when activated.

Time-based mode

Set mttf (Mean Time To Failover) and max_delay. The failover is considered successful only if it completes within max_delay.

Configuration rules

Use either prob or mttf + max_delay — never both.
Probability values must be in [0.0, 1.0].
When using time-based mode, provide both mttf and max_delay.
Latch components have no mttr.

Logical Components

Logical components represent system architecture patterns and dependency relationships. They have no independent failure modes—their state is determined entirely by their inputs.

Dependency relationships

Logical components are defined through dependency configurations rather than component parameters:

Dependency types

and: Component is UP only when all inputs are UP (serial/critical paths).
or: Component is UP when any input is UP (redundancy/alternate paths).
n_of_k: Component is UP when at least n of k inputs are UP (partial redundancy/quorum).
do: Component is UP when its parent is UP.

Creating components

Step‑by‑step

Create a component

Navigate to Model Management and open your model.
Click the Components tab.
Click Add Component and choose the type.
Enter a descriptive name (and optional description).
Configure type‑specific parameters (MTTF, MTTR, distributions, etc.).
Optionally set category and tags.
Save and repeat for all system elements.

Best practices

Use clear, descriptive names.
Start with major system components; add detail iteratively.
Research realistic MTTF/MTTR values for your stack.
Keep naming conventions consistent.
Group components by categories.

Parameter guidelines

Setting realistic values

Research sources

Vendor specifications (often on request)
Historical incident data
Industry reliability databases
Internal monitoring and metrics
Similar system benchmarks

Validation methods

Compare with actual system uptime.
Cross‑check with vendor claims.
Validate with operations team experience.
Use industry standard values as baselines.
Adjust for environment and usage.

Common mistakes

Avoid these

Over‑optimistic MTTF (vendor best‑case).
Ignoring MTTR complexity (detection/diagnosis time).
Missing shared dependencies.
Using normal components to express logical relationships.
Mixing units (hours vs days/years).

Component validation

Latch‑X automatically validates components and dependencies and provides feedback. Models are validated on the fly or via the Validate button.

Model integrity

Models that pass validation are cryptographically signed (currently used for internal integrity checks).

Next steps

After creating components, you're ready to build your model:

→ Define dependencies — connect components with logical relationships.
→ Model management — complete the creation workflow.
→ Run analysis — analyze your component models.

Components

Component Types Overview

Normal Components

Latch Components

Logical Components

Inverted Logical Components (ilogical)

Root

Categories

Tags

Cost

Normal Components

Key parameters

Examples

Parameter guidelines

Latch Components

Key characteristics

Use cases

Configuration modes

Logical Components

Dependency relationships

Creating components

Step‑by‑step

Parameter guidelines

Setting realistic values

Common mistakes

Component validation

Model integrity

Next steps