Current Features: DamageBDD, ECAI, erm and Nosternity
Start with a useful workflow
Read Build an operational memory: a practical guide to the stack to choose a small adoption pilot. The articles below explain who each feature helps, what the source implements and how to evaluate it against a known problem. They are based on the application sources uploaded on 5 October 2026.
| Article | Practical entry point | Evidence in this review |
|---|---|---|
| DamageBDD acceptance evidence | Reproduce a service behaviour and share its report | Runner, HTTP, schedules and release-discovery source |
| ECAI engineering memory | Retrieve approved records and inspect code relations | Private retrieval, relation learning and index-job source |
| ECAI reviewable repairs | Retain the context and checks around a generated patch | Incident, preflight, verifier and capsule source |
| erm local voice and desktop | Control media and query an appropriate local corpus | Erlang coordination and adapter source; native hardware untested |
| Nosternity event retention | Store selected signed events with confirmation tracking | Current event store, supervisor and relay source; delivery/recovery gaps identified |
| Blossom supporting files | Retrieve bytes matching a known digest | HTTP, signed authorization, storage and ownership source |
Detailed implementation references
| Reference | Scope and status |
|---|---|
| ECAI private knowledge retrieval | Private implementation now present in the current archive; fresh runtime validation not performed |
| ECAI deterministic relation processing | Typed relations and structural evaluation code present; no benchmark score recorded |
| DamageBDD Nostr interfaces | Source-observed client interfaces and their transport boundaries |
| Nostr reliability and reply correlation | Historical 25 September live-bunker result and transport corrections |
| nsecbunker custody and policy | Historical 12-scenario release-build run; it does not certify this whole source snapshot |
What the new source changes
Blossom is no longer documented only from a development update: the current archive includes its HTTP facade, authorization verifier, rate limiter and shared ownership store. Nosternity now explicitly supervises its relay and Aeternity event store, validates events and supports cache rehydration. Its subscription filtering/broadcasting and pending-write durability remain incomplete. Those details supersede the historical July snapshot descriptions.
ECAI's private-index and LLM-bridge modules are present in this source tree. The previously reported unsafe-variable pattern in the log bridge is changed, but that observation is not a successful compilation result. The new erm article documents a real retrieval connection to ECAI's public disk corpus; private voice access still requires its own authenticated integration.
How to interpret evidence
A source review establishes the inspected implementation, its apparent control
flow and its dependencies. A test file establishes a described test case, not
that the test passed. A build or live result establishes only its recorded
revision, environment and scenarios. The EVIDENCE_DATE on new articles is
the source-review date; VALIDATION_STATUS is source_review_only.
The 25 September bunker report remains historical evidence for that run. It is not reused as verification for Blossom, private retrieval, voice, Nosternity persistence or a new release. Generated documentation timestamps are also separate from feature verification dates.
Deterministic relation encoding establishes repeatable identity. A signature binds an event to a signing key; a digest identifies bytes. None of those properties establishes the truth of arbitrary content. Model answers and application conclusions need their own supporting evidence.
Review scope
The source basis is latest-apps.tar.gz and the documentation baseline is
latest-org.tar(1).gz, uploaded 5 October 2026. The review followed selected
feature paths and tests; it is not an exhaustive security audit of every
application module.
The application archive lacks the repository's rebar.config, contract tree,
native C/C++ sources, relevant include directories and deployed configuration.
No full build, EUnit/CT suite, audio device test, model inference, payment,
chain transaction or production service operation was performed. Documentation
exports and links are checked separately.
Proposed pilot steps are acceptance goals unless explicitly identified as existing scenario vocabulary or API calls. Use the complete matching release, record its revision and configuration, and retain its own results when moving from a source-level evaluation to a deployment claim.
