Codex Handbook · Chapter 5 | Search, source ledger, and atomic claims

5.8 Make a research plan and keyword combinations

What this section solves

A useful search plan is a set of bounded decisions, not a pile of synonyms. Each group of terms must return to one question card and identify what would be enough to continue or enough to stop. The plan is written before any public page is treated as evidence.

What supports it

Use T1 and the research question card. For each question, distinguish the object term, field term, source-type term, and constraint term. A simulated result from the four offline cards is a practice signal only; it is not a live search result.

Follow along

1. List the four questions from T1 before writing any terms.
2. For each question, write an object term and a field term without using a real person or client name.
3. Name the expected material type, such as an organizer notice, a later correction, or a repost.
4. Write one stop condition for each group, such as a login request, no publication date, or an out-of-range source.
5. Use the four offline cards as simulated results and record which material type you would compare first.
6. Have a human check that summaries, comments, and promotional copy are not listed as evidence.

What you should see

T1 should show four keyword groups, each returning to one research question card. Every group says what would continue the pass and what would stop it. There should be no unused synonym list.

Practice and human acceptance

Practice: let a human choose one keyword group and explain its object, field, expected source type, continuation condition, and stop condition. Pass when no term widens the written scope.

Common pitfalls, recovery, and stop points

Do not let a search summary become a claim. Return to the question card and require a source location before recording an atomic claim. Stop when a result needs login, a download, or a new source not named in the plan.

Next

The next section explains what an official public page can and cannot establish about product capability and permission boundaries.

5.9 Product capability and permission boundaries when opening a public page

What this section solves

A public page can document a published description, but it cannot by itself establish the current state of a local machine, account, workspace, or permission prompt. This section keeps official-source wording, local observation, and exercise material in separate columns.

What supports it

The following six pages are official public references used only for the product-condition statements already written in this chapter. Their presence does not authorize a network action in this offline exercise.

Record the public references and their limits in the source ledger; the ledger is the exercise location, not a claim about the current machine.

ChatGPT Work and Codex; Using Codex with your ChatGPT plan; Models; Permission modes; Computer use; and Artifacts viewer. These links are source references, not proof of a current local state.

Follow along

1. Read the capability statement in the relevant public reference and copy only the stated scope into your notes.
2. Mark the publication date represented by the reference; do not call it a current local observation.
3. Write a separate “not established” line for the current Mac Studio, account, workspace, and permission state.
4. Compare the claim with the boundary in T1 and remove any action that would require login, browsing, or sending.
5. In T2, record the official page as a source reference with its exact location and limitation.
6. Have a human verify that no public sentence has been rewritten as a local product result.

What you should see

You should see a source column, a date column, a scope column, and a limitation column. The two CUR figures are public-page evidence from 2026-08-22; they are not local screenshots and do not prove the current Mac Studio, account, or workspace.

Practice and human acceptance

Practice: choose one official reference and write one supported sentence plus one unsupported-local-state sentence. Pass when the human checker can tell which sentence is public-source wording and which is a limit.

Common pitfalls, recovery, and stop points

Do not infer account access from a public explanation. If a permission mode, model, or page state needs a live check, record it as unverified and stop under the offline boundary.

Next

After the public-source boundary is clear, build a compact source ledger that preserves publisher, date, location, scope, and limitation.

5.10 Build the source ledger

What this section solves

The source ledger is the answer to “where did this line come from?” It stores the minimum metadata needed to reopen a statement and judge its limits. It is not a place to paste an entire card or to hide a conclusion under source-looking language.

What supports it

Use the source ledger with cards A, B, C and the public references from 5.9. Every row names a source type, an entry or page location, a date, the object and field it supports, and what it cannot establish. The later fact-check table must not be used as a substitute for this location record.

Follow along

1. Open the blank source ledger and create one row for each card or public reference used in the exercise.
2. Enter a source label and exact entry or page location; do not copy the whole source text.
3. Record publisher relationship, publication date, and the object and field in scope.
4. Write the support boundary and keep unsupported fields explicitly unknown.
5. Link any later correction to the original row instead of deleting the original.
6. Have a human open three rows and check that each can return to its input.

Copyable prompt 4:

Goal: Check whether my source ledger lets a person return from every row to a specific entry in the three offline cards.
Allowed to read: the three extract cards and my T2 personal copy.
Only output: In the existing T2 review-note area, list missing file names, entry locations, support ranges, or limitations; do not fill a conclusion.
Prohibited actions: Do not use the network, add a source, rewrite a summary as source wording, delete a conflict, or modify the three input cards.
Acceptance: A, B, and C each have a row; every row has locating information; missing items are listed one by one; no new file is created.
Stop when: A row cannot be located, a source relationship does not match the card, a new source would be needed, or anyone asks for a single conclusion.

Keep a ledger row small enough to review. If the row starts to contain a final answer, move the sentence to T3 as a candidate claim and preserve the ledger location.

What you should see

The source ledger should have a visible difference between source text, source relationship, and handbook judgment. A public URL can be a location; it is not a local execution result.

Practice and human acceptance

Practice: ask a partner to select a row and point to the exact card or page entry it names. Pass when the partner can also state the row's limitation without opening a new source.

Common pitfalls, recovery, and stop points

Do not use repeated sources as independent evidence. Do not turn a missing date into a guessed date. If the location in the source ledger cannot be reopened from the allowed inputs, mark the row insufficient and stop.

Next

The next section uses the locations recorded in the source ledger to set a minimum evidence standard.

5.11 Set a minimum evidence standard

What this section solves

“I saw a source” is not enough for a reviewable claim. The minimum standard asks whether the source can be located, whether it addresses the exact field, whether its scope applies, and whether its limitation is retained.

What supports it

Use the source ledger and the atomic-claim fields. A source location is evidence support only for the field it states. A teaching diagram, a public URL, and a local fictional UI record are different evidence types.

The atomic-claim fields are held in the atomic claims table.

Follow along

1. Choose one candidate sentence from a card and write its exact ledger location.
2. Check that the source wording covers the same object and field as the candidate.
3. Record the source date and applicable condition rather than assuming they are current.
4. Write what the source cannot prove, including any account, workspace, or private-state claim.
5. Leave a candidate in “unknown” when its location or scope is insufficient.
6. Have a human check the sentence against the source without seeing your interpretation first.

What you should see

Every candidate has a location, a matching field, an applicability note, and a limit. There are no unsupported “confirmed” labels just because a source is official or repeated.

Practice and human acceptance

Practice: test three candidates. Pass when the reviewer can find the source sentence and explain why it does or does not meet the minimum standard.

Common pitfalls, recovery, and stop points

Do not increase confidence to make the table look complete. Preserve an unsupported candidate as unknown and state what evidence would be needed, without collecting it in this pass.

Next

Once the evidence bar is explicit, split the source text into atomic claims.

5.12 Extract atomic claims that can be checked independently

What this section solves

An atomic claim makes later verification possible. It contains one matter, one object-field pair, and one source location. Splitting a sentence must not remove its condition, date, or limitation.

What supports it

Use the atomic claims table and the source ledger. A claim is a record awaiting verification, not a conclusion. If two cards must be combined to produce a sentence, label it as a handbook inference and keep both locations.

Follow along

1. Open the T3 personal copy and create blank rows in card-entry order.
2. Read A, B, and C one entry at a time and copy only one matter per row.
3. Give each row a number that returns to a card and entry number.
4. Write the simulated date, activity object, and material range in the applicable-conditions field.
5. Keep conflict, unknown, and next-safe-action fields open instead of supplying answers.
6. Randomly choose three rows and ask a human to restate only what their evidence location supports.

Copyable prompt 5:

Goal: Split the specified entries from the three offline cards into one-matter-per-sentence T3 personal records.
Allowed to read: the three extract cards and the entry range I specify in my T3 personal copy.
Only output: Fill only claim number, source sentence, information type, evidence number, applicable conditions, and next safe action; record conflict and unknown only as the material states them.
Prohibited actions: Do not merge a date with a recording claim, invent a tenth item, write a handbook judgment as source wording, use the network, or modify a card.
Acceptance: Every row contains one matter; every row returns to an entry; unsupported fields remain unknown.
Stop when: A compound sentence cannot be split without deleting a condition, an evidence location is missing, a new source is required, or the requested output is a final answer.

The diagram has already shown the row relationship; the source ledger remains the place for source metadata. Do not add a second copy of an input.

What you should see

T3 should contain numbered rows whose claims can be read without the neighboring row. A condition that applies to only one claim stays on that claim. Unknown and conflict are explicit states, not empty spaces.

Practice and human acceptance

Practice: split one compound sentence into two or three rows and have a human check that each row retains its evidence location and does not overclaim.

Common pitfalls, recovery, and stop points

Do not make a row shorter by deleting “may”, “for this scope”, or “as of”. Restore the source wording and split again. If a row needs two unrelated locations, mark it as a relationship to review.

Next

The next section checks whether each claim applies to the right time, region, object, and condition.

5.13 Check timeliness, region, object, and applicable conditions

What this section solves

A true sentence in one scope may be unusable in another. This section prevents a material date from being mistaken for an activity date, a general description from being applied to a specific object, or a regional condition from being silently widened.

What supports it

Use the date, region, object, and condition fields in T3 and the locations in T2. If the source does not state a range, write “not stated” or “pending confirmation”. Do not convert an omission into a complete affirmative sentence.

Follow along

1. Open T3 and check time, region, object, and other conditions row by row.
2. Copy only the range explicitly written by the corresponding card.
3. Mark an unstated range as “not stated” or “pending confirmation”.
4. Check that sources for the same field refer to the same object and time.
5. Mark a scope mismatch as needing cross-checking.
6. Ask a human for one row: “For whom, when, and under which condition does this sentence hold?”

What you should see

Each candidate has a visible applicability statement. A missing region or condition remains a limitation; it does not disappear because the wording sounds confident.

Practice and human acceptance

Practice: select three rows and fill only the ranges stated by their sources. Pass when another reader can identify the object, time, region, and condition without guessing.

Common pitfalls, recovery, and stop points

Do not use “today”, “everyone”, or “available” when the source gives a narrower scope. Keep the narrower wording and stop when a broader claim would need a new source.

Next

The last section of this unit decides when a row needs a cross-check and when the current bounded evidence is enough.

5.14 When cross-checking is required

What this section solves

Cross-checking is useful when it resolves a concrete difference, not when it merely increases the source count. The decision belongs in T3 with a reason, a specific comparison, and a stop point.

What supports it

Look for different dates, publishers, scopes, or missing explanations. Compare only the field named in the question. A “yes” without a comparison target is not a plan; a “no” without a limitation is not an acceptance.

Follow along

1. In T3, circle rows with different dates, publishers, or missing explanations.
2. Mark whether cross-checking is needed and write the reason.
3. State the exact entries to compare in the next-safe-action field.
4. For a row that needs no further check, write that the current bounded location is sufficient and retain its limitation.
5. Set a human stop point at the material, time, or quantity ceiling.
6. Have a human verify that every “needed” decision names a concrete comparison.

What you should see

T3 should distinguish an unresolved conflict from a checked row. The next action is specific, and the plan ends when it reaches its written limit.

Practice and human acceptance

Practice: choose one row that needs a cross-check and one that does not. Pass when the human can explain the different next actions and the stop line for both.

Common pitfalls, recovery, and stop points

Do not keep adding sources to make uncertainty feel smaller. If the required comparison is outside the approved material or would require login, stop and retain the unknown.

Next

The next unit records conflicts, insufficient evidence, fact-check status, and the final bounded delivery.