The standards behind what STACK publishes
STACK publishes research-led coverage of privacy and security products.
Our editorial standard is simple:
Claims should be as strong as the evidence allows, and no stronger.
That principle shapes how we handle sourcing, uncertainty, corrections, commercial relationships, comparisons, verdicts, and the use of research tools.
These standards describe the expectations applied to published work.
They do not describe our internal research systems, workflows, tooling, prompts, scoring logic, or proprietary editorial processes.
Evidence comes before certainty
A clean answer is useful only if the evidence supports it.
When the available evidence is strong, we say so. When it is limited, disputed, historical, provider-stated, or unresolved, we preserve that distinction. We do not turn uncertainty into certainty simply because a stronger conclusion would be easier to read.
That means a STACK article may sometimes conclude:
- the evidence is strong;
- the evidence is bounded;
- the evidence conflicts;
- a claim is provider-stated;
- a question remains unresolved;
- the answer depends on the reader’s use case.
Those are not editorial weaknesses.
They are part of accurate reporting.
Provider claims are identified as provider claims
Companies are important sources of information about their own products.
Their documentation may be the best available source for:
- current features;
- supported platforms;
- pricing;
- product behavior;
- stated policies;
- official explanations.
But company statements are not automatically independent verification.
Where that distinction matters, we preserve it.
We do not upgrade a marketing claim into an independently established fact simply because it appears repeatedly across provider-controlled material.
Independent evidence is represented within its actual scope
Independent audits, technical assessments, external testing, and third-party research can be powerful evidence.
They also have boundaries.
We do not use the existence of an audit to imply that every part of a product, company, or technical system was independently verified.
Where relevant, we consider:
- what was assessed;
- when;
- which product or system was in scope;
- what was excluded;
- what findings were reported;
- whether conclusions remain current.
The same standard applies to testing. A result observed at one point in time is not automatically a permanent property of a service.
Current and historical evidence are kept separate
- Privacy and security products change.
- Features are added and removed.
- Prices change.
- Platforms diverge.
- Security incidents occur.
- Ownership and corporate structures evolve.
Published work should make clear when evidence describes a historical state rather than the current one.
Historical evidence may still be highly relevant, especially when evaluating:
- past incidents;
- company responses;
- long-running problems;
- policy changes;
- remediation;
- product evolution.
But it should not be silently presented as a current fact.
We distinguish different kinds of questions
Privacy, security, ownership, product capability, value, and performance overlap.
They are not the same thing. A service can perform strongly in one area while remaining uncertain or weaker in another.
We therefore avoid using evidence from one category to answer a different question without justification.
For example:
- strong encryption does not, by itself, establish privacy;
- an ownership structure does not, by itself, prove operational behavior;
- an audit does not automatically prove every marketing claim;
- a large feature list does not automatically establish value;
- technical capability does not automatically establish suitability for every user.
Published conclusions should reflect the actual question being investigated.
We do not manufacture universal winners
Not every comparison has one product that is best for everyone.
Not every review needs an absolute recommendation. And not every “is it worth it?” question has a universal yes or no.
Where the evidence supports a conditional answer, we use one. That may mean explaining that a product is a stronger fit where certain requirements apply and a weaker fit where others do.
The purpose of a verdict is to clarify the decision, not to force the research into a ranking.
We do not score by feature count alone
More features do not automatically mean more value.
A sophisticated capability may matter greatly to one use case and very little to another. Likewise, the absence of a feature is not automatically a major weakness. Its importance depends on whether the user actually needs it.
STACK therefore focuses on:
- relevance;
- consequence;
- trade-offs;
- limitations;
- decision impact.
Not simply on how many boxes a product can tick.
Comparisons must compare like with like
Where products are compared, we aim to keep the basis of comparison consistent.
That means avoiding misleading comparisons between:
- introductory and standard pricing;
- current and historical product states;
- different subscription lengths without qualification;
- platform-specific and universal capabilities;
- provider claims and independently verified evidence;
- differently scoped audits;
- features that share a name but not the same implementation.
Where direct equivalence cannot be established, the article should say so.
Material uncertainty stays visible
If an unresolved issue could materially affect the reader’s decision, it should not be buried.
This may include uncertainty around:
- pricing;
- ownership;
- platform entitlement;
- technical behavior;
- audit scope;
- data handling;
- streaming reliability;
- security remediation;
- current feature availability.
Not every unknown deserves equal prominence.
But material uncertainty should remain visible where it changes how confidently a conclusion can be stated.
Commercial relationships do not determine editorial conclusions
STACK may earn revenue through some links or commercial relationships.
That does not determine:
- what companies we investigate;
- which findings we publish;
- how evidence is characterized;
- which product wins a comparison;
- whether a service receives criticism;
- whether a product receives a recommendation.
Commercial relationships and editorial conclusions are separate.
Where relevant, additional information is available in our Affiliate / Commercial Disclosure.
Corrections should be visible
If STACK publishes something materially wrong, we correct it.
If the underlying product changes, we update it where appropriate.
If wording creates a materially misleading impression despite being technically defensible, we may clarify it.
We distinguish between:
- corrections: our published information was wrong;
- updates: reality changed after publication;
- clarifications: the original wording required greater precision.
More information is available in Corrections & Updates.
Editorial independence includes resisting convenient narratives
Research sometimes produces findings that are less dramatic than expected.
- A provider may perform better than criticism surrounding it suggests.
- A highly regarded product may have meaningful weaknesses.
- An ownership story may be complicated rather than suspicious.
- An audit may be useful without proving everything.
- A controversy may matter less to the specific question being investigated than its visibility suggests.
STACK does not start from the assumption that a company deserves praise or criticism. The editorial obligation is to follow the evidence rather than protect a preferred narrative.
Tools do not become evidence
STACK may use software, automation, AI-assisted tools, databases, search systems, and other technologies to support research and editorial work.
Those tools may help us locate, organize, compare, challenge, or process information. They are not treated as evidence merely because they generated or summarized a claim.
The underlying source remains what matters.
Published claims are governed by the same evidence standards regardless of which tools assisted the research process.
We do not disclose proprietary editorial systems
Transparency matters.
So does protecting the integrity of the systems used to produce the work.
STACK publishes the principles necessary for readers to understand how evidence is treated and what standards our work is expected to meet.
We do not publish proprietary details such as:
- internal workflows;
- prompts;
- decision systems;
- evaluation logic;
- automation architecture;
- internal research structures;
- ranking mechanisms;
- unpublished quality-control procedures.
Those implementation details are not required to evaluate the editorial standard of the finished work.
Readers should be able to understand what standard the work is held to without needing access to the machinery behind it.
Our responsibility is the published work
Regardless of which tools, sources, or systems contribute to an investigation, STACK is responsible for what it publishes.
That means the final article should:
- accurately represent its sources;
- preserve material limitations;
- distinguish fact from assertion;
- avoid unsupported certainty;
- correct meaningful errors;
- make commercially relevant relationships clear;
- give the reader a usable decision rather than a manufactured verdict.
The standard is not perfection.
The standard is disciplined, transparent, evidence-led judgment.
Rigorous underneath. Clear on top.