Behaviour Driven Development · At Planetary Scale

Don’t just ship code.
Ship evidence.

Turn plain-language expectations into executable checks. Run them against real systems, inspect the results, and build a record of what your software actually does.

Open source. Erlang/OTP. Evidence over assumptions.

service-health.featureExecutable specification
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"
01 / SPECIFYExpected behaviour
02 / EXECUTEActual behaviour
03 / INSPECTRecorded evidence

Illustrative feature, not a live test result. Replace the example endpoint before running.

A composable, open stack

Erlang / OTPBitcoin / LightningIPFSNostr

Plain language in. Verifiable evidence out.

Make the requirement, the execution and the evidence part of the same conversation.

Define what matters

Write a feature that describes the behaviour you need. Give developers, testers and stakeholders the same concrete expectation to work from.

Write your first feature →

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.

Explore the modules →

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.

Build an evidence workflow →

Start with a real problem.

One stack. Different entry points. Choose a small, testable first evaluation.

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.

Open the quick start →

Retrieve engineering knowledge

Explore ECAI indexing and retrieval for source collections, engineering records and evidence-backed answers. Start with a corpus you can inspect.

Explore engineering memory →

Run your own infrastructure

Follow the installation and node guides. Understand the configuration, operational responsibilities and validation limits before deployment.

Read the installation guide →

A stack you can inspect.

The wider project connects verification, knowledge retrieval and signed-event workflows. Each component has its own implementation and validation scope.

Implementation is not the same as live verification. The component map 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.

Indexing workflows →

Nosternity

Explore Nostr event retention and the integration points around signed records. Read the documented limits before choosing a deployment.

Read the implementation guide →

erm

Bring local voice and desktop workflows into an Erlang-managed environment. Begin with an observable, bounded action.

Explore local workflows →

Go deeper. Keep it practical.

Follow the stack adoption guide, browse the implementation articles, or take the longer route through the DamageBDD book.

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.

DamageBDD — Behaviour Verification at Planetary Scale book cover

Search documentation

Search titles, summaries and document paths.