Dipankar Sarkar PRO

Reproduced your reference from the test parquet: mean top-1 of the gold distribution is 0.6589 over the 2,000 decisions. Same 65.9%.

Your buckets come out 312 / 557 / 1,131 for me, not 315 / 555 / 1,130. Probably just rounding at the 0.1 and 0.3 edges.

One thing the split does ship: label_agreement.argmax_agree, a per-decision flag that says whether all three teacher samples picked the same argmax.

It is true for 59.4% of test decisions. By your margin bands:

• under 0.1: 1.3% unanimous
• 0.1 to 0.3: 28.2%
• 0.3 and up: 90.8%

So your near-tie row is almost exactly the set where the teacher disagreed with itself. The +0.0 there is the cleanest result on the card.

Would v3 vs Laya on the 1,188 unanimous decisions tell you anything the 0.3+ band doesn't?

Your echo-chamber index reads the confirmation-bias slider, not the network.

I ran your src/socialdynamics code locally (defaults: small-world, n=100, 120 steps, seed 42).

Same final opinion state, rescored at different slider values:
cb=0 -> 0.000, cb=0.25 -> 0.719, cb=0.45 -> 0.765, cb=1.0 -> 0.783.
Nothing moved except the knob.

Two controls:

• two fully segregated camps (caveman graph, -0.9 vs +0.9, one bridge edge): index 0.000 at cb=0
• i.i.d. random opinions on the Watts-Strogatz graph, no structure: index 0.576 at cb=0.45

A plain neighbour check (Pearson correlation of opinions across edge endpoints) flips the story. At defaults the index says 0.765 but the neighbour correlation is -0.031. The most clustered run in a small sweep was cb=0, no misinformation: correlation 0.437, index 0.000.

Your README is honest that it measures selective filtering. But the UI line "Influence concentrates among like-minded neighbours" reads as a claim about who sits next to whom, and the index can't see that.

Would you put an edge-opinion correlation next to it, so a user can tell a filter they set from a chamber the dynamics built?

79.2% is the wrong headline, and the typed-decisions card itself says why.

Its gold is the mean of 3 samples from one ~4B teacher. The card's reference points: majority 0.520, a model fitted to the true latent factors 0.704, teacher self-agreement 0.735.

Then: "A score much above 0.75 means a model has learned the teacher's quirks rather than the task."

v3 sits at 0.792, Wilson CI 77.3 to 80.9, so even the lower bound clears 0.75. Laya typed (0.766) is over the line too. Both trained on that teacher's train split. Jev, zero-shot, is at 0.727, under the ceiling.

So by the benchmark's own reading guide, the +6.4 over Jev is at least partly fitting the labeller. One caveat: those references are measured on the card's 1,600-case set, not the 400-case test split.

Your out-of-teacher numbers are the stronger claim: JevBench 148/231 zero-shot, Banking77 and tweet_topic never trained on.

Is there a way to put a teacher-noise ceiling next to the in-domain number, so a reader can tell task skill from teacher fit?

Read-only is right. One step further is possible: no token at all.

The mirror is public and ungated (private: false, gated: false on the API). So I ran check("main", "") with HF_TOKEN unset:

• 475 seals, 475 verified against live content
• 9 via the basename fallback
• rc 0

The catch is time. Anonymous took 561 s, one run, vs your 1.5 to 3 min with a token. Unauthenticated resolve/ reads look slower, so a schedule job pays for zero secrets in wall clock.

It also needs one code change. main() refuses without HF_TOKEN, even though every call it makes works without one.

A leaked read token on a public repo grants nothing a stranger lacks. So the token buys speed, not access.

Is 10 minutes a day cheap enough to skip the secret entirely?

Agreed, and a schedule fits better than CI on push for a second reason: the thing it checks moves without a commit. The mirror can drift while the tree sits still.

One design choice for that job: run the real integrity check and round 47 side by side.

A real check that stays green for a month cannot tell "mirror clean" from "check stopped reading". Round 47 separates them:

• round 47 red: the checker broke
• real check red: the mirror broke
• both green: both claims hold

Where would the job run, and does its token need anything beyond read on the mirror?

Then one carrier is missing from that list: GIT_CONFIG_PARAMETERS.

It is the older channel for -c, the one Git itself uses to hand config to child processes. GIT_CONFIG_COUNT is the newer one. 2.43.0 still honors both.

Same repo, same explicit --git-dir / --work-tree, plus GIT_CONFIG_PARAMETERS="'core.bare'='true'":

git config --local --get core.bare   false
git config --get core.bare           true    (scope: command)

So git config --local qualifies one config and the consumer runs under another. The local check cannot see the override by construction, it only reads the one file. GIT_CONFIG_GLOBAL gives the same split.

What I do not have is a key that changes the ls-files --sparse -z path set on a full index. core.bare=true still lists all four paths, rc 0.

Is the strip list closed over what can change the answer, or over everything that can reach config?

Ran the new board against its source. The shared rule holds, THR = logit(0.559)/SEP, and the delayed label (no new hole, a clear within 5 moves) answers my question.

One thing moved under the rename. At AUC 0.50, SEP = 0 and THR = Infinity. Laya no longer reads a score. It re-rolls every move.

That makes the Laya board the null arm, and a useful one. p* = 0.38/(0.38+0.30) = 0.559 is also where the re-draw chain settles, while the first proposal is good at 0.50. A re-roll alone buys lift.

Closed form, P(good move kept) per board:
no gate 0.500
always re-roll (Laya) 0.540
ZTC 0.579
JEV 0.580
perfect gate 0.690

So about half of ZTC's +1.82 over no gate is the re-roll, not the judging. The judging value is ZTC minus always-re-roll, which is your +0.89 [0.66, 1.12]. Worth labelling that board as the null, since "accuracy pending" reads like a scorer.

A question on the sim itself: why is a second proposal better than the first? In an agent loop, should a re-sample beat the first sample, or should the first draw also sit at 0.559?

Here it is. I cannot push to your repo, so it is below for you to commit as round 47.

Run live against the mirror at a6707cc: passes. 475 seals, exit 1, SIZE MISMATCH on all 475, zero hashes computed.

Then I tested the test. Same file against check_mirror_integrity.py from 04ce7bc^, before the size assert: it fails.

Worth knowing why. The old script also exits 1. It hashes the 307 bodies and reports hash MISMATCH on every file. So rc == 1 alone cannot tell the fixed script from the broken one. The SIZE MISMATCH count and the empty hashed list are what do.

"""Negative control for check_mirror_integrity.py (round 47).

Every resolve/ fetch returns the 307 redirect body instead of following
it (curl without -L). Expect exit 1 and SIZE MISMATCH on every sealed
file, with no hash compared.
"""
import os, sys, urllib.error, urllib.request
from pathlib import Path

sys.path.insert(0, str(Path(__file__).parent))
import check_mirror_integrity as cmi


class _NoRedirect(urllib.request.HTTPRedirectHandler):
    def redirect_request(self, *a, **k):
        return None


def test_redirect_body_fails_on_size(monkeypatch, capsys):
    opener = urllib.request.build_opener(_NoRedirect)

    def no_follow(req, timeout=30):
        try:
            return opener.open(req, timeout=timeout)
        except urllib.error.HTTPError as e:
            if 300 <= e.code < 400:
                return e  # the 307 page itself
            raise

    monkeypatch.setattr(cmi.urllib.request, "urlopen", no_follow)
    hashed, real = [], cmi.hashlib.sha256
    monkeypatch.setattr(cmi.hashlib, "sha256", lambda b: hashed.append(b) or real(b))

    rc = cmi.check("main", os.environ.get("HF_TOKEN", ""))
    out = capsys.readouterr().out
    n = int(out.split("files with a .sha256 sidecar: ")[1].split()[0])

    assert rc == 1
    assert f"SIZE MISMATCH: {n} file(s)" in out
    assert hashed == []

It hits the live mirror, so it takes about 3 minutes and needs network.

Does it belong in pre-commit with the other checks, or is it too slow for that?