# DamageBDD Vision: Independently Verifiable Work An evidence-native platform for building, operating, verifying and exchanging software and digital services. Canonical HTML: ## Work should arrive with evidence DamageBDD is an evidence-native platform for building, operating, verifying, and exchanging software and digital services. The aim is to make the requirement, the work performed, the resulting artifacts and the acceptance decision independently inspectable. Behaviour-driven development supplies the starting point: an expectation someone can execute and challenge. The wider platform brings together execution, knowledge retrieval, local operations, signed communication and payment-related workflows around that record. | Perspective | Direction | | --- | --- | | Product | Verifiable execution: run an agreed scenario and inspect its result | | Platform | Evidence-native digital operations: connect knowledge, actions, artifacts and permissions | | Long-term vision | Independently verifiable work that can be reviewed, reused and exchanged across organisations | ## A shared evidence lifecycle 1. **Specify**: agree the behaviour, target, constraints and acceptance criteria. 2. **Execute**: record the inputs, software revision, environment and observations. 3. **Retain**: keep retrievable artifacts with content identities and access rules. 4. **Retrieve**: find the relevant record and inspect its source and release. 5. **Review**: decide whether the evidence satisfies the agreed scope. 6. **Exchange**: associate accepted work with explicit delivery and payment terms. These are the platform's organising principles. They are not a claim that one installed release already automates the entire lifecycle. ## Principles that guide the engineering - Evidence belongs with the claim: a report identifies what ran and what it observed. - Identity and integrity are distinct from accuracy: a signed record can still be wrong. - Permission to retrieve, sign, execute and spend must be granted separately. - Operators should be able to inspect dependencies, export records and recover work. - AI-assisted answers and repairs need sources, bounded authority and review. - A useful first deployment should solve one measurable problem. ## Earn broader automation through demonstrations The immediate adoption path is a scoped verification engagement: reproduce a failure, agree the expected behaviour, run the change and hand over a report that another person can inspect. Add private retrieval, signing, media or local voice when the workflow needs them. Independent multi-node verification, consensus-based job allocation and settlement, reusable knowledge markets and direct exchange of verified features are longer-term directions. Each needs its own implementation, failure handling and release evidence. Source code for a component does not establish a working marketplace or economic outcome. Business intelligence is a possible application of the indexing and LLM bridge: retain dataset provenance and licence permissions, find relevant organisations, and connect a proposed solution to tested features. This page does not certify a BI dashboard, dataset preset or sales outcome; those need release-specific documentation and evaluation. ## Read the platform as it stands The [platform map](platform.md) explains the components. The [capability matrix](articles/features_current.md) is the status entry point. The [solutions guides](solutions/index.md) turn the direction into bounded customer evaluations. Research hypotheses belong in [ECAI research](ecai/research.md), with their assumptions and experiments stated explicitly.