PredAtlas · Methodology

Editorial methodology

Every published profile passes a defined review process designed to keep factual claims traceable, comparable and current.

Effective August 26, 2026Last reviewed August 26, 2026

01

Coverage scope

Phase 1 editorial coverage is limited to products with documented Polymarket support. This includes interfaces, discovery and research tools, wallet analytics, alerts, portfolio products, developer infrastructure and automation.

A product may support additional venues, but its Polymarket workflow must be documented and meaningfully usable. Standalone prediction-market venues, generic forecasting platforms and products without verified Polymarket support remain outside the V1 public tool catalog.

02

Polymarket support levels

Native means the product is built specifically around Polymarket. First-class means Polymarket is a documented, maintained core workflow alongside other venues. Partial means only a narrower feature or subset of the product supports Polymarket.

Unknown support is never published. The label describes product coverage, not quality, safety, endorsement or expected performance.

03

Source hierarchy

We prefer the product’s official website, documentation, pricing page, application interface, developer references and official announcements. Reputable secondary reporting may add context but does not replace a first-party source for a product claim.

Community posts and social media can identify a candidate or a recent change. They are treated as leads unless the account is demonstrably official and the claim is sufficiently specific.

04

Review scope

Every profile starts with a source review: an editor checks the official domain, product description, documented access, Polymarket support, pricing representation and the relevant Polymarket workflow. Documented secondary venue coverage may be retained for context. This does not claim that the product received a security audit or complete performance test.

Access checked is used only when an editor confirms the public application or registration path. Hands-on tested is reserved for products whose core workflow was actually operated. Each scope and date is recorded separately.

05

Structured facts and unknowns

PredAtlas uses consistent fields so readers can compare products without translating marketing language. When a value is not publicly documented, we use an explicit unknown or qualified description instead of guessing.

Descriptions are written in our own words. A product’s self-description may inform the profile, but it is not automatically adopted as an editorial conclusion.

06

Status and access

Availability labels describe what an editor could verify at review time. A live marketing page does not necessarily mean that registration, data access or every feature is available.

Waitlists, invitation requirements, regional limits and account or wallet prerequisites are recorded when material and publicly documented.

07

Entity types, categories and tasks

Entity type distinguishes a market or venue, tool or application, data infrastructure, and forecasting or research product. Market and venue records may be retained for platform taxonomy, but the V1 public catalog is limited to tools and products that add a usable workflow around Polymarket.

Each published profile receives one functional category and may be mapped to multiple user tasks. Use-case pages show primary matches at a high relevance threshold and separate weaker related products. Neither placement nor appearance constitutes a rating, endorsement or estimate of investment performance.

08

Data provenance

For wallet, portfolio, market-data and order-book products, PredAtlas records publicly documented data origin, PnL methodology, fee and reward treatment, open-position treatment, historical-book method and update cadence when evidence is available.

Unknown means the official material did not establish the fact. Provenance summaries link to supporting evidence and are not filled by inference merely to make a profile look complete.

09

Risk-based update cycle and corrections

Execution and automation products are reviewed more frequently than low-risk data products or forecasting communities. Automated health checks can identify unreachable sources or unusual changes, but they do not publish material edits or change the editorial review date on their own.

Readers and product teams can use Suggest an update on any profile or the submission form. Corrections are evaluated against the same source standard as initial publication.

10

Publication gate

Market and venue entities remain unpublished in V1. A tool profile is published only when required identity, description, classification, source and verification fields are complete and at least one checked source establishes its Polymarket support.

Editorial status is separate from source health, so a temporary outage does not silently rewrite a profile. Material methodology revisions are dated on this page.

11

Machine-readable access and citation

PredAtlas publishes a concise discovery map, a full catalog context file and a versioned bilingual JSON catalog. These exports use the same publication gate as the visible HTML profiles and never include unpublished records.

When citing a PredAtlas conclusion, use the canonical profile URL and preserve its review date and limitations. For a provider’s own product claim, cite the first-party evidence URL listed in the profile. Reuse is governed by the Data usage policy.