Public sources can show what a competitor sells, ships, emphasizes, staffs, integrates, and struggles to operate. They rarely prove why. Good competitive intelligence preserves that boundary: observe the source, corroborate the change, state a bounded interpretation, and name the decision that deserves review.
What this guide covers
- which public sources answer which commercial questions;
- what each source can and cannot prove;
- a corroboration ladder for stronger conclusions;
- a signal-to-decision worksheet for small teams.
EXVIV corpus snapshot, August 4, 2026: the public source map contained 1,036 homepage sources, 96 documentation/trust sources, 93 pricing sources, 48 changelogs, 37 jobs sources, and 24 status/other sources. Those totals describe monitored source coverage; they do not imply that every source carries equal strategic weight.
The source is part of the meaning
The same sentence carries different weight depending on where it appears.
A capability on a public pricing page may be commercially available. The same capability on a roadmap is an intention. In a job posting, it may be an investment area. In a status incident, it may be an affected component. In a partner announcement, it may be a distribution relationship rather than mature usage.
Always keep the source type beside the observation.
Pricing and packaging pages
Best for: current public plans, prices, units, limits, entitlements, trial conditions, and sales motion.
Can support: “The public Team plan now includes X” or “The visible unit changed from seats to usage.”
Cannot prove alone: adoption, profitability, customer satisfaction, negotiated enterprise price, or the internal reason for the change.
Fireworks AI's pricing page, for example, is a first-party commercial source. It can support a dated observation about visible products and rates. It does not prove which product is most used or most profitable.
Changelogs and release notes
Best for: launches, general availability, improvements, deprecations, new integrations, and sometimes plan availability.
Can support: “The company says the feature shipped on this date and is available under these stated conditions.”
Cannot prove alone: broad customer adoption, durable differentiation, or quality in production.
Cursor's changelog is useful because it is a dated product record. Review the actual availability and packaging language; a release headline alone may not say who can use the capability.
Documentation
Best for: technical limits, supported models, APIs, migration steps, deprecations, regions, data handling, and edge cases.
Can support: precise implementation and compatibility facts.
Cannot prove alone: how important the capability is to the company's go-to-market strategy.
Documentation often changes before marketing copy catches up. That makes it valuable for discovery and dangerous for overinterpretation. Corroborate material product conclusions with the pricing page, changelog, or announcement.
Homepage and positioning pages
Best for: target audience, primary promise, category claim, proof, and call to action.
Can support: “The public lead message changed from X to Y.”
Cannot prove alone: a complete company pivot, product revenue mix, or buyer response.
Positioning is deliberately edited and often tested. Repeated or cross-page movement is stronger than one short-lived hero variation. Record the exact language, duration, and other pages that changed with it.
Job postings
Best for: roles, locations, seniority, capability language, and sustained hiring clusters.
Can support: “The company advertised these roles during this period.”
Cannot prove alone: headcount growth, approved budget, filled roles, a market entry, or the priority of one team relative to another.
One role is weak evidence. A persistent group of roles, combined with new product and partner sources, can support a stronger investment hypothesis.
Status pages
Best for: disclosed incidents, affected components, timeline, updates, and recovery.
Can support: incident frequency and duration within the observed source record.
Cannot prove alone: comparative reliability across products with different disclosure practices, usage levels, or incident definitions.
Bubble's public status page is operational evidence, but a fair comparison must also account for time window, affected component, severity, and recurrence. Counting every post as an equal outage is misleading.
Trust, security, and policy pages
Best for: certifications, data regions, subprocessors, controls, terms, and public policy commitments.
Can support: a dated statement that a control or certification is publicly claimed.
Cannot prove alone: implementation quality, universal scope, or that every product and region is covered.
Lovable's announcements can document public enterprise and governance claims. A serious evaluation still reads the linked trust material and verifies scope.
Integration and partner pages
Best for: supported connections, ecosystem direction, co-selling, distribution, and implementation paths.
Can support: the existence and stated availability of a relationship or integration.
Cannot prove alone: customer adoption, partner-sourced revenue, technical depth, or strategic exclusivity.
Check both parties' sources. A directory listing is weaker than documented setup instructions and a co-authored launch.
Use a corroboration ladder
Increase confidence through independent source types, not repetition of the same announcement.
| Level | Evidence | Appropriate conclusion |
|---|---|---|
| 1. Observation | one primary page changed | state the exact public change |
| 2. Persistence | change remains across repeat captures | rule out brief experiment or error |
| 3. Cross-source | pricing, docs, changelog, or partner source agrees | support availability or direction |
| 4. Market response | customers, usage, filings, or multiple independent sources | discuss adoption or consequence carefully |
| 5. Outcome | measured effect on your deals, usage, or decisions | update internal strategy |
Several articles repeating one press release do not create independent corroboration. Trace claims back to their origin.
Convert signals into decision packets
Use this worksheet:
## Observation
Source type:
Primary URL:
Observed at:
Before:
After:
## What the source supports
[Narrow factual conclusion]
## Plausible interpretations
1.
2.
3.
## What remains unknown
-
## Corroboration needed
- [source or internal evidence]
## Decision to review
Owner:
Decision:
Due:
Outcome:
That structure prevents a common failure: presenting an attractive explanation as if it were the observed fact.
Match the signal to a real decision
| Signal | Review question | Possible owner |
|---|---|---|
| Price or package | Does our segment comparison or packaging assumption change? | pricing/product marketing |
| Launch/deprecation | Does parity, migration risk, or roadmap priority change? | product |
| Positioning | Is the competitor claiming our buyer or reframing the category? | product marketing |
| Hiring cluster | What product, region, or motion deserves corroboration? | strategy/founder |
| Reliability | Does this affect a live displacement or risk conversation? | engineering/sales |
| Trust/policy | Has an enterprise blocker changed? | security/sales |
| Integration | Does distribution or switching cost change? | partnerships/product |
Browse EXVIV's market map to identify a bounded peer set, use the company directory to inspect source coverage, and use Evidence Compare when a decision requires side-by-side records. The monitoring guide covers the operating loop.
Sources and further reading
Method note
This framework uses public first-party sources and treats intent as an inference unless the company states it directly. Public availability does not make every collection method appropriate: respect access controls, source terms, personal data boundaries, and bounded request rates.