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

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

• Current tier: the bundu.verificationTier sub-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 with verificationType, verificationMethod, tierBefore/tierAfter, and evidence. Read-only for Kweli.

Starting a verification

Representatives do not need a deep link: kweli.mukoko.com/en/verify is the flow’s front door. It offers a venue finder (search the graph by name), the signed-in user’s owned venues and pending claims with status chips, and the tier-ladder explainer. Sibling apps can still deep-link a specific venue — see Cross-app verification.

The claim flow

A representative claims a venue before verification can proceed:

1. The representative submits a claim — POST /api/claims.
2. A pending row is written to entity.representativeClaims (claimantPersonId, entityId, claimedRole, status, evidenceUrl).
3. 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)

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

Signed-in users can vouch for a venue’s operator — this is the evidence base for tier 1 (Community).

• POST /api/vouches writes to engagement.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.

Tip

Sibling apps that need to display or trigger verification should read the cross-app verification how-to — never build a parallel flow.