Why Systems Fail

What this book helps you do

This book explains why operational systems disagree even when every database has an owner. It connects identity, classes, relationships, time, provenance, constraints, change, telemetry, CMDB, and knowledge graphs so engineers can distinguish declared topology from observed behavior and give AI investigators bounded, queryable evidence instead of ambiguous labels.

Problems this book helps you solve

• The same service, component, resource, or application has several incompatible identifiers.
• A CMDB record is complete but stale, duplicated, orphaned, or mapped to the wrong runtime entity.
• Taxonomy, ontology, knowledge graph, semantic layer, and catalog are treated as synonyms.
• Declared dependencies are mistaken for evidence that a runtime request used that path.
• Telemetry and configuration data cannot be joined with stated provenance and time.
• An AI investigator receives a graph but cannot tell which edges are asserted, inferred, observed, or outdated.

Decisions you will be able to make

• Whether a problem needs labels, a taxonomy, an ontology, a graph, a semantic layer, or a combination.
• How identity, equivalence, versioning, and source records map to operational entities.
• Which constraints belong in an ontology, validation layer, application, or governance process.
• How to represent events, state, time, provenance, confidence, and conflicting observations.
• How CMDB, discovery, service catalogs, telemetry resources, and topology evidence should interact.
• Which graph paths support impact analysis or causal candidates without proving causality.

Reading path

1. Clarify the semantic choicesDistinguish inventories, taxonomies, ontologies, graphs, semantic layers, and operational models.
2. Model identity and relationshipsDefine entities, keys, equivalence, roles, composition, events, state, time, and provenance.
3. Use formal standards deliberatelyUnderstand what RDF, RDFS, OWL, SPARQL, SKOS, and SHACL add—and what they do not.
4. Repair the CMDB boundarySeparate source records, domain entities, observations, lifecycle, reconciliation, and ownership.
5. Connect telemetry and topologyRelate declared structure, runtime resources, observed paths, changes, incidents, and evidence windows.
6. Bound AI investigationRetrieve relevant subgraphs while preserving source, time, confidence, permissions, and causal limits.

Ownership does not create operational truth

A named owner can improve accountability, but freshness still depends on identity, update paths, discovery coverage, lifecycle rules, source precedence, and the time represented by each observation. Semantic quality is an operating system, not a documentation field.

Graphs contain different kinds of edges

A declared dependency, an observed network call, an inferred relationship, and a human assertion carry different evidentiary weight. The book keeps those distinctions visible so impact analysis does not silently become a causal claim.

Use it with

Take one incident and trace a single affected entity across its catalog, CMDB, deployment, telemetry resource, runtime path, change record, and owner. Record every identity conversion and the time each source actually describes.

Evidence and method

W3C standards and official product documentation establish their own data models and behaviors; the cross-system operational model is an author synthesis. Product examples show documented capabilities, not endorsements or equivalence. Synthetic cases distinguish declared, observed, inferred, and disputed relationships and never treat graph connectivity as proof of root cause.

Read a sample

Signal Studio does not reproduce manuscript chapters on this site. Open the Amazon listing to use Read Sample or Kindle Instant Preview

Resources

Errata and related guidance

Report or review an erratum.

• Ontology, taxonomy, knowledge graph, or semantic layer: which one do you need?
• Why does CMDB data become stale even after a cleanup?