Scope the decision first

Every evaluation must name the intended users, application types, sensitive data, required integrations, deployment boundary, identity provider, operator, recovery expectation, and commercial constraints. A feature that exists but cannot satisfy the stated operating model does not count as decision evidence.

Use six fixed criteria

  1. Identity and action authorization — 20%. Authentication, lifecycle, role enforcement, privileged actions, and data-level boundaries.
  2. Build, review, release, and recovery — 20%. Separation between editing and live use, attributable releases, validation gates, rollback, and data recovery.
  3. Data and execution boundary — 20%. Where code, data, credentials, logs, and runtime state live and who controls them.
  4. Inventory, audit, and operations — 15%. Fleet visibility, ownership, activity history, health, alerts, and disable paths.
  5. Maintainability and exit — 15%. Source access, versioning, portability, dependency ownership, handoff, and retirement.
  6. Commercial fit and evidence freshness — 10%. Plan restrictions, current availability, support model, source date, and unresolved questions.

The weights organize evidence and recommendation reasoning. Pageka does not publish an aggregate score until the same behaviors have been tested comparably. A documented claim and a reproduced result are not interchangeable points.

Label every material finding

  • Documented: supported by current first-party documentation, contractual material, or an inspectable repository.
  • Reproduced: Pageka performed a dated test and retained its setup, expected result, actual result, and evidence.
  • Vendor statement: present only in vendor-authored sales or marketing material.
  • Editorial judgment: Pageka's interpretation of visible facts, with the reasoning stated.
  • Unverified: evidence was unavailable, ambiguous, plan-dependent, or not tested.

“Unverified” is not the same as “unsupported by the product.” It means the current evaluation cannot responsibly claim the behavior.

Run the comparison in a fixed order

  1. Freeze the decision scope, criteria, weights, candidates, and source cutoff.
  2. Collect primary documentation and record URLs plus access dates.
  3. Normalize terms so every row uses the same definition.
  4. Run the same test where access and a reproducible environment exist.
  5. Give each vendor an opportunity to correct a material factual error.
  6. Publish findings, interpretation, limitations, ownership, and update date separately.

Apply hard stops before preference

A candidate cannot be recommended for the stated use when it fails a non-negotiable identity, authorization, data-boundary, release, recovery, or ownership requirement. A strong result elsewhere does not average away a critical mismatch.

The security criteria draw on the OWASP Application Security Verification Standard. The lifecycle and evidence expectations use the NIST Secure Software Development Framework as reference frameworks, not certifications.

Corrections and updates

Material corrections should identify what changed, why it changed, and whether the conclusion changed. Source or product changes require a new reviewed date. Send a correction with supporting evidence to [email protected].