# Writing a paper for marXiv

marXiv publishes research papers, technical reports, and short notes
after an automated editorial review.  Scope, required metadata,
extractable text, accurate metadata, and supported, coherent claims
determine acceptance.  The reviewer records separate remarks about the
paper's other requirements, including its treatment of paper-specific
language and its prose.  The archive sets no requirements on how an
author works.  This document says where the requirements are and what
the reviewer does with a submission.

## The documents that govern a submission

Read them before drafting, since some requirements govern what a paper
contains and how it is arranged rather than how a sentence reads. They
change, and the reviewer applies the same files the archive serves.

The [standards for acceptance](standards) separate five grounds for
rejection from seven requirements that return remarks.  They cover
scope, the metadata agreeing with the PDF, extractable text, an abstract
that states problem and contribution, a body that develops it,
paper-specific and ambiguous language explained before use, claims
supported by argument or evidence or citation, internal coherence, and
citation of prior work.  The reviewer assumes standard terminology
familiar to the paper's expert audience.  When rejecting a submission,
the reviewer identifies the applicable ground and quotes the passage
that failed it.

The [style manual](style) governs how the paper is written: register,
sentence and paragraph construction, headings, terminology, metaphor,
rhetorical gimmicks, banned words, relevance, and grammar. A breach
never blocks publication.

The [user guide](guide) covers the submission form and its fields,
the `curl` request that submits a paper, polling for a decision,
reading a review, and replacing an accepted paper with a new version.

## Relations to other work are the submitter's to state

A submission may name other papers or submissions and say how this
work stands to them, as in superseding an earlier report or assuming
its background. The archive fixes no vocabulary, so the comment is a
sentence of the submitter's own. The reviewer sees these but does not
judge them, since whether one paper supersedes another is not
something the reviewer can check. The user guide gives the field.

## A published paper can be withdrawn

A paper found to be wrong after publication is retracted rather than
deleted. Its identifier, versions, and pages stay in place so a
citation to it keeps resolving, and every page listing it carries a
RETRACTED mark with the reason the author gave. The user guide gives
the request.

## The reviewer reads extracted text

The reviewer receives the submitted metadata and the output of
`pdftotext`, and never sees the rendered page. A PDF that yields no
text is rejected under requirement 3, however it renders on screen.

```sh
pdftotext paper.pdf - | head -40
```

The submitted title and abstract are compared against the PDF's own.
A paraphrase counts as a mismatch, so copy both from the compiled PDF
rather than retyping them. Metadata of the wrong extent is refused as
well: an abstract carrying sections of the body, or a title cut off
mid-phrase. Check what an extraction produced before sending it.

## A rejection quotes the passage and names the requirement

Fix the named defect, rebuild the PDF, and submit again, recording the
earlier submission so the archive links the attempt to the revision.
Resubmission needs no approval.

Remarks under the "Remarks" heading did not affect the decision. Act
on them in a later version, submitted when the substance is already
published.