# What this blog is, and is not

> 19 Jul 2026 · Telemeter · 3 min read

Evidence-backed implementation notes and architecture decisions — not manufactured benchmarks, customer stories, or trend commentary.

This is the first post on the telemeter.ai blog, and its only job is to state
the standard the rest of this blog is held to before a second post exists to
test it against.

## What this is

The plan is for this space to carry implementation notes and architecture
decisions from building telemeter.ai: what a design doc committed to, why a
particular tradeoff was made, what changed after it met a real constraint.
When a post makes a technical claim, it should be checkable — against the
code, against a cited source, or against a decision record in the repository
— rather than asserted on the strength of the byline alone.

Telemeter is a pre-MVP, solo-founder build. Most of what eventually gets
written here will describe a system still being built in public, including
the parts that are designed but not yet live. A post that describes planned
behavior will say "planned," the same way the rest of this site does.

## What this isn't

Three things this blog will not do, on purpose:

- **No manufactured benchmarks.** A performance number needs a real
  measurement behind it, with the method disclosed, or it does not appear.
- **No invented customer stories.** telemeter.ai is pre-launch. A blog post
  is not the place to imply a customer, a case study, or a quote that does
  not exist yet.
- **No trend commentary for its own sake.** A post exists to document a
  decision this project actually made, not to comment on the industry in
  general to fill a publishing schedule.

### Honesty as a build constraint, not a tone

This isn't a style preference — it's the same rule the rest of the site
holds itself to (see ADR 0016): a specific, falsifiable claim, or an
explicit "planned" / "designed, not yet built" label. A blog is an easy
place for that discipline to slip, because a narrative reads better with a
few invented specifics in it. The standard here is that it shouldn't.

## How a post gets published

Every post in this blog is an MDX file with a small set of required
frontmatter fields, validated against a schema at build time. An invalid or
incomplete post fails the build rather than publishing quietly wrong:

```yaml
title: "Post title"
subtitle: "One or two sentences — the deck and the card excerpt."
author: "Byline"
date: "2026-07-19" # ISO date, drives ordering
tags: ["topic-one", "topic-two"]
category: "engineering" # engineering | architecture | notes
```

A post can also be marked `draft: true` while it's being reviewed — a draft
is excluded from the index and the sitemap (and, once it ships, the RSS feed),
and its own page declines to render, until it's ready.

## Reading this blog

If a future post here ever states something that turns out not to hold up —
a number that was wrong, a decision that got reversed without saying so —
that's a bug in this blog, evaluable against the standard set out above, not
a reason to read everything on it a little more skeptically. Report it to
[founder@telemeter.ai](mailto:founder@telemeter.ai).

[Read on telemeter.ai](https://telemeter.ai/blog/what-this-blog-is) · [Every tool and doc, machine-readable](https://telemeter.ai/llms.txt)