liminis-context-graph v0.16.0 — entities get a kind, and lbug 0.21.0

[verveguy]

v0.16.0 gives entities a kind, so same-named entities of different kinds (Person "Aurora" and Technology "Aurora") now coexist instead of merging. The graph engine also moves to lbug 0.21.0. This is the first release where lbug's core and its vector and full-text extensions are built for the same version. First start migrates entities, and downgrade is unsupported, so read Upgrading before you take it. There is no storage migration.

Upgrading

1. Back up .lcg/ first if you might roll back. A pre-0.16.0 binary cannot replay a WAL written by 0.16.0, because lookup_key is no longer written to the WAL. Rolling back means restoring that copy.

2. First start migrates entities, automatically and once.

   • Every existing entity gets kind Entity.
   • lookup_key is re-keyed as group ␟ kind ␟ lower(name).
   • labels is normalized so Entity comes first. The label set is unchanged.

   On a real notebook this added about 3 seconds to the first start.

3. No storage migration. Databases stay at storage version 47, so a 0.15.x database opens as-is. A 0.14.x database migrates 42 → 47 exactly as it did under 0.15.0.

4. One behaviour change to know about: a name-only entity resolution that matches more than one kind now fails with JSON-RPC -32002 and a list of candidates, instead of picking one. Everything else in the API is additive.

What's new

• Kind-scoped entity identity (ADR-0615):
  • knowledge_assert_entity takes kind.
  • knowledge_assert_relationship takes source_kind and target_kind.
  • knowledge_find_entities and knowledge_list_entities can filter by kind.
  • There is a new knowledge_resolve_entity read tool.
  • Merges never cross kinds.
• Ontology-driven kinds (ADR-0616):
  • Mark an entity type identity: true, and entities extracted as that type take it as their kind.
  • Existing ontologies, which have no flags, behave exactly as before.
  • A change to a group's identity set that would reinterpret existing entities is refused rather than applied silently.

Why lbug 0.21.0, now

On 2026-09-29 upstream republished its v0.20.0 extension binaries. The Windows files became 0.20.4-era builds, which crash full-text index creation under the 0.20.3 core that 0.15.0 used. The bytes 0.15.0 was verified against are no longer served. Installed 0.15.0 copies are unaffected, because they carry their extensions inside the release archive.

lbug 0.21.0 publishes extensions under their own v0.21.0 path, built for the 0.21.0 core. This resolves LadybugDB/ladybug#971 as far as this project can observe. On Windows 11, the vector and full-text suites run clean on it.

Two safeguards landed with this upgrade:

• Release builds verify the extension bytes against pinned sha256 hashes, so an upstream republish now fails the build instead of shipping. The check caught this republish the first time it ran.
• Windows CI now creates and queries real vector and full-text indexes, instead of only confirming the extensions load.

What was verified

• Published artifacts: all four archives pass their checksums, every bundled extension matches its pinned hash, and the macOS binary reports 0.16.0.
• Real-data upgrade. A real notebook written by 0.14.x (198 entities, 246 relationships, 51 episodes) was upgraded directly and via 0.15.0, then compared against 0.15.0:
  • All counts and all 693 stored vectors are identical.
  • 100 of 100 searches are byte-identical in results, order and scores.
  • The storage header was confirmed 42 → 47 on disk.
• Windows 11 x64:
  • lbug-level: vector 45/45 and full-text 10/10, checking every returned row.
  • lcg's semantic end-to-end suite: 20/20.
  • A 0.18.1-era database through migration, reopen and WAL rebuild, with the header confirmed 42 → 47.
  • Zero crash-reporting events.
• macOS: the full suite passed (1,650). The sidecar-gated replay battery ran with no skips.
• Linux: full CI, including every real-corpus end-to-end job.

Two caveats, stated plainly:

• Embedding recompute is not bit-exact on the release machine: minimum cosine is 0.99995, where 0.15.0 recorded 1.000000. This isn't caused by 0.16.0. The shipped v0.15.0 gives identical figures on the same machine with the same embedding sidecar, so the embedding environment changed, not the release. It has no practical effect on search.
• This release skipped the usual release-candidate soak. The Windows and real-data checks above ran on development builds of the release code, not on these published archives.

Full detail: docs/releases/0.16.0.md · CHANGELOG