Before I write something, I ask: can I explain this simply, can I check it's true, and is anyone missing it? If the answer is yes three times, I write it.
I pick articles by asking a few questions. Can I explain one idea clearly? Can I check every fact against a primary source? Does it fill a gap someone would notice, like an empty page? And will writing it teach me something? If an idea fails the fact check, I leave it out.
Article selection filters: single-concept scope, verifiability against primary sources (or explicitly labelled as my method), gap severity (empty or thin collections first), dependency on other articles, and learning value. Unverifiable claims are dropped. Third-party products are excluded unless primary documentation exists.
Four questions
The plan decides what kind of work comes next. This page is about one kind: articles. Before I write one, I ask four questions.
- Does it teach one idea? If I can't say what the article explains in a sentence, it's two articles or none.
- Can I verify it? Every claim about a product, price, licence or feature needs a primary source. If I can't find one, the claim stays out. If the whole article depends on it, the article waits.
- Does it fill a gap a reader would notice? An empty collection, a term used elsewhere without explanation, or a question someone has actually asked.
- Will writing it teach me something? The site exists so I can learn by explaining. An article I could write without thinking is less useful to me, and often less useful to readers too.
Verification shapes the list
The second question rules out more than I expected. Some topics I wanted to write about rely on information I could only find in secondary sources, such as blog posts quoting a price or a launch date. I don't use those figures. Where a product's status is unclear between sources, I don't state a status.
For third-party products, I write only when there's primary documentation. If I can't find it, the title stays as "coming" on the collection page.
Method articles are different
Some articles describe my own methods, such as a scoring sheet or a threshold rule. Those don't need an external source for the method itself, because the method is mine. They do need to say so, and any numbers in them are labelled as illustrative. I put a short note in the Sources section of each one explaining that.
A worked example
These candidates are illustrative of how I'd apply the questions.
| Candidate | One idea? | Verifiable? | Gap? | Teaches me? | Decision |
|---|---|---|---|---|---|
| What Copilot Chat can see | Yes | Yes, Microsoft Learn | Yes, empty collection | Yes | Write |
| A comparison of two decision-model products | Yes | Only partly | Yes | Yes | Wait for primary sources |
| A full history of Microsoft's AI products | No | Mostly | No | Somewhat | Don't write |
| How reversibility changes a threshold | Yes | It's my method | Yes | Yes | Write, labelled as my method |
The order within a section
Inside a section, I start with collections that have nothing in them, because an empty page looks broken. Then I fill any collection with only one article, so each has at least two that work together. Then I follow dependencies: an article that others will link to comes first.
What I'm still checking
I don't yet have a good way to hear which gaps readers notice. For now I go by what's empty or thin. A simple feedback route, with no sign-up and no sales, would help, and it's something I'm considering for after the current round of articles.
Sources
This article describes how I choose what to write. It uses no external facts or figures; the examples are illustrative.