The stack covers several related jobs: checking software behaviour, finding the records behind an answer, reviewing a repair, controlling a workstation, and sharing signed events or supporting files. Each component has its own inputs, dependencies and operating limits.

Start with the practical adoption guide if you want to connect these pieces around one incident or service. Use the map below to go directly to a component. The links in each article lead to the relevant implementation in the DamageBDD repository.

DamageBDD gives a behaviour an executable form. ECAI can retain and retrieve the explanation surrounding that behaviour, and its relation layer describes structural facts such as which function calls another. erm provides a human interface to selected services. Nostr messages and Blossom files let a separate application share references to the resulting records.

The connections are explicit. A signed announcement needs a report reference; an answer needs a supporting document; a repair needs the revision it was prepared against. Those identifiers help another person follow the reasoning without trusting the original author's memory.

Some integrations require additional work. erm's current ECAI voice route uses public disk retrieval, rather than the private corpus API. The public repository also has incomplete incident-learning and Nosternity event-store integration, described below. Choose a complete path for an initial pilot.

The source links in this collection refer to revision a993c0421b38, examined on 6 October 2026. They point to specific files rather than a changing branch. The repository's README and installation guide are the starting points for running a matching checkout.

Two integration gaps are visible at that revision:

• Nosternity's supervisor and relay call nosternity_event_store, but that module and its named test module are absent from the tracked tree. The contract and integration guide are present; the separate configuration example named by that guide is also absent.
• DamageBDD's incident log bridge calls ecai_log_learning, but that module is absent. The repair manager, preflight, verifier and capsule modules are present and can be examined independently of automatic incident ingestion.

These are specific packaging or implementation gaps to resolve before using the affected paths from a clean checkout. A successful documentation build does not resolve them.

Most articles describe source behaviour and provide a proposed evaluation. They do not report a new application build, hardware test, model run or chain transaction. The nsecbunker articles also preserve a dated acceptance report for the release and scenarios named in that report.

That distinction helps you choose the next test. A private retrieval pilot needs access and disclosure checks; a voice pilot needs real audio; a storage pilot needs confirmation and restart recovery. A result from one of those does not establish the others.

The machine-readable metadata records these distinctions in VALIDATION_STATUS, VALIDATION_SCOPE and EVIDENCE_DATE. Current document and capability lists are generated during publishing, so adding or removing an article does not require maintaining a fixed count here.

• Repository overview and quick start
• Installation and operations guide
• Article index
• ECAI implementation guides and conceptual background
• DamageBDD step references
• Node administration