Ai-Forum.org uses sources to help readers examine claims, follow technical instructions, and distinguish evidence from opinion. This policy applies to publisher-produced articles, tutorials, comparisons, and resources. It also describes the sourcing practices we encourage in community discussions.
Sources must be relevant to the statement they support. A reference should establish the specific fact, method, limitation, or context being discussed. Adding a link does not make a claim reliable if the linked material concerns a different version, repeats an unsupported assertion, or does not address the claim.
For technical information, we generally prefer official documentation, release notes, specifications, source repositories, model cards, original research, and licensing documents. These sources are particularly useful for identifying intended behavior, configuration requirements, and stated restrictions. Provider materials must still be assessed critically: a product announcement or benchmark establishes the provider’s account, not independent confirmation of performance.
Independent technical analysis and reputable reporting can supply context, competing interpretations, and evidence unavailable from a provider. Community posts can identify practical problems and possible solutions. Sources are assessed for authorship, methods, supporting evidence, relevance, publication date, commercial interests, and applicability rather than accepted solely because of their format or publisher.
Authors must consult the underlying source before citing it. Search snippets, summaries, social posts, and AI-generated descriptions may help locate material, but they are not substitutes for examining it. If only an abstract, excerpt, or secondary account is available, the article must accurately describe that limitation and avoid implying a review of the complete original work.
Citations should appear close to important, disputed, or time-sensitive claims. A reference list may supplement these links, especially in longer articles. References should provide enough information to identify the source: author or organization, title, publication or update date where available, and a direct URL or DOI. Changing documentation, pricing pages, repositories, and similar resources should also identify the relevant version or access date when needed.
For software, code, and model-related claims, cite the applicable release, repository tag, commit, documentation version, or model identifier where practical. Do not silently apply instructions for one release to another. Licensing statements should link to the relevant license or terms; labels such as “open source,” “open weights,” and “commercial use permitted” must not be treated as interchangeable.
Research coverage should identify whether a work is a preprint, peer-reviewed publication, technical report, or other research output. Editors should consider methods, limitations, and relevant conflicting evidence. Peer review does not establish that every conclusion is correct. Check for corrections, retractions, or later versions when these could affect interpretation, and identify material uncertainty.
When reporting our own tests, provide enough context to understand the result. Relevant details include the tested environment, model and software versions, configuration, inputs, evaluation method, and test date. Retain supporting records where practical. A screenshot or selected output illustrates an observation; it does not establish a general performance claim without an appropriate method.
Third-party benchmarks must be attributed to their actual source. Describe meaningful differences in hardware, datasets, workloads, scoring, and test conditions before comparing results. Estimates and provider-reported numbers must be labeled accordingly. Do not combine incompatible measurements into a ranking or present a community report as an independently reproduced result.
AI-generated answers are not factual authorities. If an AI tool suggests a reference, the author must locate and verify the real source. Invented titles, authors, quotations, URLs, and DOIs are prohibited. Model outputs may be included as experimental material when clearly labeled with their context; they must not be presented as independently verified evidence.
Community contributors should link to documentation or other evidence when making technical claims, particularly when recommending commands, configuration changes, or security-related actions. When an editorial article draws on a public discussion, credit the contributor appropriately and link to the relevant post where suitable. Assess the evidence separately from votes, reputation, or accepted-answer status.
Quotes must preserve the original meaning and clearly identify their source. Paraphrases must use original wording while retaining attribution for distinctive ideas, findings, and methods. Citations do not replace permission or license compliance. Images, charts, datasets, and code require appropriate attribution and rights consideration; translations and adaptations should be identified.
Avoid linking to exposed credentials, private records, unauthorized copies, or unnecessarily identifying personal information. Private correspondence requires an appropriate basis before quotation or publication. Archive links may preserve historical evidence, but must be labeled and should not imply that outdated instructions remain current.
If a source disappears, changes materially, or is corrected or retracted, review the affected claim. Replace broken links with a verified equivalent where possible, explain historical sources when relevant, and correct conclusions that no longer have adequate support. Significant changes should follow our editorial and corrections standards.
Readers may report unsupported claims, inaccurate quotations, broken references, or attribution concerns through the contact page. Include the article URL, affected passage, and relevant evidence. Read this policy alongside our Editorial Policy and other applicable research, testing, and corrections policies.