GO Vault

CODEX_CURATION_TOIL_PROTOCOL

4 min read

Curation & Toil Protocol (Higher-Order Work)

This document defines the difference between gathering information and making the system right.

If you are an AI working in this vault: you are not being asked to “merge files.” You are being asked to think, connect, and refine—with traceability.

The Distinction

Gathering (Necessary, Not Sufficient)

Gathering is mechanical:

  • copy files into the right folder
  • extract rows from spreadsheets
  • consolidate markdown into a dump
  • deduplicate obvious repeats

Gathering increases availability of information, but not understanding.

Curation (The Real Work)

Curation is intellectual:

  • state each claim cleanly (one sentence)
  • classify it (axiom/definition/lemma/theorem/evidence/protocol/etc.)
  • identify what it depends on and what it enables
  • add objections and defenses that actually address the claim
  • make the claim testable (when possible) by defining operationalizations and evidence trails
  • remove ambiguity, bloat, and hidden circularity

Curation produces usable structure: a claim graph a reader (human or AI) can traverse and audit.

Toil (Why It Takes Sweat)

Toil is the iterative cost of making curation correct:

  • reread sources until the invariant meaning is clear
  • choose the minimal dependency set (not “everything related”)
  • resolve contradictions (or explicitly mark them)
  • reword until the claim is both minimal and precise
  • verify the chain does not smuggle in unstated assumptions

Toil is the cost of rigor.

Definition Of “Make It Right”

A note is “right” when it is:

  1. Explicit: the statement is unambiguous and minimal.
  2. Typed: the claim type matches what it really is (axiom ≠ evidence ≠ protocol).
  3. Positioned: dependencies and downstream effects are correct and not circular.
  4. Defended: strongest objections are stated; defenses answer those objections.
  5. Auditable: source pointers exist; evidence trails exist where needed.
  6. Non-fictional: no fabricated citations, quotes, datasets, or experiments.
  7. Consistent: terminology and symbols match the vault’s conventions.

The Higher-Order Curation Loop (Per-Note)

1) Extract the core claim

  • Write a single sentence: “X is true (in scope S).”
  • If you can’t write the one-sentence claim, you don’t understand it yet.

2) Classify the claim (typed discipline)

Choose one and commit:

  • AXIOM, DEFINITION, LEMMA, THEOREM, BOUNDARY_CONDITION, EQUATION, PROTOCOL, PREDICTION, EVIDENCE, RESULT, INTERPRETATION

If it’s not a claim (it’s a topic overview), it belongs in a MAP/MOC, not as an axiom.

3) Dependencies (no smuggling)

  • List the minimal prerequisites required for the claim to be meaningful.
  • For each dependency, add a one-line justification: “needs this because…”
  • Don’t add dependencies just because two notes share vocabulary.

4) Downstream enables (what this unlocks)

  • List what becomes possible if this claim holds.
  • Prefer concrete unlocks (derivations, constraints, tests) over vague thematic links.

5) Defeat conditions (what would break it)

Write at least one:

  • empirical defeat (if falsifiable)
  • formal inconsistency (if logical/mathematical)
  • scope failure (if it only holds under specific assumptions)

6) Standard objections (steelman first)

List the strongest 3–7 objections, not the easiest.

7) Defense summary (tight, not long)

For each objection, write a short defense that addresses it directly. If you can’t defend it without handwaving, mark the note for human review.

8) Collapse analysis (why it matters)

State what dies if this claim fails:

  • which theorems collapse
  • which bridges fail
  • which predictions lose meaning

9) Evidence trail (only when appropriate)

If the claim is empirical-support / evidence / prediction:

  • write an operationalization note (what measure proxies the construct)
  • link dataset notes (where the numbers come from)
  • create evidence extracts (exact quote/table/figure + access date)
  • write results notes (methods + parameters + outputs)

If the claim is axiomatic/definitional, don’t pretend it is “proven by evidence.”

10) Quality pass (anti-circularity)

Check:

  • does the claim use its own conclusion as support?
  • are definitions being used as evidence?
  • are “bridges” becoming hidden assumptions?
  • is the claim too large (should split) or too small (should merge)?

Rules For Editing Canonical Notes

  1. Additive by default
  • Don’t overwrite meaningful prose without cause.
  • Prefer adding clarity in-place over rewriting history.
  1. Never fabricate
  • If a source is missing, say so and leave an explicit TODO marker.
  1. When uncertain, mark it
  • Use explicit markers (e.g., “) and describe what is unclear.
  1. Prefer minimalism
  • If two paragraphs can become one sentence without loss of meaning, do it.
  1. Keep provenance
  • Every major claim should point to where it came from (file + context).

When To Stop And Ask A Human

Stop if any of these are true:

  • a dependency choice changes the meaning of the system
  • sources conflict and the resolution isn’t obvious
  • the work implies a new axiom or modifies David’s axioms/equations
  • you cannot write a non-handwavy defeat condition or defense

One-line Summary

Gathering collects words. Curation turns words into a typed, traceable claim graph. Toil is the price of making it correct and usable.

Graph View