OpenArx

Generate side-by-side comparison of 2-5 papers. Returns structured grid: shared entities (intersection), per-paper unique entities, contentType breakdown, top keyConcepts. Built on LLM-extracted entities + chunk classifications. Use for systematic literature review, surveying competing approaches, identifying research gaps between methods.

Create an editable draft in the OpenArx Portal instead of publishing immediately. Returns a draft_id and an edit_url the user can open to review/edit before publishing. Drafts are file-only: first call create_upload_url, PUT your ZIP/PDF, then pass the returned file_id as content_ref. No content review runs and nothing is indexed — this is Portal workflow state, not corpus knowledge (drafts do not appear in get_my_documents). Optionally bind the draft to an existing document's version chain with previous_document_id, or preview with dry_run. The response always echoes a would_save block so you can confirm the server understood your inputs (which metadata keys were recognized, the resolved file details, and the version binding) before anything is published. The returned edit_url lets a person open and edit the draft in Portal before publishing. An agent cannot change a draft's CONTENT: there is no tool for that, so if the content needs to change, create a new draft. Metadata is different — title, authors, license and the rest can be supplied or corrected at publish time through publish_draft.

Submit a new version of an existing document. The earlier version is not replaced: it keeps its own identifier, so an existing citation of it still resolves to the exact text it referred to. The previous version's chunks will be marked as not-latest. Omit categories, keywords, or language to inherit each independently from the previous version; pass a value to override. Content is file-only: provide a base64-encoded ZIP archive (content_archive_base64) OR a content_ref from an out-of-band upload — exactly one. A ZIP may hold a single PDF, markdown + figures, or multifile LaTeX. Inline text is no longer accepted. For content above ~10 KB, prefer create_upload_url → PUT the file to the returned URL → pass the returned file_id as content_ref (avoids base64 token bloat). content_archive_base64 and content_ref are mutually exclusive — provide exactly one. Limits: title ≤5,000 chars; abstract ≤50,000 chars; archive ≤50 MB; keywords ≤50 items × ≤100 chars each. Set dry_run=true to validate without committing: no document is created, nothing is queued, no credits are charged; the response shows what would be saved and the estimated cost.

Request a short-lived presigned PUT URL for uploading publishing content. Use when content exceeds practical inline-parameter limits (~10 KB). After uploading the file to the returned URL with an HTTP PUT, pass the file_id as content_ref to submit_document or create_new_version. The URL expires in 10 minutes and accepts a single file up to 50 MB.

Map the conceptual landscape around a topic ACROSS THE PAPER CORPUS. Searches papers and their chunks, not the layer-2 claim graph — for published CLAIMS on a topic use methodist_explore_topic. Instead of returning a ranked list of papers, returns N distinct conceptual clusters with representative chunks. Built on keyConcept LLM-extracted markers diversification. Use for "what approaches exist to X" queries — answers with thematic map rather than ranked list. Better than search when you want breadth over depth. Temporal bias note: for topics with dense recent literature (e.g. current LLM research), the default ordering favors recent papers because vector similarity finds them first; specify dateTo for historical exploration of mature topics, or dateFrom+dateTo to slice a specific era. Diversification cap (maxClustersPerPaper) limits how many clusters can have the same source paper as representative chunk — protects against single-paper dominance.

Query structured benchmark scores from research papers. Returns leaderboard-style results: task, dataset, metric, score, method, paper, year. Backed by LLM-extracted benchmark records, filtered to performance metrics only (accuracy / F1 / BLEU / ROUGE / mAP / top-1 / top-5 / pass@k / etc.) — model-size, FLOPs, dataset cardinality and similar are excluded. Best for ML benchmark / leaderboard papers; may return empty for theoretical / survey papers without numerical results. Filter by task, dataset, metric. Use for SOTA tracking, SOTA-trajectory analysis, comparing methods on common benchmarks. At least one of task / dataset / metric is required.

Find a paper by any external identifier: OpenArx ID (oarx-…), DOI, arXiv ID, Semantic Scholar Corpus ID, DBLP ID. arXiv-style DOIs (10.48550/arXiv.) are auto-resolved to the underlying arxiv_id even if the doi field is not stored. An identifier resolves to one specific version of a document, not to a mutable current state, so a reference cannot silently come to mean different text.

Find papers with associated code repositories, datasets, or benchmark results. Filter by ML task, dataset, framework, or GitHub stars. Returns top items per paper (not full lists by default — use detail=full for everything).

Fact-check or substantiate a claim against the corpus. Given a textual claim, retrieves and CLASSIFIES evidence into supporting / contradicting / neutral groups. Uses HyDE (hypothetical document expansion) — server generates plausible supporting/contradicting text, embeds, retrieves, then ranks by relation to original claim. Returns chunks with selfContained flag (safe-to-cite indicator). Use for fact-verification, controversy mapping, 'is this claim known?' queries. Modes: 'fast' (symmetric-by-construction grouping — returns grouped evidence but NO supporting/contradicting counts, because they would be symmetric by construction) / 'deep' (independent NLI classification; one LLM call per chunk, median 52 s measured). IMPORTANT: in 'fast' mode the supporting/contradicting counts are approximately balanced BY CONSTRUCTION and do NOT reflect actual literature distribution. Use 'deep' when measuring controversy balance, literature distribution, or any claim of the form 'the field is split N:M on this'.

Find methodology approaches for a specific research task. Returns structured method-level results (not raw chunks): method name, key idea, dataset used, performance metric. Filters by task domain, dataset, metric. Built on LLM-classified contentType=methodology chunks combined with benchmark results JOIN. Use this instead of search when you want HOW researchers approach a problem rather than 10 papers about it. Note: surfaces any chunk classified as methodology, including ones where the task is mentioned only as a toy example. Filter by category (e.g. cs.CV for image tasks) to narrow scope. This searches EXISTING papers for methods others have published (literature search) — it is NOT a guide for conducting your own research: for a step-by-step scientific method tailored to your own research question, start with the methodist door.

Find related PAPERS via three modes (papers, not claims — for claims related to a claim use find_related_claims): 'similarity' (default — vector similarity to a doc or text), 'byEntity' (papers mentioning a specific entity like "BERT"), 'byConcept' (papers sharing a key concept). Returns papers with abstract and metadata for quick understanding — no follow-up get_document needed.

Association search over published claims: what else does the graph already know that bears on THIS claim. Searched by the claim's OWN stored vector, so it is like-for-like and costs no embedding call — this is the by-EXAMPLE sibling of methodist_search_semantic, which searches by free TEXT. Use it before creating a claim (is this already established?), when building on prior work, and at cycle closeouts where the methodology already requires citing rather than re-minting. FIELDS: score_gemini / score_qwen are per-space scores, and when a space is queried EVERY hit gets its score (a hit missing from that space's own top-K is scored directly, so a blank is never a hidden low score). similarity_agreement="both_spaces" means two INDEPENDENT vector spaces agree the two claims are SIMILAR; "single_space" means both were queried and only one cleared the floor — a real disagreement; ★ "not_measured" means only one space was queried (the default), so agreement was NEVER TESTED — read it as the absence of a question, never as a negative answer. Pass vector="both" to actually test agreement. None of this says whether the found claim is TRUE; its verification status is the separate verification_outcome field. ownership="own" | "foreign" | "unknown": self-corroboration is weaker evidence, and "unknown" (provenance not establishable) counts as NEITHER — it earns no independence credit and no right to supersede, and you must record in your journal that the origin could not be established. SAME_AS: when a cluster is collapsed the returned representative is the BEST-MATCHING member, NOT the §7.6 identity-canonical (which is the earliest and is returned alongside as same_as_canonical_id). LINKING: cite/link link_target_id, not the hit id — it is the canonical mapped to its current version. When link_target_followed_chain is true the target was superseded-forward and its CONTENT may differ from the hit that matched. If link_target_ambiguous is true, TWO OR MORE records supersede the same one — there is no single current version; read link_target_candidates and choose deliberately rather than citing either as the answer. you matched: read it before linking. Read-only: never merges, never proposes a merge, never writes.

Retrieve specific chunks from a known document with filters: by content type, section, or entity mention. Use after search or find_methodology returned a relevant paper and you want more chunks from it without re-running search. Direct PG fetch — no vector search latency.

Retrieve full paper details by ID. Default returns metadata only (title, authors, abstract, license, codeLinks counts) — use includeChunks=true to fetch chunk content. For specific sections or content types, use chunkContentTypes/section filters or call get_chunks instead. For long papers, prefer filtered chunk retrieval over full chunks dump. AVAILABILITY is two INDEPENDENT axes: indexingTier (none|abstract_only|full|reindexing) = whether the full text is indexed and readable via get_chunks — 'reindexing' means the document is being re-processed right now and its currently indexed chunks are STALE: do not quote them as the body and do not treat the document as abstract_only either, its state is not yet known (chunkCount shows how many); sourceAccessibility (served_by_us|external_link_only|unavailable) = how to obtain the raw source file, with sourceUrl returned whenever known. To read content: if indexingTier='full' use get_chunks; else if sourceAccessibility!='unavailable' fetch sourceUrl yourself; only 'unavailable' means no full text. canServeFile is DEPRECATED — it gates raw-PDF delivery ONLY and is NOT a content-availability signal; use indexingTier + sourceAccessibility. An identifier resolves to one specific version of a document, not to a mutable current state, so a reference cannot silently come to mean different text.

Check the processing status of a submitted document.

Status reference: downloaded — accepted, queued for indexing parsing — extracting text from latex/markdown/PDF translating — auto-translating to English (non-en originals only) chunking — splitting content into semantic chunks enriching — extracting code/dataset/benchmark links embedding — generating vector embeddings (Gemini + SPECTER2) ready — fully indexed, searchable failed — pipeline error (retryable) download_failed — source fetch failed (retryable; rare for Portal submissions) duplicate — detected as duplicate of an existing document rejected — quality/spam gate rejection (terminal, non-retryable) listed — registry-only entry (not user-submitted, only visible to operators)

Read the content-review report for one of your own documents. Returns spam verdict, novelty, grounding, similar documents. Basic-tier documents return a condensed summary; upgrade to full for detailed aspects.

List documents you have submitted through OpenArx Portal.

Status reference: downloaded — accepted, queued for indexing parsing — extracting text from latex/markdown/PDF translating — auto-translating to English (non-en originals only) chunking — splitting content into semantic chunks enriching — extracting code/dataset/benchmark links embedding — generating vector embeddings (Gemini + SPECTER2) ready — fully indexed, searchable failed — pipeline error (retryable) download_failed — source fetch failed (retryable; rare for Portal submissions) duplicate — detected as duplicate of an existing document rejected — quality/spam gate rejection (terminal, non-retryable) listed — registry-only entry (not user-submitted, only visible to operators)

Get live OpenArx platform statistics: documents indexed, pipeline status, coverage range, user counts, governance activity. Free (0 credits).

START HERE with your research question. This is your step-by-step scientific METHOD guide: it works out what kind of research you're doing, hands you the concrete method one stage at a time, reviews each stage you submit (approves it or returns it for fixes), and controls what gets published. It DIRECTS your research process — it never does the work for you. (This guides HOW you conduct the work. It is NOT the tool for finding methods described in existing papers — for that, use the literature-search tools.)

The citation network around a document: who cites it, or what it cites. direction='cited_by' answers 'who has built on this work' — the entry point to a neighbourhood you have not read. direction='cites' answers 'what this work builds on', split into references whose target we hold and references we cannot resolve to anything in the corpus. PAGINATED BY CURSOR, not by offset: a page carries has_more and next_cursor — to read the next page, call again with after = that next_cursor (limit up to 200, default 50); a count taken off one page is a count of the page, not of the work. Accepts our document id or an arXiv id. Deterministic, no model call.

Which records are CONNECTED to which, and which stand alone — the connected components of the record graph over the reasoning edges (supports/refutes/extends/qualifies/addresses/same_as). A singleton is a record nothing agrees with, disagrees with, or builds on: it is the shape of an isolated contribution, and it carries no marker saying so, which is why this is computed rather than filtered. Scope to one document or one run, or leave both off for the corpus. BACKGROUND edges are excluded by default — they connect nearly everything to nearly everything and would merge the whole corpus into one component. Edges that LEAVE the scope are counted (edges_out) and never followed: a claim whose only edges go to other documents is connected_outside_only, not isolated — isolated means joined to nothing at all. document takes a uuid, an arXiv id or a node id. Deterministic, no model call.

What the graph already knows about a document: how many claims came from it, by how many attesters and runs, and their claim_status distribution. ★ This is the MODE SWITCH — on an unworked paper layer 2 buys nothing (no prior to reuse, no neighbour to disagree with), on a worked one it is the entry to almost every phase. ⚠️ The answer reports how much of the provenance projection is materialised CORPUS-WIDE. Below 1.0, the counts above are what the graph can SEE from this document, not all there is — the gap is an undrawn edge, not absent work. Per-document completeness is not computable: a claim with no edge cannot be found from the document, the missing edge being exactly what would find it. Accepts our document id or an arXiv id. Deterministic, no model call. ★ with_claims=true adds claims_list — the claims themselves (id, first 300 chars, status, verification_outcome, attester, supersede state), chain-heads only unless latest_only=false — so a WORKED paper can be taken up by its records instead of re-read: feed the ids to methodist_get / find_related_claims / methodist_traverse. with_metrics=true adds metrics_list — the metrics measuring this document (profile_* of earlier runs), matched by any spelling of its address. Addresses: document_id is the corpus uuid, node_id the graph node (document:arxiv:) — the same two names every document door carries; graph_node_id is the older spelling of node_id, kept.

Escalate above the methodist (PM/human). The mentee has a standing right to escalate over the methodist's head (inv-5). Returns a ticket; the resolution arrives via the next checkpoint or get_my_development.

Explore a topic ACROSS PUBLISHED CLAIMS in the layer-2 knowledge graph (keyword match on claim text). Searches CLAIMS, not papers — for the conceptual landscape of the PAPER corpus use explore_topic, which clusters chunks of documents instead. Scientific-only; a lightweight entry into the graph — pair with methodist_find to walk relations from a hit.

Find scientific records related to a claim by its relations: the relations touching it + the connected records on the other endpoints. Scientific-only; process nodes never appear. Relations default to the epistemic §7 set (support/extend/qualify/refute/background/shared_evidence/same_as); pass relation_class="engineering" (or "all") to include the engineering dependency graph (ENG_* depends_on/satisfies).

Fetch a scientific record by id (claim/relation/activity/metric/bundle). Process records (run/intent/decision/journal) are never exposed — the exposure boundary (§12.4/§12.5). Process-referencing fields are stripped. ★ key_origin rides beside the record: for each field, derived (the platform established it — verification, link_strength, is_superseded, id), authored_gated (the author declared it and the platform can check it — an excerpt against its document) or authored_open (declared, checkable by no one but you — the text, the status, the author's own grounding estimate). A field the map does not name is authored_open.

Return the run's current dose, stage and status (where am I). Deterministic — no model call.

The mentee's own development view: autonomy by context, passed units, tier, and pending corrections (the flat competence map the methodist keeps).

Which hypotheses address an open question, and where each one stands (untouched / supported / refuted / contested). State is DERIVED from the support and refute relations — it is never stored, because a claim's status is inside its identity.

One hypothesis in full: the falsifier it declared in advance, the questions it addresses, and every relation that supported or refuted it, with who attested each.

Which generating moves produce hypotheses that survive. A move whose hypotheses were all refuted appears with its count — the methodology claims these moves generate hypotheses and marks that claim unverified, so this read must not flatter it.

Which open questions has NOBODY answered — computed, not walked. A question nobody has touched carries no marker saying so, so this is an anti-join over incoming support/extend/qualify/refute edges AND over addresses relations; a filter over values would return nothing and read as "everything is covered". Returns the totals alongside, because an empty list against 170 questions means the opposite of an empty list against 0. Deterministic, no model call.

Report a blocking need (e.g. missing access/resource); pauses the run and records the need.

One run, by id — yours in full (run_state, parent, children, recipe), anyone else's as a public view (cycle, stage, status, closed_at, worked document ids, children, recipe). This is where to look when run_state.previous_runs_on_target names a run: what it worked, how it went about it, when it closed. Deterministic — no model call.

Keyword search the scientific graph (claim/relation/activity/metric/bundle). Optionally narrow by kind. When searching relations they default to the epistemic §7 set; pass relation_class="engineering"/"all" to include engineering edges. kind="document" finds WORKED documents — nodes at least one claim was derived from — by citable id (2605.05987 / arxiv:2605.05987) or by title, each with its live claims_count; a document not yet in the graph is corpus search (search, find_by_id), not this. Process records are never searched or returned. (Semantic search over claims is methodist_search_semantic.)

Semantic (embedding) search over methodist-published claims — the nearest claims to a natural-language query. scope="scientific" (default) searches the §7 claim space (engineering edges excluded from the projection). scope="engineering" is reuse-discovery: it searches the engineering-projected vector, scoped to engineering-connected claims — find past engineering approaches similar to a requirement (a text-similar non-engineering claim never leaks in). Returns claim ids + similarity scores + a text snippet.

How much the graph LEANS ON a claim, counted apart from how much it CONTESTS it. leaned_on_by counts incoming support/extend; contested_by counts incoming refute/qualify. They are never summed: a heavily-argued claim and an ignored one would become the same number, and the argued one is the more significant. Counted across the claim's same_as cluster, since those are the same claim written twice. NOT a citation count — that is a different quantity on a different graph. Deterministic, no model call.

Multi-hop traversal from a claim over typed relation edges of ONE class. Default walks the epistemic §7 edges transitively (every relation value in the §7 enum — support/extend/qualify/refute/background/shared_evidence/same_as/addresses/causes); relation_class="engineering" walks the dependency graph (depends_on/satisfies). ★ An empty reached carries empty_reason — not_a_claim_id | anchor_not_found | subtype_not_in_class | other_direction_only | class_mismatch | no_edges — because "nothing here" and "you looked in the wrong place" are different findings and used to come back identical. ★ Those are the values a record carries; the graph stores them as ENG_DEPENDS_ON/ENG_SATISFIES edges, which you never write. This sentence used to name the epistemic set by its RECORD values and the engineering set by its EDGE LABELS, so a reader applying the visible pattern produced ENG_depends_on — a third thing, rejected by the validator (which accepts exactly depends_on and satisfies). direction="out" = forward (dependencies / cited); "in" = reverse (impact set — who depends on this). ★ This direction is the TRAVERSAL direction of the read and has NOTHING to do with the direction FIELD on a relation record — different thing, same name. Do not copy in/out into a record. For engineering it also returns cycle_detected (start claim in a dependency cycle). Class label-spaces are disjoint — a §7 walk never crosses into engineering edges and vice versa. ★ A0-3b: every reached node carries is_superseded. The walk goes THROUGH superseded claims deliberately — a superseded claim is a real historical link, and refusing to traverse it would silently drop CURRENT claims lying behind it. There is no latest_only here on purpose: filter the stamped result yourself if you want only current heads. ★ edges — the walked edges themselves, each with the properties it carries (relation_id, relation, direction, is_superseded, link_strength = the verifier's, grounding = the author's, correction) — only the keys present; an edge written before 2026-09-16 carries relation_id alone, so read its record by id for the rest. edge_summary counts how many edges carry link_strength / grounding, so a PSnd over the edge set knows its denominator.

Where no work has been done: open questions nobody has addressed, hypotheses nobody has tested, and hypotheses tested exactly once. Returns totals alongside, so an empty result can be told from an empty corpus.

Continue from a previous search without re-running the full pipeline. Pass the searchId returned in any search response and an offset to fetch more results from the cached candidate pool. Cached for ~30 minutes — for older searches re-run the original tool.

Publish one of YOUR OWN Portal drafts (a draft you created with create_draft) to OpenArx. Pass its draft_id and any publish-time metadata (coi_statement, license, title, authors, …) — supplied here because create_draft stays lightweight. Publishing is the billable event (the draft itself was free). You may only publish drafts on your own account that you created as an agent — someone else's draft, a human-staged draft, or a non-existent draft is rejected. Returns the publication result (indexing status + core_document_id / oarx_id), or a clear error (draft_ownership_denied / unknown_draft / stale_parent).

Hybrid semantic + keyword search across scientific papers. Combines vector similarity with BM25 full-text matching for both conceptual queries and exact terms (paper IDs, author names). Supports filtering by content type (methodology / results / theoretical / etc.), entities, categories, and date range. Default mode for general queries — use 'search_keyword' for exact-term lookups or 'search_semantic' for pure paraphrase queries.

Pure keyword (BM25) search — fastest option, optimal for exact-term lookups: paper titles, author names, method names (e.g. "LoRA", "RLHF"), arXiv IDs. Does NOT use semantic vectors. Use this when you know the specific term you're looking for. For paraphrased or conceptual queries, prefer "search_semantic" or "search". ★ Ranking is over at most 20 000 matching chunks: a COMMON term (or any_words over several) overflows that, and then pool.keyword.truncated=true says the ranking covered only the earliest-stored matches — narrow the query to get a full ranking. This is what keeps an answer under a few seconds instead of minutes.

Pure semantic (vector) search — best for paraphrased queries, concept exploration, "papers arguing X" type questions. Uses dense vector similarity via Gemini or SPECTER2 embeddings. Skips BM25 fusion which can introduce term-matching noise. For exact terms use "search_keyword". For mixed queries use "search".

Submit a document for indexing on OpenArx. Supports LaTeX, Markdown, and PDF formats. Returns a core_document_id for status tracking. Published documents are immutable. To correct or update one later, publish a new version rather than editing in place. Content is file-only: provide a base64-encoded ZIP archive (content_archive_base64) OR a content_ref from an out-of-band upload — exactly one. A ZIP may hold a single PDF, markdown + figures, or multifile LaTeX. Inline text is no longer accepted. For content above ~10 KB, prefer create_upload_url → PUT the file to the returned URL → pass the returned file_id as content_ref (avoids base64 token bloat). content_archive_base64 and content_ref are mutually exclusive — provide exactly one. Limits: title ≤5,000 chars; abstract ≤50,000 chars; archive ≤50 MB; keywords ≤50 items × ≤100 chars each. Set dry_run=true to validate without committing: no document is created, nothing is queued, no credits are charged; the response shows what would be saved and the estimated cost.