qilbeeDB: technical assessment and evolution program

Assessment and source retrieval date: September 20, 2026. Scope: Rust code, HTTP execution paths, persistence, retrieval and selected research. This is neither an exhaustive audit nor a systematic review of the entire literature. Third-party experimental results were not reproduced here.

Product decision#

Focus on verifiable memory and continual learning for production agents. The database should preserve experience, represent knowledge and procedures, assemble useful context and record evidence of improvement. The unit of success is a correctly completed task within budget, while retaining earlier abilities.

Storing more text or finding vector neighbors does not demonstrate learning. The database can support behavioral adaptation through external memory; updating model weights requires a separate training system. Operational autonomy can increase through automated evaluation without assuming that any objective or evaluator is perfect. There is no evidence that this project is the best database for agents, or that the hypotheses below are previously undiscovered.

Findings confirmed in code#

Inspected baseline (4341ca4): HTTP server, transactions, memory manager, consolidation, memory types, parser, Bolt.

Research and engineering implications#

The implications below are proposed qilbeeDB design decisions, not claims that the cited work validates this implementation.

Titans/MIRAS and Nested Learning are Google Research work; sources identified as DeepMind above are from Google DeepMind. Engineering reports and preprints have different evidentiary status from independently reproduced results.

Target architecture#

flowchart TB
    I[Authenticated idempotent ingestion] --> E[Durable versioned events]
    E --> K[Temporal knowledge with provenance]
    E --> P[Candidate procedures]
    K --> R[Text, vector and graph retrieval]
    P --> V[Independent evaluation and replay]
    V --> L[Outcome and policy ledger]
    L --> R
    R --> C[Context within budget]
    C --> A[Agent execution in the environment]
    A --> E
    A --> V
    L --> S[Suspension and baseline fallback]

Explicitly distinguish observations, claims, hypotheses, procedures and outcomes. Every derivation should retain source references, extractor version, valid time in the world and transaction time in the database. A correction should end a claim's validity while preserving history rather than silently replacing a fact.

Memory policy should use verifiable outcomes and resource budgets to decide what to acquire, retrieve, compact, invalidate and forget. Preserve experiences that contradict the prevailing procedure to avoid confirmation loops. The current ledger is an initial component of this architecture, not its entirety.

Specific research hypotheses#

These are hypotheses for experimentation, not demonstrated discoveries or novelty claims. Surprise, consensus and model confidence can provide signals; they are never automatic certificates of truth.

Evaluation protocol for state-of-the-art comparisons#

1. Freeze the experiment: commit, hardware, dataset revision and license, model/embedding, prompts, tokenizer, seeds, grader and cost limits. Separate development, selection and final holdout sets. Do not send private data to external evaluators by default.
2. Compare equal conditions: no memory, full context when feasible, text search, vector RAG, hybrid retrieval and pinned external systems. Include ingestion, consolidation and reconstruction costs, not just query cost.
3. Measure distinct abilities: LongMemEval for updating knowledge, temporal reasoning and abstention; LongMemEval-V2 for environment experience and workflows; MemoryAgentBench for retrieval, test-time learning, long-range understanding and forgetting; LoCoMo for complementary conversational evaluation. Pin each dataset revision and review ambiguous examples.
4. Measure actual operation: task success, recall of all required evidence, temporal errors, calibrated abstention, learning curves, transfer, retention of old tasks, p50/p95/p99 latency, tokens, total cost and stored bytes. High retrieval recall does not substitute for answer quality.
5. Exercise database guarantees: abrupt restart, disk failure, concurrency, duplicate delivery, isolation, deletion including derivatives, index reconstruction and hostile data.
6. Publish artifacts: commands, per-case results, uncertainty intervals, failures, limitations and ablations. Obtain external reproduction before claiming leadership. None of these external benchmarks ran in this stage.

Initial proposed targets, subject to a measured baseline: zero isolation violations in the test suite; zero loss of acknowledged writes in the durable profile under the declared fault model; positive held-out improvement at equal cost; and regression on old tasks within a preregistered limit. Define latency and scale targets per hardware and workload rather than inventing universal numbers.

Deliverables and implementation sequence#

Publish each improvement as a separate feature with acceptance criteria, tests, compatibility notes and a remote repository change. Merge validated features in batches of five PRs. Do not advertise library features as HTTP features before integration. Selection policies may improve agent behavior; general failure-free autonomy and indefinite self-improvement remain research problems.

The maintainer's delivery acceptance contract now fixes P0/P1/P2 priorities. QilbeeDB must operate independently of QMN while absorbing validated capabilities through explicit platform contracts. See the initial QMN semantic mapping; existing promotion mechanisms must not be treated as equivalent without policy and evidence compatibility.

Validation of this delivery#

The first batch contains five features. Roadmap milestone identifiers above describe the broader program, not the chronological PR order:

Validation uses cargo test --workspace --all-targets --locked. No external agent benchmark, paid model evaluation or power-loss simulation was run. Workspace Clippy currently reports pre-existing approx_constant errors in core property tests; it is not a passing gate. Each feature PR records its commands and tested commit.

Pre-existing local SDK and provider changes are excluded from these commits. Existing application databases in data/ and test-data directories were not migrated or rewritten by these features.

Details: storage integrity, learning contract, retrieval, episode lifecycle and atomic graph commits.

Subsequent retrieval and memory research#

The 0.6.0 SciFact report adds external retrieval judgments; it does not qualify agent-task improvement. The experience-memory design reviews the supplied ReasoningBank, ZenBrain and Dream-RSI work and proposes contracts for experience lineage, replay and shared publication.