OpenArx

Added value: +{
+  "description": "Optional: which entry INSIDE your uploaded ZIP is the main document, as its path in the archive (e.g. \"main.tex\" or \"paper/main.tex\"). Omit it and the platform takes the single .pdf/.tex/.md at the archive root; a multi-file LaTeX project, or an archive wrapped in a folder, needs it named — the error then lists the candidates. Ignored for a PDF upload. Never the name of the uploaded file itself.",
+  "type": "string"
+}

Previous value: -"window over claims_list, default 20"New value: +"window over claims_list, default 200 (the whole list up to 200; claims_truncated only beyond)"

Previous value: -100New value: +200

Added value: +{
+  "description": "start of the claims_list window (0-based) for lists longer than limit; claims_total says how many there are",
+  "minimum": 0,
+  "type": "integer"
+}

Previous value: -"Mode fields the routed sub-procedure reads: diagnose → {intent, focus?, parent_run_id?}; checkpoint → {submission{records[],track_note?}, stage, claimed_usage?} (submission_hash is SERVER-derived — do NOT send it); ask → {question, focus?}. Send this as a JSON object; a JSON string of the same object is also accepted, but a string that is not a JSON object is rejected."New value: +"Mode fields the routed sub-procedure reads: diagnose → {intent, focus?, parent_run_id?, target_documents?: string[] (the works this run is ABOUT — arXiv ids, arXiv urls or document ids; the platform writes them on the run as run_state.target and draws TARGETS edges; unresolvable names come back in declared_targets.unresolved), budget?: {protocol: \"A\" | \"B\", frame?: string | number} (A = a frame fixed with the human up front, B = decisions as you go; written on the run as run_state.budget)}; checkpoint → {submission{records[],track_note?}, stage, claimed_usage?} (submission_hash is SERVER-derived — do NOT send it); ask → {question, focus?}. Send this as a JSON object; a JSON string of the same object is also accepted, but a string that is not a JSON object is rejected."

Added value: +{
+  "description": "also list the metrics that MEASURE this document (metric.measures_entity names it, in any spelling) — the profile a repeat review starts from (default off)",
+  "type": "boolean"
+}

Previous value: -"How much of each connected record to return. Levels DROP WHOLE FIELDS and never cut a string: 'minimal' = identity + supersede state, no claim text; 'standard' = + the claim itself, whole, without evidence; 'full' (default) = everything. Measured ~145 / ~658 / ~1281 characters per record."New value: +"How much of each record to return — applies to `connected` AND to `relations`. Levels DROP WHOLE FIELDS and never cut a string: 'minimal' = identity + supersede state + verification_outcome + a 200-char text_preview (a separate field that names itself a preview, with text_length beside it — never quote from it); 'standard' = + the claim itself, whole, without evidence (relations: + citation_context); 'full' (default) = everything. Measured 2026-09-17 on a 20-edge claim: full 87 270 chars, standard 63 326, minimal 45 431 before relations were levelled — relations were 91 % of minimal, now they are not."

Added value: +{
+  "description": "claims_list: chain-heads only (default TRUE); false lists superseded claims too, stamped",
+  "type": "boolean"
+}

Added value: +{
+  "description": "window over claims_list, default 20",
+  "exclusiveMinimum": 0,
+  "maximum": 100,
+  "type": "integer"
+}

Added value: +{
+  "description": "also list the claims derived from this document (default off)",
+  "type": "boolean"
+}

Previous value: -"optional filter by KIND of statement instead of by exact value: sourced (what a source asserts) | derived (your own inference) | action (your own decision or commitment) | open (a question or a gap). Expands to that set's values, so you never enumerate them by hand. Ignored if claim_status is also given — the exact value is more specific."New value: +"optional filter by KIND of statement instead of by exact value: sourced (what a source asserts) | derived (your own inference) | action (your own decision or commitment) | open (a question or a gap) | proposed (a hypothesis or forecast put up to be tested). Expands to that set's values, so you never enumerate them by hand. Ignored if claim_status is also given — the exact value is more specific."

Previous value: -[
-  "sourced",
-  "derived",
-  "action",
-  "open"
-]New value: +[
+  "sourced",
+  "derived",
+  "action",
+  "open",
+  "proposed"
+]

Added value: +{
+  "description": "Soft filter chunks by entity (case-insensitive ANY match). Implies includeChunks=true. Chunks mentioning a listed entity return first; chunks with NO entities recorded are kept (about a quarter of the corpus predates entity extraction, and dropping them would hide real matches); only chunks that HAVE entities, none of them matching, are dropped.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

Added value: +{
+  "description": "How the words are combined. DEFAULT 'all_words' — EVERY word must appear in the chunk, which is why long queries often return nothing. ⚠️ MEASURED 2026-09-11 over archived all_words traffic: 6-10 word queries CAME BACK empty 78% of the time on this door — a figure about that traffic under that mode, which this parameter exists to change. Adding more words makes the default stricter, not broader. ⚠️ Matching happens INSIDE ONE CHUNK, so that figure depends on the CURRENT chunking policy as much as on the mode — re-measure if you need a current one rather than relying on this. stricter, not broader. Use 'any_words' to find chunks matching ANY of them, and 'phrase' for the words adjacent and in order. ⚠️ Writing `or` in the query text does NOT ask for any_words — it is dropped as a stop word; name the mode instead.",
+  "enum": [
+    "all_words",
+    "any_words",
+    "phrase"
+  ],
+  "type": "string"
+}

Previous value: -"optional filter on the claim_status payload field"New value: +"optional filter on the exact claim_status value"

Added value: +{
+  "description": "optional filter by KIND of statement instead of by exact value: sourced (what a source asserts) | derived (your own inference) | action (your own decision or commitment) | open (a question or a gap). Expands to that set's values, so you never enumerate them by hand. Ignored if claim_status is also given — the exact value is more specific.",
+  "enum": [
+    "sourced",
+    "derived",
+    "action",
+    "open"
+  ],
+  "type": "string"
+}

Previous value: -"Max CONNECTED records to return — the claims, which are 99.96% of this response by measurement; `relations` keeps its own cap. Omit for all of them. The answer always carries total / returned / complete, so a windowed read is never mistaken for an exhausted one."New value: +"Max CONNECTED records to return — the claims, which are 99.96% of this response by measurement; `relations` keeps its own cap. ★ DEFAULT 20, chosen by measurement: 98.9% of documents carry 20 claims or fewer and so arrive complete in one call. It is a default, NOT a ceiling — ask for more and you get more. Every answer carries total / returned / complete (and nextOffset when there is more), so a defaulted read is never mistaken for an exhausted one."

Added value: +{
+  "description": "How much of each connected record to return. Levels DROP WHOLE FIELDS and never cut a string: 'minimal' = identity + supersede state, no claim text; 'standard' = + the claim itself, whole, without evidence; 'full' (default) = everything. Measured ~145 / ~658 / ~1281 characters per record.",
+  "enum": [
+    "minimal",
+    "standard",
+    "full"
+  ],
+  "type": "string"
+}

Added value: +{
+  "description": "Max CONNECTED records to return — the claims, which are 99.96% of this response by measurement; `relations` keeps its own cap. Omit for all of them. The answer always carries total / returned / complete, so a windowed read is never mistaken for an exhausted one.",
+  "exclusiveMinimum": 0,
+  "type": "integer"
+}

Added value: +{
+  "description": "Skip the first N connected records. Use nextOffset from the previous answer.",
+  "minimum": 0,
+  "type": "integer"
+}

Previous value: -[
-  "claim",
-  "relation",
-  "activity",
-  "metric",
-  "bundle"
-]New value: +[
+  "claim",
+  "relation",
+  "activity",
+  "metric",
+  "bundle",
+  "document"
+]

Previous value: -"drop members of the ANCHOR's own same_as cluster — they are the same claim (default TRUE)"New value: +"drop members of the ANCHOR's own same_as cluster — they are the same claim (default TRUE). The response reports how many were dropped in excluded.same_as_members."

Previous value: -"exclude superseded claims (default TRUE)"New value: +"exclude superseded claims (DEFAULT OFF since A0-3b, aligned with methodist_find / _search / _search_semantic). Every returned claim carries is_superseded, so filtering here is optional: you can always drop stamped records, but you cannot recover records a door hid from you."

Previous value: -"'fast' (~3s): retrieval uses symmetric HyDE pools — top-20 chunks against the supporting-hypothetical plus top-20 against the contradicting-hypothetical, then each chunk is assigned to the bucket whose HyDE-vector it scored higher against. Because the retrieval pool is symmetric and the classification mirrors the retrieval direction, supporting/contradicting counts come out approximately balanced regardless of the actual distribution of evidence in the corpus (a topic that is 90% supported in the literature will still show a ~1:1 split here). Use fast mode for 'is there evidence on either side?', not for 'how is the field actually split?'. May also misclassify chunks that mention the topic but logically point the other way (e.g. a paper explaining 'BN is bad in transformers' may land in the contradicting bucket for an 'LN > BN' claim). 'deep' (~10s): adds an independent per-chunk LLM NLI classification on top of the union pool, so counts reflect actual semantic distribution and can be arbitrarily asymmetric. Use 'deep' whenever classification accuracy or distribution shape matters — including controversy mapping and any analysis that interprets the supporting/contradicting ratio as a signal about the field."New value: +"'fast' (~3s): retrieval uses symmetric HyDE pools — top-20 chunks against the supporting-hypothetical plus top-20 against the contradicting-hypothetical, then each chunk is assigned to the bucket whose HyDE-vector it scored higher against. Because the retrieval pool is symmetric and the classification mirrors the retrieval direction, supporting/contradicting counts come out approximately balanced regardless of the actual distribution of evidence in the corpus (a topic that is 90% supported in the literature will still show a ~1:1 split here). Use fast mode for 'is there evidence on either side?', not for 'how is the field actually split?'. May also misclassify chunks that mention the topic but logically point the other way (e.g. a paper explaining 'BN is bad in transformers' may land in the contradicting bucket for an 'LN > BN' claim). 'deep': adds an independent per-chunk LLM NLI classification on top of the union pool, so counts reflect actual semantic distribution and can be arbitrarily asymmetric. ★ COST IS LINEAR IN POOL SIZE — one LLM call PER CHUNK, up to ~60 per invocation. Measured over 35 real calls: median 52 s end-to-end (the '~10s' this description used to claim was never the general case). That is money as well as time. Use 'deep' whenever classification accuracy or distribution shape matters — including controversy mapping and any analysis that interprets the supporting/contradicting ratio as a signal about the field."