iLiC Notes 010

Cooperating Subsystems and Conversation Coherence

A public engineering note on iLiC as a governed set of cooperating subsystems, and why conversation quality needs repeatable evaluation rather than trust-by-vibes.

Summary

iLiC should not be understood as one model trying to be a mind. It is better understood as a governed system of cooperating subsystems. Conversation, memory, source evidence, candidate knowledge, validation, telemetry, and human approval are separated on purpose. That separation makes the system slower to accept unsupported claims, but easier to inspect, repair, and trust over time.

The latest hardening step adds a repeatable conversation coherence evaluation layer. Instead of deciding that iLiC is improving because one response sounds good, the system can run a controlled multi-turn script and check continuity, routing, source discipline, placeholder failures, and accidental Candidate Shelf staging.

The Subsystem Model

iLiC is not a single chatbot. It is a coordinated architecture where each subsystem has a limited role, boundary, and audit trail. The practical model is:

  • Wizard: the visible operator and review layer.
  • iLiC FSM: the deterministic governance and decision layer.
  • Bookworm: the local source-library caretaker and indexing layer.
  • Personal Internet Library: private source material that can be searched and cited.
  • Candidate Shelf: a staging area for possible future knowledge, not durable memory.
  • Claim Ledger: an audit trail for claims, evidence, status, and validation history.
  • Memory Store: governed durable recall, written only through approved memory paths.
  • Telemetry: records of what happened, when, and through which path.
  • Validators: deterministic checks that challenge weak evidence, contradictions, and unsafe promotion.

This structure matters because it prevents one fluent answer from silently becoming trusted knowledge. Each subsystem can do useful work, but none of them should be allowed to collapse the whole governance loop into automatic acceptance.

Why Coherence Needs Evaluation

Conversation can fail in ways that look harmless at first. A response can sound confident while routing to the wrong source, misreading a follow-up, citing weak evidence, or staging a bad Candidate Shelf entry. That means conversation quality cannot be judged only by whether one answer reads well.

The current coherence evaluator runs a fixed ten-turn conversation and checks whether the system preserves context, answers follow-ups, avoids placeholder replies, avoids weak source misuse, and refuses to stage unsupported candidates. It is a small test, but it creates a repeatable pressure loop:

Conversation script → Response → Coherence checks → Failure report → System hardening → Re-run.

What the Evaluator Catches

The evaluator is intentionally practical. It is not a claim that iLiC understands every conversation. It checks a defined slice of behavior that matters to governed cognition:

  • Does the system preserve the topic across turns?
  • Does it resolve a follow-up such as "why does that matter?" against the prior subject?
  • Does it avoid using the source library when the source does not actually answer the question?
  • Does it avoid staging Candidate Shelf entries from weak or irrelevant evidence?
  • Does it avoid placeholder answers such as "I am ready to help" during a live thread?
  • Does it summarize the conversation using the actual topic that was discussed?

This kind of evaluation is boring in the best way. It turns improvement into something measurable.

The Hardening Result

In the latest local run, the first evaluator pass failed. That was the important part. It exposed source overreach, weak follow-up handling, accidental candidate staging, and placeholder responses. After hardening, the evaluator passed its current script with no weak source misuse, no accidental Candidate Shelf staging, no placeholder responses, and no failed checks.

The point is not that this proves finished intelligence. It proves a healthier development pattern: the system can fail a repeatable test, explain where it failed, and then be hardened against that failure mode.

Why This Fits Governed Cognition

Governed cognition is not just about stopping dangerous actions. It is also about stopping subtle drift. A system that forgets what "that" refers to, cites a source that only loosely overlaps the question, or stages a bad candidate because the wording sounded plausible is not ready to be trusted as a memory-bearing assistant.

Coherence evaluation becomes part of the governance layer because it protects continuity before continuity is written into memory. The system should be able to converse, retrieve, stage, and remember, but each path should remain inspectable and bounded.

Boundary

This note describes a local engineering milestone and research direction. It does not claim general intelligence, autonomous authority, or human-like understanding. The coherence evaluator is one controlled measurement layer, not a universal benchmark. Its value is that it catches known failure modes and makes improvement repeatable.

What Is Intentionally Not Disclosed

This note does not disclose private source-library contents, memory contents, credentials, prompts, internal routing details, or implementation code. It publishes the public design thesis: governed cognition should be built from bounded cooperating subsystems, and conversation quality should be tested through repeatable evaluation rather than assumed from fluent output.

References

  • Prior iLiC Notes on governed cognition, Wizard, Truth Ledger, categorical governance, and governed learning.
  • Systems engineering practices around state machines, audit trails, regression testing, and bounded authority.
  • AI evaluation practices focused on retrieval quality, conversation continuity, and failure-mode regression tests.