YantrikDB

TL;DR

Foundation-only release. No new public API. No behavior change at the runtime surface. Sets up the v0.8.x substrate-adoption experiment by extending the memories table schema to v26 — four additive columns that the upcoming WriteResolution API will populate.

If you're already using v0.7.15 and not depending on the engine's main branch directly, you can keep using v0.7.15. v0.7.16 exists so downstream consumers (yantrikdb-server, anyone embedding the Rust engine) have a stable tag to pin against rather than floating against main.

What ships

v26 schema migration (closes #29 via PR #35)

Adds 4 additive columns on the memories table:

| Column | Type | Purpose |
|---|---|---|
| prior_rid | TEXT NULL | Set by the future WriteResolution API when resolution is update_existing / merge_with_existing / supersede_chain; references the prior memory's rid. NULL for append_as_new. |
| resolution_kind | TEXT NULL | One of append / update / merge / supersede / dismiss. NULL on pre-v26 rows. |
| dismissal_reason | TEXT NULL | Non-empty only when resolution_kind='dismiss'. The WriteResolution API will enforce length minimums for High-confidence-tier dismissals. |
| confidence_at_write | REAL NULL | Conflict detector confidence at the moment of the write decision, [0.0, 1.0]. |

Plus 2 partial indexes for the resolution / supersession query patterns:

• idx_memories_prior_rid (partial: WHERE prior_rid IS NOT NULL)
• idx_memories_resolution_kind (partial: WHERE resolution_kind IS NOT NULL)

Plus source-enum normalization: rows with values outside {user, inference, document, system} are coerced to user and the affected count is logged once to meta.source_normalization_log_v26 for forensic visibility.

What does not ship

• No new public engine API. Byte-equivalent at the runtime surface to v0.7.15 from agent callers' perspective; only the schema layout is extended.
• Columns are NULL on every existing row and not yet populated by any write path. The WriteResolution API (#30) lands in a future release and will start populating them as part of the v0.8.x conflict-aware-writes intervention.

Migration impact

Zero. Migration is purely additive:

• ALTER TABLE ADD COLUMN × 4
• CREATE INDEX IF NOT EXISTS × 2
• Idempotent UPDATE memories SET source = 'user' WHERE source NOT IN (...) (only touches rows with non-enum values)

Replay-safe per the v0.7.3 idempotent runner contract — ALTER TABLE errors on already-applied migrations are swallowed cleanly.

Three behavioral tests pin the contract:

• schema_v26_fresh_install_has_provenance_columns_and_indexes
• schema_v26_migration_from_v25_adds_columns_and_normalizes_source
• schema_v26_migration_replay_is_idempotent

Context — the v0.8.x substrate-adoption experiment

v0.7.16 is the foundation layer for the substrate-adoption experiment described in RFC 026. The experiment tests whether the substrate-shaped advantage from the Zenodo paper translates to measurable behavior change at unavoidable agent action points. The first intervention is conflict-aware writes — transaction-semantics resolution modes (append_as_new / update_existing / merge_with_existing / supersede_chain / dismiss_conflict) with confidence-tiered enforcement — which needs these provenance columns to record the chosen resolution per write.

The next substantial engine release will ship the WriteResolution API that populates these columns and produces the conflict-aware-write transaction semantics the experiment needs to measure.

Artifacts

• 25 wheels (Python 3.10–3.14 × macOS x86_64, macOS arm64, manylinux x86_64, manylinux aarch64, Windows AMD64)
• 1 sdist (yantrikdb-0.7.16.tar.gz, 8.25 MB)
• yantrikdb crate on crates.io
• yantrikdb package on PyPI

Upgrade

Standard pip/cargo upgrade. No code changes required. New DBs initialize at v26 directly; existing DBs migrate from v25 → v26 on first open with the new binary.

pip install --upgrade yantrikdb
# or
cargo update yantrikdb