Source policy is the trust layer for the wiki. A reader should know whether a page is canonical-linked, explanatory, draft, reviewed, stale, contradicted, or archived before using it.
Publication boundary
AI-assisted drafts, intake files, notes, and audit reports are not public truth by default. They can help a maintainer draft or structure a page, but reviewed public content still needs source status, authority labels, review date, and a path for readers to verify important claims.
Page status labels
| Label | Meaning | Publish rule |
|---|---|---|
| Canonical Source Linked | The page explains an external authoritative source. | Always link the canonical source near the top and avoid replacing it with LlmWikis wording. |
| Non-normative Explainer | The page interprets or teaches but does not define the standard. | Use on UAIX-related pages and protocol comparisons by default. |
| Draft | Useful but not complete enough to trust as reference. | Keep claims modest, request sources, and avoid broad conclusions. |
| Reviewed | Human-reviewed and source-checked at a known date. | Show last-reviewed date, source trail, and reviewer trail when available. |
| Needs Update | Known stale, incomplete, or superseded content. | Show the warning before the main article body and schedule a source refresh. |
| Contradicted | Two or more sources or pages conflict under the same scope. | Preserve the conflict visibly until a human resolves date, scope, or source quality. |
| Archived | Historical or retired material that should not guide current work. | Keep context only when useful and point readers to current guidance. |
Source reliability tiers
| Tier | Use for | Do not use for |
|---|---|---|
| Primary or official | Release facts, API behavior, package docs, standards text, model cards, benchmark definitions, licenses, and changelogs. | Independent claims of superiority unless the source itself is the subject. |
| Peer-reviewed or formal research | Technical mechanisms, evaluation methods, safety findings, training methods, and reproducible experiments. | Operational claims about a vendor service unless the paper directly measured that system. |
| Well-edited secondary source | Historical context, balanced comparisons, and topic orientation after primary facts are established. | Precise schema, validator, API, or benchmark behavior when official sources exist. |
| Project repository or docs | Software behavior, versioned implementation details, issue context, and examples. | Broad ecosystem claims unless supported elsewhere. |
| Social or forum source | Narrow announcements from a verified subject-matter source, with date and archive when possible. | Standalone support for model capability, benchmark, safety, legal, or governance claims. |
How to cite AI and ML artifacts
Preprints and papers
Record title, authors, date, version, venue or preprint identifier, DOI when available, and whether later peer-reviewed publication exists.
Model cards and weights
Record model name, publisher, repository or official page, version, license/access boundary, release date, and any linked paper or DOI.
Software repositories
Prefer versioned docs, releases, tags, commit hashes, and citation files. Repository wikis and issue comments need extra caution.
Datasets and benchmarks
Record dataset or benchmark source, version or snapshot, task scope, scoring method, access date, contamination caveats, and update cadence.
Claims that need sources near the sentence
- Model releases, context windows, modality support, pricing, licensing, access status, or deprecation.
- Benchmark scores, leaderboard position, score comparisons, or claims that one model/tool outperforms another.
- Security, privacy, legal, safety, compliance, or governance statements.
- Protocol support, validator behavior, schema fields, registry values, and compatibility claims.
- Time-sensitive provider behavior, product limits, API behavior, or roadmap status.
AI-assisted writing rules
| Use | Allowed posture | Required control |
|---|---|---|
| Outline, formatting, summarization, copy editing | Allowed as drafting support. | Human review and source check before reference status. |
| Fact generation from memory | Draft only. | Replace or verify with sources before publication. |
| Comparison or synthesis | Allowed when the underlying sources support the comparison. | State assumptions, cite sources, and preserve uncertainty. |
| Public page publication | Not automatic. | Needs source status, authority boundary, review date, and release checks. |
Content quality rubric
| Quality class | Page has | Page still lacks |
|---|---|---|
| Stub | Topic, route, and why it belongs. | Enough source material to guide implementation. |
| Start | Definition, source boundary, related links, and draft caveats. | Examples, checks, contradiction handling, or reviewer signoff. |
| C | Useful explanation, at least one source path, and clear limitations. | Broad source coverage or worked examples. |
| B | Source-backed guidance, examples, quality caveats, and next-step routes. | Independent review or enough evidence for high-risk claims. |
| A / Reviewed | Human review, source trace, freshness rule, contradiction policy, and update owner. | Only future monitoring or domain-specific expansion. |
Benchmark and leaderboard rules
Leaderboard values are volatile and often depend on model version, quantization, prompt format, tool access, evaluation harness, and date. Do not publish a ranking as stable truth unless the page states the source, score date, method, version, and caveats. Prefer explaining what a benchmark measures and what it cannot prove before presenting numbers.
Source review checklist
- Classify the claim. Is it definitional, historical, operational, comparative, legal, safety-sensitive, or time-sensitive?
- Choose the source tier. Prefer official or primary sources for current behavior and formal sources for research claims.
- Attach the date. Time-sensitive claims need a checked date or review cadence.
- Preserve uncertainty. Use source-needed, stale, contradicted, or draft labels when evidence is incomplete.
- Link the next page. Connect the claim to related architecture, operations, template, model, benchmark, security, or UAIX boundary pages.