Skip to content
Telemetry
Editorial standards

How we check and correct what we publish

The Telemetry editorial team is responsible for the writing. The product team checks descriptions of product behavior, event schemas, and known limitations. Here is what we check and what still needs your judgment.

Claims must match the product

We check documentation against the public API contracts and application code. We only claim capabilities a reader can verify.

Use original sources

Guides use official vendor documentation and specifications where possible. Comparison pages link to their sources and show a review date so readers can check claims that may have changed.

Say what the SQL checks cover

Published recipes contain read-only SQL and specify event fields and types. Automated checks ask the documented DataFusion version to plan each query. We review synthetic result rows separately.

Sample data is not a customer benchmark

We never present synthetic test results as customer benchmarks. Before publishing customer metrics, we get approval for the measurement, time window, attribution, and exact wording.

Update dates when content changes

We change a page's modified date when we review and change its claims, examples, sources, or guidance. We do not refresh dates to make unchanged content look recent.

Ownership

Who is responsible

Our bylines and page metadata credit the Telemetry editorial team as author and the product team as technical reviewer. We name individual contributors only with their agreement. Telemetry remains responsible for pages without an individual byline.

We record each author or reviewer's consent, role, relevant experience, and public profile URL before adding their profile. We do not invent contributors or publish private employee details.

A reviewed query can still use the wrong definition for your business. Your team must choose event names, identity rules, time windows, thresholds, prices, and incident policy. Recipes list these decisions so you can check them before using the results.

We may use AI to draft or check content. A person remains responsible for the page, and AI output does not count as evidence. Before publication, we check internal links, review sources for claims that can change, and run the automated content checks.

Authors and reviewers

Before we credit an author or reviewer

  • Consent to the public name, role, profile, and byline
  • A profile URL owned by this site with relevant experience and scope
  • Recorded review responsibility for the specific content type
  • Approval date and a process for correction, removal, or role changes

Use the public template to record what you reviewed, your sources, corrections, consent, and approval before we add your contributor profile.

Open contributor template

Evidence before claims

What we need before publishing results

We publish claims only when we have supporting evidence and approval. These pages list the claims we can make and the evidence we need for others.

Performance results

To publish a benchmark, we need the workload, test environment, raw results, correctness checks, limitations, and reviewer approval.

See benchmark requirements

Customer outcomes

A measured result needs a baseline, UTC dates, the group measured, the original report or data, limitations, and wording the customer approved.

See customer result requirements

Security claims

Before describing a security control publicly, we need its current owner, implementation evidence, exact scope, exceptions, and approved wording.

See security claim requirements

See how we test SQL recipes

The SQL methodology explains how we check query plans and browser examples, which results you can reproduce, and what a person still needs to review.

Read SQL methodology