fast-submission

FAST Submission

Run this audit before uploading to the FAST HotCRP site. FAST — the USENIX Conference on File and

Storage Technologies — publishes open access via USENIX, reviews double-blind, and runs

two deadlines a year. The first decision you make is not about the PDF but about *which

deadline* you are aiming at. Every number below was read from the FAST '26/'27 calls on 2026-07-09

via search renderings of the usenix.org URLs (see resources/official-source-map.md); treat them

as a one-cycle snapshot and reopen the live call first.

Pick the deadline first

FAST '27 runs a Spring deadline (17 Mar 2026) and a Fall deadline (15 Sep 2026), each with

its own HotCRP instance, author-response window, and notification date. Consequences:

• Choose by readiness, not habit: a study that will be steady-state-solid in August targets Fall;

do not rush it into a Spring slot it will fail.

• Register at the right HotCRP site — the Spring and Fall instances are different URLs; an

abstract registered on the wrong one does not carry over.

• As of 2026-07-09 the live actionable target is the FAST '27 Fall deadline, 15 Sep 2026.

Register the abstract early

FAST expects title, authors, abstract, and topics registered in HotCRP; some cycles require this a

few days before the full-paper cutoff. Register with the real title and abstract — they drive

reviewer bidding and PC match — not a placeholder you intend to swap.

Format and page limit

• USENIX two-column template (LaTeX or Word), unmodified: 10-point on 12-point leading, a 7" x

9" text block, 0.33" inter-column gap, US-letter. This is the USENIX path — not ACM acmart, not

IEEE 10+2. Do not carry a two-column ACM/IEEE habit over.

• Page limit (verify per cycle): FAST '27 posts ≤12 pages for a long paper and **≤6 pages

for a short paper, excluding references** — the bibliography is uncapped and does not count.

Camera-ready allowances are larger (reported 13 / 7 excluding references), so do not pad the

submission toward the camera-ready size.

• Everything a reviewer must read to judge the paper lives in those pages; the artifact supports,

it does not hold the argument.

Double-blind sweep

FAST review is double-blind: anonymize the PDF and references and refer to your own prior work

in the third person. Storage papers leak identity through devices, tools, and traces, so the

surface is wide:

# Mechanical pass on the submission PDF and any anonymized artifact archive
pdfinfo paper.pdf | grep -Ei 'author|creator|producer'
pdftotext paper.pdf - | grep -nEi 'github\.com/[a-z0-9-]+|zenodo\.org/record|our (system|lab|group)|acknowledg|grant' | head
unzip -l artifact.zip | grep -Ei '\.git/|\.DS_Store|/home/|/Users/|hostname' | head
grep -rni 'university\|@[a-z0-9.]*\.edu\|internal cluster\|<companyname>' artifact/ --include='*.md' | head

The storage-specific leaks: a system named after your lab or product, a cluster/hostname in a

config or SMART dump, a trace hosted on a personal or institutional URL, a datacenter name in a

field study, and commit metadata inside a zipped repository. Re-host artifacts and traces behind an

anonymizing location before upload.

Availability story at submission time

USENIX values sharing. Concretely for the submission:

• State where the code, traces, and scripts will live and, where possible, provide an anonymized

artifact or trace-replay bundle at review time.

• If something cannot be shared (proprietary drives under NDA, production traces with privacy

limits), say so and why — a silent gap reads worse than a stated, justified exception.

• Pin device models, firmware, and trace identifiers now; they cannot be reconstructed later.

Desk-risk triage

| Finding at audit time | Severity | Real fix |

|---|---|---|

| Body over the 12/6-page limit | Desk-reject-grade | Cut or move to the artifact; references don't absorb body text |

| Wrong template (ACM/IEEE, altered margins/font) | Named format-reject ground | Recompile in the USENIX template; recover space editorially |

| Identity leak in PDF, artifact, tool, or trace URL | Anonymity violation | Re-anonymize and re-host; scrub PDF and SMART/config metadata |

| Registered on the wrong deadline's HotCRP | No valid submission there | Re-register on the correct Spring/Fall instance before its cutoff |

| No device/firmware detail in the evaluation | Storage-soundness weakness | Add the testbed table before submission, not in rebuttal |

| Same work under review elsewhere | Concurrent-submission violation | Withdraw one venue; a one-shot revision also blocks parallel submission |

Final-week order of operations

1. Confirm the target deadline (Spring/Fall) and its HotCRP URL and cutoff.
2. Freeze the body early; references can churn, the storage argument cannot.
3. Finalize the testbed table (devices, firmware, kernel, workloads/traces, device state).
4. Build the anonymized artifact/trace bundle and place its availability statement in the paper.
5. Run the mechanical double-blind checks on the final PDF and archive, not drafts.
6. Fill every HotCRP field — topics matching your evidence, conflicts for every coauthor's

institution and recent collaborators — a day early.

1. Re-download the uploaded PDF and read it cold to confirm it is the file you meant.

Reverify each cycle

• Both deadline dates and which HotCRP instance is live now.
• The page limit and which USENIX template revision is required.
• Artifact timing, one-shot-revision and shepherding wording, concurrent-submission rules, and any

AI-disclosure policy — all cycle-volatile.

Output format

[FAST submission status] ready / blocked / needs work
[Target deadline] Spring / Fall <date + correct HotCRP URL>
[Registration] title/abstract/authors/topics/conflicts locked? yes/no
[Format] pages used (body/refs), USENIX template compliance
[Anonymity] clean / leaks: <where>
[Availability] artifact/trace bundle present? device+firmware provenance stated?
[Fix queue] <ordered, with owners and dates before the AoE cutoff>