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.

Existing documentation