How ScrubMyText guides are researched and reviewed.

1. Product behavior is checked against executable sources

The primary sources for a ScrubMyText feature are the implementation, the generated OpenAPI document, the MCP tool metadata, and the automated contract tests in the public repository. Before a guide release, the repository verification command checks website links, generated documentation, browser JavaScript syntax, Worker syntax, security-sensitive page boundaries, test suites, and a Cloudflare deployment dry run.

A passing test establishes only the behavior covered by that test. It does not prove that a service will never fail, that an integration is secure, or that a workflow satisfies a legal or organizational requirement. Guides therefore describe narrow response rules and failure boundaries instead of using broad labels such as “safe,” “compliant,” or “guaranteed.”

2. Examples are synthetic and reproducible

Guide examples use fictional order numbers, documentation domains, reserved test IP ranges, and invented workflow details. They are designed to make one failure mode concrete without exposing customer prompts, responses, credentials, approval links, webhook URLs, or transaction records. The expected result is written so a reader can reproduce the case in a test environment and detect a disagreement.

Synthetic examples are not presented as customer case studies. When ScrubMyText later publishes production measurements or customer outcomes, they must be labeled separately with the population, time window, collection method, and known limitations. Provider self-tests and founder-generated observations are never described as independent customer evidence.

3. Facts, product boundaries, and judgment stay separate

4. Comparisons are allowed to conclude that another option is better

ScrubMyText owns the products discussed in these guides, so every product comparison has an inherent commercial conflict. We address that conflict by defining the decision criteria before naming a preferred option, including do-it-yourself and established-category alternatives, and publishing “use another approach when” conditions. A guide should not claim that a narrow hosted primitive replaces a database transaction, enterprise identity system, durable queue, security assessment, legal review, or comprehensive data-loss-prevention program.

Payment, advertising, partnerships, repository popularity, and directory placement do not increase TrustMyChoice evidence weight. Advertising may appear inside qualifying guide articles, but ad selection and revenue do not alter the comparison table, decision rule, source threshold, or directory order.

5. Privacy constrains what we collect and publish

Ordinary text-tool inputs should not be copied into analytics or editorial examples. Stateful products store only the bounded data described by their product and privacy contracts. Guides never publish live API keys, bearer approval links, webhook tokens, customer text, payment-card data, or production exports. Analytics are used at aggregate route and outcome level so we can understand whether a page or workflow is useful without turning private content into marketing material.

6. Corrections and review cadence

Each guide displays its publication and modification dates. A guide should be reviewed when the related endpoint, response contract, pricing, privacy boundary, or evidence method changes. Material corrections should update the page and its modification date rather than silently preserving an outdated claim. Readers can report a reproducible error through the support channel; the report should identify the public page and disputed statement without including secrets or customer data.

Editorial review is not certification. It is a repeatable process for making claims inspectable, examples useful, conflicts visible, and corrections possible. The final responsibility for authorization, security, compliance, and production operation remains with the system owner.