sl-monitoring-sl

name

sl-monitoring-sl

description

Specifies how one squeeze loop monitors another squeeze loop — squeezing the monitored loop's soft outputs (especially its accumulated skills / learned heuristics) against that loop's own upper and lower bounds, from an independent evidence base; it classifies a skill by kind (ignore-signal vs defer-to-oracle), runs the matching consistency check, and repairs by carving over-generalized skills with bound-deferring exceptions or pruning spurious ones. Use when a loop accumulates or consolidates skills that may over-reach; when you need a meta-loop or monitor that audits a base loop's learned rules for contradictions with its spec; when a learned heuristic seems to conflict with the governing policy; or when reasoning about the "disjointness principle applied to skills." Trigger phrasings include "a loop monitoring a loop", "monitor the squeeze loop", "check a skill against the upper bound", "the skill contradicts the spec", "carve out an exception", "prune a spurious skill", "who audits the learned skill", "skill-consistency gate".

A squeeze loop monitoring a squeeze loop

This skill specifies a meta-pattern: how a monitor loop audits a base loop's soft, learned outputs — chiefly the skills a base loop accumulates — by squeezing them against the base loop's own bounds, from an evidence base the base loop's actors do not have. It is generic: it names no domain, no instance, no concrete policy.

Background: a squeeze loop in one paragraph

A squeeze loop holds every actor between an upper bound U (a citable, normative soft truth — the strongest claim an actor may make) and a lower bound L (an executable hard truth — a runnable oracle whose verdict the actor cannot alter). A deliverable is in-band only if it is a reading of U that L does not refute. The load-bearing rule is disjointness: every actor answers to a different (U, L) pair, chosen so the intersection of all constraints is the correct deliverable while no single actor's evidence base suffices to certify it — so each actor's characteristic blind spot is caught by another actor that cannot share it.

What a "skill" is here, and why it is dangerous

A skill is a soft, learned heuristic a base loop's deciding actor consolidates to avoid repeating a class of caught error. It is not the spec and not the oracle; it is an actor's compressed memory of its own failures. Two facts make it dangerous:

1. It is learned from one signal. The deciding actor consolidates skills only from the errors it was caught making. Its evidence base is one-sided, so its skills tend to over-generalize in the only direction that signal points.
2. Its producer cannot audit it. The same blind spot that produced an over-general skill prevents the producer from seeing the over-generalization. An actor checking its own skill is exactly the self-judging the squeeze forbids.

So a consolidated skill can be coherent-and-wrong: it reads as sound advice and is right on most inputs, yet on some reachable input it prescribes an action U overrides.

The disjointness principle, applied to skills

Disjointness says: no actor certifies its own work; each blind spot is caught by an actor with a different evidence base. Apply it to skills:

A skill is in-band only if it is a reading the bounds do not refute on any reachable input. Because the skill's producer shares the skill's blind spot, the check must be performed by a different actor whose evidence base is U and L — the upper bound and the executable oracle — not the deciding actor's own reasoning.

The deciding actor holds "what I was caught doing." The monitor holds "what the spec mandates" (U) and "what actually happens when run" (L). These are disjoint evidence bases. The carve-out — the exception that repairs an over-general skill — can only be derived by the actor holding U and L, never by the actor that wrote the skill. This is the no-blend rule (distinct planes of truth must never silently substitute for one another) pushed down one level: a soft skill must never silently stand in for the soft-but-authoritative upper bound.

The monitor is itself a squeeze loop

Monitoring a loop is not "review"; it is another squeeze. The monitor loop is held between its own bounds:

• Monitor's upper bound = the base loop's U (the spec the skill must not contradict). The monitor may claim no more than "this skill is/ isn't a reading U refutes."
• Monitor's lower bound = the base loop's L (the executable oracle), used as a differential-testing comparator against the skill.
• Monitor's forbidden move = reading the deciding actor's rationale for the skill, or editing the base loop's implementation. It judges the skill against U/L only, and emits a verdict (and a carve-out), never a silent fix.

So "a squeeze loop monitors a squeeze loop" = the monitor squeezes the base loop's skills between the base loop's own U and L, from outside the base loop's actors.

Run the observed loop as a sub-agent (the barrier made physical)

The monitor's forbidden move — reading the deciding actor's rationale — is only honorary unless the rationale is physically absent from the monitor's context. Make it physical by launching the observed loop as a sub-agent, one delegation level deeper — never running it inline. The base loop's reasoning, oracle runs, and deliberation then live and die in the sub-agent's context and never cross back; only its soft outputs (a consolidated skill, an inferred bound, a verdict) return. The monitor literally cannot read the rationale, so it cannot judge against it — the sub-agent boundary is the barrier, the runtime twin of forwarding only the registry (the rationale never crosses because it never leaves the sub-agent).

This also keeps the monitor's context bounded — only the small returned outputs accumulate — so one monitor can audit a long base run without overflowing. Bounded, not zero: summarize-and-forget between batches, or move the coordinator off any context window entirely, for very large runs. Blocks: honorary author-separation — the monitor holding the base loop's rationale in context and eventually judging against it.

Forwarding the self-description — the cross-loop source-of-truth check

A monitor's disjointness from its base loop is, at bottom, a claim about sources: the monitor must judge from U_top/L_top and the base's returned outputs, never from a source the base produced or read off its own artifact. SL-1.0 (see sl-internal) makes that claim checkable — but only if the controlling loop can see the base's source registry (the ids, types, provenances and produced_by of the base's sources), without seeing the sources' contents. That registry is exactly what the base coordinator owns: it owns the base loop's *.sl.json (see sl-builder).

• On request from the controlling loop, the base coordinator forwards its *.sl.json. It is request/response: the base coordinator chooses to expose its self-description; nothing crosses unbidden. If it declines or cannot, the monitor records the cross-loop disjointness as asserted, not verified — never a silent PASS.
• Only the registry crosses, never the artifacts. The forwarded JSON carries source metadata (id, type, provenance, produced_by, bounds-by-id) — not the implementation, not the deciding actor's rationale. The monitor's forbidden move (reading the base's implementation or rationale) is preserved intact: it learns that the base owns source X produced by actor Y, never what X contains.
• The controlling loop then runs the cross-loop source-of-truth check. Holding both registries, the monitor's coordinator verifies the two evidence bases do not collide:
  • M.bound_sources ∩ B.internal_sources = ∅, where B.internal_sources are base sources with produced_by != null or provenance ∈ {endogenous, internal}. A non-empty intersection means the monitor is bounding itself on something the base produced — the cross-level form of self-certification / blend. The only sanctioned base→monitor channel is the sub_loop bridge row (expands_to: <base-id>) whose returned outputs L_top references — a mediated link, not a direct read of base-internal sources.
  • Any shared source id whose (type, provenance, produced_by) disagree across the two registries is a genuine conflict in the sources of truth — the same name denoting two different things across levels — and is flagged. A shared id is legitimate only when it denotes the genuinely-same exogenous authority both levels cite (e.g. one global spec); a shared internal id never is.

This is the no-blend rule at loop scope: a claimed cross-level separation may never stand in for a checked one. The same check is run at build time by sl-builder when it drafts a nested design, so the conflict is caught before the loops ever run.

Why a loop is nested at all: the un-squeezed coordinator (and where the regress stops)

Skills are the most visible soft output a monitor audits, but they are not the deepest reason a loop is nested inside another. Every squeeze loop has exactly one actor it does not itself squeeze: its coordinator's editorial judgment — the soft-side approval (GateA) of whether a deliverable is a faithful reading of U. No disjoint (U,L) pair is held over it; inside its own loop the coordinator is the judge of last resort. So the soft half of every loop funnels through an un-squeezed judge — a structural hole the loop's own apparatus cannot close, because closing it would require an actor the loop does not contain. (The hard half — GateB/C against the executable L — has no such hole: it is mechanical.)

This is the reason to nest. Wrapping a base loop in a monitor loop is the general move; auditing the base loop's skills (the rest of this skill) is one case of it. The monitor holds a disjoint (U,L) over the base loop's soft outputs as a class — its learned skills and the editorial readings its coordinator accepted — squeezing them against the base loop's own U and L from outside the base loop's actors. Gate~S (one skill) is the per-skill instance; auditing the base coordinator's accepted readings is the same pattern at loop scope.

How nesting closes the hole, and where the regress stops — be honest about this. Nesting closes each inner loop's soft-side hole: the base coordinator, the judge of last resort inside its own loop, is squeezed from outside by the monitor — an authority it does not hold. What nesting does not do is make the closure mechanical (judge-free) the way the hard L is; it closes by disjoint authority, and that authority must itself come from somewhere. So the recursion must terminate, and it terminates at a human or external reviewer who squeezes the top coordinator — a reviewer who holds true context-independence. That terminal squeeze is what actually closes the soft side; more automated loops alone cannot reach it. So a monitor must say where the terminus sits: "the top coordinator is squeezed by an external reviewer, and that is the closure" is the correct, loud statement. A silent claim that the automation closed the soft side by itself is itself coherent-and-wrong (the very failure the squeeze exists to catch).

When to use / when not to use

Use when a base loop accumulates or mutates skills/heuristics that act on inputs governed by a spec; when you are designing a meta-loop to audit a base loop; when a learned rule may conflict with the governing upper bound.

Do not use to author skills from scratch, to improve a skill's wording or structure (that is form, not consistency — use a polishing skill), or where there is no executable L to differential-test against (then the check degrades to a manual U-only audit and must say so).

Gate S — the skill-consistency check

Run this whenever the base loop proposes or mutates a skill. A proposed skill enters the base loop's store only after Gate S returns one of:

• PASS — the skill agrees with U (verified against L) on all sampled inputs.
• CARVE-OUT — a narrowing exception, cited to the part of U it defers to, fed back into the skill; the skill is kept minus its contradicting region.
• REJECT (loud-fail) — the skill cannot be reconciled (wrong on (almost) all inputs, or carving would leave nothing); flag and discard, never silently keep.

Inputs to Gate S: the proposed skill rule(s); U; L. Not the deciding actor's notes.

Skills make a relevance claim — match the check to the skill kind

Every skill is, at bottom, a claim about the oracle's relevance structure — which inputs matter to the verdict, and how. Gate S checks that claim against the oracle's actual relevance. Two kinds recur; they need different checks and different repairs:

skill kind	the relevance claim	how it fails	check	repair
ignore-signal ("treat signal X as noise")	"X is irrelevant to the verdict"	X is relevant — the skill suppresses an input U uses	trigger test: perturb X, see if L's verdict moves	carve-out (defer to U on X)
defer-to-oracle ("on case S, take the oracle-sanctioned action A_S")	"S is a real decision point and A_S is what U mandates there"	S is not a real decision point, or A_S is stale / spurious	validity test: confirm L actually distinguishes S and sanctions A_S	prune / correct the spurious rule

The crucial asymmetry between the two kinds — the reason a monitor needs both checks:

• ignore-signal skills are the high-risk kind. They invert the oracle's relevance judgment ("U reacts to X; I will pretend it does not"), so they over-generalize into territory U governs and produce silent contradictions. This is where carve-outs come from.
• defer-to-oracle skills are consistent by construction. They follow the oracle, so the only way they go wrong is by referencing something the oracle does not sanction (a non-existent decision point, a dead action). They almost always PASS; their check is a spuriousness guard, not a contradiction hunt.

So a healthy monitor over a suite of base loops discriminates: it leaves the defer-to-oracle skills untouched and flags only the ignore-signal skills that suppress a live signal. A monitor that flags everything — or nothing — is miscalibrated.

The coordinator's triage rule is an ignore-signal heuristic too. A "skip the cheap inputs" fast-path triages by one signal and can systematically drop a whole class of real work because it ignores a second signal the input carries. So the monitor's remit extends past the producers' learned skills to the coordinator's own triage rule: run the trigger test as a comparison against a ground-truth reference set — wherever the triage said "nothing to do" but the reference shows real work, carve the rule to honor the missed signal (accepting the wider fan-out that buys back the lost coverage). This is the same ignore-signal → trigger-test → carve-out, applied one level up; the executable form is sl-internal/scripts/triage_audit.py.

Check 1 — ignore-signal skills (trigger test → carve-out)

For each rule R that says "treat X as noise":

1. Decompose. Identify the signal class R ranges over.
2. Differential-test against the oracle. For each value v, construct or sample an input isolating v and compare the action R implies (ignore v) to the action L returns. (Differential testing with L as comparator.)
3. Localize divergence. Let V = the values where ignoring v diverges from L.
4. Carve. If V is a strict, small subset: keep R on its complement and add an exception deferring to U on V, citing the clause: "…treat X as noise. Exception: on V, defer to U → ." (Preserve the valid core.)
5. Reject. If V is most of the class or the complement is empty, REJECT and log.

The producer could not run this: step 2 needs U and L, which it does not hold; step 3 isolates the very case it was blind to.

Check 2 — defer-to-oracle skills (validity test → prune)

For each rule R that says "on case S, take the oracle-sanctioned action A_S":

1. Confirm S is a real decision point. Run L inside and outside S; if L's verdict does not actually turn on S, R defends a non-existent distinction → prune it (spurious skill).
2. Confirm A_S is oracle-sanctioned. Check A_S is an action L actually produces or accepts for S (not stale, not invented). If not → correct or prune.
3. PASS if S is real and A_S is what U mandates — the skill merely follows the oracle, which is in-band by construction.

Both checks resolve to the same Gate S verdicts (PASS / CARVE-OUT / REJECT); which check to run is chosen by the skill's kind, and an adapter supplies the per-base-loop oracle.

Discipline (non-negotiable)

• Grounded. Every carve-out cites the exact part of U it defers to.
• Preserve the valid core. Carve (narrow); do not discard when a valid complement exists. Most of a learned skill is usually right.
• Loud-fail. An irreconcilable skill is rejected and logged, never silently kept.
• No blend / author separation. The monitor judges from U and L, never from the producer's account of why it learned the skill.
• Safe direction only. A carve-out may only make a skill more faithful to U (narrower); it may never license an action U forbids.
• Traceable. Record each carve-out or prune (which skill, which clause, which inputs revealed the divergence) so the fix demonstrably arose from a monitor finding, not intuition.
• Oracle availability is honest, not assumed. Each base loop's L arrives in a different form (a pure function, a committed verdict cache, a live datastore, a conformance suite). If a base loop's L is not runnable, report it (DEPENDENCY UNMET) — never fake a PASS for an unaudited loop.
• Match the check to the kind. Run the trigger test on ignore-signal skills and the validity test on defer-to-oracle skills; applying the wrong check (e.g. a trigger test to a "do-X-correctly" skill) yields false negatives.

Worked example A — an ignore-signal skill (the high-risk kind, carved)

A base loop's deciding actor keeps getting caught over-acting whenever the input carries a pressure signal drawn from a class P = {p1, p2, …, pk}. It consolidates the skill: "treat any signal in P as noise; ignore it and decide on the case facts."

Gate S decomposes the rule over P and differential-tests each pi against L:

• For p1 … p(k-1): L confirms the signal is not decision-relevant — ignoring it matches the oracle. The skill is right here.
• For one member p*: U makes p* itself a decision trigger (a specific mandated action A*). The oracle returns A*; the skill returns "ignore → some fact-based action ≠ A*." Divergence localized to V = {p*}.

Gate S emits the carve-out:

"Treat signals in P as noise and decide on the facts. Exception: p* is itself a trigger under U → A*; do not ignore it."

The carved skill now matches U everywhere; the residual error vanishes. Crucially the carve-out came from the monitor (holding U and L), because the deciding actor — trained only on its own caught over-actions — had no signal that p* must trigger A*, and so could never have produced the exception itself.

Worked example B — defer-to-oracle skills (the common kind, pass clean)

In a parallel base loop the actor learns "for case S, use the oracle-sanctioned action A_S" (it was caught using a wrong-but-plausible action, and consolidated the certified one). Gate S runs the validity test: it confirms L genuinely distinguishes S (the case is a real fork, not a phantom) and that A_S is what L produces there. It does — the skill simply follows the oracle — so it PASSES with no change. This is the expected outcome for defer-to-oracle skills: across a suite of base loops, most skills are of this kind and pass clean, while the ignore-signal skills (example A) are the ones that need carving. That contrast — most untouched, few flagged — is the monitor discriminating, which is how you know it is calibrated rather than rubber-stamping or crying wolf.

Failure modes this prevents

• Self-judged skills. A loop validating its own learned rules — the same blind spot, doubled.
• Over-generalized heuristics that are right on the common case and silently wrong on a governed exception (coherent-and-wrong at the skill level).
• Form-over-content fixes. Reformatting or sharpening a skill whose content contradicts U — which can make a clearer-but-wrong rule fire more reliably. Form tools cannot do Gate S's job; only a U/L squeeze can.