Product claims follow inspectable behavior
Documentation is checked against public API contracts and the application behavior represented in this repository. Capability claims are scoped to what a reader can verify.
Technical sources are primary
Guides prefer official vendor documentation, specifications, and first-party references. Comparison pages identify sources and a review date so time-sensitive claims can be rechecked.
SQL examples have a declared test boundary
Published recipes are read-only and include a typed event contract. Automated checks plan the SQL against the documented DataFusion version; synthetic result rows are reviewed separately.
Evidence is separated from interpretation
Synthetic fixtures never become customer benchmarks. Customer metrics are published only after the customer approves the measurement, time window, attribution, and exact wording.
Dates represent substantive review
A page’s modified date changes when its claims, examples, sources, or material guidance are reviewed and changed. Dates are not refreshed only to make unchanged content look recent.
Ownership
Accountable organization, explicit review boundary
The visible byline and structured data identify the Telemetry editorial team as the organizational author and the Telemetry product team as technical reviewer. Individual contributor names are added only when the person has agreed to a public profile; the organization remains accountable when no individual byline is shown.
The publishing components support named author and reviewer profiles, including person-level structured data, once consent, role, relevant experience, and an accountable profile URL are recorded. Placeholder identities, generated biographies, and private employee details are not published to fill a byline.
Review does not mean a query is correct for every business definition. Event names, identity rules, time windows, thresholds, prices, and incident policy remain choices for the implementing team. Recipes call out those decisions as edge cases instead of hiding them in a polished chart.
Generated assistance may help draft or check content, but it is not listed as an author or evidence source. A publishable page still needs human ownership, working internal references, source review where claims can change, and the repository’s automated content checks.
Named contributor gate
Requirements for a person-level byline or review credit
- 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
A reviewer can use the public evidence template to record scope, primary sources, corrections, consent, and approval before a person-level profile is added to the contributor registry.
Open contributor templateEvidence before claims
Public intake paths for the gaps evidence can close
The site keeps an empty claim register when approval evidence is missing. These paths expose the required fields and the current public boundary instead of replacing evidence with estimates, anonymous attribution, or roadmap language.
Performance results
The benchmark register requires workload, environment, raw results, correctness checks, caveats, and reviewer approval.
Review benchmark gateCustomer outcomes
A measured result needs a baseline, UTC window, population, source artifact, caveats, and customer-approved wording.
Review outcome gateSecurity assertions
A public control claim needs a current owner, implementation evidence, exact scope, exceptions, and approved language.
Review assurance gateInspect the reproducibility boundary
The SQL methodology explains automated planning, browser fixtures, deterministic outputs, and the decisions that still require human review.