Venue verification
Verification is how a venue proves who it is. It covers all entity types — schools, NGOs, government offices, media organizations, companies, and parks all go through the same flow, not just hospitality.
The four-tier ladder
Section titled “The four-tier ladder”Each tier maps to a mineral color — this is the nyuchi-verified-badge contract, and every app in the ecosystem renders the badge the same way.
| Tier | Name | Mineral | How it is earned |
|---|---|---|---|
| 1 | Community | Terracotta | Community members vouch for the venue’s operator |
| 2 | Identity (OTP) | Cobalt | The operator verifies contact ownership via OTP |
| 3 | Government | Gold | Checked against an official government registry |
| 4 | Licensed | Tanzanite | Holds a licence from the relevant regulator — a paid legal review |
Tiers 1–3 are free. Tier 4 (Licensed) is a paid service — a legal check of the operator’s licence with the relevant regulator, performed after tier 3 is held.
Where verification state lives
Section titled “Where verification state lives”- Current tier: the
bundu.verificationTiersub-object, carried by place, person, and entity documents. This is the single source of truth — apps read it, they never recompute it. - Audit trail:
entity.verifications— one record per tier change withverificationType,verificationMethod,tierBefore/tierAfter, and evidence. Read-only for Kweli.
Starting a verification
Section titled “Starting a verification”Representatives do not need a deep link: kweli.mukoko.com/en/verify is the flow’s front door. It offers a place finder (search the graph by name), the signed-in user’s owned places and pending claims with status chips, and the tier-ladder explainer. Sibling apps can still deep-link a specific place — see Cross-app verification.
The claim flow
Section titled “The claim flow”A representative claims a venue before verification can proceed:
- The representative submits a claim —
POST /api/claims. - A pending row is written to
entity.representativeClaims(claimantPersonId,entityId,claimedRole,status,evidenceUrl). - An admin decides the claim in the verification console (below).
Approved claims give the claimant a management role on the entity; verification then proceeds up the tier ladder.
The verification console (internal)
Section titled “The verification console (internal)”Kweli is a full KYC platform — individuals and organizations, not just venue claims. The admin console at /dashboard/admin/claims (admin role required) has four tabs:
| Tab | What it shows |
|---|---|
| Queue | Pending ownership claims — claimant, role, evidence link, review sheet with an optional decision note, approve/reject |
| People | Individual KYC over identity.persons — auth-identity and email-verified signals, tier, search + tier filter |
| Entities | Organization KYC over entity.entities — legal name, entity type, tier, Ubuntu trust score |
| Audit | The platform-recorded tier transitions from entity.verifications |
Claim decisions flow through the platform API (/v1/admin/claims/:id/decide) — the console never writes tiers to the graph directly. People/Entities are read-only review surfaces until the platform exposes person- and entity-level decision endpoints.
Community vouches
Section titled “Community vouches”Signed-in users can vouch for a venue’s operator — this is the evidence base for tier 1 (Community).
POST /api/voucheswrites toengagement.vouches.- Each vouch declares a relationship via
vouchingType:
vouchingType |
Meaning |
|---|---|
personal_knowledge |
I personally know the operator |
long_term_customer |
I have been a customer over time |
business_partner |
I do business with them |
community_member |
We are part of the same community |
neighbor |
I am located nearby |
professional_endorsement |
Professional endorsement of their work |
Enough active vouches satisfy the community_attestation verification method toward tier 1.
Owners can also publish a community verification request (POST /api/verification-requests) — a public call for vouches shown on the venue page.