Three kinds of claim, labelled differently
Every page separates what has been tested, what is a conceptual example, and what is an open question. A tested practice is something that has been implemented and observed. A conceptual example illustrates a shape — a schema, a pipeline, a record — without asserting that a particular run produced it. An open question is named as a question, not smoothed into advice. When a page cannot tell you which of the three applies, that page is not finished.
- Tested practice: stated plainly, with the conditions it was observed under.
- Conceptual example: marked as illustrative in the caption or the surrounding text.
- Open question: written as a question, with what would be needed to answer it.
Code is pseudocode until it is verified
Code samples on this site are illustrative unless a page explicitly says the example was run. Illustrative samples use example.com hostnames, omit error handling that would distract from the idea, and describe API shapes that do not exist as written. Treating them as runnable will waste your afternoon. Where a sample is verified, the page says so and names what it was verified against.
- Illustrative samples are labelled in the code-block header or the paragraph introducing them.
- No sample implies a specific vendor API unless that vendor is named.
- Schemas and record shapes are examples of structure, not published specifications.
Pages are reviewed when the concepts change
Content is updated when the underlying concepts, tooling conventions, or sensible defaults change — not on a calendar. Each page carries a version and a short version history so you can see whether what you are reading is the first pass or a revision. Material corrections are recorded in that history rather than quietly patched.
- Every content page shows a version number and its history.
- Corrections that change the advice are logged, not silently edited.
- Pages still being expanded are labelled in active development.
What is never fabricated
Sourceframe is an independent product concept, not an operating company. That makes certain content impossible to write honestly, so it is not written at all. There are no customers here, so there are no customer stories. There is no production deployment, so there are no uptime, latency, or accuracy figures. There are no partnerships, no funding history, and no usage numbers.
- No customer data, case studies, or testimonials.
- No performance benchmarks, accuracy rates, or reliability figures.
- No partnerships, integrations, funding, or commercial claims.
- No engagement counts, share totals, or vote tallies on any interactive control.
Tone is chosen per piece, not applied globally
Each piece declares one of three tones, shown as a badge near the byline. The tone describes how the piece is written and who it is written for, and it is a commitment: an authoritative piece has to name its trade-offs, and an educational piece has to include steps a reader can follow.
- Conversational: Plainspoken and practical. Used for field notes, perspective pieces, and workflow explainers where momentum helps.
- Authoritative: Precise, calm, and candid about trade-offs. Used for research notes, comparisons, architecture guides, and documentation.
- Educational: Patient and step-by-step, with worked examples. Used for tutorials, implementation guides, glossaries, and checklists.
Audience is declared before the first paragraph
Technical depth is a choice about the reader, so every page names a primary audience and, where relevant, a secondary one. If a page cannot say who it is for, it usually means it is trying to serve everyone and will serve no one. Audience badges also drive the Start-here tracks and the library filters.
- One primary audience per piece; optional secondary audience.
- Depth matches the declared audience rather than the broadest possible reader.
- Prerequisites are linked rather than re-explained.
Writing rules
The house style is plain, specific, and short on adjectives. Claims that cannot be checked are cut. Words that signal enthusiasm without adding information are cut. If a sentence would survive being pasted into any other company's blog, it is probably not saying anything.
- No vague superlatives, invented statistics, or unsupported rankings.
- No comparisons to named companies, and no borrowed positioning.
- Direct answer first, caveats immediately after, detail below.
- Internal links point to the page that actually continues the thought.
Standing disclosure
Sourceframe is an independent product concept created for research, product-design, and technical-content exploration. It is not an operating company, and nothing here describes a live commercial service. All examples, schemas, and code are illustrative unless a page says otherwise. No client data, customer outcomes, performance results, or partnerships are described anywhere on this site.
Found something that breaks one of these rules? Say so.