How We Work

1. Start with a real user job

We group search language by underlying intent and canonical concept. Before a new URL is proposed, we check whether an existing page, a section, or a calculator would serve the user better.

2. Inspect current results and sources

Research records the date, search intent, useful existing results, genuine gaps, and what the proposed page can add. Exact search volume, keyword difficulty, traffic, and authority scores are marked unavailable when reliable data is not available—they are not guessed.

Consequential technical claims begin with applicable primary and authoritative sources. A product manual is scoped to that product and revision.

3. Classify claims and risk before drafting

Each important claim is assessed for confidence, variability, and technical risk. The outline identifies prerequisites, equipment assumptions, warnings, diagrams, and calculations before prose is written.

4. Write from verified claims, not source prose

Sources establish facts, limits, and uncertainty. Research packets retain the claims a source supports, but source or competitor wording and page structure are not used as draft text. Articles are written in an original structure and in our own language. A necessary direct quotation is clearly marked, cited beside the claim, and limited to 25 words.

The publication build scans the complete article corpus for repeated prose, long matching sequences, excessive similarity, and overlong quotations. A separate editorial check compares distinctive wording with cited sources and representative search results. The local scan is a preventive gate, not a claim that we can search every page on the internet.

5. Use code for reproducible results

Ohm’s Law, power relationships, series/parallel equivalents, unit conversions, and supported wiring topologies are tested deterministically. Where a technical diagram is required, its calculation, terminal labels, connection list, and SVG should come from the same reviewed fixture.

6. Review within defined limits

Every consequential claim must remain traceable to applicable evidence. Missing specifications are recorded as gaps rather than filled by inference. High-risk pages require at least two applicable Tier 1 sources from independent publishers, an adversarial review artifact, applicable deterministic validation, explicit scope and stop conditions, and the site’s visible safety/limitations notice. No current review is represented as human expert approval.

7. Plan and validate every media asset

Every ready article has a unique thumbnail that also appears as its hero and social preview. We choose the visual role during outlining, generate or source the asset, normalize it to a compact 1200×675 WebP, write descriptive alt text, and record its source or prompt, dimensions, checksum, and visual review in a machine-checked manifest.

Supporting diagrams, charts, photographs, and illustrations are planned with the outline and declared in the article metadata. Their filenames use one short, descriptive topic phrase rather than a generic filename or a list of search terms. The build checks that each declared file is present in the article with matching alt and caption text, and that no local body image bypasses the media plan. Published assets are exposed through an image sitemap; scheduled or blocked media is not.

Generated editorial images are never evidence for wiring, polarity, terminals, fusing, grounding, loads, settings, measurements, or compatibility. Technical diagrams must come from structured, validated data and remain blocked until all evidence, topology, visual, accessibility, and review conditions required by their risk level are complete.

8. Block incomplete work

Before publication, the build and editorial checks cover metadata, sources, originality, canonical-topic ownership, internal links, required warnings, calculations, diagram fixtures, and review state. A failed required check blocks the page from routes, search, feeds, and sitemaps.

9. Correct and improve

Reader reports, source changes, tool changes, and later search-query evidence can trigger review. We prefer improving or consolidating the canonical page over creating another overlapping URL. Substantive errors are documented on the corrections page.