nsaspy/prolog-rlm

Fork 0

[RESEARCH][semantic-store] Evaluate CouchDB as an append-only replicated semantic-ledger transport for Prolog-RLM #390

New issue

Open

opened 2026-09-08 01:29:17 +00:00 by nsaspy · 1 comment

nsaspy commented

2026-09-08 01:29:17 +00:00

Owner

Related: #388 #392 #394 #400 #402
Downstream boundary: lost-rob0t/symbolic-memory

Research question

Determine whether CouchDB is a good physical transport/storage adapter for the append-oriented symbolic-knowledge architecture without treating CouchDB as the reasoner, truth oracle, or a magical CRDT database.

Target conceptual split:

source / semantic compiler
        ↓
immutable semantic assertions + lifecycle events
        ↓
CouchDB replication / durability / _changes
        ↓
materialized Prolog knowledge view
        ↓
reasoning / truth maintenance / verification

This is a research/design issue only. Do not implement a CouchDB backend here.

Core questions

Research and record:

Which CouchDB guarantees are actually useful here: MVCC, revision trees, replication, conflict detection, _changes, partitioned DBs, Mango/indexes, attachments, checkpoints?
Which guarantees CouchDB explicitly does not provide, especially semantic CRDT merge or application-level conflict resolution?
Can immutable uniquely-IDed assertion/event documents make the common write path effectively conflict-free through set-union semantics?
What identity scheme is required so logically identical retries deduplicate while independent sources remain distinct assertion episodes?
How should retraction, supersession, correction, redaction, quarantine, and source withdrawal be represented without destructive overwrite?
How should CouchDB revision conflicts be treated if they still occur in metadata/control documents?
How should _changes sequence/checkpoint state map to exact semantic frontiers without confusing CouchDB sequence tokens with semantic truth/time?
What data belongs in CouchDB versus rebuildable Prolog tables/materialized indexes?
What is the crash/replay contract for ledger commit -> changes feed -> Prolog materialization -> checkpoint?
How should multi-node replication interact with provenance/source-independence so replicas do not masquerade as independent corroboration?
What are the operational limits: large-document count, compaction, view/index rebuilds, conflict volume, replication lag, attachment behavior, backup/restore, redaction requirements?
Does CouchDB remain a good first adapter once #402 SAFIRE requirements are applied, or should it be explicitly scoped to a smaller profile?

Candidate document model

Research a model where CouchDB stores immutable records such as:

semantic_object
assertion_episode
support_episode
source/span record
retraction / withdrawal
supersession / correction
conflict/corroboration relation
commit/batch metadata
materialization checkpoint

Prefer append-only lifecycle events over last-write-wins mutation of a global truth document.

A proposition and an assertion episode must remain distinct per #392.

CRDT-like semantics to evaluate

Evaluate whether the immutable assertion/event collection can safely use an application-level grow-only-set style merge:

merge(A, B) = A ∪ B

and where this stops being sufficient.

Compare at least:

G-Set style immutable event accumulation;
2P-Set / remove-marker approaches;
OR-Set style observed-remove semantics;
append-only event sourcing with active-state projection;
CouchDB native conflict trees without semantic merge;
an actual CRDT store as an alternative.

Do not call CouchDB itself a CRDT unless the exact property being claimed is proven.

Prolog materialization boundary

Define the required adapter contract between a durable semantic ledger and Prolog. Questions include:

initial cold rebuild
incremental consume
checkpoint / resume
duplicate delivery
out-of-order replicated arrival
retraction / supersession invalidation
schema/profile upgrade
source redaction / unavailable payload
integrity failure
rebuild equivalence

Required invariant to investigate:

same canonical ledger cut
=> cold rebuild == warm materialization == incremental materialization

under a normalized semantic comparison.

Repository boundary

Preserve #402's ownership split unless research produces a strong reason to revise it:

prolog-rlm: semantic record contracts, reasoning profiles, materializer/replay semantics, conformance expectations;
symbolic-memory: concrete durable storage adapters and physical CouchDB integration if adopted.

Do not make prolog-rlm depend directly on CouchDB merely because this research evaluates it.

Required outputs

Produce a durable research record containing:

exact CouchDB guarantees and non-guarantees with primary sources;
at least 3 candidate ledger/document models;
CRDT comparison matrix;
failure/adversarial analysis;
proposed semantic-store adapter contract;
replay/checkpoint/frontier semantics;
storage-vs-Prolog ownership table;
benchmark/fault-injection plan;
recommendation: adopt, adopt for limited profile, or reject;
concrete follow-up issue changes, if any.

Acceptance

Does not conflate CouchDB replication with semantic CRDT merge.
Immutable assertion/event strategy is evaluated explicitly.
Retraction/correction/supersession semantics are non-destructive and provenance-preserving.
Replica copies cannot become fake independent corroboration.
Exact cold-vs-incremental rebuild oracle is specified.
Crash, duplicate delivery, reorder, replication lag, and conflict cases are covered.
Result is reconciled against #402 SAFIRE rather than creating a parallel persistence architecture.
Final recommendation states the narrowest profile for which CouchDB is actually defensible.

Non-goals

no CouchDB implementation in this issue;
no new truth semantics; #394/#400 own reasoning;
no destructive mutable current truth document as canonical state;
no assumption that database conflict resolution equals epistemic conflict resolution;
no Clojure/Datomic dependency.

Related: #388 #392 #394 #400 #402 Downstream boundary: `lost-rob0t/symbolic-memory` ## Research question Determine whether CouchDB is a good physical transport/storage adapter for the append-oriented symbolic-knowledge architecture without treating CouchDB as the reasoner, truth oracle, or a magical CRDT database. Target conceptual split: ```text source / semantic compiler ↓ immutable semantic assertions + lifecycle events ↓ CouchDB replication / durability / _changes ↓ materialized Prolog knowledge view ↓ reasoning / truth maintenance / verification ``` This is a **research/design issue only**. Do not implement a CouchDB backend here. ## Core questions Research and record: 1. Which CouchDB guarantees are actually useful here: MVCC, revision trees, replication, conflict detection, `_changes`, partitioned DBs, Mango/indexes, attachments, checkpoints? 2. Which guarantees CouchDB explicitly does **not** provide, especially semantic CRDT merge or application-level conflict resolution? 3. Can immutable uniquely-IDed assertion/event documents make the common write path effectively conflict-free through set-union semantics? 4. What identity scheme is required so logically identical retries deduplicate while independent sources remain distinct assertion episodes? 5. How should retraction, supersession, correction, redaction, quarantine, and source withdrawal be represented without destructive overwrite? 6. How should CouchDB revision conflicts be treated if they still occur in metadata/control documents? 7. How should `_changes` sequence/checkpoint state map to exact semantic frontiers without confusing CouchDB sequence tokens with semantic truth/time? 8. What data belongs in CouchDB versus rebuildable Prolog tables/materialized indexes? 9. What is the crash/replay contract for `ledger commit -> changes feed -> Prolog materialization -> checkpoint`? 10. How should multi-node replication interact with provenance/source-independence so replicas do not masquerade as independent corroboration? 11. What are the operational limits: large-document count, compaction, view/index rebuilds, conflict volume, replication lag, attachment behavior, backup/restore, redaction requirements? 12. Does CouchDB remain a good first adapter once #402 SAFIRE requirements are applied, or should it be explicitly scoped to a smaller profile? ## Candidate document model Research a model where CouchDB stores immutable records such as: ```text semantic_object assertion_episode support_episode source/span record retraction / withdrawal supersession / correction conflict/corroboration relation commit/batch metadata materialization checkpoint ``` Prefer append-only lifecycle events over last-write-wins mutation of a global `truth` document. A proposition and an assertion episode must remain distinct per #392. ## CRDT-like semantics to evaluate Evaluate whether the immutable assertion/event collection can safely use an application-level grow-only-set style merge: ```text merge(A, B) = A ∪ B ``` and where this stops being sufficient. Compare at least: - G-Set style immutable event accumulation; - 2P-Set / remove-marker approaches; - OR-Set style observed-remove semantics; - append-only event sourcing with active-state projection; - CouchDB native conflict trees without semantic merge; - an actual CRDT store as an alternative. Do not call CouchDB itself a CRDT unless the exact property being claimed is proven. ## Prolog materialization boundary Define the required adapter contract between a durable semantic ledger and Prolog. Questions include: ```text initial cold rebuild incremental consume checkpoint / resume duplicate delivery out-of-order replicated arrival retraction / supersession invalidation schema/profile upgrade source redaction / unavailable payload integrity failure rebuild equivalence ``` Required invariant to investigate: ```text same canonical ledger cut => cold rebuild == warm materialization == incremental materialization ``` under a normalized semantic comparison. ## Repository boundary Preserve #402's ownership split unless research produces a strong reason to revise it: - `prolog-rlm`: semantic record contracts, reasoning profiles, materializer/replay semantics, conformance expectations; - `symbolic-memory`: concrete durable storage adapters and physical CouchDB integration if adopted. Do not make `prolog-rlm` depend directly on CouchDB merely because this research evaluates it. ## Required outputs Produce a durable research record containing: - exact CouchDB guarantees and non-guarantees with primary sources; - at least 3 candidate ledger/document models; - CRDT comparison matrix; - failure/adversarial analysis; - proposed semantic-store adapter contract; - replay/checkpoint/frontier semantics; - storage-vs-Prolog ownership table; - benchmark/fault-injection plan; - recommendation: `adopt`, `adopt for limited profile`, or `reject`; - concrete follow-up issue changes, if any. ## Acceptance - [ ] Does not conflate CouchDB replication with semantic CRDT merge. - [ ] Immutable assertion/event strategy is evaluated explicitly. - [ ] Retraction/correction/supersession semantics are non-destructive and provenance-preserving. - [ ] Replica copies cannot become fake independent corroboration. - [ ] Exact cold-vs-incremental rebuild oracle is specified. - [ ] Crash, duplicate delivery, reorder, replication lag, and conflict cases are covered. - [ ] Result is reconciled against #402 SAFIRE rather than creating a parallel persistence architecture. - [ ] Final recommendation states the narrowest profile for which CouchDB is actually defensible. ## Non-goals - no CouchDB implementation in this issue; - no new truth semantics; #394/#400 own reasoning; - no destructive mutable `current truth` document as canonical state; - no assumption that database conflict resolution equals epistemic conflict resolution; - no Clojure/Datomic dependency.

nsaspy referenced this issue

2026-09-08 01:29:20 +00:00

[EPIC][artifact-synthesis] Typed symbolic artifact generation, validation, and repair substrate #407

nsaspy referenced this issue

2026-09-08 01:46:59 +00:00

[EPIC][cyber-harness] Generic Prolog-RLM cyber reasoning harness for Hackmode/Hackpert #409

nsaspy commented

2026-09-08 01:48:08 +00:00

Author

Owner

we should look into local databases too, this is more so a starintel problem not a prolog-rlm issue
or even non databases too

we should look into local databases too, this is more so a starintel problem not a prolog-rlm issue or even non databases too