IDKMesh · explained

Seven ideas, and the pictures that carry them

No prior knowledge assumed. Each figure below states one idea, and names the experiment or contract in the repository that it came from. Where a number appears, it was produced by code you can re-run.

Run it yourself → The four pipelines Experiment atlas
claim — what a worker says about its own output evidence — produced independently authority — the stage that may integrate denied — fail-closed
01

A worker gets a bounded task, never the project

The unit of work is a Work Unit: an explicit scope, explicit inputs, and acceptance criteria written down before anyone starts. Everything outside that boundary — repository write access, the merge button, the acceptance decision — is deliberately not delegated, no matter how well the work went.

uncertain goal incomplete, contested, possibly wrong WorkUnit v0.2 bounded · reviewable WorkUnit v0.2 scope · inputs acceptance criteria, fixed first WorkUnit v0.2 bounded · reviewable NEVER DELEGATED WITH THE TASK write access to canonical history the merge decision the right to declare its own work accepted a good result does not enlarge a worker’s authority
Contract: work-unit-v0.2.schema.json is the machine-readable version of the left-hand box, and WorkUnit composability v0.2 defines how units decompose without losing the evidence boundary.
02

Three arrows that do not exist

Most of the design follows from refusing three tempting shortcuts. Each row below shows a stage trying to speak for the next one, and the barrier that stops it. These are not policy preferences — they are where the system fails closed.

worker success a self-report ≠ acceptance independent evidence only a verifier that did not do the work may say this verification result a recommendation ≠ merge authority an explicit human decision evidence informs the decision; it does not make it CI success the checks it was given ≠ independent human review a green tick proves the tick a passing gate is a floor, never a verdict
Where this lives: the boundary is enforced in the pipelines themselves — see the four flowcharts — and recorded as ADR-0009, evaluator sovereignty and ADR-0008, independent evidence verification.
03

Generation outruns verification, and the gap has a name

If candidates arrive faster than anyone can check them, the backlog is not a queue-management annoyance — it is verification debt, and unverified work carries risk that compounds. IDKMesh models it as a control problem: admission is throttled when the debt grows, rather than letting the queue absorb it silently.

ARRIVES FAST agents, humans, tools UNVERIFIED QUEUE risk, not just latency INDEPENDENT VERIFICATION drains slowly — scarce human attention verified work the real throughput RISK-WEIGHTED BACKPRESSURE CONTROLLER reads the debt, then throttles admission instead of hiding the queue admission closed
Where this lives: ADR-0007 records the decision, the controller model specifies it, and a multi-window temporal benchmark measures it. E022 compares seven verification modes under a matched budget.
04

Verifiers fail together, and that is the whole problem

A panel of verifiers is only worth what its independence is worth. If they share a blind spot, adding members adds cost and confidence without adding evidence. This is the project’s central verification claim, and it stopped being a simulation the day it was measured — on programs, not people. Each verifier below is a partial test oracle covering one region of a problem’s input domain, and ground truth comes from executing hidden tests.

THE ASSUMPTION 25 verifiers = 25 independent votes nominal panel size 25 WHAT WAS MEASURED the same 25, on a real corpus (E017) effective panel size 1.00 · mean pairwise error correlation 0.587
Observed, not assumed. E017 ran 25 independently seeded partial test oracles — 5 input regions × 5 seeds — over a shared 72-candidate corpus, and found a mean pairwise error correlation of 0.5873 across 300 pairs. Under majority vote the panel’s error was 0.2083 against a single verifier’s 0.2044: an effective panel size of 1.00 of 25 nominal. The panel was no better than one of its members. All 25 passed a discrimination screen first, which is what makes the correlation interpretable. Its predecessor E016 did not: 20 LLM verifiers averaged a Youden J of +0.0487, and their majority vote scored 0.514 accuracy against 0.639 for a trivial “always reject”. Its own status line is “the verifiers it deployed do not verify”. So no AI review panel has been measured in this repository — these 25 are programs.
And the standard correction is optimistic

The textbook discount N/(1+(N−1)ρ) put that panel at 1.66 effective votes against a measured 1.00. Worse, E018 and E017 showed the usual shared-shock model is the wrong shape: real panels fail partially — 11 of about 15 real panel failures had some verifiers right and some wrong, a case the shared-shock model predicts essentially never. An item-difficulty (beta-binomial) model reproduces it, and lands within 0.016 of the independently measured correlation.

05

“How many independent votes do I have?” has three different answers

Same five verifiers. Same votes on the same candidates. Three ways of counting, and a factor of three between the extremes. These numbers are synthetic — the bundled example is a small hand-authored input that declares "evidence_class": "synthetic" in its own output. The gap between the three counts is the point, not the values; the observed version of this effect is §4 and §6.

nominal head-count what a five-person panel looks like 5 N/(1+(N−1)ρ) heuristic the usual correlation discount 3.6588 gate-audit effective votes what these votes actually support 1.6944 synthetic bundled example — the same votes, counted three ways
Reproduce it: idkmesh gate-audit examples/gate-audit/panel-votes.example.json --pretty. The same report also counts how many seeded known-bad probe candidates the panel let through — two of three here, including the prompt-injection probe. Point the tool at verdicts you actually collected and the same three counts become an observed measurement of your panel. The contract is Gate Audit v0.1; the audit is diagnostic only and grants no acceptance or merge authority. Run it in 15 minutes →
06

Fix the rule, not the head-count

If a bigger panel buys nothing, what does? On the same 25 test oracles and the same observed votes, changing only how the votes are combined cut panel error 3.7×. And then it stopped: four defects were missed by every single one of the 25, a floor no quorum can reach.

accept on any 1 vote 0.4167 majority (13 of 25) the default nobody questions 0.2083 need ≥ 19 0.0972 need ≥ 24 0.0556 unanimous (25 of 25) 3.7× better than majority 0.0556 panel error · lower is better · the last two are identical because 4 defects are missed by all 25
The practical rule: measure whether your verifiers’ errors are one-sided before choosing how to aggregate them. Source: E017 §6, extended to the full frontier with the corpus base rate in E020 — which also qualifies E017 by showing the recommended beta-binomial under-predicts the unanimity floor by 1.77×.
The result that reframed the threat

Two panels with identical accuracy, differing only in verifier correlation, behaved completely differently against contributors optimising to pass the gate: one was immune, the other was not (E036). Correlation, not accuracy, is the attack surface.

07

Not every artifact is the same kind of truth

A large share of documentation confusion comes from treating a sketch, a passing test, and a measured result as interchangeable. IDKMesh keeps them on an explicit ladder and stops on whichever rung the evidence actually reaches — often deliberately early.

proposal / hypothesis someone thinks this is true implemented mechanism code, schema or workflow exists synthetic fixture or simulation deterministic fixtures test the mechanics observed controlled evidence a controlled run measured real behaviour scoped accepted conclusion strong enough for one bounded decision enough to decide a claim, nothing more a benchmark contract plus a synthetic fixture means the experiment is runnable — never that a strategy has been shown superior
Where this lives: the ladder is stated in the documentation map and applied throughout the experiment atlas, where each experiment carries its own honest status — including the negative ones.

Where to go next

Hands on

Reproduce a number

Install the CLI, re-derive the example’s three counts yourself, then run the repository’s own test suite.

Quickstart →
Deeper

The four pipelines

Animated flowcharts of the work/evidence path, the two-attempt orchestrator, compute admission, and the PR gate.

Read →
All of it

Experiment atlas

E011 to E042, each with its real status and what it changed — including the results that falsified earlier ones.

Read →
Reference

Documentation library

Every contract, specification, architecture document, finding, audit, and decision record in the repository.

Browse →