01
Entity resolution
Each page represents one defined entity. Canonical names, aliases, entity type and stable identifiers are stored separately from prose. Similar names are not treated as proof that two records describe the same entity.
02
Source hierarchy
Sources are evaluated for what they can establish. Official and government sources are preferred for legal identity and first-party product details. Structured public data and independent sources provide corroboration and context. Discovery sources can lead to evidence but are not automatically treated as evidence themselves.
03
Claim extraction
Claims are stored as property–value statements with status, volatility and verification dates. Evidence is attached to the claim, not merely listed near the page. Visible source markers lead to the exact source record used.
04
Conflict handling
Conflicting sources are retained and marked as conflicting. GroundingWiki does not silently choose the most convenient value. The page should state the discrepancy, its dates and the basis for any editorial conclusion.
05
Review cycles
Review frequency follows volatility. Legal names and founding dates usually change slowly; pricing and product capabilities can change quickly. Last-reviewed dates report evidence checks, not a guarantee that nothing changed afterward.
06
Corrections
Corrections should identify the entity, the exact claim, a reason and a source. Accepted changes create a revision trail instead of overwriting history without explanation.
07
Commercial independence
Payment does not determine claim status, category membership or editorial conclusions. Commercial relationships, if introduced later, must be disclosed and kept separate from evidence assessment.
08
Structured data
Public pages use established Schema.org types only. Machine-readable fields must match visible content. Structured data is a representation of the page, not a place to add facts that readers cannot inspect.