How ChoiceMosaic Evaluates Course and Community Platforms

1. Frame the decision before naming a product

We define the intended buyer, business model, required learning structure, expected member interaction, team roles, integrations, portability needs, and budget basis. A product can fit one condition and fail another; there is no default universal winner.

2. Keep evidence classes visible

VERIFIED FACT Verified fact

A value or capability supported by an identified source and review date.

INFERENCE Inference

A conditional conclusion that names the verified claims used as inputs.

COMMERCIAL PLACEMENT Commercial placement

A paid or affiliate-supported placement, never disguised as editorial evidence.

3. Prefer official sources and record scope

Pricing, plan limits, cancellation, exports, API access, SSO, and other material facts start with current vendor pricing, product, terms, or help documentation. Every record stores its capture time, applicable scope, freshness policy, and a deterministic hash of the recorded extraction. A changed live page does not silently rewrite the record.

Conflicting official sources become OFFICIAL_SOURCE_CONFLICT and require a person or merchant to resolve the material point. The commercially attractive reading is never selected by default.

4. Treat user reports as a bounded, third-party layer

Wave A records only aggregate labels exposed through public search discovery for a named review platform. We do not access or copy the underlying corpus, automate ingestion, or present a third party's summary as direct testing. Unknown population, access method, sampling limits, incentives, plan differences, and time period remain visible.

Duplicate, obsolete, or unverifiable reports are not converted into facts. A reported theme can guide a trial checklist; it cannot override current official documentation or prove that every customer will have the same experience.

5. Normalize plan, user segment, and use case

We compare prices on the same billing basis, name add-ons and transaction fees, and distinguish creator, small-team, professional, and enterprise plan boundaries. A feature available only on a custom enterprise tier is not shown as a base-plan capability.

6. Derive conditional fit without a public score

The Wave A requirements-to-fit matrix maps declared needs—learning, interaction, events, administration, integration, and portability—to current verified claims. It produces course-first, community-first, blended, or none-of-these conclusions. Compensation is not an input, and no opaque numeric product score is published.

7. Separate documentation, solo verification, and experience

A documented capability is labeled as documentation-verified. A logged-in workflow is labeled as a solo test only when its account, plan, steps, inputs, and result are recorded. We do not simulate real customers, claim large-scale operation, or turn general business experience into product-use evidence.

Unverified performance, support, migration completeness, contract terms, and real-world outcomes remain explicit unknowns. AI helps organize records and check consistency; it does not supply missing evidence or approve publication.

8. Fail closed at publication

Each page has a versioned content record and publication audit. Unsupported or stale important claims, missing inference inputs, source conflicts, mismatched crawl settings, unapproved affiliate behavior, or missing editorial approval block indexability. Review candidates may build locally, but remain noindex and outside the sitemap.

9. Publish limitations, corrections, and review dates

Pages show their evidence date and source ledger. Pricing receives the shortest review interval. Material corrections update the claim record, affected conclusion, change log, and publication audit together. Readers can use the public corrections process or contact the editorial address.