CMDB / Configuration Items

The CMDB stores Configuration Items (CIs) — discrete assets and services that other TATER entities reference. Replaces the freeform configurationItems: string[] array on TaskerTask with a proper entity that supports typed relationships, criticality-weighted impact analysis, environment tagging, and auto-discovery.

CI types (16 total)

Category	Types
Hardware / endpoints	server · workstation · mobile
Software / services	application · saas · database
Logical	service · business-service
Network	network · firewall · load-balancer
Cloud	cloud-account · cloud-resource
External	integration · vendor
Catch-all	other

Typed relationships (10, with auto-inverse)

Forward	Inverse (auto-maintained)	Use when
depends_on	used_by	A's failure causes B's failure
runs_on	hosts	App lives on a server
member_of	contains	CI is part of a service
connects_to	connects_to (self-inverse)	Network/integration peer
managed_by	managed_by (self-inverse)	Vendor or team owns the CI
replaces	replaces (self-inverse)	New CI supersedes old
related_to	related_to (self-inverse)	Generic association (last resort)

When you add A depends_on B, the system automatically adds B used_by A. Never edit the relationship array directly — always use the /relate endpoint or relate_cis MCP tool.

Auto-discovery

POST /api/cmdb/discover (Admin) walks three sources and imports CIs idempotently:

Devices → workstation/server CIs (criticality high for servers, low for workstations)
CloudAccounts (from multiCloud.ts) → cloud-account CIs (criticality high)
Vendors (active only) → saas/vendor CIs (criticality from riskTier)

Idempotent via discoveryRefId dedupe (each imported CI carries the source record's id). Run after onboarding an org, then periodically as fleet grows. Run from app: CMDB page → Auto-Discover button.

Impact analysis

GET /api/cmdb/cis/:id/impact?maxDepth=N walks used_by + hosts + contains outbound up to N hops (default 5, max 10). Returns:

severity badge — CRITICAL BLAST RADIUS (any critical impacted) / HIGH / MEDIUM / LOW
count by criticality across all impacted CIs
full impacted tree with the relationship path that led to each downstream CI

Use cases: change-request approval (justify CAB scrutiny), major incident triage (estimate scope), upgrade prioritization.

REST endpoints

GET /api/cmdb/cis (Viewer+) — list, filter by type/criticality/status/environment/tag/q
GET /api/cmdb/cis/:id (Viewer+) — single CI with full relationship graph
POST /api/cmdb/cis (Admin) — create/update; manual entry for logical CIs
DELETE /api/cmdb/cis/:id (Admin) — auto-strips this CI from other CIs' relationship arrays first
POST /api/cmdb/cis/:id/relate (Admin) — add/remove with auto-inverse
GET /api/cmdb/cis/:id/impact (Viewer+) — recursive blast-radius walk
POST /api/cmdb/discover (Admin) — auto-import from devices/cloud/vendors

MCP tools (6, HTTP + stdio parity)

list_cis — browse, filter by type/criticality/status/env/tag/q
get_ci — single CI with relationship graph
create_ci — logical CIs only; use discover_cis for inventory-sourced ones
relate_cis — add/remove relationships, auto-inverse
get_ci_impact — recursive impact with severity badge
discover_cis — auto-import from devices/cloud/vendors

Pitfalls

Discovery is idempotent via discoveryRefId. If you delete an auto-discovered CI and re-run discover, it gets recreated. To permanently exclude a discovered CI, deactivate the source record (offboard the vendor, retire the device).
Cross-org relationships are blocked. A CI in org A can't relate to a CI in org B. This is intentional — CMDB is per-org. If you need cross-org dependencies, model them as related_to with a note rather than a hard relationship.
Delete cascade strips relationships but doesn't delete dependents. If you delete CI A that has B depends_on A, B is left with a dangling reference (rendered as targetId only, no name). Future cleanup pass will GC these.
Service Portfolio depends on CMDB. Services are CIs of type business-service or service. See Service Portfolio guide for the consumer view.

Service Portfolio — uses CMDB to define business services backed by CI infrastructure
Major Incident workflow — uses CMDB for affected-CI rollup + impact
CAB workflow on Change Requests — uses CMDB for change conflict detection