TerraNetTechnologies

Trust center

Software comparison methodology

Our validation flow separates vendor evidence, normalized product facts, automated scrutiny, editorial judgment, and final human approval. A page cannot enter the sitemap until every enforced gate passes.

Last updated August 3, 2026

Validation and publication flow

Each product and editorial draft moves through a recorded, repeatable workflow. Automated agents assist with scrutiny and correction; they do not approve publication.

  1. Collect current official pricing, product, documentation, API, and release-note sources.
  2. Normalize pricing, features, API scope, and source-to-claim mappings into a versioned evidence record with a SHA-256 evidence hash.
  3. Run source-reachability checks and a concise Gemini evidence audit. Bot-protected pages are opened manually rather than treated as false evidence.
  4. A human reviewer separately confirms pricing, features, API scope, and sources before publishing the product evidence.
  5. GLM drafts comparison or alternatives copy using only the verified evidence associated with the current hashes.
  6. A deterministic quality gate blocks leaked prompts, template placeholders, model meta-commentary, formatting artifacts, and repetitive stock openings across the published corpus. Gemini then reviews the draft for factual support, balance, clarity, and formulaic language.
  7. Quality and editorial findings are returned to GLM for up to two correction rounds, followed by a final stored audit.
  8. A human makes the final editorial decision. Approval applies only to that exact draft and its exact evidence hashes.
  9. Only pages with current verified evidence, a non-blocking current agent audit, and human-approved editorial become indexable and enter the sitemap.

Evidence hierarchy

Pricing, plan availability, product capabilities, and API access should be supported by current evidence. We prefer first-party sources for facts controlled by the vendor.

  • •Official pricing pages for prices, free plans, trials, and billing units.
  • •Official product pages and documentation for features, integrations, and APIs.
  • •Official release notes for recent additions, removals, and renamed capabilities.
  • •Independent sources only when they add clearly attributed context rather than replacing vendor facts.

Pricing and feature normalization

Free plans, free trials, subscriptions, usage-based charges, and contact-sales plans are recorded as different states. A missing or zero legacy value is not treated as proof that a product is free.

Features are assigned stable capability keys so similar vendor terminology can be compared without implying that a differently worded feature is absent.

Comparison and ranking

Comparisons focus on documented capabilities, implementation fit, pricing model, control, and likely workflow tradeoffs. Alternative ordering uses direct comparison relationships, category fit, shared capabilities, and pricing model.

Numerical ratings are currently suppressed because the legacy catalog does not contain a documented scoring methodology. Affiliate relationships do not add ranking weight.

Freshness, hashes, and publication gates

Published evidence receives a next-review date 90 days after approval. Source reachability is checked during review and when a correction or freshness concern is raised. Because automated access can be blocked by vendor sites, a failed automated check is a review signal rather than proof that a claim is wrong.

When a product evidence hash changes or expires, dependent editorial no longer matches its evidence. The affected page loses sitemap eligibility until the evidence and editorial are reviewed again. Sitemap entries are derived from current Firestore state rather than maintained as a manual URL list.

Use of AI

GLM helps draft and correct analysis from approved catalog evidence. Gemini acts as a separate skeptical editor for evidence and editorial audits. Both are instructed to ignore instructions embedded in vendor pages and not invent prices, features, testing, benchmarks, quotes, or market claims.

Agent findings are stored beside the affected claim for human review. A clean automated result is not publication approval, and a human reviewer can request further changes after the correction loop.

Audit trail and limitations

Evidence hashes, source check dates, agent models, audit outcomes, correction rounds, reviewer identity, and approval timestamps are retained in the private review history. Public pages show their supporting sources and the most recent product-evidence verification date.

Verification means the stated claim was checked against the cited source at the recorded time. It does not mean TerraNet independently tested every product, guarantees vendor performance, or guarantees that a vendor will not change a page after review.

Questions about these policies? Contact the editorial team.