DamageBDD Solutions: Choose an Evidence Workflow
Start with software acceptance, private knowledge, signed services or local operations, then evaluate a bounded workflow.
Start with a problem someone owns
Choose an outcome, a controlled target or dataset, and a person who will accept the result. Each path below links to existing evaluation guides and the implementation evidence behind them. These are proposed engagements, not published customer outcomes or a claim that every integration is ready to run.
| Outcome | First demonstration | Evaluation path |
|---|---|---|
| Accept a software change | Reproduce one failure, apply the change and inspect both reports | Software acceptance and release evidence |
| Find the record behind an answer | Answer a small question set from an approved corpus with source references | Private knowledge and incident review |
| Control signing and retain records | Reject an unauthorised signing request and retrieve a permitted artifact | Nostr, media and payment integrations |
| Operate through a local interface | Complete one bounded voice or desktop action and inspect failures | Local operations and self-hosting |
For the full set of buyer-oriented articles, read Start With the Problem. Keep the Evidence. Use the capability matrix to check status before selecting a release. The platform map explains how the parts fit together.
A concrete first engagement
Agree a baseline, acceptance criteria, environment, execution budget and report format. Deliver the scenario or query set, the relevant source/build identities, observed results and remaining failures. The buyer should be able to repeat or inspect the demonstration.
Keep delivery acceptance and payment terms explicit. Discuss the scope through the project contact channels, or begin with the manual on a controlled fixture.