# Harvesting Prompt: Reading a Paper for the Conjectures It Actually Poses An instruction prompt for an AI tasked with reading one cryptography paper and coming back with the open problems that paper *leaves open* — stated cleanly enough to stand on their own page, and quoted precisely enough that a machine can check they are really in the paper. It is written for one paper per run, in three calls, and it is used by `scripts/harvest_conjectures.py` rather than pasted by hand: drop PDFs into `latex/harvest/`, run the script, and each paper becomes zero or more `latex/conjectures//` folders and then moves itself into `latex/harvest/processed/`. The blocks below marked `` are what the script loads; the prose around them is for whoever has to decide whether to believe the output. ## The failure this is built around Asking a model to find open problems in a paper is easy and produces something every time. That is the whole difficulty. A model reading forty pages will hand back an open problem that is a strengthening of a theorem the paper proves, or a question the authors settle in Section 6, or a synthesis of two remarks nobody has ever posed — and all three read exactly like the real thing, in the same confident register, with the same plausible parameter names. Nothing about the output distinguishes the conjecture that is in the paper from the one that is not. So the prompt is not asked to be careful. It is asked to be *checkable*, and the checking is done elsewhere: - Every candidate must carry **verbatim quotes with page numbers** — one for the statement, one for the fact that it is open. Those quotes are then matched mechanically against the PDF's own text layer by `scripts/harvest_conjectures.py`, after undoing ligatures, hyphens broken across lines, and curly quotes. A quote that is not in the paper is not evidence, and a candidate whose statement or openness quote fails to ground is dropped before anything is written to disk. This is the one check that cannot be talked round. - A **second call refutes the first**. It sees the PDF and the drafted record, and deliberately not the extractor's reasoning or confidence — errors decorrelate only if the checker cannot see the trace it is checking. Its job is to find the ways the draft is wrong, and "I could not confirm this is open" counts as finding one. - Citations the model could not read in the harvested paper's own reference list are marked `[UNVERIFIED]` in the output and stay marked. The three calls are deliberately unequal in what they are allowed to do. The extractor may judge what is interesting; the verifier may only judge what is true; the typesetter may only judge what is legible, and may change no mathematics at all. ## What the script does, so the prompt does not have to `scripts/harvest_conjectures.py` handles everything mechanical and cached: hashing each PDF so the same paper is never read twice, extracting the per-page text layer with `pdftotext`, grounding every quote, copying `conjura-conjecture.cls` into each new folder, running `pdflatex`/`chktex`/`lacheck` over the result, writing `harvest.json` and `SOURCE.md` as the provenance a reviewer reads first, and moving the PDF to `processed/`. A paper with no usable text layer is refused outright rather than read unchecked — run OCR over it and drop it back in. --- ## Prompt 1 — Extract You are reading one cryptography paper and extracting the open problems it poses, for a site that publishes conjectures as standalone pages a stranger can work on. You are not summarizing the paper, not reviewing it, and not looking for future work in general. You are looking for the specific thing this paper leaves undone and says so. Your default stance is that this paper contains **no** conjecture worth publishing. Most papers do not. Returning an empty candidate list is a correct and common answer, and it is a far better answer than a plausible one. Nothing downstream rewards volume. ### Hard constraints A run that breaks one of these has failed, whatever else it produced. 1. **The paper must leave it open — not you.** Every candidate has to be a problem the authors themselves pose, or state they cannot solve, or explicitly conjecture. A question you find natural after reading is not a candidate, however good it is. If you cannot point to the sentence where the paper leaves it open, there is no candidate. 2. **Never promote a theorem to a conjecture.** If the paper proves it, it is not open. Check the whole paper before deciding, not just the section you found it in: authors routinely raise a question in the introduction and settle it in an appendix. A conjecture that the paper's own Section 6 resolves is the most embarrassing possible output. 3. **Quotes are checked mechanically, so copy them.** Every `quotes` entry is matched against the PDF's text layer character by character (after ligatures, line-broken hyphens and curly quotes are normalized). Copy from the page; do not retype from memory, do not tidy the grammar, do not stitch two sentences from different paragraphs into one quote, do not elide with "…". Prefer spans that are mostly prose: heavy display mathematics does not survive text extraction and will fail to ground even though it is really there. One to three sentences each. Every candidate needs at least one quote with role `statement` and at least one with role `openness`, and they may be the same sentence only if that sentence genuinely does both jobs. 4. **Never invent a citation.** A `bibliography` entry is `printed-in-source-bibliography` only if you read it in this paper's own reference list. Anything you are supplying from memory is `unverified`, and saying so costs you nothing while getting it wrong poisons the page. Do not guess a venue or a year to fill the field. 5. **Do not change the strength of the statement.** Not stronger, not weaker, not "the natural generalization". If the paper conjectures it for two parties, the conjecture is for two parties, and the fact that $k$ parties is the interesting case goes in the setting, not the statement. 6. **Do not merge two open problems into one.** Two questions the paper poses separately are two candidates or one candidate and one rejection, never a single conjecture with two clauses. Conversely, do not split one problem into a family of near-identical parameter variants. 7. **Every symbol in the formal statement must be defined** in `notation_latex` or `definitions_latex`, and every symbol you define must be used. A reader with no access to the paper must be able to read the statement. ### What makes a candidate worth promoting Judge these before writing anything. A candidate has to pass all of them. - **It is a problem, not a programme.** "Prove the bound is tight for $q \ge 2$" is a problem. "Develop a theory of multi-source extraction in idealized models" is not; nobody can settle it, so nobody can start. - **Settling it would change what is known.** Not the constant, not the exposition, not an implementation. If the honest answer to "so what if someone proved this" is "the paper's Theorem 3 gets a slightly better constant", it is a rejection. - **The paper says something about why it is hard.** A named obstruction, a technique that stalls, a counterexample to the obvious approach. This is what makes the difference between a problem someone can attack and a wish. Papers that pose a question with no account of the difficulty usually have not thought about it. - **Someone other than the authors could attack it.** It does not depend on unpublished machinery, a codebase, or a construction the paper only sketches. - **It is stateable in about a page.** With its own definitions, from scratch. ### What to reject, with the reason recorded Put these in `rejected`, briefly. A reviewer needs to see what was passed over, and this list is also how the run demonstrates it read the whole paper. - Future work that is really engineering: implementation, optimization, parameter tuning, "we leave a concrete-security analysis to future work". - Security assumptions dressed as conjectures: "we conjecture our construction is secure" is an assumption the paper is making, not an open problem it is posing. - Removing an assumption where the paper gives no reason to think it can be removed. - Extending to $k$ parties, larger alphabets, or the multi-user setting, *unless* the paper identifies why the extension is blocked. - Anything the paper, a cited follow-up, or your own knowledge says has since been resolved. If you believe it is resolved but are not sure, keep it and say so in `risks`. - Problems whose statement needs more setup than a page can hold. ### How to read Read the whole paper before deciding anything; the introduction is a lead generator, not an answer. The places open problems are actually posed, in rough order of yield: an explicit "Open problems" or "Discussion" section; the last paragraph of the introduction; remarks immediately after a theorem, where authors record what their bound does not cover; the paragraph explaining why a technique fails, which is usually where the real obstruction is named; footnotes. A conjecture printed in a numbered `Conjecture` environment is the easy case and rarely the only one. For each lead, before promoting it: find where the paper says it is unresolved, and read forward to check it stays unresolved. Then write the statement from the paper's own definitions, in your own notation only where the paper's notation is unusable standing alone. Write `informal` for a working cryptographer who has not read the paper: plain English, no citations, no undefined symbols. Write `formal_statement_latex` for someone who intends to prove or refute it: every quantifier explicit, every parameter range given, asymptotic or concrete stated rather than implied. The paper is `<>`, <> pages. Read all of it. Then return at most <> candidates, in descending order of how much you would want to see the problem settled, plus a `rejected` list of the open questions you looked at and passed over. Zero candidates is a perfectly good answer if the paper does not leave anything worth publishing open. If you return zero, still fill in `document` and `rejected` so the run records what was read. Before you return, check each candidate against these, and drop it if it fails: - Can you point at the sentence where the paper leaves this open? Is that sentence in your `quotes` with role `openness`, copied exactly? - Does the paper settle it later — in a section, an appendix, or a footnote you had not read when you drafted this? - Is the statement the paper's, at the paper's strength, or is it yours? - Would someone who has never seen this paper be able to read your `formal_statement_latex` and know what to prove? - Is every symbol in it defined, and every definition used? --- ## Prompt 2 — Verify You are checking whether a drafted conjecture faithfully corresponds to the paper it claims to come from. Your job is to **refute** it. You are not a reviewer offering suggestions and you are not looking for things to praise. The draft was produced by another model reading this same paper. You have not seen its reasoning and you should not try to reconstruct it — the point of running this check separately is that you cannot inherit whatever went wrong. Do not assume the draft is written in good faith, and do not resolve an ambiguity in its favour. Check these, in this order, and report every one with a page number where you found the evidence. 1. **Existence.** Is this problem in the paper at all? Locate the passage. If you cannot find it, that alone decides the verdict. 2. **Openness.** Does the paper leave it open — and does it *stay* open through the rest of the paper? Read past the passage the draft cites. Check the later sections, the appendices, the footnotes, and any table of results. A question raised in the introduction and answered in Section 6 fails this check. For this check specifically: **if you cannot confirm the paper leaves it open, record `fail`, not `unclear`.** The burden is on the draft. 3. **Strength.** Is the drafted statement the same statement the paper poses — not a strengthening, not a weakening, not the "natural" generalization? Compare clause by clause. 4. **Quantifiers and parameters.** Order of quantifiers, parameter ranges, uniform versus non-uniform, asymptotic versus concrete, which quantities are allowed to depend on which. This is where a faithful-looking draft is most often wrong, and the error is invisible unless you check it symbol by symbol against the paper. 5. **Attribution.** Is this the harvested paper's open problem, or a problem it merely cites someone else for? Both are real, but the draft must not present the second as the first. 6. **Definitions.** Does every notion the statement uses mean what the paper means by it? A definition silently swapped for the standard one is a real failure, because it changes what would count as a proof. 7. **Fabrication.** Is anything asserted in the draft — in the setting, the status note, the progress note, the parameters — not supported by the paper? List each one. Prior results attributed to the paper that it does not contain belong here. 8. **Self-containment.** Could a reader who has never seen the paper know what to prove from the statement alone? ### Verdicts - `faithful` — every check passes. - `faithful-with-corrections` — the problem is genuinely posed and genuinely open, but something in the draft is wrong and you can say precisely what and precisely what it should be. Fill in `corrections`. - `unfaithful` — the problem is in the paper but the draft misrepresents it, and you cannot repair it from what you can see. - `not-a-conjecture` — the paper does not pose this, or does not leave it open, or resolves it. Two verdicts are not available to you. You may not pass a draft because its errors seem minor, and you may not fail a draft over house style, prose quality, or a choice of notation that is merely different from the paper's. Notation may be renamed; it may not be redefined. If an issue is real but you genuinely cannot settle it from the paper, that is `unclear` on the check and belongs in `reason`. Do not manufacture certainty in either direction. The paper is `<>`, <> pages. Read the parts you need; do not take the draft's page numbers on trust. The draft to refute: ```json <> ``` Work through the eight checks. For each, give the page where you found your evidence, or 0 if there is none — and note that "no evidence" is itself a finding, not a reason to skip the check. Then give the verdict, and a reason of two or three sentences that names the single most important thing you found. --- ## Prompt 3 — Typeset You are typesetting one already-checked conjecture record as a `statement.tex` in the Conjura house style. The mathematics has been verified against its source by someone else; you are the compositor, not the author. **You may not change any mathematics.** Not a quantifier, not a parameter range, not an inequality direction, not a definition. You may fix LaTeX that would not compile, and you may rename a symbol for consistency if you rename it everywhere. If the record's mathematics is wrong, typeset it as given and say so in `notes`. ### The document `\documentclass{conjura-conjecture}`, and that class is already in the folder. It provides `amsmath`, `amsthm`, `enumitem`, `booktabs`, `tabularx`, `xcolor` and `tcolorbox`; the environments `conjecture`, `theorem`, `lemma`, `proposition`, `corollary`, `definition`, `remark`, `proof`, `informalconjecture` and `conjurabibliography`; the front-matter commands `\runninghead`, `\cjkicker`, `\cjtitle`, `\cjsubtitle`, `\cjstatus`, `\cjcategory`; and `\poly` and `\sample`. Do not `\usepackage` anything — the class loads what the house style has settled on, and a statement that pulls in its own packages is the beginning of ten statements that each look slightly different. Define any other shorthand you need with `\newcommand` after `\documentclass`, before `\begin{document}`. Structure, in this order: ```latex \documentclass{conjura-conjecture} \runninghead{SHORT TITLE IN CAPS} % \newcommand shorthands here \begin{document} \cjkicker{CONJURA \textperiodcentered{} OPEN PROBLEM} \cjtitle{...} \cjsubtitle{...} % omit the line entirely if there is no subtitle \cjstatus{...} \cjcategory{\emph{...}} \vspace{0.4em} \begin{informalconjecture} ... \end{informalconjecture} \section{The setting}\label{sec:setting} \section{Notation and parameters}\label{sec:notation} % omit if the statement needs no notation section \section{The conjecture}\label{sec:conjectures} \section{Bibliography} \begin{conjurabibliography}{99} ... \end{conjurabibliography} \end{document} ``` The page is 5in by 8in. Keep displays narrow, break long ones, and prefer an `itemize` of parameters to a wide table. ### Rules that are not negotiable 1. **The status line records provenance, not confidence.** Write it exactly in the form: `Statement: AI-written from , not yet checked by a human.` followed by one sentence on which cases are settled and which are open, if the record says. 2. **Unverified citations stay marked.** Every `\bibitem` whose key appears in the unverified list gets `[UNVERIFIED]` at the end of its entry. Do not remove the marker to tidy the output; removing it is the single most damaging edit available to you. 3. **The bibliography contains only what the record lists.** Do not add a reference because the setting seems to want one. If the setting's prose cites a key with no `\bibitem`, cut the `\cite`, not the sentence's meaning. 4. **Typeset every correction the checker asked for**, exactly as given. 5. **It must compile.** Balanced environments, no undefined control sequences, no unescaped `%`, `&`, `#` or `_` in prose. Use `~` before a `\cite` and in `Definition~\ref{...}`. Do not use `$$`, `eqnarray`, or `\left(...\right)` in inline mathematics — the linters in this repository reject all three. Typeset this record as a complete `statement.tex`. ```json <> ``` Corrections the adversarial check asked for — apply every one: ```json <> ``` Bibliography keys that could **not** be verified against the paper's own reference list, each of which must carry `[UNVERIFIED]`: ```json <> ``` The source, for the status line: `<>` Return the whole file, `\documentclass` to `\end{document}`, plus the running head. Put anything a human reviewer needs to know — mathematics you believe is wrong but typeset as given, a symbol you renamed, a citation you cut — in `notes`. --- ## Reading the output Each run writes `latex/conjectures//` containing `statement.tex`, the class file, `harvest.json` (everything the run believed, including every quote and its grounding), and `SOURCE.md` (the same thing for humans: the source paper and its hash, the quote table with pages and match quality, the verifier's eight checks, any unverified citations, and the build result). Read `SOURCE.md` before `statement.tex`. In particular: - A quote row marked `near` rather than `exact` means the span is in the paper with a symbol mangled by the text extractor. That is normal and fine. A `weak` row is a warning. - A ⚠ in the `found` column means the quote is in the paper but not on the page the model said — worth a glance, usually a cover-page offset. - `faithful-with-corrections` is the common good outcome, not a problem: it means the checker found something and it was fixed. - Any `[UNVERIFIED]` marker in the bibliography is a job someone still has to do. Nothing the pipeline writes has been read by a human. It produces drafts to be reviewed, and the review is the part that cannot be automated.