One worked example covering your four focus areas. The prompts are real, the verification gate below actually executes in this page, and the roadmap shows what you will be able to do alone after each session. That last part is the product.
Invented research question: should Sagebrush Supply, a 12 store outdoor gear retailer, launch a rental program in 2026? Five steps. Each prompt comes with the reason it exists, because the reasons are what you are actually learning.
You are helping me frame a business research question before any research happens. Question: should Sagebrush Supply, a 12 store outdoor gear retailer, launch a rental program in 2026? 1. Rewrite the question as a decision with two or three options and a deadline. 2. List the five sub questions that would most change the decision, ranked by weight. 3. For each sub question, name the evidence that would settle it and where that evidence lives: filings, government data, trade press, primary interviews. 4. List three ways this research could fool us, such as stale data, sampling bias, or vendor marketing dressed up as research. Do not research yet. Output a framing table only.
An unframed research prompt returns a confident essay. A framed one returns a checklist you can hold every later answer against.
Research sub question 2: how fast is US outdoor gear rental growing, and who is renting? Rules: 1. Every claim must carry the figure, the publisher, the publication date, the URL, and a verbatim quote of the sentence the figure comes from. 2. If you cannot quote a sentence, mark the claim UNSOURCED and keep it out of the main table. 3. Prefer primary sources (filings, government data, company reports) over trade press, and trade press over aggregator blogs. Label each source with its tier. 4. No projections without the author of the projection and the method behind it. Output: a claims table, then a short list of what you could not source.
The rules do one thing: they force every number to arrive with the evidence needed to check it. A model can invent a figure easily. It is much worse at inventing a verbatim quote that survives the gate in section 02.
Convert the claims table into records with exactly these fields: id, claim, figure, quote, publisher, tier, date. One record per claim. No commentary. This output feeds an automated checker, so format discipline matters more than prose. If a field is missing for a claim, write MISSING rather than guessing, and list those claim ids at the end.
Prose is where errors hide. A fixed record shape is what turns step 4 into an automatic check instead of an afternoon of squinting at paragraphs.
Asking a model to double check itself mostly produces politer versions of the same mistakes. Verification has to live outside the conversation.
Write a one page decision memo for the Sagebrush rental question. Rules: 1. Use only claims marked VERIFIED by the checker. Claims marked MISMATCH, UNSUPPORTED or STALE may appear only in a footnote titled "discarded and why". 2. Every figure in the memo carries its claim id in brackets. 3. State a recommendation with a confidence level, and name the single missing piece of evidence that would most change it. Structure: decision, recommendation, evidence, risks, what would change our mind.
The memo inherits its trustworthiness from the gate, not from its tone. That is the whole trick, and it is teachable in one session.
Six claims came back from step 2 (all invented for this demo). Three survive. Press the button: the checks run right here in your browser, on the raw records embedded in this page. Open any row to see the evidence and the verdict.
C3 fails on a transposed digit, the single most common number error models make. C4 fails because its quote does not exist in the source. C5 is accurate but six years old. A human skimming the claims table would likely have passed all three. The gate is about forty lines of deterministic code, and in session 2 you have Codex write one for your own domain.
Chat is for exploration. Scripts are for repetition. Here is the same verification step at week one and at week three of the mentoring, and the exact kind of instruction you give Codex to get there.
You paste the gathering and extraction prompts by hand, eyeball the claims, and carry the rules in your head. This is the right place to start: you feel where the workflow bends before you freeze it into code.
The cost: every run depends on you remembering every rule, and the checks are the first thing skipped on a busy day.
The gate becomes a small script in your own repo. Codex writes it, extends it and tests it; you review the diff and run it. Same logic as the gate above.
# check_claims.py · Codex maintains it, you run it RECENCY_MONTHS = 24 def check(claim): if norm(claim["quote"]) not in norm(claim["snippet"]): return "UNSUPPORTED" if not figures_match(claim["figure"], claim["quote"]): return "MISMATCH" if age_in_months(claim["date"]) > RECENCY_MONTHS: return "STALE" return "VERIFIED"
In the research-kit repo, extend check_claims.py: 1. Add a tier field to each source (primary, secondary, tertiary) and attach a confidence label to VERIFIED claims based on tier. 2. Add a test where a claim's figure does not appear in its own quote, and assert the checker returns MISMATCH. 3. Run the test suite and show me the diff before anything is committed.
Notice what the instruction does: it names the repo, the file, the behavior and the test that proves the behavior. Writing tasks at this level is the Codex skill, and it transfers to any codebase.
Two or three sessions to start, as your posting describes. Each one ends with something you keep and something you can now do alone. Ongoing sessions after that are optional by design.
We map how you research today, then build the framing and sourcing prompts live, on one real question from your business or on a neutral example like this page.
We set up Codex against a small repo of yours and have it write your claim checker. You drive; I navigate. We break it on purpose once so you learn to read a failing test.
End to end on a second question, faster. Then failure drills: sources that disagree, paywalled evidence, and when to distrust even a VERIFIED claim.
The measure of success I propose: by session 3 you should not need me for the workflow itself, only for the next workflow.
The same discipline the workflow teaches, applied to the page that teaches it. Fourteen deterministic checks recompute the gate from the raw embedded records and audit the page, in your browser, every load.