Key takeaways
- Uploaded reports and secondary articles are discovery indexes, not final authority.
- Every technical claim should trace to a source, controlled test, transparent calculation, or clearly labeled analysis.
- Version, status, hardware, configuration, and UTC review date are captured for changing facts.
- Contradictory sources are investigated and scope differences are presented rather than erased.
- Diagrams and examples are original and tested for accessibility and technical coherence.
- Publication includes content, link, code, SEO, accessibility, and packaging QA.
Runtime boundary
A useful architecture identifies what this layer receives, owns, emits, measures, and refuses to own. That boundary prevents overlapping products from being treated as interchangeable.
Receives
Research questions, reports, live-site/code baseline, primary sources, standards, repositories, papers, and implementation evidence.
Owns
Verification workflow, provenance, evidence grading, conflict handling, freshness, and publication gate.
Emits
Research matrix, controlled vocabulary, claim records, page copy, diagrams, source lists, QA results, and known limitations.
Does not own
Assuming reports are correct, copying source prose, or inferring project status from search snippets.
Failure modes
Unsupported claim, stale source, citation mismatch, benchmark apples-to-oranges, inaccessible visual, broken link, and missing limitation.
Evidence and metrics
Claims verified, source-type distribution, conflicts resolved, broken links, reviewed dates, QA pass, and open limitations.
Baseline audit
Inspect current pages, URLs, headings, navigation, templates, CSS/JS, content model, SEO, accessibility, analytics, plugins, drafts, and repository state.
Implementation
Use live site and repository as source of truth and preserve newer work.
Operational implications
When live access is unavailable, state the limitation and produce a staging verification plan.
Measure
Page inventory, broken links, thin pages, duplicate headings, accessibility/SEO gaps, and screenshots.
Research matrix
Map each topic and proposed claim from reports to target page and primary sources.
Implementation
Record claim status, verification date UTC, exact source section/version, conflict, and editorial note.
Operational implications
A bibliography alone does not show which claim a source supports.
Measure
Claims/source, unverified claims, primary-source coverage, and conflict count.
Controlled terminology
Define how the site uses AI runtime, inference engine, model server, serving platform, compiler, graph runtime, execution provider, delegate, agentic runtime, and AI OS.
Implementation
Apply terms in page templates, glossary, directory, and comparisons.
Operational implications
Keep vendor names for their products while explaining cross-vendor category differences.
Measure
Term consistency, aliases, glossary backlinks, and corrections.
Primary-source verification
Open current official docs/spec/repo/paper; confirm feature, status, version, license, and limitations.
Implementation
Capture title, owner, publication/update, URL, access UTC, source type, and relevant sections.
Operational implications
Search snippets and secondary summaries are insufficient for time-sensitive claims.
Measure
Verified links, source freshness, official-source share, and unavailable evidence.
Benchmark review
Require complete disclosure and comparable scope before publishing numbers.
Implementation
Check model, precision, hardware, software, workload, cache, warmup, metrics, quality, errors, and raw data.
Operational implications
If the method is insufficient, omit numbers and describe qualitative trade-offs.
Measure
Disclosure score, reproducibility, quality gate, and rejected benchmark claims.
Synthesis and originality
Write original explanations that combine mechanisms, boundaries, failure modes, metrics, and decisions.
Implementation
Avoid long source paraphrases and duplicate definitions; use cross-links and glossary terms.
Operational implications
Separate sourced facts from aRuntime.com analysis.
Measure
Similarity review, redundancy, citation placement, and readability.
Diagrams, tables, and code
Create original semantic HTML/CSS or accessible SVG; retain source; include alt/long descriptions; validate code/examples.
Implementation
Tables need captions/scopes and responsive behavior; code uses synthetic data and no secrets.
Operational implications
No information should rely on color alone.
Measure
Accessibility checks, code parse/test, table overflow, and mobile legibility.
Technical and editorial review
Review terminology, architecture boundaries, source support, current status, security, code, SEO, accessibility, and internal links.
Implementation
Use checklists and archive evidence with the release.
Operational implications
Pages with unresolved material verification remain draft or clearly note limitations.
Measure
Review status, open issues, corrections, and reviewer/date.
Freshness and corrections
Schedule review based on volatility and monitor broken links/project changes.
Implementation
Display reviewed UTC, record material updates, and route reports through corrections.
Operational implications
Do not automatically update claims from unreviewed feeds.
Measure
Review age, broken links, source change, correction time, and stale queue.
Reference tables
| Field | Purpose |
|---|---|
| Claim ID/text | Precise unit of verification |
| Target page/section | Publication context |
| Source and section | Evidence |
| Source type | Authority context |
| Version/date/accessed UTC | Freshness |
| Status | Verified/qualified/rejected/open |
| Conflict/limitation | Scope and uncertainty |
| Reviewer | Accountability |
Decision checklist
- What is the exact claim being verified?
- What is the strongest primary source and relevant section?
- Is the fact version- or date-sensitive?
- Do sources disagree because scope or configuration differs?
- Is a benchmark methodology comparable?
- What is synthesis versus sourced fact?
- Has the visual/code been tested?
- What limitation remains and when will the page be reviewed?
Common mistakes
- Treating attached reports as publishable authority.
- Collecting links without claim mapping.
- Citing documentation without verifying version/status.
- Resolving disagreement by selecting the most convenient source.
- Copying vendor diagrams or prose.
- Publishing benchmark figures with missing methodology.
- Leaving page review dates static after substantive changes.
Sources and further reading
-
Reproducibility and Replicability in Science
(opens in a new tab)
-
MLPerf Inference
(opens in a new tab)
-
WCAG 2.2
(opens in a new tab)
-
JSON-LD 1.1
(opens in a new tab)
Last reviewed: 2026-06-21 UTC