Information status taxonomy
| Status | Meaning |
|---|---|
| VERIFIED | A specific claim is supported by sufficient reliable evidence. |
| SOURCE-REPORTED | A supplied asset/source states or shows it, but wider identity claims are not independently established. |
| NOT INDEPENDENTLY VERIFIED | Evidence is insufficient for a factual conclusion. |
| NEEDS VERIFICATION | Do not publish the missing field as fact. |
Withdrawal-report methodology
Payment status is tracked separately because it can change quickly. Every report should include an exact app name, date/time, amount/status, evidence type and whether it later resolved. Personal information is redacted before publication.
One negative report remains one report. Multiple independent recent reports can change the community label, and a later successful payment should update the history rather than being ignored.
What we never infer
A shared Yono name does not prove the same developer, backend, APK, wallet, ownership or legal entity. A screenshot can show what was visible, but it does not by itself prove current ownership, safety, payout reliability or legality.
Freshness
Pages show a last-checked date. “Recently checked” does not mean “newly launched”. Unknown versions, release dates, developer names, ratings, bonus figures and payout speeds remain unverified.
Corrections
Send corrections or redacted status evidence to support@yonoduniya.com with the page URL and supporting context.
Evidence ladder: a claim gets stronger only when the evidence gets stronger
YONODUNIYA uses different evidence types for different questions. A search result can establish that a name is being used publicly, but it cannot establish a developer. A supplied screenshot can support what one user saw, but it cannot establish long-term payout reliability. An app package can help with technical identity, but it does not automatically prove who legally operates the service.
| Evidence type | Useful for | Typical public wording |
|---|---|---|
| Search/directory observation | Name discovery and first-observed checks. | Observed online / needs verification. |
| User-supplied app icon or screen | Visual identification of a submitted app experience. | Source-reported. |
| Consistent domain/policy/support identity | Stronger entity matching. | Identity checked, with remaining limits stated. |
| Package/signing information | Technical comparison between Android files. | Technical identity checked for the specific file/build. |
| Redacted receipt / bank confirmation | Supporting a dated withdrawal report. | Recent receipt reported; not a guarantee. |
| Multiple independent recent reports | Current community pattern. | Multiple recent reports / mixed recent reports. |
Minimum data kept for a useful app record
Where practical, the structured app database keeps the app name, slug, category, icon/source status, first-observed date, launch estimate only when justified, identity status, withdrawal status, Android status and a genuine last-checked date. Unknown fields remain empty or marked not independently verified rather than receiving a plausible-looking value.
How a withdrawal label changes
Withdrawal status is event-based. A new received report is appended with a date. A later delay does not erase the earlier receipt, and a later resolution does not erase the delay. This produces a history that can answer a more useful question: what changed and when?
How corrections work
If later evidence shows that an app name, domain relationship, launch estimate or payment report was wrong, the relevant page should be corrected and the reason recorded where the change materially affects users. Freshness dates should reflect a real review, not an automatic daily date change.
When an app gets its own indexable page
A separate page is useful only when it can answer a distinct question with enough unique information—such as identity, status history, Android troubleshooting, login/OTP problems or verified supporting context. Otherwise the app remains in the directory so users are not sent through repetitive pages.
