Asset

slug: asset element_type: TERM mutability: MUTABLE inline: true current_version: 0 status: seed-draft contentURI: null

An asset is anything under federation protection whose compromise would constitute harm. Assets include: information (data at rest, in transit, in compute), systems (hosts, services, accounts, credentials), processes (business workflows, governance procedures), and reputation (trust position with users, peers, regulators). Each asset has an owner (the participant responsible for it), a classification (sensitivity level), a dependency map (what other assets depend on it), and a protection floor (minimum controls required). An asset's compromise can be measured in confidentiality, integrity, availability, or reputational terms — the classical CIA triad expanded with reputation as a federation-relevant fourth.

Status

Seed-draft, no personal attribution. Cyber Security Sub-Leviathan opening set (2026-05-16).

Why this matters

Security exists to protect something. Without a federation-wide definition of asset, every other element (threat, vulnerability, incident, control) floats free. Asset is the anchor.

Reasoning trail

• Reputation is a first-class asset. Classical CIA triad misses the federation's most fragile property — trust. A Sub-Leviathan loses standing not through data breach but through visible incident mismanagement. Reputation as an asset class makes this protectable.
• Owner is mandatory. An asset without a named responsible participant is unowned, which means unmaintained, which means a vulnerability factory. No owner, no asset registration.
• Dependency map. An asset's compromise blast radius depends on what depends on it. Static analysis at the asset level prevents the "one secret = whole-system breach" surprise.
• Protection floor, not ceiling. Sub-Leviathans (and downstream instances) raise the floor for their domain; never lower it. Compare: rule:evidence-required (inherited from meta) — floor pattern is federation-standard.

Open questions for domain authors

• Is the asset inventory federated or per-instance? Federated → cross-instance visibility but coordination cost; per-instance → privacy but blind spots.
• How is owner identity verified? Same as proposer-sentinel standing, or stricter (cyber security may require guardian for high-classification assets)?
• What is the relationship between asset and term:control? An asset has controls; a control may protect multiple assets — many-to-many.
• Should "human" be an asset class? (Insider risk frames the operator as both defender and potential attack surface.)

Related elements

• term:threat — threats target assets
• term:vulnerability — vulnerabilities are properties of assets
• term:incident — incidents affect assets
• principle:defensive-only — defense is the orientation toward assets, never aggression

Awaiting domain author

Asset taxonomy, classification scheme (e.g., TLP for information, IL for systems), and inventory architecture are domain-author decisions.