Editorial policy

Last reviewed 14 September 2026  ·  Version 1.0

This page sets out who writes for The Software Scribe, how their work is checked before publication, and what separates our editorial decisions from our commercial ones. Our testing process is a separate document: see how we test and review software.

1. Who this policy covers

This policy applies to everything published on thesoftwarescribe.com, and to everyone who writes, edits, researches or approves that content, whether employed by KCS Global Group or working with us on contract.

Every person who contributes agrees to it before their first article goes live. Breach of the independence rules in section 2 or section 12 ends the working relationship.

2. Editorial independence

The Software Scribe is funded by display advertising and affiliate commission. That is stated plainly on every page it applies to, and it changes nothing about what we publish.

The rules are absolute, not aspirational:

• No vendor, advertiser or affiliate partner decides what we cover, how we rank products, or what score a product receives.
• No vendor sees an article, a score or a verdict before publication.
• We do not accept payment for reviews, rankings, placements, or for adding a link to an existing article.
• We do not publish sponsored posts or guest posts.
• Commission rates are not a scoring criterion and are not part of the information a writer works from.
• A product that pays us nothing is tested, scored and ranked exactly as one that pays well.
• Advertising is visually distinct from editorial content, and we do not format ads to resemble articles.

If a commercial relationship ever made a particular finding awkward for us, we publish the finding. The commercial detail is set out in our affiliate disclosure.

3. Authorship and bylines

Every article names its author, and that name links to a profile giving their background, their areas of work, and the other articles they have written. We do not publish under house names, pen names or an anonymous “editorial team” byline.

The person named as author is the person who did the testing described in the article. Where more than one person contributed, the article says who did what.

Articles carry a publication date and, where they have been revised, the date of the most recent substantive update.

4. Use of AI tools

We use AI tools in parts of our workflow, and we would rather tell you than leave you to guess.

What they are used for: background research, assembling first drafts from notes and recorded test results, suggesting structure, and routine editing work such as tightening prose and checking consistency.

What they are never used for:

• Generating findings, scores or verdicts. Those come from the recorded results of tests a person ran.
• Supplying facts, prices or feature claims. Every one of those is verified against a primary source by a person.
• Producing an article that no named human has reviewed, corrected and taken responsibility for.

A named person is accountable for every article on this site, and that accountability is not delegated to a tool. Where a draft has been assembled with AI assistance, it is still that person’s job to confirm that every sentence is true.

5. Sourcing and evidence

Claims on this site come from one of three places, in order of preference:

• Our own testing. What happened when we used the product, following our published methodology. This is the basis of every review.
• Primary sources. The vendor’s own pricing page, documentation, release notes, status page, security documentation or terms. We link to these so you can check them.
• Identified third parties. Where we cite research, regulatory guidance or another publication, we name it and link to it.

We do not cite other review sites as evidence of how a product behaves, and we do not reproduce a vendor’s marketing claims as though they were findings. Where we report something we did not verify ourselves, the article says so.

6. Fact-checking before publication

No article is published on the author’s word alone. Before anything goes live, a second person checks it.

• Every price is confirmed against the vendor’s current pricing page, with the currency and region noted
• Every feature claim is traced to a test result or to documentation
• Screenshots are checked to be current and from the version described
• Scores are checked to follow the published weighting
• Links are tested
• Anything the checker cannot verify is removed or explicitly flagged as unverified

The checker is not the author. Where a disagreement cannot be resolved between them, the editor decides, and the article records any remaining uncertainty rather than hiding it.

7. Originality and plagiarism

Everything we publish is written for this site. We do not republish, spin or lightly reword content from vendors, competitors or anywhere else, and we do not reproduce another publication’s comparison tables or research findings as our own.

Short quotations from a named, linked source are fine. Anything more is not. Plagiarism, in either direction, ends a working relationship immediately.

8. Linking practices

We link out when it helps the reader check something or go deeper, and for no other reason. We do not sell links, exchange them, or add them as a favour.

• Affiliate and paid links carry the appropriate sponsored or nofollow attribute, in line with search engine guidelines
• Editorial links to vendor documentation and primary sources are ordinary links
• Links within an article point to our own related coverage only where it genuinely helps
• A link is never an endorsement of the linked site

9. Keeping articles current

Software pricing and features change constantly, so a review that is never revisited becomes misinformation over time.

• Pricing pages are re-verified on a regular cycle and whenever we learn of a vendor pricing change
• Reviews are re-examined after a major product release
• Substantive updates are dated on the article, so you can see how current the information is
• Where an article is no longer maintained, we say so on the page rather than leave it to look current

10. Corrections

We get things wrong. What matters is what happens next, and our rule is that a correction is made openly rather than quietly.

How to report an error

Email contact@thesoftwarescribe.com with the article URL, the specific statement you believe is wrong, and any source that supports your version. Anyone can report an error, including the vendor concerned.

What we do

We acknowledge your message within two working days. We check the claim against the vendor’s current documentation and our own test records. If you are right, we correct the page. If we cannot substantiate the change, we tell you why and the article stands.

How corrections are recorded

We do not delete an article to make an error disappear, and we do not edit a substantive mistake out of the record without saying so.

11. Right of reply

If we publish a critical finding about a product, the vendor is entitled to respond. Send evidence to contact@thesoftwarescribe.com.

Where the evidence shows we were wrong, we correct the article under section 10. Where the finding was accurate, it stays, and we will add the vendor’s response where it adds something useful for the reader. We do not remove accurate negative findings, and requests to do so in exchange for advertising, commission or access are refused and recorded.

12. Conflicts of interest

Anyone writing for this site must declare any relationship that could reasonably be seen to affect their judgement, before they start work on the article. That includes employment or past employment with a vendor, consulting arrangements, family connections, and holdings in a company we cover.

Where a declared interest exists, that person does not write or check the affected article. Where a connection is relevant for readers to know, we disclose it in the article itself.

The Software Scribe is published by KCS Groups, trading as KCS Global Group, which operates other publications in unrelated subject areas. Those publications have no bearing on what is written here.

13. Reader complaints

If you believe we have breached this policy, write to contact@thesoftwarescribe.com setting out what happened. Complaints go to the editor, who is not the author of the article in question wherever possible. We respond within ten working days with our findings and any action taken.

14. How to contact us