Build an Operational Memory: A Practical Guide to the DamageBDD Stack
Keep the explanation with the evidence
A team fixes a service failure, explains the workaround in chat and moves on. A month later, someone asks why the change was made. The test is in one system, the deployment version in another, and the person who remembers the details is unavailable.
An operational memory is the set of records that lets another person recover that explanation: what was expected, what happened, which version ran, and which source supports the answer. The DamageBDD stack provides components for building that record and making it useful during everyday work.
DamageBDD runs readable behaviour checks and produces reports. ECAI retrieves documents and represents relationships in code. erm offers voice and native desktop controls. Nostr supplies signed messages, Blossom stores supporting files, and Nosternity explores longer-term retention of selected events. You can begin with the component that solves your immediate problem.
Choose a starting point
| Your immediate problem | Start with | First useful result |
|---|---|---|
| A customer cannot reproduce a service failure | DamageBDD acceptance evidence | A readable scenario and its exact run report |
| Answers are scattered across private records | ECAI engineering memory | A supporting record with its source and access decision |
| Generated code changes take too long to review | ECAI repair review | A candidate patch tied to a revision and validation output |
| Routine desktop controls interrupt focused work | erm voice and desktop tools | A spoken command with an observable action result |
| Applications need supporting files readers can verify | Blossom media storage | Downloaded bytes matching the expected digest |
| Selected signed events need a retention policy | Nosternity event retention | A contract and integration plan, with current repository gaps identified |
These components have different requirements. A voice pilot needs a working microphone and audio models. A private knowledge pilot needs a defined corpus and permissions. A retention pilot needs a complete event-store integration and a configured chain. Starting with one component keeps the result easy to understand and the work small enough to evaluate.
Follow one incident through the stack
Imagine an API that returns success but omits a field a customer needs. A DamageBDD scenario can describe the expected response and preserve both the failing run and the run after the fix. The report becomes a shared reference for the customer, support team and developer.
An approved incident note can then explain the cause and refer to the report. ECAI can retrieve that note for a later question, while its relation layer helps identify the modules and functions involved. The note records an explanation; the scenario records an observation. Keeping both makes a future answer easier to assess.
If the result needs to be announced outside the team, an application can publish a signed Nostr event containing the report reference. Blossom can hold a supporting file addressed by its SHA-256 digest. A digest is a fingerprint of the file's bytes: changing the file changes its identity. It helps a reader check the attachment without relying on its filename.
This is an integration pattern to build and test. The application must link the feature, report, release, source record, event and attachment explicitly. The components do not automatically assemble that whole history. A signature identifies the signing key, while the report and source records explain the claim being signed.
Know what you are preserving
| Record | Question it helps answer |
|---|---|
| Behaviour scenario | What did we expect the service to do? |
| Execution report and release identity | What happened, and which software ran? |
| Source document and retrieved excerpt | What supports this explanation? |
| Code relation and its premises | Which dependency was derived, and how? |
| Signed event | Which key published this statement? |
| Attachment digest | Are these the same bytes that were referenced? |
Content references remain useful only when the referenced data can be retrieved. Decide who retains reports and attachments, who may read private records, and how those records are backed up. These operating choices are part of the workflow.
Run a small, useful evaluation
Choose one service, one reproducible failure and a small set of non-sensitive records. Agree on the expected outcome before the demonstration.
- Write a supported DamageBDD scenario. Keep a passing run and a deliberately failing run, together with their report references and release identities.
- Index an approved explanation in ECAI. Ask a question with a known answer and another whose answer is absent. Check access denial and model-destination policy separately if private data is in scope.
- Ask another person to reconstruct the incident from those records. Measure the time needed to find the explanation and the number of missing details.
- Add voice access, signed announcements or attachment storage when one of those makes the workflow more useful. Private voice access requires an authenticated integration; erm's existing retrieval route uses a public disk corpus.
For Nosternity, complete the missing event-store integration described in its article before treating chain retention as an available step in this workflow.
Start from the repository
The DamageBDD repository contains the application code and operating guides. Use the installation instructions for the revision you intend to run, and record that revision with your results. The article source links pin the code examined for these explanations; they remain useful even after the development branch moves.
Bring one reproducible problem, the expected output and the data you can use to the first integration discussion. That gives the project a concrete starting point and gives your team a result it can judge.