DamageBDD Capability Matrix: Implementation and Evidence
The status entry point for execution, knowledge, operations, signing, retention, media and payments, with dated evidence and integration limits.
Use the status for the workflow you need
DamageBDD's platform map describes the component roles; this matrix is the documentation status entry point. It reconciles the linked implementation guides and their evidence, not a fresh review of application source or a live health check. Start with a solution when evaluating a customer outcome.
How to read a capability claim
| Status in a reference | Meaning |
|---|---|
source_present / components_present |
Implementation was described in the referenced source review; runtime success is separate |
partial_implementation |
A concrete path remains incomplete or has a recorded integration gap |
patch_supplied |
A separate pilot exists; inclusion in a public application release is not established |
evaluation_blueprint / documented_components |
An evaluation is proposed using documented components; the assembled workflow is not certified |
source_review_only |
Source was inspected at the stated evidence date; tests were not executed for that review |
live_suite_passed / partial_live_coverage |
A named live run covers only its release, environment and scenarios |
local_smoke_and_tests_passed |
Local pilot checks passed within the scope stated by that reference |
documentation_review_only |
Editorial synthesis; no new application validation |
A LAST_MODIFIED date describes the page. EVIDENCE_DATE and
VERIFIED_RELEASE describe the underlying evidence. A publish timestamp
cannot promote a component to a newer release or a broader validation scope.
Capability matrix
| Capability and reference | Implementation described | Evidence and remaining boundary |
|---|---|---|
| Scenario execution, schedules and reports | Runner, result handling, report references and accounting paths | Source review, 6 October; no new execution, payment, load benchmark or release-installation run |
| Engineering memory and LLM bridge | Indexing, source retrieval and model-dispatch interfaces | Source review, 6 October; no retrieval benchmark or live model demonstration |
| Managed indexing jobs | Durable queue, adapters, ingestion and disk publication | Source review, 6 October; recovery and live publication still need execution evidence |
| Wikipedia collections | Corpus selection, indexing and snapshot workflow | Source review, 6 October; no full-corpus build or chain transaction |
| Search and record proofs | Search, proof construction and snapshot activation | Source review rechecked 7 October; exact wikidata_id filtering and snapshot-digest checks remain open in that review |
| Private retrieval and controlled LLM access | Corpus permissions, encrypted segments and disclosure boundary | Source review, 6 October; real cryptographic backend and live HTTP/model paths not validated there |
| Typed relation processing | Repeatable relation identities, composition and benchmark source | Source review, 6 October; no executed benchmark score or general reasoning claim |
| Incident learning and repair review | Bridge, learner, checkpointing and candidate-review context | Source review, 7 October; publication gap and concrete-target validation mismatch remain; no automatic repair deployment |
| Versioned index artifacts and NFTs | Artifact metadata and partial mint/payment integration | Source review, 7 October; job mint helper dry-runs and chunk payment is a local placeholder |
| NIP-46 signing policy and custody | Remote signer, configured vault and restricted client policy | 12 live scenarios, 25 September, release 1.7.5-rc2+build.1603.ref28a4047; external-client smoke, rotation, restore and IAM revocation remain separate |
| Nostr identity and event interfaces | Identity-backed clients, event helpers and relay configuration | Partial live coverage from the bunker suite only; general posting, wallet and media flows are not covered |
| Relay delivery and reply correlation | Client/adapter transport and request matching | Same dated bunker suite; no universal relay-availability or latency result |
| Nosternity event retention | Relay/store adapter and selected contract-storage path | 7 October review: pending queue remains volatile; chain writes, recovery and interoperability need validation |
| Blossom files | HTTP handlers, authorisation, ownership store and routing | Source review, 6 October; no live upload, pinning, restart or full client-conformance result |
| erm local voice and desktop | Voice, media, TTS, model-pull and Lens paths with GTKGS integration | Source review, 6 October; microphone, native binaries, playback and UI were not exercised |
| Video reuse and signed revisions | Separately supplied Video Fastpath pilot | 10 October: seven local tests and localhost smoke with a mock provider; no current Erlang build, production launch, live generation, IPFS pin or NFT mint |
| Lightning and DAMAGE accounting | Top-up and execution-spend paths described in the token/execution guides | Documentary model; no fresh settlement or reconciliation run in this revision |
| Nostr search product and paid API / NWC | Evaluation blueprints around documented components | 10 October editorial review; no complete search-dashboard or paid-wallet acceptance evidence |
Broader applications need their own evidence
The vision includes independent multi-node verification, consensus-linked settlement, exchange of verified features and knowledge, and business intelligence built on indexed data. This matrix does not certify those as completed services. Dashboard, BI and browser voice-note workflows needs a versioned implementation reference and acceptance record before being added as validated functionality.
Update a claim without losing its history
For a new release, name the implementation revision, relevant configuration,
scenario set and result artifact. Retain old evidence under its original date.
Use CAPABILITY_ID on implementation references so the publisher can generate
docs/capabilities.json from their status metadata. Collections and vision
pages should not impersonate verified capabilities.
The generated inventory discovers published documents; it is not a live application inventory. This matrix summarises the detailed references, which retain their individual validation scope and release identity.