[Judge-M]

A boundary note in docs/KNOWLEDGE_PLANE.md. Docs-only — no code, no schema, no behavior.

The orchestration controller historically named brainconnect-control-model is a Work-plane artifact, renamed connect-control-model and owned by AgentConnect (ADR 0010). It never ran inside BrainConnect, and nothing here imported it — the name was the only thing still implying otherwise.

This is this repository's own boundary, not a new rule. Six of the model's seven decision modes — ROUTE, ASSIGN, REVIEW_PLAN, MONITOR, RECOVER, CLASSIFY — are capabilities ADR 0008 delegates to AgentConnect, under its binding prohibition against duplicating AgentConnect's router, delegation, governor, or observability model. A BrainConnect-named model whose dominant output is a routing decision sits across that line.

Nothing changes in substance. The note says so explicitly, so the correction cannot be misread as walking back the product's determinism claim:

• the brainconnect CLI still makes zero model calls;
• brainconnect-librarian remains the only model-using part of this product, still only to draft candidates for human promotion.

Gate: tests/acceptance.py 951 passed, 0 failed — including the tracked-file scan for API keys and machine paths.

Companion PRs

• Judgernaut777/AgentConnect — ADR 0010 and the vocabulary projection module
• Judgernaut777/Connect — naming fix in the website design handoff

🤖 Generated with Claude Code

https://claude.ai/code/session_01Y6joPXQNmYFptiH2qGGJz1

---

Generated by Claude Code

[Judge-M]

CI status: acceptance (windows-latest / py3.14) and (windows-latest / py3.11) failed in one run and passed in another — on this same commit. Standing down on it; it is not this PR's failure and I am not porting a fix, because none exists yet.

The evidence

Commit 97fdc87 triggered two workflow runs. Identical tree, opposite results:

run	trigger	windows py3.11	windows py3.12	windows py3.14	ubuntu 3.11/3.12	ruff
32913106786	push	❌	✅	❌	✅	✅
32913163154	pull_request	✅	✅	✅	✅	✅

A fully green run already exists on this exact commit, so the one permitted re-run is unspent rather than needed — re-running could only reproduce what run 32913163154 already shows.

The failure

One assertion, in the librarian adjudicate section of tests/acceptance.py:

[librarian-adjudicate] proposals for open contradictions/escalations; never resolves/closes
  ok   escalations.proposal column present after migration
  ok   adjudicate produced at least one contradiction + one escalation proposal
  FAIL contradiction proposal written to contradictions.proposal
  ok   escalation proposal written to escalations.proposal
RESULT: 947 passed, 1 failed

tests/acceptance.py:2855. The escalation half of the same pass wrote its proposal fine; only the contradiction half did not.

Why it is not this PR's

This PR changes one markdown file — a boundary paragraph in docs/KNOWLEDGE_PLANE.md. No code, no schema, no fixture, no CI config. There is no path from that edit to contradictions.proposal. Locally on Linux/py3.11 the same suite is 951 passed, 0 failed, and every ubuntu leg is green in both runs here.

The pattern also rules out a platform incompatibility: windows py3.12 passed in the run where py3.11 and py3.14 failed, and all three passed in the other run. Same OS, same commit, different outcomes across runs is nondeterminism, not a Python-version or Windows problem.

Not fixed here, deliberately

I did not chase this to a confirmed root cause and will not guess at one in a comment. What I can say from reading the code: librarian/adjudicate.py:run() iterates every open contradiction (SELECT id FROM contradictions WHERE status='open' … ORDER BY id) and writes a proposal for each, while the test asserts against the single lowest-id row it captured earlier — so a stale-read or write-visibility difference across the Repo.open(...) boundaries in this section is the shape of thing to look at first, and Windows file locking around the tempfile.mkdtemp repo is the usual suspect for why it only shows up there. That is a hypothesis, not a diagnosis.

Hardening it belongs in its own change against the librarian test, not in a docs-only PR — widening this one to touch the acceptance suite would make a one-paragraph boundary note unreviewable. Happy to open that separately if you want it chased down.

This PR is otherwise green and mergeable, and its two companions are fully green: AgentConnect#13 (4/4) and Connect#11 (5/5, including the manifest drift check).

I will keep watching this PR until it is merged or closed.

---

Generated by Claude Code