DamageBDD: Turn Acceptance Criteria into Evidence You Can Share

“It worked on my machine” leaves the next person with an investigation. A useful acceptance record tells them what was requested, what was observed, which version ran and where to inspect the result.

DamageBDD connects a readable behaviour specification to an execution and its report. This is a practical entry point for API teams, integration developers, service operators and contractors agreeing on a delivery boundary. The first adoption goal can be small: turn one recurring support issue into a scenario that another person can run and understand.

Behaviour-driven development (BDD) describes a requirement as an example someone can run. In a Gherkin scenario, Given establishes the starting conditions, When describes an action, and Then checks the result. Support can explain the failure in the same terms a developer uses to reproduce it.

For example, an integration may need an API to return both a successful status and a particular JSON field. Checking only the status can miss a breaking change. A short scenario makes the complete expectation explicit and keeps it available for the next release.

The following is an illustrative scenario using sentence patterns implemented in steps_http.erl. The reserved example host and response are placeholders; replace them with an authorised test service. This example was not executed during the review.

Feature: Service readiness is visible to clients

  Scenario: The readiness endpoint reports a healthy service
    Given I am using server "https://service.example"
    When I make a GET request to "/health"
    Then the response status must be "200"
    And the json at path "$.status" must be "ok"

The supported vocabulary gives the example its meaning. Add scenarios for the failures your users actually experience: a refused request, a missing dependency or an incorrect response field. New sentences require matching step implementations; ordinary prose alone is not executable coverage.

The runner publishes the report directory through IPFS after run metadata is written. The returned record includes feature_hash, report_hash, release information and encrypted-context references. This gives a handoff a stable content reference instead of relying on a screenshot or a mutable copy of a log.

That distinction is useful when a customer and supplier disagree about a regression. They can refer to the same scenario and report, then compare a later run against it. Content addressing detects changed bytes; continued availability still depends on retention, pinning and the serving infrastructure. The observations remain those of the executing environment.

A failed run may also have a report hash. The HTTP execution code handles explicit failure fields before the ordinary report-hash success branch. Integrations should inspect the result and failing step, and should distinguish dry-run output from an executed check. Saving a report is not itself success.

The scheduling code stores a feature reference with account, schedule and concurrency information, registers execution through the schedule index, and records execution state. That supports a useful progression: prove a scenario manually, then run it on a schedule to detect a recurrence.

Configuration, account state and downstream services are part of that operational path. A pilot should include restart recovery, one expected failure and a check that the reported schedule corresponds to the intended feature. It should also establish resource use before raising concurrency. The source review provides no throughput measurement or planetary-scale capacity result.

The release NFT discovery implementation reads a selected release and platform, resolves metadata through a local validating Kubo daemon, and exposes installation fields including the package digest. Publication verification compares release, platform, Git identity, metadata and asset references.

For operators, the adoption value is traceability: which artifact did a report or deployment refer to? The code separates read-only discovery from explicit account-signed state changes. A token or CID identifies an artifact; it does not replace the build tests or establish that the software is defect-free. Use the repository's installation guide for a matching release and keep its build identity with the result. The workflow described here has not been validated by a new installation or chain operation for this article.

Pick a customer-facing API behaviour with a known failure mode. Write a passing scenario and a negative case. Preserve the feature, release identity, execution result and report references. Ask a colleague to reproduce the result from those records, then repeat through the scheduler.

The pilot succeeds when both people can explain the same outcome from the same evidence, and a deliberately failing case remains visible as a failure. Only after that should you extend the workflow into custody, payments or cross-node verification. Those paths need their own acceptance evidence.

Start with the HTTP step reference when writing a scenario; use the code links when you need to inspect how the result is executed and recorded.

• Scenario execution and report assembly
• HTTP execution results and failure handling
• Implemented HTTP scenario vocabulary
• Scheduled feature execution
• Release discovery and artifact verification
• Damage application tests

These references identify the implementation. No new application execution, payment or release installation was run for this article.

• Write an HTTP scenario
• Use the DamageBDD manual
• Read a separately recorded acceptance example
• Choose the next component