Three placements for a causal layer.
IngaDB isn't a standalone destination — it's a layer that slots into an existing architecture. Three common placements, with what IngaDB carries in each and what deliberately stays with its neighbors.
1. Beside a monitoring stack
Anomaly detection over sensors and telemetry stays with your time-series stack. IngaDB picks up what comes next: the causal structure (fault trees and mechanism facts), evidence-derived probabilities (empirical Bayes), and importance-ranked priorities for what to fix first. Your monitoring keeps running untouched, while the reports and inspection records that were sleeping in folders become the evidence that explains what detection found.
The coupling is loose: on an alert, query data/analysis or data/importance; in a review, read the changes_since delta for what moved since last week.
2. Under your own application
Typed fault-tree storage, cut-set enumeration, evidence quantification, revision tracking — embedded as an engine instead of implemented in-house. IngaDB runs as a single binary beside PostgreSQL, deployable as an internal service with no published ports. Typed TypeScript and Python clients are generated from the OpenAPI contract, so your application writes typed calls and keeps its own screens.
The interface stays yours; the numbers carry IngaDB's revision-stamped provenance — so "which evidence produced this probability, computed as of when" is answerable from outside your app too.
3. Between documents and agents
Most of an organization's causal knowledge lives in reports, FMEA sheets, and veteran engineers' heads. In this placement, a coding agent (Claude Code, Codex, or similar) assembles candidates from the documents, a person approves them, and IngaDB validates and computes. The agent bootstraps itself from the guide ingactl skill --format claude-skill generates, and every write goes through a dry-run and confirmation.
The result: veteran know-how survives as mechanism facts — data, not prose — compilable into a tree for any hazard, indefinitely. Scenario 3 of the examples is this placement end to end.
In every placement, IngaDB's job is storing, validating, and deterministically computing causality. Anomaly detection, time-series storage, and screen-building remain the neighbors' jobs — and the clearer that boundary, the more independently each layer can be swapped.