DamageBDD Platform: From Behaviour to Evidence

DamageBDD connects executable expectations to the records needed to inspect and accept digital work. Its Erlang/OTP stack combines services that can be evaluated separately and composed around a specific workflow.

Component	Role in the platform	Start here
DamageBDD	Execute Gherkin scenarios against supported interfaces; produce reports and execution accounting	Acceptance evidence
ECAI	Index and retrieve records, inspect typed relations, control private-corpus access and support LLM-assisted review	Knowledge and reasoning interfaces
erm	Provide local voice, media and desktop interaction with configured services	Local operations
Nosternity	Retain selected signed Nostr events through a relay and contract-storage integration	Retention and recovery boundaries
DamageBDD Nostr and nsecbunker	Manage identity-backed event workflows and policy-controlled remote signing	Nostr interfaces and signer evidence
Blossom	Store and retrieve supporting media by byte identity	Supporting files
Lightning and DAMAGE/Aeternity	Provide payment-related interfaces and execution-credit accounting	Payment flows and token model

GTKGS supplies an Erlang-facing desktop interface used by erm. IPFS supplies content-addressed artifact distribution in the documented workflows. Neither a toolkit nor a content identifier alone establishes end-to-end reliability.

A customer defines an API journey. DamageBDD executes its supported steps and produces a report. ECAI can index approved incident notes and retrieve the records relevant to a failure. A developer reviews a candidate change and reruns the scenario. A release record can associate the build with the report; a signed announcement can refer to it, with attachments stored separately.

Payment remains an explicit workflow with its own state and receipt. A test result, a signature, a content hash and a payment confirmation answer different questions. Connecting them is the integration work; they must not be treated as interchangeable proof.

Record	What can be checked	What still needs evaluation
Scenario and execution report	Declared assertions and recorded observations for that run	Coverage, fixture quality and the target environment
Content hash or CID	Whether retrieved bytes match the expected identity	Continued availability and who selected the trusted reference
Signature	Whether a key signed a particular payload	Key custody, authorisation and the payload's accuracy
Search result and provenance	Which source record and corpus release support an answer	Relevance, completeness and generated-answer quality
Chain or payment receipt	The transaction and confirmation state it records	Correct job linkage, recovery and commercial acceptance

The hosted dashboard is an entry point for the account and execution flows it currently exposes. Self-hosting gives an operator responsibility for keys, backends, retention, network access, upgrades and recovery. Private knowledge, voice and signing each bring additional dependencies.

The public service terms permit test data on the public service. Use synthetic fixtures for public evaluations. A private-corpus capability is not permission to upload confidential records to a public endpoint; establish an appropriate controlled deployment and data terms first.

Consult the capability matrix before selecting a release. Follow a solution guide, then the installation guide or dashboard and API entry points. The vision describes where these components are intended to lead.