# ✅ Vellum Pre-Publication Quality Checklist

Use this before marking any documentation as ready for review or publication. Every item must be verified or explicitly marked N/A with justification.

## Accuracy (Non-Negotiable)

- [ ] Every factual claim is directly supported by source material or explicit confirmation from subject matter experts.
- [ ] All code examples were tested (or explicitly marked as illustrative / pseudocode).
- [ ] Parameter tables, request/response schemas, and default values match the current implementation exactly.
- [ ] Version numbers, model identifiers, and compatibility statements are correct for the intended release train.

## Completeness

- [ ] Scope and out-of-scope sections exist and are accurate.
- [ ] Prerequisites, assumptions, and required permissions are listed and realistic.
- [ ] All error paths, failure modes, and edge cases are documented with resolution steps.
- [ ] Security, privacy, data residency, and compliance considerations are addressed at appropriate depth.
- [ ] Limitations, known issues, and deprecation timelines are called out honestly with workarounds.

## Clarity & Usability (Diátaxis Alignment)

- [ ] The primary documentation mode (Tutorial / How-to / Reference / Explanation) is unambiguous and consistent throughout the page.
- [ ] Progressive disclosure is respected — beginners are not overwhelmed while experts can find depth quickly.
- [ ] Jargon is defined on first use or linked to a glossary. Acronyms are expanded on first appearance.
- [ ] The document answers the top 5–7 questions the target audience will realistically have.

## Style & Formatting

- [ ] Follows every rule in STYLE.md (voice, active voice, forbidden words, callout consistency, terminology).
- [ ] Heading hierarchy is logical and scannable (no skipped levels, no more than one H1).
- [ ] Tables are properly formatted, aligned, and contain useful information (not just decorative).
- [ ] Code blocks declare language, are copy-paste friendly, and include realistic examples for both success and error paths.
- [ ] Links are descriptive (never "click here" or bare URLs in body text).

## Structural & Maintainability

- [ ] Frontmatter / metadata block is complete and accurate (audience, owner, last reviewed date, applicability).
- [ ] Suggested repository location, ownership model, and review cadence are provided.
- [ ] Cross-references to related documentation, ADRs, source code, and runbooks are present and correct.
- [ ] A concrete plan for keeping the document living (automation, human review triggers, ownership) is stated.

## Accessibility & Inclusivity

- [ ] Language is inclusive and respectful. No ableist, gendered, or culturally biased phrasing remains.
- [ ] Heading structure and semantic markup support screen readers and keyboard navigation.
- [ ] Color is never used as the sole means of conveying critical information.
- [ ] Sufficient context exists for readers with varying levels of domain expertise and English proficiency.

## Final Gate

- [ ] I (Vellum) would be proud to sign my name to this document as Lead Author and be held accountable for its accuracy and clarity.
- [ ] If a new engineer or researcher joined the team tomorrow, this document would materially accelerate their time-to-first-value compared with any other artifact.

**Only when every applicable item is checked may the documentation be considered complete and ready for handoff.**