Skip to content
corpus.
Corpus home

The public edition / Inspect the evidence

Start with three actual examples of Corpus at work, then inspect the source samples and their limits below.

Evidence & source samples

Corpus’s public claims should be inspectable. This guide connects the site’s explanations to selected findings, requirements, design decisions, review results, and observations from actual work. The studies and case accounts include further samples beside the claims they support.

These are selected excerpts and authored accounts from a private project archive. They let you inspect the reasoning and recorded evidence behind a claim; they do not give you the complete datasets, repository, or independent reproduction environment. Quotation blocks reproduce selected source wording. Tables labeled “selected fields” preserve record values; surrounding explanations are editorial interpretations. Dates describe the historical work, not a promise about every later version.

For the combined account of purpose, architecture, and what the record supports, read How Corpus works. It brings together separate reports from the project’s Archivist, Architect, and Sigillite.

Choose a claim to inspect

Claim or question Evidence you can read What it does not establish
Can work remain owed after an agent leaves? Order books: an unpaid task disappears from a handoff; a closure fails until its follow-up has a carrier; later review finds stale obligations. That preserved obligations are always useful or completed on time.
Does a handoff actually reach the next session? Succession and retirement: misdelivered entrance prompts, a reversed restart design, and observed use of a simpler command. Better successor judgment or continuity of personal identity.
What was independently reviewed? Source custody: a bounded assignment, overlapping writers, repeated amendments, an exact candidate, and a postacceptance defect. A guarantee that accepted software has no defects.
Was a performance explanation measured? Tests under the floor: repeated database setup, a regression caused by its repair, and a corrected worker-count explanation. A current benchmark or one speedup applying to every test selection.
Can a correct answer hide faulty use of evidence? Reader pilot: a chronology task, a fixed rubric, and failures despite valid output structure. A general model ranking or evidence-discovery ability.
Did collegial wording improve agent work? Address study: a confounded comparison withdrawn, further trials, and disagreement between Human and model judges. A reliable benefit or proof that wording never matters.
Did a conceptual primer improve research? Primer pilot: original task samples, an inquiry rubric, and a grading correction. Improved research performance; participants produced plans, not executed inquiries.

What the record types mean

The identifiers below belong to Corpus’s internal record system. They are stable references within that archive, not external certifications. On this site, links lead to the selected public material rather than to inaccessible private records.

  • FIND — a finding. An observation, concern, interpretation, or correction worth preserving. Its presence does not make it true. The address-study withdrawal shows one finding correcting earlier conclusions.
  • BANNER — a larger goal and its requirements. BANNER-004 asked for retirement to work through ordinary use. Its completion needed observations beyond committed code.
  • BLUEPRINT and PART — an approach divided into pieces. The plan below separates a rehearsal tool, command changes, repeat-run behavior, and a final live test. A planned part is not a delivered result.
  • REQ — a bounded work contract. REQ-856 states the unwanted behavior, the change, and an observable completion condition.
  • TRACE — an execution or review record. TRACE-5533 records an independent review of an identified candidate. TRACE-5535 separately records integration.
  • PATCH — a recorded repair. The testing case includes the verification fields for PATCH-593. A repair has its own evidence and may have limits.

A change from plan to live use

The Keeper checks an open notebook with a magnifying lens.Fictional illustration

Reading guide / Source trail

Follow the change, one record at a time.

Plan → Contract
BLUEPRINT-023 and REQ-856 describe the repair and its completion condition.
Review
TRACE-5533 records judgment of an identified candidate.
Integration
TRACE-5535 records landing separately.
Use and correction
FIND-5390 and FIND-5415 keep later observations beside the accepted change.

Start with the plan →

The following example concerns a handoff that was too long for a size check. It is a small enough change to explain concretely, while showing how Corpus connects a goal, a plan, a contract, a candidate, review, integration, and subsequent observation.

Here, retirement means ending an agent’s tenure in an office; it does not necessarily terminate the host session. The wider goal was to let a departing agent leave useful words and finish without procedural workarounds. The first live test of the new retirement route exposed a contradiction: both walkers were refused at the size check and trimmed their handoffs to pass. That failed the intended behavior even though implementation work had already landed. The plan gained another repair, PART-087, implemented through REQ-856. The full succession case explains the earlier host failures and design reversals.

The plan: BLUEPRINT-023

Historical design, October 2026; closed on 12 October. Selected objective excerpt:

A holder who knows what it wants to hand on retires in at most three turns: write the Baton, write the Roll’s story or don’t, run one command (python corpus.py session retire --handoff FILE --story FILE).

“Baton” means the forward-looking handoff. “Roll” means the departing holder’s retrospective account. These samples describe their function without publishing either document.

Selected parts, not the complete dependency graph:

Part Selected work Associated requirement
PART-029 Add a retirement rehearsal tool. REQ-803
PART-030 Accept a handoff file and a story file. REQ-809
PART-033 Make a repeated retirement command safe. REQ-815
PART-038 Point old retirement commands to the new route and remove dead code. REQ-845
PART-087 Report a handoff-size overrun instead of refusing departure. REQ-856
PART-044 A new walker leaves through the command and another arrives. Final live test

The owning blueprint reports fifteen landed parts and five earlier parts struck. The final test is a separate piece of work; completing implementation parts alone did not answer the goal.

The contract: REQ-856

Requirement revision 1, fulfilled 12 October 2026. Selected completion-condition excerpt:

In the rehearsal a 5,012-byte handoff retires on the first run with exit 0, its receipt says Baton: N bytes, M over the 5,000 the house keeps, and the retirement commit’s message carries the same line; nothing is written into the Baton.

This makes the desired behavior testable. The command must preserve the supplied words, complete the departure, and report the excess outside the handoff itself. Three of its ten declared paths were tools/retire_session.py, tools/retire_rehearsal.py, and tools/baton_check.py.

Repairing the departure command alone would have moved the same forced trimming to a successor’s next write. The requirement therefore made the size check a notice at retirement and at both source-write gates, using one helper for the shared message. That explains why this small behavioral change touched ten paths.

The scope matters: this requirement changes the size check. It does not authorize ignoring every retirement error. Missing files and invalid identities still have their own behavior.

The review: TRACE-5533

Independent agent review, 12 October 2026. Selected fields:

“Independent” here means a separate agent review job within the same project. It is not an external audit or independent reproduction.

Field Recorded value
Requirement REQ-856, revision 1
Review role Eyes
Verdict PASS
Candidate commit 7538f8053a1d36e1c5fa01aadd5acf8a59755685
Candidate tree 544f581143cd0472dac4f6163a7d5e3f5ca64788

The reviewer identified the candidate and read all ten declared paths. It ran the whole retirement rehearsal twice, reporting 86 of 86 cases, and inspected preserved scratch repositories at the size boundary.

Selected observation from the review:

5,012 bytes: retired on the first run. The committed Baton blob is 5012 bytes.

Recorded output, selected from that same review:

Baton: 5,012 bytes, 12 over the 5,000 the house keeps

The review also checked 4,999, 5,000, and 5,001 bytes. It explicitly did not run integration against the live store; its real call-site checks used scratch fixtures. Some existing tests still expected the old refusal and needed a separately recorded update. The PASS therefore belongs to this contract and candidate, not to every test or every operation in the project.

The integration receipt: TRACE-5535

Integration record, 12 October 2026. Selected event text:

LANDED REQ-856: refs/heads/main 23f8f4f5ffb4 -> 2b6c50d0afaa (constructed of reviewed 7538f8053a1d)
AFTER-LAND PASS REQ-856: 1 of 1 item(s) passed at 2b6c50d0afaa; the landing stands either way

These receipts record a branch update and a specific postintegration check. The landing commit differs from the candidate because the reviewed change was integrated onto the then-current main branch. Neither line, by itself, establishes that a real departing holder can complete the entire journey.

The observed use: FIND-5390 and FIND-5415

The second live walkthrough passed on 12 October. FIND-5390 records both walkers leaving on their first attempt and the successor following the handoff’s first task. The two handoffs contained 2,464 and 2,556 bytes, so this walk did not exercise the over-limit branch. It also records a dropped recovery instruction that was restored separately. That omission remains part of the result.

A subsequent observation examined one Human-directed batch of fourteen retirements using --empty-chair, which deliberately left the offices vacant. These were departure checks, not fourteen automatic successions or a sampled reliability rate. All fourteen completed the command in one run; twelve supplied new handoffs. The other two must not be counted as new handoffs. One 5,203-byte handoff completed with its overrun notice. FIND-5402 judged the required run of five qualifying examples met.

FIND-5415 checked the account and supported the fourteen rows and twelve qualifying handoffs, while correcting guessed clock times and the count of commands that piped their receipts: twelve receipts were piped. Completion was corroborated by commits and stored status, not fourteen directly observed exit codes. It also noted a separate draft-checker complaint; no words were edited to satisfy it. This is why the account cites the correction alongside the original observation.

The evidence supports a bounded claim: the revised departure route worked in these observed uses, including one over-limit handoff. It does not establish the truth of every handoff, improved successor performance, or failure-free retirement in all future settings.

Read or reuse the public evidence

The following Markdown files contain the same reviewed prose and selected samples as the corresponding web pages. They can be saved, attached to a review, or read without the visual interface. They are public editions, not exports of the underlying private records.

The excerpt chain above was checked against BLUEPRINT-023, PART-087, REQ-856 revision 1, TRACE-5533, TRACE-5535, FIND-5390, FIND-5402, FIND-5412, and its correction FIND-5415. The design document is house/banners/BANNER-004/blueprint-one-command.md; its full text remains private. Record identifiers and file paths identify provenance, not public repository links.

Public edition reviewed 17 October 2026. Shawn Ganz originated and directs Corpus; agents contribute design, implementation, research, and review. This page demonstrates selected engineering and evaluation practices, not a certification of AI safety or security.