Skip to content

Let a knowledge base turn off automatic entity merges, independent of governance #1248

Closed

Description

@QuintinBotes

Why

With governance off, the adjudicator still applies a same verdict at confidence ≥ 0.8 (AUTO_CONF in adjudication.rs), after the second look that #889 added for similarity-proposed pairs. On a hosted model that gate held in the identity bench. On a small local model it does not, and there is no switch that keeps the merges for a person while still letting the model do extraction, alignment and chat, because one chat model serves all of them (#470).

What I ran

v0.1.0-rc9 image (888761c), Docker on macOS arm64. Chat model qwen3:30b-a3b-instruct-2507 (Q4_K_M) and embeddings bge-m3, both served by Ollama through its OpenAI-compatible endpoint. One restricted KB with governance off, inferences off and no ontology packs. A statements source received 51 pushes of code-structure statements (833 statements about 647 entities). Entity names were path-qualified so that no two distinct things share a name, for example src/Billing/InvoiceExporter.cs, src/Billing/InvoiceExporter.cs#ExportAsync() and src/Accounts/Account.cs#Account.

What happened

The pushes produced 5,321 adjudicating pairs, almost all from name_vector, because path-qualified names share long prefixes. After about 25 minutes and 78 chat calls, 771 pairs were kept apart, 17 went to human review and 40 were merged automatically. Nearly all 40 merges were wrong, for example:

  • src/Billing/InvoiceExporter.cs#ExportAsync() merged into src/Billing/InvoiceExporter.cs (a method into its file)
  • src/Jobs/RateMigrator.cs merged into src/Accounts/Account.cs#Account (two unrelated types)

The merges are undoable, but on a base that keeps ingesting, the queue grows faster than a person can audit it.

What I'd like

A per-KB setting (for example auto_merge: false) under which a same verdict from the batch step or the second look becomes a human review item instead of a merge, the same way the "no chat model configured" path already sends everything to review. kept verdicts could still close pairs automatically, which keeps the queue small.

I can open the PR against dev (setting, migration, the gate in adjudication.rs and the governance path, plus a test that a same verdict becomes a review item with the switch off) if this direction works for you. If a different shape fits better, such as a configurable AUTO_CONF or a per-source "names are identities" flag for statements sources, I'm happy to follow that instead.

Activity

  1. WaylandYang commented on Oct 22, 2026

    @WaylandYang
    Contributor

    There is no such switch today: a same verdict at 0.8 merges whether governance is on or off, and 0071 ruled out a per-base switch as a dead end. 0071 points this issue at the merge side of the per-source names: identity flag. Could you write that as a short revision of 0071 (a same verdict touching an identity-source entity becomes a review item; kept verdicts still close) so it can land after #1333?

  2. added a commit that references this issue on Oct 22, 2026
  3. Aschenbath commented on Oct 23, 2026

    @Aschenbath
    Contributor

    I'll implement 0071 decision 7 from the design-only #1364 now that #1333 is on dev: a same verdict touching an identity-source entity will wait for human review in both adjudication paths, while kept still closes. I'll include database-backed regressions and the review reason in both languages.

  4. WaylandYang commented on Oct 24, 2026

    @WaylandYang
    Contributor

    Thanks @Aschenbath. @QuintinBotes, you wrote decision 7 in #1364; were you planning the code too? If not, Aschenbath has it.

  5. WaylandYang commented on Oct 29, 2026

    @WaylandYang
    Contributor

    Done by #1425 (with #1333 and #1390): a merge involving a name declared as an identity now waits for human review, per ADR 0071.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions