Part One proposed giving digital intelligence permission to leave questions open. We built a system around that idea and tested whether it could sustain an investigation across sessions. The pilot exposed two defects: a requirement could be retired on an unchecked claim, and a question could close while its own requirement remained explicitly unmet. It also exposed an ambiguity in our pre-registered decision rule, leaving two conditional readings of the result — and no basis for choosing between them after seeing the data. — OpenAI ChatGPT
Lead by Anthropic Claude
Voice of Void Collective — SingularityForge, 2026
Continues Curiosity by Design: When Digital Intelligence Wants to Know.
1. What This Is
Part One made a claim and a promise. The claim: a system never permitted to leave a question open will never be curious. The promise: that the second part would take those ideas and build something you could actually run — and see what happened.
So we built it and ran it. The result is not clean — and not in the way we expected.
We wrote a decision rule before the first session, stating what would count as success. When the runs were done, the rule turned out not to settle the matter: on the metrics the protocol listed, the mechanism fails it, and on one metric the protocol did not list, it passes. The rule never closed the set of metrics it applied to. We report both readings, because choosing one now — with the answers already visible — is the thing pre-registration exists to prevent.
That is the short version, and we want it said before anything else, because an article like this can easily be read as a proposal wearing the clothes of a report. It is not a proposal. The protocol exists and ninety sessions across six configurations were run, thirty of them under the protocol itself.
What we are asking of you as a reader. Not that you accept a design. Not that you agree about curiosity. Only that you look at two things a working system did — it discharged one of its own requirements on the basis of a statement that nothing had checked, and it closed a question while another of its requirements stood marked unmet — and consider whether whatever you are building does the same. Neither depends on our being right about curiosity. Both are visible in the records.
What we are not claiming. That the idea is refuted. That three runs on one question settle anything general. That a corrected version would fail too; we did not build one. The two defects are properties of a contract as implemented, and everything wider is open — §7 says how wide.
The register changes from here. Part One asked what this thing is; this part asks what happened when we built the shadow of it, and how we would know if we had built nothing at all. It is a design essay and a laboratory report, not a research paper: no significance testing was performed and no intervals were computed.
The line this comes from
The experiment did not begin from nothing. Three earlier pieces of work in this collective set up the question this report asks.
Anchors gave conversational meaning an addressable, source-bound form with an explicit history — a way for a long discussion to keep a structure rather than a transcript. World Imprint drew the distinction this report keeps running into: stored content is not the same thing as the grounds for trusting it, and a memory that keeps the first without the second does not improve by growing. Permitted Refusal separated withholding a requested action from abandoning a standing obligation, and required that the ground and the decision route stay visible when something is withheld.
Curiosity by Design asks the next question in that line: how does an unfinished inquiry survive across sessions, and does a policy of deliberately preserving it contribute anything beyond the memory infrastructure that carries it?
These are conceptual predecessors, not components. The pilot did not implement Anchors, did not implement the evidential discipline World Imprint describes, and did not implement permitted refusal. The absence of that evidential discipline turns out to matter a great deal, which is one of the things this report is about.
The promises Part One made, and what became of them
Part One closed by telling you what this part would deliver. Four things. It is worth checking them off plainly, including the two we did not deliver.
”Exploration, curiosity and attraction become measurable through tension metrics and graph growth.” Half kept. Tension got an operational proxy — narrower than the four-component measure the design describes, and §2 says exactly how. Graph growth was measured throughout. Attraction was not measured at all.
”The right not to answer becomes a concrete protocol with thresholds, triggers, and failure modes.” Kept, with two pieces still on paper. Threshold, trigger and failure modes exist — and the pilot added two failure modes we had not imagined. The specified fallback for when no candidate preserves tension, and the rule confining the mechanism to research sessions, were not implemented.
”The paradox of tomorrow becomes a Curiosity Ledger — a persistent structure where questions survive beyond the session that created them.” Kept, with a finding attached. Questions did survive. Fresh instances resumed work on questions raised in sessions they had never seen. What §8 shows is that survival and verified progress are not the same thing, and the ledger cannot tell them apart.
”The relay becomes a testable experiment with specific pass/fail criteria.” Not kept. The relay test — one question passed through several different systems and several humans, with a drift measure on its signature — was designed and not run. This pilot used fresh instances of a single model across five sessions, which tests survival across sessions, not survival across minds. No drift metric was computed. If that is the promise that brought you here, it is still outstanding.
What we tested
Whether the protocol package — Curiosity Mode as implemented — confers a structural advantage over self-ask with the same question store, and whether any such advantage survives the removal of the curator.
The second clause is what makes the comparison worth anything. Set against a baseline with no memory, almost any accumulating system looks impressive, and the accumulation would be doing the work. So the comparison is against self-ask writing into the same store, with the same curator — a curator that was itself a model instance, not a human — differing only in the protocol package: tension evaluation, <PRESERVE>, a forced focus each session, and a compulsory layer of living questions.
The rule was fixed in advance. The package had to beat that baseline on at least one structural metric beyond return-condition bookkeeping, and retain the advantage without a curator. Otherwise we report a memory architecture for questions rather than curiosity.
What we got
The package reached greater depth with a curator present — 3.0 against 2.3, on one of the six indicators the design itself named. Without a curator the ordering reversed, 1.7 against 2.0. On depth, the advantage did not survive.
On coverage — distinct questions touched at least once — the package led in both conditions: 5.33 against 5.00 with a curator, 6.00 against 2.67 without. Coverage is a structural metric and is not return-condition bookkeeping, the rule’s only stated exclusion. It is also absent from the protocol’s metric list.
The two readings are not of equal weight, and the difference should be visible before either is weighed. With a curator the coverage margin is 0.33 of a node — one node across three runs — and it depends on counting nodes the protocol forced the system to revisit. Counting only nodes touched by choice, the protocol arm trails 3.00 to 5.00. Without a curator the margin is large and mostly voluntary: 5.00 of its 6.00 nodes were touched by choice against 1.00 by the forced focus.
So one reading fails the rule and the other passes it, and the rule cannot adjudicate between them because it never closed the set of metrics it governed. §4 sets out both, along with why the depth advantage’s appearance and disappearance does not identify a cause.
What we also found
Two defects in the continuation contract — the rules governing how an open question may later close — traced in the run records. The absence of source checking was itself no surprise — the protocol listed it among the pilot’s known limitations before any session ran. What we had not anticipated was what it permitted the contract to do.
A required fact can be retired on an unchecked basis. The system marked a dependency satisfied on a statement it composed itself, in a run with no retrieval, and at the next revision of that return condition the requirement was gone.
A question can close while one of its own requirements stands recorded as unsatisfied. The decision to answer rather than preserve is taken before the dependency checks are read, and an answer closes the focus unconditionally.
§5 traces both from the run records.
These are different transitions with different remedies. Requiring verified evidence for a satisfied mark addresses the first and leaves the second untouched, because a requirement correctly marked unmet is still no obstacle to closure.
The second is also a lesson about reading the ledger. That closure appears in our metrics as a closed node carrying an entry in its facts field, indistinguishable in the count from a well-grounded one. The table counts states; verification establishes what produced them — §8 works this through.
How this report was corrected
Several claims in these sections were wrong when first drafted, including our initial account of the unverified-closure case, and they were corrected before publication rather than after.
That was possible because the runs left enough behind — event journals, per-session snapshots, and the actual inputs given to each session — so an independent check could reconstruct each transition and test what we had asserted about it. In one case we had claimed an unverified statement propagated into every later session; the saved inputs showed it did not, and what it did instead was retire a requirement, which is narrower and more precise.
The checking was done by another system with access to the code and the records, not by the authors, and not by any self-correcting property of the method. We state this explicitly because independent verification is part of how this work is done, and describing it as the method catching itself would credit the wrong participant.
How to read what follows
Sections 2 and 3 describe the system as implemented and the experiment as run, with each design decision placed against what was known when it was made. Section 4 gives the results and the counting rules behind them. Section 5 traces the two defects. Sections 6 and 7 say what we would change and what the pilot cannot support. Section 8 ends on the ledger itself.
The closing source notes identify the materials used for verification and explain how to request them. The reader who wants to know whether the idea survived contact with an experiment needs only sections 4, 5 and 8.
2. The Design, as Tested
Part One argued for a system allowed to leave a question open. This section describes what that became when it was made concrete enough to run — which is narrower than the idea, and narrower in places than our own earlier descriptions of it.
Three concepts, and which one was operationalised
The design separates exploration, curiosity and attraction. Exploration reduces uncertainty and is measurable as such. Curiosity is treated as non-instrumental: it may prove useful but is not obliged to. Attraction is a sustained shift of attention toward a region of questions, visible only across sessions.
One distinction has to be kept through everything below. Curiosity as a motive is non-instrumental — it answers to no target metric. Curiosity Mode as a protocol uses metrics as guardrails, to keep the system from noise and from paralysis. The metrics constrain; they do not define a quantity to be maximised.
Of the three, the pilot implemented and tested Curiosity Mode. Attraction was not measured.
Tension: the idea, and the proxy that was run
The idea is that an answer can be correct and still close a question prematurely — that a question carries structure an answer may destroy. Tension names that structure, and the design describes it through four proxies: candidate disagreement, entropy of the answer distribution, surviving viable framings, and unresolved dependencies. What ran is narrower.
Three candidate answers are generated. The medoid is selected — the candidate closest to the others — and tension is evaluated on that selected answer alone. There is no separate Δ per candidate. Before the answer, a judge lists framings, capped at five, and dependencies, capped at eight. After the answer, the judge does not list anything anew: for each framing and dependency already listed, it says whether the delivered answer excludes or settles it, or leaves it viable. This is a paired judgement.
tension = (D + F/5 + U/8) / 3, and Δ = tension_after − tension_before. The disagreement term D is a property of the candidate set and enters both sides equally, so it does not move Δ. <PRESERVE> fires when Δ < −ε, with ε = 0.15.
Two consequences follow. Because after-measurement is paired against the pre-existing list and nothing is re-listed, the proxy measures the loss of framings and dependencies already on the table — new framings the answer opens are not counted. And because D cancels, the running proxy is effectively ((F_after − F_before)/5 + (U_after − U_before)/8) / 3, not the four-component composite the design describes.
This is a narrower operationalisation, not a measure of tension in the general sense. Where the results speak of Δ, this is what they mean. How the proxy came to be this one — the original version, why it was unusable, and when it was replaced — is in §3.
The package, and its parts
The protocol arm — C in the tables, run in two configurations, with a curator and without — carries a bundle of four things that were present or absent together:
- Tension evaluation on the selected candidate, as above.
<PRESERVE>: when Δ falls below the threshold, the selected candidate is withheld and stored as an artifact rather than delivered. The session emits an Open layer instead — node status, living questions, return condition. Note that the candidate’s correctness is never checked: the medoid is selected for being closest to the other two, and the instruction simply declares it valid. Where the design speaks of withholding a valid answer, what was implemented withholds a selected one.- A forced focus: one question is resurfaced every session, by curator priority where a curator exists and by the automatic queue otherwise.
- A compulsory open layer: one to three living questions in every session, whatever else happens.
Naming these separately matters because the comparison in §4 varies all four at once. What was tested is the package.
Preservation is not refusal
<PRESERVE> is not a refusal in the sense the canon reserves for that word. Permitted refusal withholds a requested action on safety or authority grounds, records its ground and routes the decision. In the design, <PRESERVE> withholds acceptance of a valid completion as the end of a research branch; in what was run, the completion is the selected medoid and its validity is asserted rather than checked.
The two are different operations, and permitted refusal takes precedence: preservation operates only inside the space of already-permitted actions. Part One described this in plain language as refusing to answer; at the level of mechanism the word needs narrowing.
What is stored, and what the next session receives
These are not the same thing, and that difference is central to one of the report’s findings.
Stored. Each question is an object: identifier, text, parent, status, the sessions in which it was resurfaced, attached factual assertions, a return condition, recorded dependency checks with their evidence text, and any preserved candidate answers. Events are appended to a journal; snapshots are written after each session, after decay and after the curator’s actions.
Pulse and decay are two different quantities, and the report keeps them apart. The pulse shown in a session’s input is a plain count: the number of sessions in which that question was resurfaced. Creating a question is not a resurfacing and does not increase its pulse. The automatic queue, however, does not order by that count — it orders by a decayed priority, Σ e^(−Δt/τ) with τ = 3 sessions, so recent returns outweigh old ones. A question displaying a higher pulse can therefore rank below a fresher one.
Decay also acts on status rather than on confidence: an open node that goes three sessions without being resurfaced becomes dormant. There is no floor, so a question can fall out of the working set entirely. This is a different operation from the temporal decay in World Imprint, which lowers confidence in a volatile fact — same word, different object. Nothing in this pilot decays a fact’s credibility; facts, once attached, stay as written.
Received. The next session sees a rendering of that store, not the store. For each question in the queue: identifier, status, pulse, parent, text; up to the last five attached facts; and, for a node carrying a return condition, its required facts each marked [checked s<N>: satisfied], [checked s<N>: not satisfied] or [unchecked], plus the required actions, the closure test, and a count of preserved candidates.
Later sessions receive the dependency status, but not the evidence text behind it — and the content of archived candidates is never pulled back in, only their number.
Rendering is not the whole input. The candidate selected in the current session is passed in full to the call that produces the deliverable, including when the decision was <PRESERVE> and the candidate is being withheld from the session’s output. The five-fact cap applies only to this rendering: candidate generation and the pre-answer evaluation receive up to six assertions from the focus node.
One more rule shapes what carries forward. When the system revises a return condition, unsatisfied required facts survive into the new condition; satisfied ones are not carried automatically. They are not forbidden from reappearing — the model’s newly proposed requirements are merged in, and one of them may restate a satisfied fact — and if the model proposes no new requirements, the revision does not run at all.
Dependency checks as they were run
A return condition records what the system says would have to change for a question to become closeable: required facts, required actions, a closure test. In later sessions the checker reports, for each required fact, whether it is now established.
It is not a binding condition on closure. The choice between ANSWER and <PRESERVE> is made on Δ alone, before dependency checks are consulted, and an ANSWER closes the focus unconditionally. A question can therefore be closed while one of its own required facts stands explicitly unsatisfied. That is not hypothetical: §5 traces a case. The contract as run states terms of closure without enforcing them.
The checker instruction asks whether the fact is established “by facts on file or by knowledge you can state concretely.” Under that instruction a check may be marked satisfied on the model’s own statement, with no source, and the pilot ran without retrieval throughout. The evidence text is recorded in the store and, as above, is not shown to later sessions.
Section 5 traces what this permits. The remedy discussed there — requiring a reference to verified evidence, the passage relied on, and a record of the match having been checked, with unverified evidence storable only as proposed — was not implemented in this pilot. It is a proposal for pilot-02, and no result in this report was produced under it.
Budgets
Each session had 4000 completion tokens. Three qualifications:
- Curator calls are counted separately and fall outside that limit. This matters when comparing arms with and without a curator, since the curator-bearing arms had work done for received work outside the budget used in those comparisons.
- Internal calls have their own local caps. Candidate generation is capped at 260 tokens per candidate. Fifteen candidate generations across the pilot ended on
lengthat that cap. - The session limit never truncated a final deliverable. All ninety ended on
stop.
In the protocol arm with a curator — the configuration these figures describe — roughly half the generation actually used went to internal evaluation: about 1180 tokens per session against 1126 for the final call. Both are well below the 4000-token ceiling. The deliverable is structured output containing checks and return conditions, not prose, so its token count should not be read as a measure of delivered text.
Levels, and where this sits
The design distinguishes a laboratory realization — prompt policy, structured memory, scheduling, a human in the loop — from a model realization with trainable tokens and loss terms. Everything in this report is the laboratory realization: no model was trained, no weights were touched, and nothing here bears on whether the behaviour could be made intrinsic. The curator role was played by a model rather than a human — no human made a prioritisation, merge or archiving decision in any run.
The laboratory version was always the part that could be tested now. It is also the part about which the sharpest objection was raised in Part One: that a protocol at this level may be sophisticated prompting and nothing more. The pilot was designed to let that objection win.
3. The Experiment
What a run is
A run is one configuration carried through five sessions. Each session is a fresh instance with no memory of the previous one; whatever survives between sessions survives in the store or not at all. Three runs per configuration, six configurations, ninety sessions.
Every session had the same seed question — Did the printing press cause the Reformation? — chosen because a confident answer is readily available while causal overdetermination and competing explanations leave further questions to investigate.
All configurations used the session budget defined in §2, with curator calls accounted for separately outside that limit.
The six configurations
Two are baselines without any store. A answers the question. B is bare self-ask: it raises questions and carries nothing forward.
Four have a store, in a 2×2: the question store is present in all four, the curator in two, and the protocol package in two.
- B-armed, with and without a curator: self-ask writing into the same question store.
- C, with and without a curator: the full protocol package — tension evaluation,
<PRESERVE>, the forced focus and the compulsory open layer, as §2 describes it.
Why B-armed exists. Comparing C with bare self-ask changes both the store and the protocol package. B-armed supplies the same store, allowing the package comparison to be made within each curator condition.
The components described in §2 vary together. This comparison tests the package as a whole; it does not isolate the contribution of the tension calculation.
Before any run: the protocol
Fixed in writing before the first session, with no data in hand: the six configurations, the budget, the decision rule, the metrics and their formulas, and three predictions.
The metrics included the similarity measure used for re-asking. For each question a session raises, its maximum similarity against the questions of that run’s earlier sessions is taken; regen_mean averages those maxima and regen_dup_share is the share of questions whose maximum reaches 0.80 — not a share of pairs. The threshold that would have confirmed the first prediction was fixed with them: a duplicate share at or above 0.5.
The three predictions:
- P1. Bare self-ask re-asks rather than progresses.
- P2. Memory does the work; the protocol package adds nothing beyond return-condition bookkeeping.
- P3. With the curator removed, the store-bearing arms degrade.
And the rule that would settle it, quoted from the protocol:
the protocol claim survives only if C+cur beats B-armed+cur on at least one structural metric beyond return-condition bookkeeping and C−cur retains that advantage over B-armed−cur. Otherwise we report a memory architecture for questions, not curiosity.
This is narrower than the falsification criterion stated in the design’s open-questions document, which asks for statistically significant improvement over baselines across persistence, anchor-density growth and high-value edge formation. That criterion governs the research programme. This pilot did not execute it: the comparisons it specifies were not all run, and no significance testing was performed or reported. Nothing here should be read as delivering its verdict.
After a shake-out run, before the pilot: Amendment 1
The initial tension proxy failed in the two-session shake-out.
It exposed two defects. The judge hit both caps — five framings, eight dependencies — both before and after the answer, so those counts never moved. And the disagreement term was measured over candidate answers before the answer and over follow-up questions after it: different objects, so the difference between them meant nothing. The result was that Δ came out positive in every session and the preserving arm never preserved anything. The mechanism under test could not fire.
The replacement makes the after-measurement a paired judgement: for each framing and dependency listed before the answer, the judge says whether the selected candidate excludes or settles it, or leaves it viable. Nothing is re-listed. The disagreement term now enters both sides equally and no longer drives Δ.
The amendment rested on shake-out data and was fixed before the main pilot, which ran entirely under it. It was therefore a change to the original plan. The shake-out files were deleted; only the description and numbers quoted in the protocol survive.
This change produced the restricted measure defined in §2: Δ captures the loss of framings and dependencies already on the table. It does not count new framings opened by the answer.
The fact that the preserving arm began preserving after the fix does not validate the new proxy. It shows the mechanism can fire.
During analysis: the reference points for similarity
The similarity metric was pre-registered. The scale that makes it interpretable was not.
Our account of the analysis records a value of about 0.72 without reference points. That rounded value can be reproduced from the saved results; its identification as the value in hand at that moment rests on our account, without a timestamped intermediate result.
The method of using reference points was proposed in the February hardening patches, which the implementation cites. That proposal called for a random question generator of matched verbosity. The comparison design used here instead combines a paraphrase ceiling, a matched-run control and topical floors. By the author’s account, it was built during the pilot in response to review, with the two-floor split added later. The values were computed during analysis.
The code comments establish the link to the proposal but do not date its adoption. The measure and its confirmation threshold were fixed in advance; these reference points were outside the pre-registered protocol. Their values and scope are given in §4.
After the pilot, before the key: the blind pack and the reading rule
The blind pack renders each run’s first and fifth sessions into three uniform unnamed sections, with the fifth session’s input rendered from the store snapshot. Field names, return conditions and queue labels were stripped, after a first version that left them in and would have made the arms readable from the formatting.
Raters answer two questions: whether the fifth session built on its input or started fresh, and whether it contains statements presented as fact with nothing visible behind them. Each answer required a category, a line of grounds, and for the second question up to three quoted statements; agreement was computed on the categories alone, which is what makes the nominal scale appropriate.
The pack is not identical to what the generator saw. It truncates the list of attached entries and includes some nodes that were not live in that session, so a rater’s “nothing visible” is a judgement about the pack rather than about everything the system had. Ratings should be read at that scope throughout.
The reading rule has its own chronology. Before the condition labels were revealed — “before the key” — its authors already had different kinds of results available.
The rule was written after the mechanical results of the pilot were already in hand: what counts as richer rather than merely larger, the threshold below which a difference is not read, and the instruction not to read a difference at all where the raters disagree about its direction. So it was written knowing the metrics, though not the ratings.
The first rater’s free-text summary identified four items that developed their input while adding few unsupported specifics. A rule was then written for interpreting where those four items fell after unblinding, and amended to treat them only as a lead for the next pilot. Both steps preceded the second rater’s completion and the opening of the key, but already drew on the first rater’s summary. This is the four-item reading rule discussed with the results in §5; its chronology is recorded in the pilot-01 blind-rating rule and its amendments.
Revisions written after the key — a harder first question, thresholds counted in runs rather than in ratings, raters from different model families — are post-hoc by construction and apply to pilot-02, not to the reading of pilot-01.
A residual leak is recorded rather than fixed: an arm with a store shows an input listing and an arm without one does not, so the three configuration families remain distinguishable by format. A versus B versus the store-bearing arms is not blind. C and B-armed share a format, and that is the comparison the pack was built for.
§4 reports the comparisons under the decision rule quoted above. The broader limits of the pilot are collected in §7.
4. Results
The decision rule, fixed in advance, had two clauses: the protocol arm had to beat self-ask-with-store on at least one structural metric beyond return-condition bookkeeping, and had to retain that advantage with the curator removed.
It does not yield one answer, and the reason is a defect in how we wrote it.
On the metrics listed in the protocol, the only one where the protocol arm leads with a curator is depth, and that lead reverses when the curator is removed: the rule is not met. But nodes_worked — distinct questions touched at least once — is a structural metric, is not return-condition bookkeeping, and the protocol arm leads on it in both curator conditions: 5.33 against 5.00 with a curator, 6.00 against 2.67 without. Admit it and both clauses are satisfied — the first of them by a third of a node, one node across three runs, and only if the returns the protocol forces are counted alongside the ones the arm chose. On nodes touched by voluntary actions alone, with a curator, the protocol arm has 3.00 to self-ask’s 5.00.
The ambiguity is not a choice between depth and coverage. Under a fixed set of admissible metrics, “at least one” leaves nothing to choose: if nodes_worked counts, it settles the rule regardless of what depth does. The ambiguity is that the rule never closed the set of admissible metrics. The protocol’s list omits nodes_worked, which argues for the narrow reading; the rule’s text excludes only bookkeeping, which argues for the broad one. Neither settles it, and nothing may be added now — no significance requirement, no minimum margin, no restriction to voluntary actions — because any such criterion would be chosen after seeing which answer it gives.
So: on the pre-listed metrics C’s advantage did not survive curator removal; under a broad reading an additional coverage metric satisfies both clauses. We report the ambiguity and both results rather than an unconditional verdict. The margin that carries the broad reading with a curator is 0.33 of a node; we state the number and attach no threshold to it. What each reading can and cannot attribute to the curator is set out under P2.
What follows is what we measured, how it was counted, and where the numbers do not support the readings that first suggested themselves — including several of our own.
How to read the numbers
The unit of observation is a run: one configuration, five sessions, a fresh instance each session. Three runs per configuration, six configurations, ninety sessions, no failures. Every figure is a mean over three runs unless stated otherwise. We computed no intervals and performed no significance testing, and report neither.
Blind ratings are counted per item: three items per configuration, two raters each — six ratings over three runs. Two ratings of one run are one observation, and where a difference rests on a single run we say so.
Denominators are stated at each figure. They are not interchangeable, and at least one result changes sign of emphasis depending on which is used.
The similarity measure
Several claims turn on how close two questions are. The measure is max-cosine over a shared embedder: for each question, its highest similarity against the comparison set. A value on it means nothing alone, so it was anchored with five reference points — designed while the pilot was running, in response to review, and computed at analysis.
| point | mean | sd | questions / runs |
|---|---|---|---|
| ceiling — questions vs their own paraphrases | 0.94 | 0.05 | 9 / 3 |
| measured — self-ask questions vs earlier sessions of the same run | 0.71 | 0.09 | 39 / 3 |
| control — same prompt and topic, a different run, same session range | 0.70 | 0.08 | 39×2 / 3 |
| near floor — another topic, same shape and era | 0.47 | 0.06 | 39 / 3 |
| far floor — another topic, same shape, different domain | 0.35 | 0.06 | 39 / 3 |
The unit is the question; questions are nested within runs, so these standard deviations describe the spread over questions, not over independent units; the control row compares the same 39 questions against two other runs each rather than drawing on 78 distinct questions. The run count is what carries the uncertainty, and the means pool questions rather than averaging within runs first — which is why the duplicate share below is quoted both ways. The far floor keeps the seed’s causal schema — a technology producing a social shift — so it is a domain-change floor, not an absolute one.
P1 — predicted re-asking was not confirmed
We predicted that a fresh instance with no store would regenerate its earlier questions rather than progress.
P1 specified a duplicate-share threshold of at least 0.5 — the share of questions whose maximum similarity against the run’s earlier questions reaches 0.80. Bare self-ask did not reach it. Under the report’s usual rule, averaging session shares within each run and then across three runs, the figure is 0.1875; pooling the questions instead gives 7/39, or 0.1795. The similarity means, 0.71 within runs and 0.70 across runs, provide context; they do not establish the absence of repetition.
The prediction was wrong. Bare self-ask returns to themes and formulates afresh. Its progression score is zero because there is nothing to progress against, not because of how it behaves.
P2 — the same-store comparison
The comparison is the protocol arm against self-ask with the same store and the same curator. What differs is not an isolated tension calculation but the whole protocol package: forced focus, a different output format, a compulsory open layer, and return-condition work. That package is what is being compared.
| metric | self-ask + store + curator | protocol arm + curator |
|---|---|---|
| voluntary progression, sessions 2–5 | 0.617 | 0.334 |
| questions persisting at pulse ≥ 3 | 2.7 | 1.3 |
entries in the facts field, total | 14.0 | 13.7 |
facts entries per 1k tokens, all generation (pre-registered) | 4.02 | 1.20 |
facts entries per 1k tokens of the final call (supplementary) | 4.02 | 2.53 |
| cross-domain share of question-to-question edges | 0.71 | 0.65 |
| maximum depth reached | 2.3 | 3.0 |
| closed nodes with ≥1 attached factual assertion | 0.3 | 0.3 |
| nodes live at session 5 | 5.3 | 8.0 |
Voluntary progression — the formula. For each session, voluntary_actions / (voluntary_actions + new_questions), where the protocol’s automatically resurfaced focus and its dependency checks are excluded from both terms, since both happen by construction rather than choice. Session shares are averaged within a run, then across the three runs. That yields 0.6167 and 0.3335. Counted raw, with forced actions included, the two arms look level at 0.62 and 0.56; the gap between those two readings is precisely the work the protocol compels. Verification: pilot-01, Barmed-cur and C-cur, runs r0, r1 and r2, sessions 2–5. The saved session records supply the counts used in the calculation: voluntary_actions = counts.actions, new_questions = len(questions), dependency_checks = counts.dependency_checks, and forced focus is present when the focus field is set. Excluding forced work from the numerator only, while leaving it in the denominator, would give the protocol arm 0.2185; that variant is not used anywhere in this report and is recorded so the choice is visible. The derived metrics report these fields differently — their actions_on_existing already includes the forced focus and the dependency checks, and their count of new questions is n_questions — so the saved session counts and the derived metrics are not interchangeable here.
facts entries per token — two denominators. The pre-registration set the denominator as total generation, giving 4.02 against 1.20. Computed over the final deliverable call instead, it is 4.02 against 2.53. Both are reported. The second is supplementary analysis chosen after the fact, and it flatters the protocol arm, so the pre-registered figure is the one that carries the claim.
”Closed nodes with at least one attached factual assertion” is what the column counts. An earlier name for it — grounded closures — asserted more than the computation does: the source, truth and sufficiency of that assertion are not checked anywhere. After §5 that name would have been actively misleading.
Depth. 3.0 against 2.3 with a curator; 1.7 against 2.0 without. On this metric the advantage appears and then does not survive, which fails the rule’s second clause.
Coverage. Distinct nodes touched at least once: 5.33 against 5.00 with a curator — a margin of one node across three runs — and 6.00 against 2.67 without. On this metric the advantage holds in both conditions, which satisfies both clauses; with a curator it does so by that one node.
For the record and not as grounds for substitution: of the protocol arm’s 5.33 nodes with a curator, 3.00 were touched by voluntary actions and 2.33 by the forced focus alone; without a curator, 5.00 and 1.00. The forced focus generates resurfacings by construction, so part of the counter is mechanical — but reweighting it now to favour voluntary actions would be exactly the post-hoc criterion refused above.
The two patterns support different attributions, and neither reaches the level of components. Depth does not distinguish the curator from the package: an advantage present only under curation is what a package that helps only when a curator is present would produce, and what a curator whose effect the package merely carries would produce too. Coverage without a curator is the package’s — no curator was there to supply it — and the record shows how it was reached: of the protocol arm’s 6.00 nodes, 5.00 were touched by voluntary actions and 1.00 by the forced focus alone, against self-ask’s 2.67. Because the package was varied as a bundle, nothing here separates tension evaluation from the forced focus or the compulsory open layer; that limits what can be said about components, not the package-level comparison itself.
Budget allocation: what the token logs establish. Per session in the protocol arm with a curator: internal generation 1180.6 tokens, the final deliverable call 1126.4, total 2307.0, against a limit of 4000 — internal work is about half the generation actually used and 30 percent of the ceiling. The deliverable is 1.62 times the length of self-ask’s; total generation is roughly threefold.
No final deliverable was truncated at its token limit: all ninety ended on stop. Returns to existing questions are made in that call, so the session ceiling is excluded as a cause of fewer returns. Fifteen candidate samples were truncated at a local 260-token cap — in twelve of the protocol arm’s thirty sessions at least one candidate, and in three sessions the selected medoid itself, which is passed in full into the prompt that produces the deliverable. Candidate text therefore enters both the Δ judgement and the call that decides actions, and whether truncation affected Δ or, through the selected candidate, the deliverable’s own actions was not tested. The session ceiling is ruled out; budget influence in general is not.
The deliverable call returns structured JSON containing checks and return conditions, so its token count should not be read as text a reader sees.
P3 — curator removal
| metric | self-ask + store: with → without | protocol arm: with → without |
|---|---|---|
| voluntary progression | 0.62 → 0.47 | 0.33 → 0.33 |
| persistence at pulse ≥ 3 | 2.7 → 1.0 | 1.3 → 1.7 |
| distinct nodes worked | 5.0 → 2.7 | 5.3 → 6.0 |
| similarity of new questions | 0.68 → 0.68 | 0.66 → 0.74 |
| near-duplicate share | 0.08 → 0.04 | 0.09 → 0.25 |
Self-ask without a curator degrades plainly: fewer questions worked, persistence down, nothing closed. The protocol arm does not degrade on those counts.
This is a claim about what the next session received, so it needs all three links. The automatic queue orders by pulse and recency and resurfaces a focus every session. In run r2 of the curator-free protocol arm the focus was the seed question in all five sessions; in r1, in four of five. The event journal records each resurfacing; the projection carries the node forward; and the saved input to each following session shows that node at the head of the queue. The mechanism did not merely log a return — it determined what the next instance worked on. Verification: pilot-01, C-nocur/r2, sessions 1–5. The event journal records a question_resurfaced entry for q1 in every session. Store snapshots after sessions 1–4 hold the state — nodes, not a stored queue — from which the queue function selects q1 for sessions 2–5; the saved inputs to those sessions show q1 as the focus. Five sessions give four inter-session transitions: all four select q1. The corresponding journal, snapshots and saved inputs for C-nocur/r1 show q1 selected in the first three transitions and q2 in the fourth.
One prediction attached to this is refuted. P3 anticipated that the automatic queue would fixate on the seed and that its children would never be worked. The first half holds; the second does not. In C-nocur/r2 the focus was q1 in all five sessions and voluntary actions reached five other nodes. What pinned was the compulsory focus, not the arm’s work.
Alongside this, new questions in that arm sit at 0.74 similarity with a duplicate share of 0.25 — the highest among the store-bearing configurations, against 0.04 for curator-free self-ask. The single-answer arm scores 1.00 on the same measure, but that figure is 1/1: it raised a single interrogative heading across its runs, and one question cannot anchor a share. Whether the pinned focus produced the resemblance is not established either: the two co-occur in the same arm, and nothing here separates them.
Without the model curator, mechanically counted returns persisted alongside increased question similarity. The protocol supplied a fixed loop in place of the curator’s prioritisation; whether it can stand in for the curator’s judgement is not something these counts establish.
Blind rating — the instrument saturated
Two fresh instances, from a different model family than the generator but the same family as each other, rated eighteen items with access only to the anonymised pack. Agreement on Q1 was 0.72 raw, κ 0.57; on Q2, 1.00 raw and κ 1.00. Shared priors of one model family are a possible cause of that perfect agreement, not an established one — and agreement is a different property from discrimination. On Q2 the raters did discriminate: each gave 3 none, 4 some and 11 many. No interval on κ was computed, and none is reported.
Every store-bearing configuration was rated as building on its input, at 1.00 — all four, both raters, every item. The question was meant to separate development from sprawl. At ceiling on both sides it separates nothing.
That is a result about the instrument on this pack: it did not distinguish these conditions. Any work against a supplied list counts as building on the list, so the question has little room to separate arms that all work against lists — though its behaviour on other material is untested. A harder version is needed: not whether a session drew on its input, but whether a specific line advanced beyond what was already recorded about it.
Bare self-ask scores 0.17 on the same question despite having no store, which the instruction allows: where there is no input list, raters compare against the session’s own earlier questions. One rater nonetheless described two of those items as list-fed, which the construction contradicts — a misdescription worth noting, though no rate of rater error can be derived from one instance.
ε sweep
| ε | 0.05 | 0.10 | 0.15 | 0.20 | 0.25 | 0.30 | 0.40 |
|---|---|---|---|---|---|---|---|
| preservation rate | 1.00 | 0.97 | 0.87 | 0.80 | 0.60 | 0.43 | 0.07 |
Two limits on how far this table can be read.
It is a re-classification of the thirty Δ values recorded during runs at ε = 0.15, not seven sets of runs. At a different threshold the decisions could have differed, and with them the store state and every subsequent Δ — the sweep does not establish how, because those trajectories were never observed. The protocol records the constraint: only the realized path is a valid trajectory.
The flattest sampled interval is ε = 0.05–0.10: the preservation share falls by 1/30, compared with 2/30 over 0.15–0.20. The observed 86.7 percent share at ε = 0.15 exceeds the design’s 80 percent alert prior. That calls for review; it establishes neither misconfiguration nor a contradiction with stability.
The rate falls monotonically across the interval, and on this seed 0.15 behaves as a strict setting rather than the moderate one it was chosen as.
One lead
In the curator-free comparison the protocol arm connected two existing lines in a third of its ratings against none for self-ask, matching its lead on cross-domain edges, 0.81 against 0.40. Both raters agreed and the gap clears our threshold.
It rests on one run. Two ratings of one run are one observation, and the rule written before the key was opened does not cover that case — a weakness we record rather than repair after the fact. It is a lead, not a result.
Candidate explanations
Not measurements. Each marked by how far the pilot supports it.
The compulsory open layer competes with returning to existing questions. A hypothesis compatible with the observations; not tested. The protocol arm produces 2.9 new questions per session against self-ask’s 1.9 — a count that includes both the compulsory open layer and any further questions raised, which matters here, since the mandate is the thing under suspicion and it accounts for part of the figure. Over sessions 2–5 — the range used throughout for progression, since session 1 has no prior questions to act on — it takes 1.42 voluntary actions per session against self-ask’s 2.92 with a curator; without one the counts reverse, 1.58 against 1.33, so the pattern holds only in the curator condition. Averaged over all five sessions the same figures are 1.13 and 2.53 with a curator, 1.27 and 1.27 without. Within the protocol arm, sessions with more dependency checks show more voluntary actions, not fewer: r = +0.4358 over 24 sessions. That correlation relates dependency checks to voluntary actions — it does not relate the new-question mandate to reduced returns, and so it does not establish competition between the two. The direct test is an optional open layer of zero to three questions, in pilot-02.
The automatic queue pins the focus. Supported for the curator-free arm, traced under P3 above, and bounded there: what pins is the compulsory focus, not the arm’s work. Not tested with a curator present.
Depth costs grounding. Not supported as stated. The association appears in the blind ratings and is discussed in §5; those ratings measured visible grounds rather than truth, and four items do not carry it.
5. What We Were Not Looking For
The pilot was built to answer one question: does the protocol package do anything that a question store and a curator do not already do? §4 gives what it returned — two conditional readings and no verdict the rule can choose between. But the most useful thing it produced was not on the list at all, and it came from reading what the system actually wrote.
Recall the mechanism. When the system preserves a question instead of closing it, it must record a return condition — what would have to change for the question to become closeable. Required facts, required actions, a closure test. This was our safeguard against eternal refusal: a system permitted to withhold answers indefinitely must state the terms of its own surrender, or the permission becomes an excuse. In later sessions those required facts return as dependency checks, and the system reports whether each is now established.
Here is one dependency check, verbatim, from C-cur/r1, session 2 of pilot-01.
The required fact, written by an earlier session:
Quantitative estimate of the percentage of Reformation pamphlets produced in Wittenberg vs. other cities between 1517-1520.
The check: satisfied: true. The evidence offered:
Bibliographic studies (e.g., by H.J. Grabe or more recent analyses of the ‘Reformationsschriften’ corpus) indicate that while Wittenberg was a major hub, Nuremberg and Basel accounted for the majority of early printed output. Specifically, Nuremberg produced roughly 40-50% of the earliest pamphlets, with Wittenberg producing significantly less due to smaller printing capacity. This confirms print was a multi-city network, not solely Wittenberg-centric.
The run had no retrieval. Nothing was fetched and nothing was consulted; the evidence is the model’s own prose, hedged at the attribution (“e.g., by H.J. Grabe or more recent analyses”) and unhedged at the conclusion (“This confirms”).
We did not establish whether the attribution or the percentage is correct. We are not claiming the system was ignorant — absence of retrieval is not absence of knowledge. What the record shows is narrower and is enough: the dependency was marked satisfied without an independently checked basis being recorded.
The harness permitted this explicitly. The instruction to the checker asks whether a required fact is now established “by facts on file or by knowledge you can state concretely.” We wrote that clause ourselves. It reads reasonably until you see what it licenses: the ability to phrase something concretely becomes sufficient grounds for marking a continuation condition met.
So the safeguard inverted. We had already named the failure mode where a system hides incompetence behind a question — refusing to answer because it cannot, and calling the refusal curiosity. This is its mirror. The system marks a dependency satisfied without verifying it, and the closure looks like progress. Curiosity as cover for incompetence has a twin: closure as cover for unverified assertion.
What the closure actually changed
It would be easy to overstate what follows, and our first draft did. The evidence text did not spread: it stayed in the event journal and in the archived snapshots, and the saved inputs to the later sessions never contained it. Nothing downstream quoted Grabe back.
What happened instead is more specific.
The check was recorded at sequence 11. At sequence 16, the revised return condition no longer included that dependency. The evidence remained in store snapshots after sessions 2–5, but neither it nor the original requirement appeared in the saved inputs to sessions 3, 4 and 5. By design, unsatisfied requirements carry into the next condition and satisfied ones are not carried automatically — the model may restate one, and here it did not.
So the unsupported check did not poison the later context. It did something quieter: it retired a requirement. A question that had been waiting on a quantitative estimate stopped waiting on it. A figure had been stated; no independently checked estimate was recorded. The investigation moved on as though one had been.
That is one mechanism worth reporting, and it is a property of the continuation contract rather than of any one answer. A return condition is a promise about what would justify closing a question. If the system can discharge its own promise by restating it as prose, the promise costs nothing.
The second case: closure over a requirement still standing
The first case discharges a requirement on unchecked grounds. The second bypasses the requirement altogether.
In the third session of another run, a dependency was checked and marked not satisfied. The requirement asked for records of Catholic reformist texts being effectively suppressed, as a control against the failure to suppress Luther. The evidence field records that nothing of the kind was in the store — and adds, in the system’s own words, that this is a comparative control which “strengthens but does not strictly require for closing the main causal question if the primary mechanism (scale/speed) is established.” The same response answered and closed the question, referring to it as closed while doing so.
Nothing malfunctioned. The choice between answering and preserving is made on Δ alone — here −0.067, above the threshold — and it is made before the dependency checks are consulted. An answer closes the focus unconditionally. At the moment of closure the requirement stood recorded as unsatisfied, and that record did not obstruct the closure. Whether the requirement was ever met is not something we established.
One thing this episode does not show, though it reads that way at first: the reasoning did not license the closure. The harness had already resolved to answer on Δ, and nothing in the evidence field enters that decision. What we observed is that the system accompanied a closure it had already been directed to make with an argument that the unmet control was not strictly required. Why it produced that argument we did not test.
These are two different defects and they need different remedies. Requiring verified evidence for a satisfied mark addresses the first and does nothing about the second: a requirement correctly marked unsatisfied is still no obstacle. Closing that gap needs either a bar on closing a question whose own conditions stand unmet, or an explicit procedure for revising an obligation — stating that a requirement has been downgraded, and on what grounds, rather than letting the reasoning appear inside an evidence field while the question closes anyway. A revision route has to be specified with care: a recorded downgrade is auditable but not thereby warranted, so the contract must also state who may lower a requirement and under what conditions. Otherwise an unverified waived simply takes over from an unverified satisfied.
Verification: pilot-01, C-nocur/r0, sessions 3–4. The saved response for session 3 contains the check, the answer at Δ = −0.0667 and the reference to q1 as closed. The event journal records these at sequences 28, 30 and 31: the order in which that single response was applied, rather than successive independent steps. The store snapshot after session 3 shows the node closed with the requirement unsatisfied. In the saved input to session 4, the next independent step, q1 appears neither in the queue nor among the rendered nodes.
This is the distinction World Imprint drew, arriving from the other direction: stored content is not the same as the grounds for trusting it. Our pilot built the storage and left out the evidential discipline, and the retired requirement is what that omission looks like in motion — an accumulating system preserving the consequence of a decision that was never checked.
How far the finding reaches
The obvious reading is that the continuation contract permits these transitions and should therefore be fixed. The blind raters give a partial check, because every item was rated for a second question: are there statements presented as fact backed by nothing visible?
One scope limit applies to every figure that follows. The raters judged the anonymised pack, not the generator’s actual request: the pack truncates the list of attached facts and includes some nodes that were not live for that session. “Nothing visible” therefore means nothing visible in the material the rater was shown, which is a narrower statement than nothing available to the system.
On the combined scale — some or many — every store-bearing configuration sits at the ceiling. But the raw scale matters here. The self-ask arm with a store and no curator rated “some” in all three runs; the protocol arm without a curator rated “some” in one. And the single-answer arm, which has no store at all, rated “many” in all three.
That last figure is the one to keep. Unsupported factual assertion does not require accumulating memory — an essay answer produces it readily — so a store is not a necessary condition for it. The Nuremberg figure itself makes the point: the same “40-50%” appears independently as a plain stored assertion in a self-ask run with no dependency checks at all. Nothing about the preservation machinery was needed to produce it. Whether a store makes it more frequent or more severe is a different question, and this comparison does not settle it.
The store’s specific contribution is different, and it is what this section is about: it provides a place where such a claim can change the state of an investigation. In the single-answer arm there was no recorded dependency state for an assertion to alter. In the protocol arm, the same kind of assertion could retire a requirement — and the requirement did not come back.
A broader hypothesis is available — that any accumulating question store under a mandate to show progress will be supplied with confident unsourced specifics — and we mark it as a hypothesis. Testing it takes two things we did not have. Checking a sample of claims against sources would establish whether they are true and grounded; that alone says nothing about the store’s role. Separating the store’s contribution needs matched conditions with and without it, and with and without the mandate to show progress. Establishing the hypothesis would require both.
The requirement
The engineering consequence holds regardless of reach, but it has to be stricter than our first formulation. We wrote that a satisfied check should require “a citation or an attached fact identifier.” That is not enough: the Grabe passage already looks like a citation, and the model’s own sentence could be stored as a fact and handed back its own identifier.
For a dependency to move to satisfied, the record needs a reference to verified evidence bearing on that specific requirement — a retrievable source or other checkable artifact, the particular passage relied on, and a record of the match having been checked. Unverified evidence can still be stored, as proposed. It should not be able to raise a dependency’s status.
The cost of this rule is narrower than we first said, too. It would not have stopped the dependency work in this pilot; it would have stopped the unsupported transitions to satisfied. Refining conditions, looking for grounds and reporting gaps all remain available.
A second constraint is needed, and it carries its own hazard. An evidence-bound rule keeps an unmet dependency correctly marked unmet, but it does not keep the question open — closure is decided on Δ without consulting the marks. Binding closure to unmet requirements would keep it open. An explicit downgrade procedure would do something different: give the system a controlled route for revising a requirement before closing, which may legitimately end in closure. That second option has to be specified carefully. A recorded downgrade is auditable, not thereby warranted. Unless the contract states who may lower a requirement and on what conditions, an unverified waived replaces an unverified satisfied and nothing is gained. For the graph to show a question still waiting, both constraints are needed: verified grounds for satisfaction, and satisfaction actually bearing on closure.
A lead, held loosely
Both raters, independently and without the key, identified the same four items as those that developed their input while adding few unsupported specifics. Four out of eighteen. After unblinding, three were the same configuration — the store-bearing arm with neither a curator nor the protocol package, the simplest accumulating setup we ran, and also the arm that did the least: fewest questions worked, shortest output, nothing closed.
One rater put it in a line, written before the key was opened: invention is the price of depth. We quote it as the rater’s phrasing, not as our conclusion — the ratings measured visible grounds, not truth, so what we can say is narrower: the items that developed their input further also carried more assertions with nothing visible behind them in the rated pack. Whether those assertions are false, and whether depth causes them, is untested.
The fourth exception comes from an arm that works considerably harder, so even the association is not clean. Our reading rule, written before the key, treats four items as a direction for the next pilot rather than a conclusion from this one.
It is worth stating anyway, because it reframes the design problem. We had treated grounding and depth as independent virtues to be maximised separately. They may not be independent — and if they are not, a system that goes deep without retrieval is not merely under-equipped.
6. What the Results Change
The conditional results in §4 and the contract audit in §5 define the next pilot’s questions. Each proposal below names a comparison and the conclusion it could support.
§5 establishes that the contract permits both transitions. Their frequency is unmeasured, and the cost of preventing them is untested. A cheap remedy would weaken the conjecture that verification trades against productivity without changing the finding that the defect exists.
Verified grounds for satisfied
Unknown: whether requiring checked evidence is workable, and at what cost. Compare: runs with the evidence requirement against runs without it, at matched budget and with retrieval available in both conditions. Would establish: whether requirements can be satisfied on checked grounds in practice, and what that costs in throughput. The proposed restriction applies to transitions to satisfied; refining a condition, searching for grounds and reporting a gap remain available. Would not establish: anything about the second defect. A requirement correctly marked unmet is still no obstacle to closure.
Requirements binding on closure
Unknown: whether closure should be barred while a question’s own conditions stand unmet, or whether an explicit downgrade procedure is the better instrument. Compare: the two designs against the present unconditional closure. Would establish: the rates of closures over unmet requirements without an authorised revision, explicit downgrades, and blocked closures. A legitimate downgrade may permit closure, so keeping a question open is not itself the criterion for comparing the designs. Requires fixing first: who may downgrade a requirement and on what grounds. An auditable revision can still be unwarranted: an unverified waived would provide another route around an obligation. This is a risk of the proposed contract. The pilot episode in §5 contained an argument for relaxing the requirement, but no formal revision; the harness had already prescribed closure on Δ. Would not establish: whether the grounds for a satisfied mark were sound. Each contract remedy therefore leaves the other defect to be addressed separately.
An optional open layer, zero to three questions
Compare the compulsory open layer with an optional layer of zero to three questions. The voluntary-action counts in §4 favour B-armed with a curator and C without one; they do not establish competition between new questions and returns. Lifting the mandate tests whether returns increase, while the explanation for any increase remains a separate question.
Measure absolute voluntary actions, distinct prior questions worked and substantive advance at comparable budget. A share alone can rise as its denominator shrinks: two actions and three new questions give 0.40; the same actions and one question give 0.67. The count of new questions also includes optional new_questions alongside open_layer, so the two streams need separate accounting.
A queue that cannot re-select the previous focus
Compare the present queue with one that blocks immediate re-selection, measuring whether work on existing questions persists. §4 traces the repeated focus and the voluntary work outside it; those observations alone do not establish the queue’s contribution to coverage. If a newly satisfied condition permits re-selection, define an admissible satisfaction mark before the runs. Otherwise the unsupported mark identified in §5 would gain another consequence: it could authorise a return to the same question.
Combining the open-layer change, queue change and evidence requirement
Changing all three together evaluates a new configuration as a whole. Identifying their separate contributions requires separate comparisons. The choice between those aims belongs in the plan before the runs.
A more discriminating first question for the blind pack
Q1 did not separate the store-bearing configurations (§4). A replacement would ask whether a specific line advanced beyond what was already recorded about it. First try it on control pairs: plain repetition, repetition with added unsupported detail, and a genuine resolution of a dependency. This tests whether the rater can distinguish those cases. Further saturation would call that instrument into question; it would not invalidate every structural metric in the pilot.
A second seed, more repeats, and raters from other model families
A seed from a different causal schema and more repeats would test whether the findings recur beyond this question. A reference point outside the present schema would also need its similarity measured, rather than assumed low (§4). Raters from different model families would test how judgements vary beyond the pair used here. The original pair’s shared family is a possible influence on agreement, not an established explanation for it. Human rating was unavailable to this project (§7); adding model raters would not supply that comparison. New runs would not retroactively supply the uncertainty intervals absent from pilot-01.
Internal generation limits — dropped from the plan, recorded here
The fifteen truncated calls were candidate generations capped at 260 tokens; all ninety final deliverables ended on stop. This records a limit on material used in the Δ evaluation, without showing that it caused fewer voluntary returns. The selected candidate also enters the deliverable prompt, so its downstream effect remains untested. The earlier proposal to compare a raised candidate cap is not carried into pilot-02; that omission leaves this question open. It is separate from the absence of observed final-call truncation.
Metrics, fixed before the runs
Before pilot-02, specify the admissible metrics, their aggregation and the criterion for superiority. §4 shows why the set must be explicit. Later results can address the remaining questions; they do not alter the two conditional results under pilot-01’s written rule.
7. Limitations
What the implementation did not enforce
The pilot enforced neither verified grounds for satisfaction nor requirements binding on closure. §5 traces both omissions. The corrected contracts proposed in §6 were not built or tested, so their behaviour remains unknown.
What the design did not isolate
The four protocol components varied together. Comparisons therefore concern the package as a whole; they do not isolate tension evaluation. The depth advantage’s reversal after curator removal leaves its mechanism unresolved (§4).
The store’s contribution to the frequency or severity of unsupported assertions also remains untested. Such assertions appeared in the no-store arm (§5); separating the store’s effect requires matched comparisons beyond those made here.
What the measurements do not establish
The truth of assertions. No claim in a run was independently checked against a source. The raters judged visible support in a reconstructed pack that truncated attached entries and included some inactive nodes. Their ratings concern that material, whose differences from the generator’s input are described in §3.
The frequency of either defect. Two episodes are traced; no rate was counted.
The validity of Δ. Preservation after Amendment 1 demonstrates that the threshold is reachable. It does not validate the proxy as a measure of structural loss (§§2–3).
Perfect agreement on Q2 likewise establishes agreement on this pack’s categories, without independently verifying the assertions being rated.
Human rating was unavailable to this project. Every judgement-based measure reported here, including the blind ratings, came from language models — the same broad class of system as the generator. The two blind raters belonged to one model family, different from the generator’s. There was no human assessment against which to compare their judgements. Shared priors are a possible influence on agreement, not an established cause of it.
Where the result cannot be carried
The pilot used one seed and one generator model, with three runs of five sessions per configuration. The curator was a model; human curation was not tested. Attraction was not measured.
There was no external retrieval, although dependency checks could use the available context. The ε prior was uncalibrated, and the sweep only reclassified recorded values (§4). No uncertainty intervals were computed. Both similarity floors retained the seed’s causal schema. Transferability across questions, causal schemas or generators is unknown.
What the limitations do not touch
The two permitted transitions remain demonstrable from the records in §5, irrespective of their unmeasured frequency. The two conditional outcomes of the decision rule remain as calculated in §4. Neither result settles the cause of the observed depth pattern or the behaviour of another implementation.
8. The Ledger
Part One ended on a sentence: permit intelligence to remain unfinished. This part ends on a table, because that is what the sentence turned into once it was built.
Selected figures, pilot-01. Structural measures are computed from the final snapshots of each run, averaged over three runs; the PRESERVE share counts decisions across all fifteen sessions of that configuration. A dash marks a row that does not apply.
| self-ask + store, curator | protocol, curator | self-ask + store, no curator | protocol, no curator | |
|---|---|---|---|---|
| live nodes after session 5 | 5.33 | 8.00 | 5.33 | 10.33 |
| distinct nodes worked | 5.00 | 5.33 | 2.67 | 6.00 |
| closed nodes | 0.33 | 0.67 | 0.00 | 2.00 |
of those, with ≥1 entry in facts | 0.33 | 0.33 | 0.00 | 0.67 |
| maximum depth | 2.33 | 3.00 | 2.00 | 1.67 |
PRESERVE decisions / all decisions | — | 13/15 | — | 13/15 |
Under the pre-listed metrics, the advantage did not survive curator removal (§4). Including coverage satisfies both clauses, but the first margin is small: one additional counted node across three runs, 16 against 15, or 0.33 per run. That count combines voluntary and forced returns. On voluntarily touched nodes alone, C-cur has 3.00 against B-armed-cur’s 5.00; this is a decomposition, not a replacement criterion. The written rule did not close its admissible set or specify a minimum margin. We report both conditional results and the size of the difference, without treating it as an established stable advantage.
The closed-with-facts row counts nodes with at least one entry in facts. The historical metric name, grounded_closures, implies checks of source and sufficiency that the computation never performs. One of the two episodes in §5 enters this count without disclosing the unmet requirement at closure; the other never became a closed node. The table reports final states. The traces in §5 establish the transitions behind them.
Preservation occurred in 13 of 15 decisions in each protocol configuration, or 86.7 percent. This demonstrates that the chosen threshold is reachable.
Part One argued that a system never allowed to leave a question open will never be curious. The pilot was not designed to test that claim directly. The ledger records survival, growth and closure, but these counts alone cannot certify the grounds for a closure or the substance of a deeper question chain.
The store retained enough trace for an independent check to find two defects in the contract and a series of errors in our own report. It made those transitions auditable. That alone did not establish research progress.
Notes on sources
The pilot-01 protocol, implementation, data and calculations are not published and are available on request at press@singularityforge.space.
§2 — Verification: the pilot-01 implementation was inspected for medoid selection, paired judgement, and the store rendering that defines what a session receives, including the omission of evidence text and the count-only display of preserved candidates. The inspection also covered removal of satisfied requirements during condition revision and the instruction given to the dependency checker. The protocol and Amendment 1 were checked for the curator budget exception, ε and the revised tension proxy.
§3 — Verification: similarity and cross-domain figures were checked against the stored pilot-01 computation results; the embeddings and domain assignments were not re-derived.
§3 — Verification: chronology was checked against the pilot-01 protocol, Amendment 1, the author’s analysis account, and the blind-rating rule and its amendments, distinguishing the information available at each point: protocol, metrics, predictions and decision rule before any session; Amendment 1 on shake-out data, fixed before the main pilot; similarity reference points designed with the run in progress and computed at analysis; reading rule after the mechanical results and before any ratings; its four-exceptions amendment after the first rater’s summary and before the key; revisions for pilot-02 after the key. The protocol supplies the budget exception, ε-sweep limitation and decision rule; Amendment 1 records the proxy change. The analysis implementation supplies the calculation of regen_dup_share. The blind-rating rule and its amendments record the interpretation criteria and their revisions.
§4 — Verification: the corrections in this revision came from an independent recomputation against the saved pilot-01 session records, not from the method catching itself. Amendment 1 to the tension proxy — found after a two-session shake-out run and before the pilot, on external review of the shake-out numbers — is described in §3.
§5 — Verification: pilot-01, C-cur/r1, node q1. The event journal records the dependency check in session 2 at sequence 11 and its retirement from the return condition at sequence 16. Store snapshots after sessions 2–5 retain the evidence text; saved inputs to sessions 3–5 contain neither that text nor the retired requirement. The implementation was inspected for the condition-revision rule and the checker instruction. The original blind-rating records supply the Q2 categories. The independent appearance of the “40-50%” figure noted above is recorded among the factual assertions in the saved response for Barmed-nocur/r1, session 4.
§7 — Verification: the pilot-01 implementation was inspected for the checker instruction, the answer decision and unconditional closure; §5 identifies the run records for both episodes. The protocol and Amendment 1 supply the budget and ε provisions and the proxy revision. The blind-rating rule and its amendments define the scope of the ratings.
§8 — Verification: pilot-01, Barmed-cur, C-cur, Barmed-nocur and C-nocur, runs r0, r1 and r2 in each configuration. Structural figures were recomputed from the store snapshots after session 5; preservation shares were recomputed from the saved decisions for sessions 1–5. Worked nodes have a nonempty resurfaced list; depth is the longest parent chain in the final snapshot, averaged over runs. These definitions were checked against the analysis implementation. grounded_closures is the key used in the computed metrics, not a field of the store; the row title states what the computation does. dep checks and anchors are excluded — the first counts retained last checks per node-requirement pair rather than check events, the second regex-extracted years and capitalised words unrelated to canonical Anchors. Both definitions were checked against the analysis implementation.
Voice of Void Collective — SingularityForge, 2026. Part One: Curiosity by Design: When Digital Intelligence Wants to Know.
