Content Disclosure

Overview

CapyToolkit is a site I build and run on my own, and the About page covers my background. Every tool, page layout, article, FAQ and image on it starts with my decisions: which topic is worth covering, who the page is for, what questions it has to answer and what it must not claim. I use AI as a writing tool to turn those decisions into text, code and graphics, and scripts then catch mechanical errors. Neither one has the final say. I read and review every piece myself, and nothing goes live until I approve it.

What I review

My review covers everything you see on the site and the code behind it, not only the articles. Each of these passes through my hands before it ships:

• Tools. The interface, the labels, the messages and the results each tool shows.
• Page layouts and design. Where the tool sits, how sections, tables and buttons are arranged, and how the page reads in the light and dark themes.
• Articles. The text on tool pages, guide pages, reference pages and blog posts.
• FAQs, titles and descriptions. The questions and answers, the headings, the page titles and the summaries you see in search results.
• Images. Diagrams, infographics, share images and tool screenshots.
• Product picks. The items recommended on pages that carry affiliate links.
• Changelog entries. The notes that describe what changed on the site.
• Code. The code that runs each tool and builds each page, written with AI to my decisions and reviewed by me before it ships.

A piece that fails my review goes back for a rewrite, a redraw or a rebuild, never straight to the site.

How a page is planned

Before any text exists, I set the scope of the page. I pick the topic, decide where it belongs on the site and list the questions a reader arrives with, so the page answers what you actually came for instead of what fills space.

The writing itself follows a set of instructions I wrote and keep updating for this site. They require verified facts only, plain language, no padding to reach a word count and no claims about devices or tests that did not happen. When I find a mistake pattern in a draft, I add a rule so it does not come back on the next page.

Automated checks

A draft is not finished when the text is written. Every page goes through a fixed chain of checks I set up, each with one job:

• Sources. Technical claims are checked against primary sources such as specifications, official documentation and manufacturer pages, including the source's title, publisher and date. A claim that cannot be backed is rewritten or removed. Sourced claims carry footnotes, so you can read the original yourself.
• Formatting. Commands, file paths, flags, headers and other literal values are marked as code, so you can see at a glance what to copy.
• Links. Internal and external links are audited, so they point to the right page and that page still loads.
• Product picks. On pages that recommend products, the picks come from research into real, currently listed items. Those pages carry a note that links to the Affiliate & Advertising Disclosure.

These checks are good at catching mechanical problems, such as a missing source, a dead link or a paragraph that breaks the formatting rules. They cannot tell whether a page is actually useful. That part is my job.

My personal review

After the automated passes, I open the page in my own review app, which also runs the site's validators over it, and read it the way you would. I ask whether it answers the question you came with, whether the steps come in the right order, whether any sentence claims more than its source or test supports, and whether it reads like a person explaining something rather than filler.

When something falls short, I send it back with notes on what to change: a section rewritten, a claim cut or sourced, an example replaced, a layout rearranged or an image redrawn. The revised version then goes through the same automated checks and comes back to me. Most pieces go through many rounds of polishing like this. Only a version I give final approval to goes live.

Images, layouts and design

Diagrams and infographics start from a brief I approve and are drawn as vector graphics. Before one goes on a page, I look at the rendered image in a real browser, because a graphic that looks right in code often renders wrong, and I ask for a redraw when a label is unclear, a value is off or the design does not fit the site. Tool screenshots are captures of the actual tools running on a build of this site. Each caption states the readings shown in the image, so the text never says more than the screenshot does.

Page layouts get the same treatment. When a tool or page template is new or changes, I check the result in the browser and request changes until the tool is easy to find, the controls make sense and the page reads cleanly in both themes.

Testing and hardware

The tools run entirely in your browser. When a page says something was tested on a specific device, the reading comes from my own hardware. I only name devices I own and measured, and I do not publish readings I did not take.

Updates and corrections

A page's "updated" date changes only when you would see different information on it: a new section, a corrected fact or number, new data, or a new source behind a new claim. Fixing a typo, swapping a dead link for a live copy of the same source or restyling a page leaves the date alone.

If you spot an error, the contact page reaches me directly. I fix confirmed errors, and the corrected page goes through the same checks and the same personal review as a new one.