AlphaAvatar v0.6.4: a self-hostable realtime multimodal assistant runtime with shared perception and ENV memory

Hi Knack — thank you, this is extremely helpful. “Absence is only information if you can prove you were looking” is probably the clearest formulation of the problem I have seen. It also reveals that absence detection cannot be implemented only at the Memory or proactive-policy layer. The perception/runtime layer must first be able to provide an observation-coverage receipt: what source was active, what time window was covered, whether sampling was continuous enough, and whether the result was genuinely empty rather than simply unavailable. That suggests a useful distinction for AlphaAvatar: * positive observation: the runtime observed something; * negative observation: the runtime actively checked a sufficiently covered window and did not observe the expected event; * missing observation: the runtime cannot make a claim because coverage was incomplete or unavailable. Only the second case should be allowed to produce an absence candidate. Your point about probability estimates is also reassuring. I agree that a bounded, monotonic, auditable ranking signal is more useful in practice than pretending to have a well-calibrated probability over sparse person-model dimensions. Capping surprisal and reducing its influence when the underlying dimension has little evidence both seem like sensible safeguards. The separation between surprisal, salience, and provenance is especially valuable. They answer different questions: * surprisal: how much did this update the model? * salience: how retrievable should it be? * provenance: where did it come from, and how much authority does it have? Collapsing those into a single importance score would make policy decisions difficult to inspect. I also strongly agree that surprisal should rank candidates, never decide outcomes. Whether something becomes durable memory, updates a current-state projection, triggers reflection, or causes proactive interaction should remain a runtime policy decision. The reflection loop failure you described is particularly relevant to AlphaAvatar’s future architecture. I will need to make the distinction between primary evidence and derived content explicit: * observations, user statements, and raw tool results are evidence; * summaries, reflections, inferred claims, and absence candidates are derived artifacts. Derived artifacts may reference evidence and produce new claims, but they must not increase the evidence count that triggers further reflection. Otherwise the system can quietly become self-referential without producing an obvious runtime error. The Shannon/Knack example also makes provenance more concrete than a generic confidence score. A user-stated claim, a self-description, and a reflection-generated inference must not compete in the same slot with equal authority. Source role and authority should participate directly in conflict resolution, and a self- or reflection-derived claim should never silently overwrite an explicit user statement. This discussion is helping clarify several future boundaries for AlphaAvatar: * observation coverage before absence inference; * evidence versus derived artifacts; * surprisal as ranking rather than policy; * source-aware claim authority; * class-specific retention and decay; * reflection triggers that count only primary evidence. And yes, keeping this discussion public makes sense. The examples and failure cases are likely useful to other people working on persistent assistants as well. Thank you again for sharing the lessons from your own implementation. They are exactly the kind of subtle failures that are much easier to prevent architecturally than to diagnose later.