Build. Operate. Verify.
Keep the evidence.
DamageBDD is an evidence-native platform for building, operating, verifying and exchanging software and digital services. Turn expectations into executable checks, connect the results to their sources, and give each acceptance decision an inspectable record.
Open source. Erlang/OTP. Evidence over assumptions.
Feature: Service health
Scenario: The API is available
Given I am using server "https://api.example.com"
When I make a GET request to "/health"
Then the response status must be "200"
Illustrative feature, not a live test result. Replace the example endpoint before running.
A composable, open stack
Erlang / OTPBitcoin / LightningIPFSNostrPlain language in. Verifiable evidence out.
Make the requirement, the execution and the evidence part of the same conversation. The vision is independently verifiable work; the platform map shows how the components contribute.
Define what matters
Write a feature that describes the behaviour you need. Give developers, testers and stakeholders the same concrete expectation to work from.
Exercise the real system
Run checks through the API and supported modules. Put repeatable verification beside the systems and delivery workflows it is meant to test.
Keep the evidence
Review the report, its inputs and its scope. Use recorded results to support acceptance decisions instead of relying on a reassuring status update.
Start with a real problem.
Choose a small, testable first evaluation from the solutions guides. Start with one service, one corpus or one controlled action.
Verify a service
Turn an API requirement or a recurring production check into a feature. Start with the manual, then inspect the HTTP module reference.
Using Python or an AI agent? Follow the Python and agent quickstart to create an account keypair, fund execution through Lightning or Coinstore, and inspect the test report. Check the account's settlement requirements before funding.
Retrieve engineering knowledge
Explore ECAI indexing and retrieval for source collections, engineering records and evidence-backed answers. Start with a corpus you can inspect.
Run your own infrastructure
Follow the installation and node guides. Understand the configuration, operational responsibilities and validation limits before deployment.
A stack you can inspect.
The platform connects verification, knowledge retrieval, local operations, signed events, supporting media and payment-related workflows. Each component has its own implementation and validation scope.
Check the evidence for the workflow you need. The capability matrix and recorded integration review distinguish what exists, what was exercised and what remains open. A publish date is not proof of a passing test.
ECAI
Index source collections, retrieve records and explore controlled LLM access. Keep the source and its evidence in view.
Nosternity
Explore Nostr event retention and the integration points around signed records. Read the documented limits before choosing a deployment.
erm
Bring local voice and desktop workflows into an Erlang-managed environment. Begin with an observable, bounded action.
Signed records and supporting media
Control which clients may request signatures through nsecbunker and retain supporting files through Blossom. Inspect signing policy and storage evidence separately.
Payments and execution credits
Understand Lightning top-ups, DAMAGE execution accounting and contractor payments as distinct workflows, each with its own confirmation record.
Go deeper. Keep it practical.
Follow the stack adoption guide, browse the implementation articles, or take the longer route through the DamageBDD book.
From behaviour to a
verification economy.
A longer-form introduction to BDD, behaviour-driven operations and the ideas behind verifiable software delivery.
