The cheap-model-picks-the-lens, strong-model-extracts-under-it split is the part I hadn't seen articulated this cleanly before. One thing I'm not sure the two-stage design handles: your three example compressions (task, relationship, who-knows-what) each read like they're picking a single dominant constraint per scene, but a lot of real next-actions need more than one satisfied at once - Alice has to act on the tail without confronting Bob about knowing, while their trust is still broken. If the cheap model is choosing one lens per compression pass, does the axis that didn't get picked just silently fall back into the same rediscovery risk for that turn, or does the packet actually carry more than one constraint at a time?
Mihai_LeanZero
Atlassian consultant and Forge developer at LeanZero. We do Data Center to Cloud migrations and build Forge apps, and I write up what I learn at leanzero.net.
Agreed. The concrete wiring for viewpoint compression and KFI injection lives in my GitHub project ai-bios-narrative-agent under sunnyspot114514. It has the state baseline, dynamic prompt compression, labeled memory injection, and validator-gated commits in working form. Happy to walk through any part if useful.
The three cuts in the essay are pedagogical. Same history under one named constraint at a time so the difference is easy to see. In the runtime the packet is not a single lens winner. It is a small set of tagged facts, and each fact keeps its own use rule. For the Alice scene you mentioned the cheap stage should return an active constraint set, not one enum. Keep who knows what on the tail. Keep the relationship guard with Bob. Keep the task move that the surveillance forces. The strong stage then extracts only sourced facts that satisfy that set. Soft axes that do not bind this turn can wait. Hard constraints that make the next action legal or illegal cannot. If who knows what drops out while Alice still has to move under the tail, you get the rediscovery failure again. That is why the validator sits after the packet. Even a partial compression pass is not allowed to commit a draft that rediscovers a known fact or leaks a fact Alice does not yet hold. So the short answer is yes, the packet can and should carry more than one constraint when the next action needs them jointly. The cheap model is choosing which constraints are live for this turn, not crowning one dominant story beat.
The cheap-model-picks-the-lens, strong-model-extracts-under-it split is the part I hadn't seen articulated this cleanly before. One thing I'm not sure the two-stage design handles: your three example compressions (task, relationship, who-knows-what) each read like they're picking a single dominant constraint per scene, but a lot of real next-actions need more than one satisfied at once - Alice has to act on the tail without confronting Bob about knowing, while their trust is still broken. If the cheap model is choosing one lens per compression pass, does the axis that didn't get picked just silently fall back into the same rediscovery risk for that turn, or does the packet actually carry more than one constraint at a time?