Editorial and Testing Methodology

This page explains the working standard for Markdown for AI. Not every article needs every step: a syntax guide and a product comparison require different evidence. Each page should make its own scope and important limitations clear.

1. Define the reader’s task

We begin with the job a reader is trying to complete, such as adding a line break, choosing an editor, or converting a document. The article should answer that task directly before expanding into alternatives and edge cases.

2. Prefer primary sources

For Markdown behavior, primary sources include specifications and official documentation for the renderer or application in question. For products, they include official documentation, pricing and download pages, release notes, source repositories, and license files.

Independent reviews, forums, and community discussions may show recurring experiences or uncover questions worth checking. We label those reports as user experience rather than treating them as proof that everyone will see the same result.

3. Keep evidence types separate

Articles distinguish among:

• Documented facts: supported by a specification or first-party source.
• Observed behavior: reproduced in a named tool, version, platform, or workflow when that context matters.
• Community reports: attributed patterns or individual experiences that have not been established as universal behavior.
• Editorial judgment: a recommendation based on stated criteria, not a measurable fact.

Links should sit close enough to consequential claims that a reader can check the evidence without guessing which source applies.

4. Test only what the article claims

Examples are checked for internal consistency and, when practical, rendered in the relevant Markdown environment. A product comparison may also involve installing or using selected tools for the workflows described.

We do not imply comprehensive testing unless a page documents it. A local observation is not a benchmark, one operating system does not represent every platform, and a successful sample does not establish full compatibility. If a tool was assessed only from documentation or community evidence, the article should not present that work as hands-on testing.

When versions, devices, settings, files, or dates could change the outcome, a guide should record the relevant context or qualify the conclusion.

5. Compare tools by workflow

Product recommendations start with use cases and decision criteria rather than a single universal score. Criteria can include standards support, file portability, platform availability, workflow friction, accessibility, maintenance, price, licensing, and the clearest reason a reader might choose something else.

No company pays for inclusion or ranking. Any sponsorship, affiliate relationship, supplied review access, or other material connection must be disclosed on the affected page. Absence from a comparison does not mean a product failed a test; scope limits should be stated.

6. Publish and update carefully

Before publication, we check that code samples and links support the surrounding explanation, material claims have an appropriate source, and recommendations explain their tradeoffs. Translations should preserve evidence and caveats rather than silently strengthen a claim.

Updates focus on claims that may have changed: prices, availability, release status, platform support, licensing, and documented behavior. A visible update date records a substantive review of the page, not continuous monitoring or a guarantee that every external detail is current.

Corrections and challenges

Corrections are part of the process. To question a claim, open a GitHub issue with the page URL, the passage, what appears wrong, and a primary source when available. We review the evidence, revise the page when warranted, and update the page date when the change is substantive.

For more on the site’s purpose, independence, and content license, see About Markdown for AI.