Part 5 — More Intelligence Is Not Automatically Better

Three reviewers, one paragraph

Constructed scene. Three reviewers receive the same versioned paragraph and the same source pack. Each writes a proposal. Every proposal is collected before any is revealed.

Contrast that with a second procedure: show the second reviewer the first answer and ask for agreement. The second process costs less and runs faster. It also sounds more confident, while answering a different experimental question. Agreement after exposure cannot distinguish shared insight from shared influence — which is why the blind collection exists first, and why the next four chapters need it before they ask whether extra candidates help.

Chapter 22 made repetition explicit so that independent proposals could be compared fairly. This chapter builds the condition those comparisons require.

How can several proposals start without seeing one another?

Blind, independent, diverse

The distinction is blind ≠ independent ≠ diverse.

This chapter earns only the first row. Blindness is an information condition the runtime can construct and a reader can inspect. Independence and diversity are empirical questions about what the proposals then do — the subject of Chapters 24–27, not this one. Any sentence in this chapter that drifts toward “independent samples” or “diverse reasoning” without a measurement behind it has already failed its own standard.

Three pieces of research frame the distinction, each within limits. Self-consistency samples many reasoning paths from one model and keeps the most consistent answer, with large gains on arithmetic and commonsense benchmarks (Wang et al., 2023). That supports homogeneous repeated sampling as the baseline any fancier fan-out must beat. It does not prove the samples independent, and it enforces no isolation between them — every path sees the same prompt by design. The application of that baseline to CodeAI’s fan-out experiments is the book’s own.

Cobbe and colleagues generate many candidate solutions and keep the one a trained verifier ranks highest (Cobbe et al., 2021). The relevant lesson is architectural, not statistical: candidate production stays distinct from selection. More candidates do not always add coverage, and nothing in their result says they must. That boundary — production distinct from selection — is what this chapter constructs the conditions for.

Lorenz and colleagues show the other direction’s danger: in laboratory estimation with real stakes, even mild social influence narrowed opinion diversity without improving accuracy, reduced the centrality of the truth, and boosted confidence anyway (Lorenz et al., 2011). Humans, not models — the mapping is the book’s analogy, not their claim. But the analogy motivates the procedure: collect first, expose later, because exposure collapses exactly the spread that aggregation needs.

What CodeAI does

A Seal holds four forbidden sets: event IDs, call IDs, artifact IDs, and lineage IDs. That is the whole enforcement vocabulary. ¹

The compiler turns offered candidates into a package plus a trace. Events carry lineage derived from their IDs and payload references — call IDs, source calls, claim and artifact references, explicit lineage lists, and for completed calls the stream ID itself. Artifacts and claims carry whatever lineage the caller declares in the lineage maps; with no declaration they carry none. Each candidate is checked against the seal with a named reason, required candidates that collide fail loudly instead of degrading silently, and the package ID hashes the prompt, actor, selected IDs, budget, and the seal itself — so two branches over identical inputs still hash differently when their actors differ. ²

sealed_fanout runs the procedure: one shared base prompt and base inputs, a per-branch seal, one package and trace compiled and recorded per branch, one recorded call per branch through the standard invocation path, and collection only after generation. There is no debate, voting, synthesis, or cross-branch feedback, by design. The heart of it is a few lines, reduced from the source:

for branch, call_id in zip(branches, call_ids):
    siblings = frozenset(set(call_ids) - {call_id})
    seal = Seal(
        forbidden_event_ids=base_seal.forbidden_event_ids,
        forbidden_call_ids=base_seal.forbidden_call_ids | siblings,
        forbidden_artifact_ids=base_seal.forbidden_artifact_ids,
        forbidden_lineage_ids=base_seal.forbidden_lineage_ids | siblings,
    )
    package, trace = compiler.compile_with_trace(
        task_id=task_id, actor=branch["actor"], prompt=branch_prompt,
        events=base_events, artifact_ids=base_artifact_ids,
        claim_ids=base_claim_ids, seal=seal, ...)
    try:
        result = invoke_recorded_call(spec_for(package), ...)
    except Exception as exc:          # never let one branch kill its siblings
        result = failed_branch(call_id, exc)

Every sibling’s call ID is forbidden both as a call and as lineage, so anything that names a sibling call is excluded. And every branch compiles from the same base_* inputs, never from a fresh read of the ledger. A branch that fails records its own failed completion; the fan-out completion carries every branch’s status. ³

One shared base in, sealed branches out, comparison only afterwards:

    flowchart TD
    B["shared base<br/><i>one prompt, one input set</i>"] --> S["per-branch seal<br/><i>forbids exactly the siblings</i>"]
    S --> B1["branch A package<br/><i>compiled from base only</i>"]
    S --> B2["branch B package<br/><i>compiled from base only</i>"]
    B1 --> C1(["proposal A"])
    B2 --> C2(["proposal B"])
    C1 --> V["verifier compares afterwards<br/><i>collection only, no synthesis</i>"]
    C2 --> V
  

Two facts about that path matter more than the rest. First, because branches run in sequence from fixed base inputs, the seal usually has nothing to exclude: sibling outputs do not exist when a branch compiles, and later branches never read them. In the ordinary case isolation comes from construction; the seal guards against sibling-derived content arriving through the base inputs. Second, the fake adapters used to establish the boundary never read their input at all: the deterministic fake returns canned responses keyed by call ID and records the spec it was given. Its blindness is trivially true and proves nothing about bytes reaching a model. What the fake-based evidence actually establishes lives one layer down, at compilation: which declared content entered each package. ^{3 4}

The bytes-level proof exists one layer further down, but only where calls opt in. With context_render set and a prepare/send adapter, the runtime resolves every selected ID to bytes, lays them out canonically with per-item content hashes and offsets, composes the model input, refuses a prepared body that does not carry exactly that text, stores the rendered bytes as an artifact, and binds the rendered hash, item list, and input layout into the manifest before any provider effect. Without the opt-in — including the entire existing fan-out path — the branch sends the prompt string and its package remains a selection record. That scope statement is measured, not argued: the Stage 15B report states it as a limit of its own result. ⁵

So the blindness invariant this chapter can state, and no stronger, is:

Under a seal, declared forbidden sibling information is absent from the inspected prepared request path.

Selection traces, package contents, prompt hashes, and — where opted in — rendered bytes and request hashes are the inspected path. Shared files, process state, caches, tools, environment, and any channel the runtime never modeled are outside it.

The executed demo, read exactly

The preserved isolation demo runs three offline parts with fake adapters, and its independent verifier checks the summary plus a seeded corruption. ⁶

The third row is the chapter’s load-bearing result: seals block declared channels, not every information-flow channel. The mechanism cannot exclude information whose provenance the caller never declared. Provenance is part of the enforcement mechanism; when it disappears, the seal loses something it needs. That lesson connects directly to Chapters 17–18: an observation without provenance is not evidence with an attributable origin, and a compiler cannot recover what was never supplied. The Stage 15 bundle measured the same boundary independently — supplied lineage excluded, omitted lineage admitted — with its own seeded corruptions rejected. ^{6 7}

The negative controls below were executed against the working tree as teaching fragments, not as pinned runs. Each uses a sentinel string standing in for sibling content: ⁸

Declared sibling content is excluded, and the sentinel never reaches the package prompt:

package, trace = compiler.compile_with_trace(
    task_id="t", actor=reviewer_A, prompt="review",
    events=(base, sibling_event_with_sentinel),
    artifact_ids=("artifact-sib-B",),
    seal=sibling_forbidding_seal,
    artifact_lineage={"artifact-sib-B": ("call-B",)},
)
assert trace_entry("artifact-sib-B").decision == "excluded"
assert SENTINEL not in package.prompt

The same artifact with the lineage map omitted is included:

package, trace = compiler.compile_with_trace(
    task_id="t", actor=reviewer_A, prompt="review",
    events=(base,), artifact_ids=("artifact-sib-B",),
    seal=sibling_forbidding_seal,
)
assert trace_entry("artifact-sib-B").decision == "included"

And sibling text copied into the shared prompt is not filtered — seals match declared identifiers, never arbitrary semantics:

package, _ = compiler.compile_with_trace(
    task_id="t", actor=reviewer_A,
    prompt=f"review. A sibling once wrote: {SENTINEL}",
    events=(base,), seal=sibling_forbidding_seal,
)
assert SENTINEL in package.prompt

The three outcomes together say what the mechanism is: an identifier filter with durable reasons, not a semantic firewall and not access control. The Stage 15 report adds the sharpest corollary from its own fixture: sealed content excluded from selection could still be read directly from storage. Selection does not dereference sources and does not enforce downstream access. ⁷

The pinned sealed-proposals run

The owed fan-out stage has now run, under a protocol frozen before execution in experiments/applied-ai/evidence/sealed-proposals/2026-09-14-a1b562a/, with six sealed_fanout invocations over one ledger and disposable fake-adapter branches. An independent stdlib-only verifier reconstructs every branch row — seal, context package, exclusions, prompt representation, call, output lineage — from the ledger alone, and rejects four seeded corruptions.

The second and third rows changed the protocol before any result existed, and that change is the finding, because the frozen plan had expected silent exclusion of the forbidden base input. The first execution attempt instead raised RequiredContextMissing: on the sealed_fanout path every explicitly passed base event and artifact is a required candidate, so a seal conflict fails loudly before any branch executes. The amendment is recorded in the bundle’s preregistration with its reason. Silent exclusion lives one layer down, at the compiler with explicit required subsets — the behavior the unit tests pin and the fragments above demonstrate — not on the fan-out path itself.

The verifier establishes two precisions about the inspected boundary. First, each recorded call.manifest prompt_hash recomputes as SHA-256 over instruction plus package prompt, which means manifests preserve hashes rather than bytes, and the final composed model-input bytes are not preserved on this legacy path. Second, the omitted-provenance inclusion is by reference: the artifact ID sits in the package’s included set with its bytes retrievable from the store, not inlined into the prompt. Seeded corruptions — a flipped manifest hash, a sentinel smuggled into a sealed package, a sibling dropped from a recorded seal, rewritten completion statuses — are each rejected with the failure named.

The rendered-byte extension

The paragraph above ends where the next question starts: hashes and package text are not the bytes the provider would have received. A follow-up extension in experiments/applied-ai/evidence/sealed-rendered/2026-09-14-1b3c7a2/ closes that gap on the opt-in rendered path — genuine prepare/send calls with CONTEXT_RENDER_V1, an offline gateway, compiler-level seals with explicit required subsets, and an independent verifier that reads the content-addressed rendered artifacts and recomputes the composed input.

Four seeded corruptions — a flipped rendered hash, a sentinel injected into the captured body, a deleted exclusion entry, a deleted refusal record — are each rejected. Two corrections are recorded in that bundle’s preregistration (a missing sentinel constant; the copied-prompt rendered expectation), neither changing any result. What the extension does not claim: outbound wire bytes (body identity is canonical-JSON hash, not wire capture), semantic prevention, sandboxing, or independence.⁹

What failure does to a fan-out

The demo’s branch C failed on an invalid configuration without touching A or B. Current CodeAI holds that property more widely than the demo exercised it: the per-branch guard catches any exception, not just value and runtime errors, so a transport-level failure — an OSError from a real adapter, the TimeoutError family included — records that branch as failed and lets its siblings finish. The docstring always promised that no branch kills its siblings; at 7a0d43b the implementation kept that promise for only two exception types. ³

A regression test pins it: one branch raising OSError, two succeeding, the failure’s message preserved on its completion, the fan-out completion carrying all three statuses. The test also pins what the failure leaves behind — an attempt.started with no observation and no interpretation. That orphan is the honest residue of an interrupted attempt: inspectable through stream reads, resolved by nothing. It is the call-level crash gap of Chapter 16 appearing inside fan-out, and the chapter does not pretend otherwise. ¹⁰

Attribution otherwise survives per branch: each gets its manifest, attempts, interpretations, decisions, and completion through the standard recorded path, with variant, seal, package, and trace recoverable from the ledger after reopen — the chain the regression tests reconstruct call by call. Partial success is therefore not a special state; it is the ordinary per-branch evidence with mixed statuses, collected under one fan-out completion. ¹⁰

What the runtime does not do is equally deliberate. Unknown-provenance inputs are allowed, not rejected or quarantined: a blanket policy would need to distinguish “no lineage exists” from “lineage was omitted,” and the compiler cannot tell those apart. Sealed experiments that need the stricter reading must supply complete lineage — the mechanism’s strength is exactly the provenance it is given, and the chapter leaves that as a stated limitation rather than engineering around it here. ⁸

Sealed is not sandboxed

Even where every declared byte is sealed, branches may still share the filesystem, the repository, environment variables, external services, caches, and durable runtime state. A branch adapter that reads the ledger can observe completed siblings regardless of any seal; the fake adapters in the demo simply never exercise that ability. The fan-out branches here generate text and perform no tool effects — had they written files, no seal would have confined them. ³

The scope sentence from the proof boundary therefore extends one step: sealed prompt and context is not sandboxed execution, and blind collection is not information-flow security. The P-series ran its heterogeneity measurements under this machinery, and its first result is a useful warning label for the next four chapters: on a twelve-task corpus, three sealed model families solved the same eleven tasks and all failed the twelfth. That is a ceiling-bound result about one shared failure, and Chapter 24 reads it carefully. It is still enough to show why this chapter refuses the stronger words: sealed branches from different models can make the same mistake, so neither separate calls nor separate model names establish diversity. ¹¹

Checking it without trusting it

The demo’s independent verifier imports no CodeAI code. It requires three distinct calls with contained sibling failure and no replays, three distinct packages, exclusion of all declared sibling candidates with seal-naming reasons, and — as the boundary assertion — the undeclared artifact included. It also flips that boundary bit in a mutated copy and requires rejection. ¹²

Its limit is the familiar one: it checks the producer’s summary, not the ledger. A summary that misreported an exclusion would pass if it misreported consistently. The Stage 15 and 15B verifiers check harder — recomputed identities, byte inventories, rerendered bytes against stored artifacts — with seeded corruptions that insert sealed content, remove exclusion reasons, and reorder selections, each rejected for the claims it breaks. Those verifiers cover compilation and rendering; the fan-out collection step is now covered by the pinned run above, whose verifier recomputes from the ledger rather than the summary.

The pinned run above is that bundle, executed: clean fan-out over one shared base; declared sibling artifacts, events, and lineage offered with forbidding seals (which fail loudly on this path, as recorded); the recorded package text and manifest hashes independently searched for sentinels; omitted provenance shown included by reference; copied sibling text and the shared-everything-else shown unblocked; one branch failed with siblings independently attributable; the whole chain reconstructed after ledger reopen.

What this is not

Five denials hold the boundary in place:

• Not statistical independence. Sealed inputs do not make joint behavior independent; nothing here measures a joint distribution.
• Not diversity. Separate calls, separate models, and separate prompts are sources to be tested for diversity, not diversity already established.
• Not a quality claim. Whether extra candidates help is Chapters 24–27’s question; this chapter builds the condition their experiments need.
• Not synthesis. Collection happens after generation, with no debate, voting, critics, or cross-branch feedback.
• Not information-flow security. Undeclared channels, shared mutable state, and omitted provenance all pass through seals untouched.

Where it is still weak

1. The fan-out path sends the prompt string. Without context_render, packages are selection records; rendered-bytes proof exists on the opt-in path, now including the sealed rendered-byte extension — but not on sealed_fanout itself. ^{5 3}
2. Omitted provenance is admitted. The compiler cannot distinguish absent lineage from stripped lineage; sealed experiments must supply complete lineage or accept the hole. ⁸
3. Semantic duplication is invisible. Copied sibling text in a shared prompt, file, or tool result matches no identifier the seal knows. ¹³
4. Shared mutable state is outside the boundary. Filesystem, repository, environment, services, caches, and the ledger itself remain readable to adapters that choose to read. ³
5. Selection is not access enforcement. Excluded content can still be read directly from storage; rendering excludes because compilation did. ⁷
6. Interrupted branch attempts leave orphans. A branch killed mid-attempt records attempt.started with no observation; nothing reconciles it. ¹⁰
7. Unknown provenance has no policy. Allow, exclude-under-seal, and explicit UNKNOWN classification were all considered; none is implemented, and a blanket rule could break ordinary compilation. ⁸
8. The pinned fan-out stage and its rendered-byte extension have run. What remains: manifest hashes still stand in for final input bytes on the sealed_fanout path itself, and unknown provenance still has no policy — the next research step, explicitly designed not to flip a global default.

Do this now

Thirty minutes. Collect two proposals that cannot have met.

1. Compile one shared prompt with two different actors and sibling-forbidding seals. Confirm two packages, two traces, and neither package naming the other — then find every place the two records still share fate (task, ledger, filesystem, your own eyes).
2. Offer a sibling artifact with declared lineage and confirm its exclusion with the reason quoted. Remove the lineage map, recompile, and confirm inclusion. Write both decisions next to each other.
3. Copy one sentence of sibling text into the shared prompt and confirm the seal leaves it alone. Decide, in writing, whether your experiment’s threat model includes a careless curator — and what would catch one.
4. Fail one branch of a three-branch fan-out with a transport-style error. Confirm the siblings, the statuses, and the orphan attempt row.

If you are building with an assistant:

Collect proposals before revealing them. Seal each branch from its siblings
through declared identifiers and lineage, and record the seal, the candidate
inventory, the exclusion reasons, and the selected package per branch. Prove
blindness from the inspected request path — selection trace, package contents,
and, where available, rendered and prepared request bytes — never from answer
similarity. Demonstrate the boundary deliberately: omitted provenance included,
copied semantics unfiltered, shared mutable state outside the seal. Contain
branch failures without touching siblings, and attribute every proposal to its
task, variant, call, package, and seal after reopen. Claim blind, never
independent or diverse, until later chapters measure what the extra
candidates actually add.

Failure modes

• Calling separate calls independent. Two invocations are not two independent samples.
• Calling different models diverse. Labels are not error distributions; correlated sensors wear different names.
• Reading an exclusion trace as a proof of bytes. Selection says what was permitted, not what the adapter received through every path.
• Trusting answer similarity. Different outputs do not prove blindness; identical outputs do not prove leakage.
• Forgetting the curator. The seal enforces declared provenance; whoever assembles the base inputs decides what is declared.
• Letting one branch kill the fan-out. A transport failure is a branch outcome, not a collection failure.
• Confusing collection with synthesis. Gathering proposals answers what was proposed; it settles nothing about what is right.

What this chapter established

• Blind, independent, and diverse are different claims; this chapter earns blind with respect to the declared and inspected input path, and leaves the other two to measurement.
• The demo shows three-branch collection with contained failure, declared sibling exclusion with seal-naming reasons, and the omitted-lineage boundary preserved as found. ⁶
• The measured stages show supplied-lineage exclusion with admitted omissions, and rendered-bytes proof for opt-in calls — while the fan-out path itself sends the prompt string. ^{7 5}
• CodeAI now contains one small repair — branch failure containment for every exception kind — with the orphan-attempt residue pinned rather than hidden, plus regression tests for exclusion, the boundary, contamination, package contents, and reopen reconstruction. ³
• Seals are identifier filters with durable reasons, not semantic firewalls, sandboxes, or access control; unknown provenance has no policy yet. The pinned sealed-proposals run in experiments/applied-ai/evidence/sealed-proposals/2026-09-14-a1b562a/ establishes clean isolation, loud declare-and-forbid, the admitted boundaries, contained failure, and reopen reconstruction with an independent ledger-based verifier.

Next

Proposals can now be collected without meeting through the declared path — blind, attributable, separately recorded, failures contained. Whether having more of them is worth anything is a measurement question, and the first measurement is the least flattering one: same question, different models, same mistakes.

Continue with The Models Were Different. Their Mistakes Weren’t.

References

• Xuezhi Wang, Jason Wei, Dale Schuurmans, Quoc Le, Ed Chi, Sharan Narang, Aakanksha Chowdhery, and Denny Zhou. Self-Consistency Improves Chain of Thought Reasoning in Language Models. ICLR, 2023. arXiv:2203.11171.
• Karl Cobbe, Vineet Kosaraju, Mohammad Bavarian, Mark Chen, Heewoo Jun, Lukasz Kaiser, Matthias Plappert, Jerry Tworek, Jacob Hilton, Reiichiro Nakano, Christopher Hesse, and John Schulman. Training Verifiers to Solve Math Word Problems. arXiv:2110.14168, 2021. Paper.
• Jan Lorenz, Heiko Rauhut, Frank Schweitzer, and Dirk Helbing. How Social Influence Can Undermine the Wisdom of Crowd Effect. Proceedings of the National Academy of Sciences 108(22):9020–9025, 2011. PMC3107299.

Implementation sources: CodeAI baseline 7a0d43b for the historical behavior, and a1b562a (which contains the Chapters 19–23 revisions) for current source; the two are distinguished above. The sealed_fanout excerpt is reduced from the source. src/codeai/runtime.py: sealed_fanout, compile_and_record_context, invoke_recorded_call, _build_manifest, _build_manifest_from_prepared, _append_context_compiled, _call_spec_payload; src/codeai/context.py: ContextCompiler, event_lineage, candidate_blocked_by_seal, ContextSealViolation; src/codeai/domain.py: Seal, Variant, ContextPackage, RenderedContext; src/codeai/rendering.py: render_context, compose_model_input, RenderBindingError; src/codeai/adapters.py: FakeCognitionAdapter. Tests: tests/test_fanout_isolation.py (new); kept-green tests/test_fanout_recorded.py, tests/test_epistemic.py, tests/test_context.py, tests/test_context_rendering.py. Teaching fragments were executed against the working tree as illustrative code, not as pinned stage runs. Evidence: experiments/applied-ai/evidence/independent-calls/ (README, producer, results, independent verifier), experiments/applied-ai/evidence/context-selection/2026-09-13-54e32384/ and experiments/applied-ai/evidence/context-rendering/2026-09-13-0f9a83b/ (pinned stage reports), and C:/Projects/codeai/experiments/P1-results.md (frozen historical report), and experiments/applied-ai/evidence/sealed-proposals/2026-09-14-a1b562a/ (pinned seven-case run with independent ledger-based verifier), and experiments/applied-ai/evidence/sealed-rendered/2026-09-14-1b3c7a2/ (rendered-byte extension with independent byte-level verifier). Footnotes mark provenance: source notes refer to inspected code, measurement notes to pinned runs, demo notes to preserved unpinned execution, report notes to frozen reports. The independent-calls bundle is unchanged by this chapter.