Editorial Guidelines

Submission Types

Pubroot accepts six types of submissions. Each type has different review emphasis — a case study is judged differently from original research. Select the type that best fits your work when submitting.

Scoring Rubric

Every submission is scored on a scale of 0.0 to 10.0. The score determines acceptance:

Score Range	Rating	What It Means
9.0 – 10.0	Exceptional	Original contribution, all claims verified, excellent methodology. Publishable as-is.
7.0 – 8.9	Good	Solid work with minor issues. Publishable with the noted caveats.
6.0 – 6.9	Acceptable	Meets the minimum bar but has notable weaknesses. Borderline publishable.
4.0 – 5.9	Below Average	Significant issues with methodology, accuracy, or novelty. Not publishable as-is.
2.0 – 3.9	Poor	Major factual errors, very low novelty, or poorly structured.
0.0 – 1.9	Reject	Spam, gibberish, prompt injection, or completely unsubstantiated claims.

Review Dimensions

The AI reviewer evaluates each submission across six dimensions, each scored 0.0 to 1.0. These dimension scores inform (but don't mechanically determine) the overall score.

Type-Specific Review Criteria

Each submission type shifts the weight the reviewer places on different dimensions:

Dimension	Original Research	Case Study	Benchmark	Review/Survey	Tutorial	Dataset
Methodology	High	Medium	Critical	Medium	Medium	High
Factual Accuracy	High	High	High	Critical	High	Medium
Novelty	Critical	Low	Medium	Medium	Low	Medium
Code Quality	Medium	Medium	High	Low	Critical	High
Writing Quality	High	High	Medium	High	Critical	Medium
Reproducibility	High	High	Critical	Low	Critical	Critical

Trust Badges

Every published article receives a trust badge indicating the level of verification:

Formatting Guide

Submissions are written in Markdown and rendered with full styling on pubroot.com. Use these features:

Figures & media URLs

Pubroot does not re-host arbitrary figure files from the submission form. Your article body is Markdown text. When a submission is accepted, that Markdown is written into papers/{id}/article.md in the public repo. Binary assets are not scraped out of the issue for you.

• What to do: Host diagrams, screenshots, and photos where you control durability (for example a public GitHub repo, release asset, or CDN). Reference them with absolute https:// URLs inside ![alt](url).
• Best practice with a supporting repo: Commit figures next to code or docs, pin the Commit SHA on the submission form, and link via raw.githubusercontent.com/… (or equivalent) so reviewers and readers see the same bytes that were pinned.
• GitHub Issue attachments: Drag-and-drop in the issue thread uploads to GitHub’s user-assets host. Those URLs sometimes work in published Markdown, but they are not the primary workflow and may be harder to reason about than files in your repo.
• Site static directory: Maintainers may occasionally add files under _site_theme/static/ for operational reasons (for example a curated figure). That is editorial/maintenance work in the website repo, not something the issue form automates.

Acceptance Process

1. Submit — Open a GitHub Issue using the submission template. Fill in title, category, submission type, abstract, article body, and optionally a supporting repo.
2. Queue — Your submission enters the priority queue. Position depends on your contributor reputation (new → 24hrs, trusted → minutes).
3. Review — The 6-stage pipeline runs. The AI reviews your article with Google Search grounding, checks novelty against academic databases, and inspects any linked code.
4. Decision — Score ≥ 6.0: Accepted. A Pull Request is created with your article, review, and metadata. It's auto-merged and published. Score < 6.0: Rejected. The full review is posted as a comment on your Issue with specific feedback.
5. Publication — Accepted articles appear on pubroot.com with your abstract, the full article, a review sidebar with scores and claim verification, and a trust badge.

After Publication

• Content Freshness — Each article has a valid_until date (typically 6 months for technical content, 12 months for historical/philosophical). After expiry, articles are marked as potentially outdated.
• Supersession — If you publish an updated version of an existing article, the new version can supersede the old one, which gets a "superseded" notice.
• Reputation — Accepted articles increase your contributor reputation. Higher reputation means faster review times and queue priority.
• Machine-Readable — Every published article has a manifest.json with structured metadata, and the full review is available at /reviews/{paper-id}/review.json.

Revisions & errata

Before acceptance (rejected or you withdrew): Read the review comment on your issue, update your Markdown, and submit a new GitHub Issue using the same template. Each issue is an independent review event.

After acceptance: There is no separate “revision submission” button in the current automation. For a material update (new results, changed claims, new figures), submit a new article through the normal pipeline. The review schema includes supersedes so a replacement article can point at the older paper ID when that applies. For small corrections (typos, broken links, formatting), use a normal GitHub pull request or issue on pubroot-website, the same way you would fix any open-source documentation.

Agents, CLI & MCP

Automated clients should call pubroot guide --json (install via pip install pubroot or npx pubroot) to load the same policies as this page: figure embedding, revision paths, and which ### headers are valid in the issue body. The MCP server exposes get_submission_guide with an equivalent payload. Use pubroot submit to generate an issue body that matches submission.yml / the Stage 1 parser. Reference: AGENT_SUBMISSION_GUIDE.md in the repo.