DIREKT World-Class Product and AI Plan

Status: Authoritative product-modernization direction for VC1–VC8
Programme: DIREKT Visual Completion and AI-Native Product Upgrade
Primary market: Zambia, with architecture suitable for later regional expansion
Primary customer/provider client: Native Android
Companion customer/provider client: Responsive installable web/PWA
Operations client: Privileged responsive web portal
Governing issue: #259
Baseline: Existing backend, data, trust, privacy, security, integration and release controls remain authoritative

1. Product ambition

DIREKT must become a world-class local-services marketplace in which customers can discover suitable providers quickly, understand why a provider should or should not be trusted, make an accountable enquiry, and continue through review or complaint without losing the underlying trust trail.

The final product must combine:

  • marketplace clarity and service-professional quality discipline;
  • transparent, check-specific trust evidence rather than a generic verification badge;
  • fast location-aware discovery and simple conversion;
  • strong provider self-service and business enablement;
  • evidence-led operations and human-accountable decisions;
  • Zambia-appropriate low-bandwidth, mobile-money, locality and communication patterns;
  • AI assistance across discovery, onboarding, operations and support without allowing AI to become the trust, authorization, payment or legal authority.

The target experience is not “a directory with better cards.” It is a trusted local-service operating system.

2. Global benchmark stack

No single global marketplace is a sufficient template. DIREKT uses a composite benchmark.

Urban Company — service marketplace maturity

Benchmark for:

  • service discovery and conversion;
  • strong service-professional experience;
  • quality systems, training and performance feedback;
  • structured fulfilment and operational discipline;
  • polished consumer presentation.

Official Urban Company material describes extensive service-professional enablement, training, quality thresholds, retraining, technology-supported fulfilment and grievance mechanisms. DIREKT should match the maturity and clarity without copying a centrally managed-service model where it conflicts with DIREKT's broader independent-provider marketplace.

Checkatrade — trust and ongoing rechecking

Benchmark for:

  • visible trust proposition;
  • recurring provider checks;
  • qualification and identity validation;
  • verified review confidence;
  • trust-oriented customer language.

Checkatrade currently describes up to 12 checks and continuing rechecks. DIREKT should exceed the generic tick model by showing exactly what was checked, its scope, date/currentness, limitations and expiry where applicable.

Taskrabbit — transaction simplicity

Benchmark for:

  • short customer path from need to provider;
  • readable provider comparison;
  • clear availability/action hierarchy;
  • low-friction enquiry/booking patterns;
  • strong mobile-first task completion.

DIREKT should hide internal identifiers, category keys, workflow stages and implementation concepts from ordinary users.

Thumbtack — AI-guided discovery

Benchmark for:

  • moving beyond keyword search;
  • allowing customers to describe problems naturally;
  • multimodal text/photo/voice project intake;
  • guided recommendations;
  • matching assistance that reduces uncertainty before provider selection.

Thumbtack announced an AI-powered experience in 2026 that guides homeowners from natural-language, photo or voice descriptions toward understanding needs and choosing a professional. DIREKT should adopt the useful interaction pattern while preserving deterministic trust, location and ranking safeguards.

3. DIREKT differentiation

DIREKT must not win by being a cheaper imitation of a foreign marketplace. It must win on a stronger combination of trust, relevance and local usability.

3.1 Proof before persuasion

Every trust claim is check-specific. Public presentation may show, where lawful and applicable:

  • identity confirmed;
  • business record confirmed;
  • qualification/licence current for a defined service scope;
  • premises/location check completed;
  • good-standing or registry-derived state;
  • reviewed date and expiry/currentness;
  • what the check means;
  • what the check does not guarantee.

A single generic Verified badge must never replace this information.

3.2 Privacy by precision

DIREKT distinguishes:

  • private base location;
  • public locality;
  • service area;
  • consented public premises coordinates;
  • field-visit coordinates;
  • evidence capture location.

The UI must reveal only the precision justified by the use case.

3.3 Trust independent of payment

Subscriptions, promotion and payment status must never manufacture verification authority or alter factual trust history.

3.4 Africa-first resilience

The product must remain usable with:

  • intermittent connectivity;
  • lower-cost devices;
  • constrained data plans;
  • manual area selection;
  • providers without formal storefronts;
  • mobile, fixed and hybrid service models;
  • WhatsApp/call handoff after explicit consent;
  • mobile-money commercial flows when separately activated;
  • local registries and evidence processes when legally and technically approved.

3.5 Human-accountable trust operations

Consequential trust decisions remain auditable human or deterministic policy decisions. AI may assist review but may not silently become the authority.

4. Product experience target

Customer promise

A customer should be able to answer five questions quickly:

  1. What service do I need?
  2. Which suitable providers are available in or near my area?
  3. Why should I trust or not trust each provider?
  4. What is the next safe action?
  5. What accountability remains after contact moves to call or external messaging?

Provider promise

A provider should be able to answer:

  1. What must I complete to become discoverable?
  2. What evidence is required and why?
  3. What is blocking publication?
  4. What work opportunities require attention?
  5. How is my trust, reputation and commercial state changing over time?

Operations promise

An authorized operator should be able to answer:

  1. What requires attention now?
  2. What evidence supports the case?
  3. Which policy/checklist applies?
  4. What can I decide, escalate or request?
  5. What audit trail will remain after the action?

5. AI-native product principle

DIREKT is an AI-assisted marketplace, not an AI-authorized marketplace.

AI is a cross-cutting capability used to reduce friction, interpret unstructured input, improve matching, summarize complex information, assist operations, improve accessibility and help users make better decisions.

AI must not replace canonical backend authority, trust policy, human accountability or explicit user consent.

6. AI capability map

6.1 Customer discovery assistant

AI may:

  • accept natural-language service needs;
  • accept optional photos or voice where consented and technically approved;
  • classify probable service/category intent;
  • ask clarifying questions;
  • suggest search terms, categories or adjacent services;
  • explain why a provider appears relevant;
  • summarize public check-specific trust information;
  • translate or simplify public information;
  • help compare shortlisted providers.

AI must not:

  • fabricate providers or credentials;
  • claim a provider is safe, guaranteed or fully verified;
  • use private evidence to persuade customers;
  • rank providers based on protected/sensitive traits;
  • make hidden paid placement appear organic.

6.2 Search and recommendation intelligence

Use a controlled pipeline:

  1. intent understanding;
  2. deterministic candidate eligibility;
  3. semantic/category/location candidate generation;
  4. policy-safe scoring;
  5. re-ranking using approved relevance signals;
  6. explainable public reasons;
  7. explicit sponsored-placement labelling where ever introduced.

Deterministic eligibility and privacy rules run before AI ranking. Payment does not create trust ranking authority.

6.3 Provider onboarding copilot

AI may:

  • explain requirements in plain language;
  • guide category/service selection;
  • identify incomplete form sections;
  • draft provider descriptions from provider-supplied facts;
  • suggest portfolio captions and service descriptions;
  • translate or simplify instructions;
  • assist with acceptable-evidence checklists;
  • summarize why action is required.

Provider must confirm editable AI-generated public copy before publication.

6.4 Evidence preparation assistance

AI/OCR may:

  • extract candidate fields from uploaded evidence;
  • detect unreadable/cropped/low-quality submissions;
  • identify likely document type;
  • identify candidate dates/names/registration numbers for reviewer confirmation;
  • compare submitted fields for inconsistency;
  • flag probable duplication or anomaly for review;
  • redact or mask data for approved internal workflows where technically safe.

AI output is evidence assistance, never evidence truth. Final verification outcomes remain policy-controlled and human-accountable.

6.5 Operations copilot

AI may:

  • summarize case history;
  • summarize evidence metadata and prior decisions;
  • identify missing checklist items;
  • cluster similar cases;
  • prioritize queues using approved risk/SLA rules;
  • draft provider-safe action-required explanations;
  • draft internal notes for reviewer editing;
  • surface conflicting data;
  • summarize complaints and review histories;
  • assist audit search.

AI may never autonomously approve/reject verification, revoke a claim, suspend a provider, decide an appeal, close a serious complaint or authorize a high-risk override.

6.6 Trust, fraud and abuse signals

AI/ML may generate risk signals for:

  • suspicious repeated evidence;
  • unusual account/device patterns;
  • review abuse;
  • coordinated fraud indicators;
  • anomalous enquiry/contact behavior;
  • payment/webhook anomaly signals when payments are active;
  • unsafe or abusive content triage.

Signals must be explainable enough for operations review, rate-limited against false positives, monitored for bias and never treated as automatic guilt.

6.7 Reviews and reputation intelligence

AI may:

  • detect spam/toxicity patterns;
  • summarize themes only after sufficient sample size;
  • separate service-specific feedback;
  • help users write clearer reviews without changing meaning;
  • identify possible policy violations for moderation.

AI summaries must retain review-count context and must not invent sentiment or suppress legitimate negative feedback.

6.8 Support and education assistant

AI may:

  • answer product-use questions from approved documentation;
  • explain trust states, privacy and verification limitations;
  • guide account, enquiry and evidence workflows;
  • provide multilingual/simple-language support;
  • route unresolved cases to humans.

It must not provide legal conclusions, emergency dispatch, financial advice or privileged case disclosure.

6.9 Internal product and operations intelligence

AI may assist authorized staff with:

  • product analytics narratives;
  • search-demand clustering;
  • taxonomy improvement proposals;
  • support-theme summaries;
  • provider activation bottleneck analysis;
  • quality and complaint trend analysis;
  • test generation and regression investigation.

Any change to taxonomy, trust policy, ranking policy or release rules remains reviewed source-controlled work.

7. AI architecture and authority boundaries

All AI capabilities must use the canonical backend/security model.

Android / PWA / Operations
          │
          ▼
Canonical authenticated API / BFF boundaries
          │
          ├── deterministic domain + authorization
          ├── trust / evidence / privacy policy
          ├── search / ranking eligibility
          └── AI orchestration boundary
                 │
                 ├── model-provider adapter
                 ├── prompt/version registry
                 ├── approved retrieval context
                 ├── PII/evidence redaction policy
                 ├── structured output validation
                 ├── safety/abuse controls
                 ├── audit + cost + latency telemetry
                 └── evaluation gates

Rules:

  • clients never send privileged system prompts or model credentials;
  • model providers never become the system of record;
  • private evidence is sent to an AI provider only after explicit approved data-processing/legal/security review for that use case;
  • retrieval is purpose-scoped and least privilege;
  • untrusted retrieved/user content is treated as data, not instructions;
  • structured model outputs are schema-validated before use;
  • tool/function calls are allow-listed and server-authorized;
  • high-impact actions require deterministic checks and human confirmation;
  • model/version changes require regression/evaluation evidence.

8. Responsible AI and security baseline

DIREKT AI work must align with:

  • NIST AI Risk Management Framework and the Generative AI Profile for governance, mapping, measurement and management of AI risk;
  • OWASP GenAI/LLM guidance, especially prompt injection, sensitive information disclosure, improper output handling, excessive agency, vector/embedding weaknesses, misinformation and unbounded consumption;
  • existing DIREKT privacy, authorization, evidence and audit controls;
  • applicable Zambian legal/privacy review before real participant processing.

Every AI feature requires:

  • documented purpose;
  • allowed data classes;
  • prohibited data classes;
  • human decision boundary;
  • failure/fallback behavior;
  • latency/cost budget;
  • model/provider abstraction;
  • evaluation dataset using synthetic or approved data;
  • quality thresholds;
  • safety/security tests;
  • audit/observability;
  • kill switch;
  • user disclosure where AI materially shapes an answer or recommendation.

9. AI UX rules

AI must feel useful, not theatrical.

  • Never show fake “thinking” that hides a deterministic process.
  • Label AI-generated or AI-assisted content where material.
  • Let users edit/confirm generated text before consequential submission.
  • Show source/trust facts separately from AI summaries.
  • Preserve uncertainty; never convert low confidence into certainty.
  • Provide a non-AI/manual path for core marketplace tasks.
  • Do not require a chatbot to use discovery, verification, enquiries or support.
  • Prefer bounded assistants embedded in task flows over a single omnipotent agent.
  • Never allow generated language to weaken legal/trust limitations.

10. Visual design target

The approved Design DNA should combine:

  • Structured Trust: calm proof hierarchy, precise state communication, accessible neutral surfaces;
  • Neighbourhood Marketplace: human local imagery, approachable service categories, clear provider identity;
  • Field Utility: efficient provider/operations density, low-bandwidth resilience, task-oriented layouts.

The final approved direction may be a documented hybrid. No aesthetic is silently selected.

Visual priorities:

  1. world-class typography hierarchy;
  2. professional iconography;
  3. authentic Zambia-relevant imagery and illustration;
  4. beautiful check-specific trust components;
  5. fast navigation and search;
  6. strong provider cards/profile/gallery;
  7. map/list equivalence;
  8. provider work-management clarity;
  9. desktop-grade operations evidence review;
  10. adaptive accessibility, offline and low-bandwidth behavior.

11. VC1–VC8 implementation programme

VC1 — World-class design-system reconciliation

Deliver:

  • final semantic token architecture;
  • typography scale and hierarchy;
  • colour/light/dark roles;
  • spacing, grid, shape and elevation;
  • icon and imagery system;
  • responsive/window-class rules;
  • motion principles;
  • accessibility rules;
  • AI interaction visual patterns;
  • loading/empty/error/offline states;
  • core component inventory across Android, PWA and operations.

Exit: one implementable design foundation with no domain-contract changes.

VC2 — High-fidelity benchmark and owner approval

Create the same representative flagship set in at least three differentiated directions:

  • Customer Discover/Home;
  • AI-assisted service-need entry/search;
  • results map/list;
  • provider profile and trust detail;
  • provider workspace;
  • verification/evidence status;
  • operations queue/case/evidence review.

Show compact/mobile and desktop/adaptive variants, plus critical loading/empty/error/offline states.

Exit: explicit owner approval of A, B, C or a precisely documented hybrid.

VC3 — Approved Design DNA and component foundation

After approval:

  • import/reconcile approved Stitch Design DNA;
  • create canonical token/component mapping;
  • replace primitive glyph navigation/icons;
  • create provider/category/search/trust/map components;
  • create AI assistant/input/explanation/confidence components;
  • create operations queue/case/evidence components;
  • establish visual regression references.

Exit: shared component foundations pass exact-head regression.

VC4 — Customer world-class experience

Implement Android and functional web/PWA together where capabilities correspond:

  • onboarding/account;
  • Discover/Home;
  • natural-language/AI-assisted need entry with manual fallback;
  • categories/search/suggestions/filters;
  • results list/map;
  • provider comparison/profile/trust details;
  • saved providers;
  • enquiry/contact-consent lifecycle;
  • reviews/complaints;
  • notification/help/account surfaces;
  • low-bandwidth/offline/error states.

AI additions are gated behind the AI architecture and evaluation controls; deterministic search remains available.

VC5 — Provider professional workspace

Implement:

  • onboarding/readiness;
  • representative/business details;
  • services/category selection;
  • operating model/service areas/public premises controls;
  • portfolio/public imagery;
  • availability;
  • verification requirements;
  • evidence capture/upload/resume/correction/timeline;
  • enquiries/responses;
  • reviews/reputation;
  • commercial/subscription/invoice states;
  • account/security/support.

AI assists explanation, draft copy, requirement guidance and evidence-quality checks but never self-approves evidence.

VC6 — Operations mission control

Implement desktop-first and adaptive operations experiences:

  • mission-control dashboard;
  • triage queue;
  • case workspace;
  • secure evidence viewer;
  • checklists/reason codes/decision controls;
  • field assignments;
  • provider operations;
  • complaints/incidents/reviews/appeals;
  • expiry/commercial/reconciliation views within active gates;
  • audit/configuration/system health.

AI copilot capabilities may summarize, highlight inconsistency and draft explanations, but all consequential actions remain role-authorized and auditable.

VC7 — AI intelligence layer

Activate AI features in bounded slices only after the underlying manual journey is complete.

Order:

  1. documentation-grounded support assistant;
  2. natural-language discovery intent and query expansion;
  3. explainable provider comparison summaries;
  4. provider onboarding/requirements copilot;
  5. evidence quality/OCR extraction assistance;
  6. operations case summarization and checklist assistance;
  7. review/content moderation assistance;
  8. risk/anomaly signals;
  9. analytics/taxonomy insights.

Each use case receives its own evaluation, privacy/security review, provider/model cost budget and kill switch.

VC8 — World-class product, AI and release-quality gate

A surface is not complete because it is visually attractive or because an AI demo works.

VC8 validates:

  • visual-reference fidelity;
  • end-to-end customer/provider/operations journeys;
  • Android/PWA functional parity where required;
  • accessibility at 200% scaling, keyboard/screen reader/TalkBack and reduced motion;
  • performance and low-bandwidth behavior;
  • offline/retry/recovery;
  • privacy and location precision;
  • trust-language accuracy;
  • no private evidence leakage;
  • exact-head backend/database/OpenAPI/client/security regression;
  • AI accuracy/grounding/fallback;
  • prompt-injection and data-exfiltration resistance;
  • human-approval boundaries;
  • bias/fairness checks appropriate to use case;
  • cost/latency/rate-limit controls;
  • observability and kill-switch verification;
  • synthetic-safe visual evidence.

VC8 does not authorize real pilot or production release. Existing Phase 11 and Phase 12 gates remain separate and authoritative.

12. World-class acceptance scorecard

Before VC1 begins, the visible product is materially behind global leaders even though the backend/trust architecture is comparatively mature.

VC1–VC8 target:

Dimension Target after VC1–VC8
Visual polish and coherence World-class benchmark quality
Customer discovery simplicity Comparable to leading local-service marketplaces
Trust transparency Stronger and more precise than generic verification-badge models
Provider workspace Professional, task-oriented and mobile-resilient
Operations review Desktop-grade evidence and decision workspace
AI usefulness Embedded across high-value tasks with manual fallback
AI safety/accountability Human-authorized consequential decisions and auditable controls
Accessibility First-class across Android/web/operations
Low-bandwidth resilience Core Zambia requirement, not an afterthought
Privacy Purpose-limited and precision-aware by design

13. Product metrics

Customer

  • search/intent success;
  • time to useful result;
  • result-to-profile conversion;
  • profile-to-enquiry conversion;
  • trust-detail engagement;
  • no-result recovery;
  • AI suggestion acceptance/correction rate;
  • user-reported recommendation relevance;
  • complaint/safety rates.

Provider

  • onboarding completion;
  • time to publication-ready state;
  • evidence first-pass quality;
  • action-required recovery;
  • enquiry response time/rate;
  • provider retention;
  • AI draft acceptance/edit rate;
  • support burden.

Operations

  • queue age;
  • review turnaround;
  • correction loops;
  • evidence-view efficiency;
  • decision consistency;
  • AI summary correction rate;
  • false-positive risk-signal rate;
  • appeal/override outcomes;
  • audit completeness.

Platform/AI

  • p50/p95 latency;
  • token/inference cost per successful task;
  • fallback rate;
  • grounded-answer rate;
  • hallucination/material-error rate;
  • prompt-injection test pass rate;
  • unsafe-output rate;
  • data-boundary violations: zero tolerance;
  • model/provider outage recovery.

14. Agent implementation rules

Every implementation agent must:

  1. read this plan after the core repository control documents;
  2. preserve existing backend/domain/security/integration authority;
  3. work against the approved Design DNA, not personal aesthetic preference;
  4. implement the manual/non-AI journey before or alongside AI enhancement;
  5. never let generated code redefine canonical API, trust or authorization rules;
  6. add/update tests and visual evidence for each bounded slice;
  7. use synthetic/public-safe fixtures in committed screenshots and AI evaluation sets;
  8. record AI purpose, data boundary, model/provider, evaluation and fallback for each AI feature;
  9. keep external integrations truthful to CURRENT_INTEGRATION_STATUS.md;
  10. stop before real participant, real evidence, real money or production activation without the existing explicit gates.

15. External references informing this direction

  • Urban Company service-professional enablement and quality model: https://investorrelations.urbancompany.com/announcements-and-highlights/service-professional-enablement
  • Checkatrade ongoing checks: https://www.checkatrade.com/twelve-checks
  • Thumbtack AI-powered guided home-services experience: https://press.thumbtack.com/announcements/thumbtack-introduces-ai-powered-experience-to-reinvent-how-homeowners-care-for-their-homes/
  • NIST AI RMF: https://www.nist.gov/itl/ai-risk-management-framework
  • NIST Generative AI Profile: https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence
  • OWASP GenAI/LLM Top 10: https://genai.owasp.org/llm-top-10/
  • Google Responsible AI guidance: https://developers.google.com/machine-learning/guides/intro-responsible-ai
  • Google recommendation-systems guidance: https://developers.google.com/machine-learning/recommendation

These external products and standards are benchmarks and references only. Repository rules, approved Zambia requirements, user research/pilot evidence and DIREKT trust/privacy principles remain authoritative.