Appearance
Feature Inventory Review
Document type: Feature Inventory Review
Prepared by: Engineering
Status: Pending sign-off
This is the Kaya Sync feature inventory, a complete list of every capability the platform is intended to have, organised by module. Each feature includes what it does and who uses it.
Open questions requiring a decision are listed at the bottom. These must be resolved before build begins.
M0: Platform Foundation
Core infrastructure that every other module depends on.
| Feature | Who Uses It | What It Does |
|---|---|---|
| Multi-tenancy | System Admin | Each client organisation (tenant) is fully isolated, their data, operators, and policies cannot be seen by other tenants |
| Policy engine | System Admin | Configurable rules per tenant: trust tier requirements, settlement speeds, evidence strictness, corridor restrictions, Fast-Pass eligibility, all changeable without redeployment |
| Role-based access control (RBAC) | All roles | Controls what each user type can see and do. Roles: Operator, Facilitator, Enterprise User, Reviewer/Supervisor, Admin, Regulator |
| Immutable audit log | Supervisors, Regulators | Every meaningful action on the platform is recorded with actor, action, resource, and timestamp. Cannot be edited or deleted |
| Feature flags | System Admin | Turn individual modules (M1–M13) on or off per tenant without code changes |
| Authenticated API | All services | OAuth2 with scopes (read / write / admin). All API calls authenticated |
| Webhook delivery | Client systems | Push notifications to external systems when key events happen (settlement released, dispute opened, etc.) |
M1: Transaction & Container Model
How cargo is represented and tracked from origin to delivery.
| Feature | Who Uses It | What It Does |
|---|---|---|
| Container creation | Originator, Dispatcher | Each physical unit of cargo gets a unique digital container ID. Container carries: designee phone number, current integrity status, fingerprint history |
| Designee phone as physical anchor | All | The receiver's phone number is written physically on the cargo and becomes the immutable identifier throughout the journey. Every scan verifies this number |
| Order management | Originator, Dispatcher | An order groups one or more containers, specifies pickup and delivery, and links to an originator and designee. Containers are assigned to operators via orders |
| Multi-leg movement | Dispatcher, Operators | Cargo moves through multiple legs (first mile → mid mile → last mile). Each leg is tracked separately with its own operators and handoffs |
| Aggregation | Dispatcher, Operators | Multiple containers can be grouped for a shared journey (e.g. loaded onto the same truck). Grouping is recorded for reporting |
| Disaggregation | Dispatcher, Operators | A grouped set of containers can be split mid-journey (e.g. containers unloaded at different destinations). History is preserved |
| Full custody history | Supervisors, Regulators | Every custody event for a container is recorded and reconstructable: who held it, when, where, what the integrity result was |
| Order state machine | All | Orders move through defined states: PENDING → ASSIGNED → IN_TRANSIT → DELIVERED → COMPLETED. Each state change is an audit event |
| Container state machine | All | Containers move through: CREATED → ORIGIN_SCANNED → IN_CUSTODY → HANDOFF_PENDING → TRANSFERRED → DELIVERED → CLOSED |
M1A: Marketplace Transaction Capture
Designed for informal market settings (e.g. produce markets) where cargo is assembled at the point of collection.
| Feature | Who Uses It | What It Does |
|---|---|---|
| Heap capture | Operator, Facilitator | Operator photographs a heap of produce (crop) from multiple angles using the mobile app. AI estimates crop type, volume range, and grade |
| Agreement video | Operator, Facilitator | Short video captures all transaction participants (seller, loader, buyer) with their phone numbers visible. This video is the binding agreement |
| AI crop estimation | System (AI) | AI attempts to estimate quantity and grade of the heap from photos. Treated as planning-grade (not the final trade truth |
| Human override | Operator | If AI estimate is low-confidence, operator can manually enter quantity and grade. Human-confirmed value is used for settlement |
| Link heap to containers | Operator | After capture, the heap is linked to one or more container IDs that will carry the produce downstream |
| Evidence bundle | Supervisors, Regulators | Heap photos + agreement video + OCR-extracted phone numbers are locked into an evidence bundle linked to the order |
M2: Operator Network, Identity & Device Governance
How operators are verified, how devices are bound, and how trust levels are assigned.
| Feature | Who Uses It | What It Does |
|---|---|---|
| Phone number registration | Operator | Operator registers with their mobile number. Verified via OTP |
| Device binding | Operator | A specific device is linked to each operator. Protected actions (scans, handoffs, settlements) can only be performed from the bound device |
| Trust tier system | Operators, System Admin | Three tiers determine what an operator can do, how strict their evidence requirements are, and how fast they get paid. Tier 1 = highest trust, fastest settlement. Tier 3 = lowest trust, strictest evidence |
| Tier requirements | System Admin | Tier 3: OTP + device binding. Tier 2: government ID + device binding + re-auth. Tier 1: Tier 2 + in-person hub verification or trusted referee endorsement |
| Supervisor manual review | Ops Supervisor | Supervisor can review and approve or reject an operator's tier elevation request. Decision is recorded in audit log |
| Trusted referee endorsement | Operators | A Tier 1 operator (with 100+ successful jobs) or a market queen/cooperative leader can vouch for a new operator, enabling tier elevation |
| Market Facilitator role | Facilitator | A facilitator is a trusted local intermediary (market queen, loading foreman, station coordinator) who is linked to multiple operators. They can assist operators with capture, batch submissions, and relabel approvals |
| Facilitator commission | Facilitator, Finance | Each facilitator has a configured commission rate. Facilitator-assisted transactions attribute earnings proportionally |
| Facilitator-assisted onboarding | Facilitator | Facilitator can onboard operators on their behalf, capture is attributed to both facilitator and operator in the audit trail |
| Re-verification workflow | Ops Supervisor | If an operator's trust conditions change (e.g. phone number changes, suspicious activity), re-verification can be triggered. Privileges may be downgraded pending review |
| Duplicate identity detection | System | On onboarding, the system screens for operators reusing the same phone, device, or identity document across multiple accounts |
| Operator status states | All | PENDING_VERIFICATION → ACTIVE → SUSPENDED → DEACTIVATED. Suspension blocks new assignments and settlement |
| Biometric re-auth (planned) | Operator | For high-trust actions (Tier 1 Fast-Pass transfers), biometric re-authentication (selfie liveness) confirms the registered operator is physically present |
M3: Proof-of-Custody & Integrity Engine
How evidence is captured, validated, and used to determine whether a handoff is legitimate.
| Feature | Who Uses It | What It Does |
|---|---|---|
| Origin scan | Operator | Before cargo leaves its origin, operator captures a video showing: the container, the designee's phone number written on it, and the physical condition. Creates the baseline fingerprint |
| Handover scan | Sender Operator | When transferring cargo, the outgoing operator captures a scan showing the container, phone number, and their presence |
| Receive scan | Receiving Operator | The incoming operator captures their own scan of the same container, confirming they have taken custody |
| Delivery scan | Delivering Operator | At the destination, operator captures final evidence. Delivery is only confirmed when the designee provides the correct OTP |
| Designee OTP confirmation | Designee | At delivery, an OTP is sent to the designee's phone number. Operator enters the OTP to confirm the right person received the cargo |
| OCR phone number extraction | System (AI) | System extracts the phone number from the video frame. Compared against the registered designee phone. Low-confidence triggers operator to manually confirm the last 4 digits |
| Container fingerprinting | System | A visual fingerprint is created from the origin scan video. On each subsequent scan, the fingerprint is compared to detect tampering, swaps, or relabelling |
| Integrity assessment | System | After each scan, the system evaluates: fingerprint match, phone number match, geo location validity, time window validity. Returns: PASS / PASS_WITH_TOLERANCE / HOLD / FAIL |
| Reason codes | Supervisors | Every integrity result includes reason codes explaining what passed and what failed (e.g. PHONE_NUMBER_MISMATCH, GEO_ANOMALY, FINGERPRINT_MISMATCH) |
| Confidence score | Supervisors | A 0–1 score representing the proportion of checks that passed. Used alongside the status for supervisor review |
| Dual-scan handoff | Both Operators | A custody transfer requires both a sender scan AND a receiver scan. Both must happen within a time window. Single-scan exceptions can be approved by supervisor |
| Evidence profile escalation | System, Policy | Evidence requirements automatically escalate based on: operator tier, corridor risk, repeated handoffs between same pair, OCR confidence failures, high-value cargo |
| Unreadable phone remediation | Operator, Facilitator, Supervisor | If phone number is unreadable: (1) operator can rewrite at origin, (2) facilitator can field-relabel with dual video, (3) supervisor can override with reason code. Each path generates an immutable event |
| Custody chain reconstruction | Supervisors, Regulators | The complete chain of custody for any container can be reconstructed: origin → every handoff → delivery. All evidence links included |
M4: Integrity-Gated Settlement Rail
How operators get paid, and how payment is controlled by custody verification outcomes.
| Feature | Who Uses It | What It Does |
|---|---|---|
| Settlement eligibility check | System | After each completed delivery, the system evaluates whether the operator qualifies for payout based on the integrity assessment outcome |
| HOLD state | System, Supervisors | If integrity assessment is HOLD or FAIL, payout is withheld. Operator is notified. Supervisor reviews evidence within SLA window |
| RELEASE | Ops Supervisor | Supervisor reviews evidence for a held transaction and approves payout. Transaction moves from HELD → RELEASED → SETTLED |
| REVERSE | Ops Supervisor | Supervisor determines the operator should not be paid. Transaction moves from HELD → REVERSED. No payout issued |
| Dispute | Operator | Operator who disagrees with a hold can raise a dispute. Evidence bundle is locked at the time the dispute is opened. Supervisor adjudicates |
| Fast-Pass lane | Tier 1 Operators | Tier 1 operators on pre-approved corridors with a clean record (no HOLD/FAIL in 30 days, no open disputes) skip the HOLD queue and receive automatic payout within 10 minutes of final delivery |
| Fast-Pass revocation | System | Any escalation event (except minor OCR warnings) removes Fast-Pass status for a minimum of 7 days. Relabel or supervisor override also triggers revocation |
| Fast-Pass reinstatement | Ops Supervisor | After 7 clean days, supervisor reviews and reinstates Fast-Pass status. Operator is notified |
| Payment provider integration | System, Finance | Platform integrates with a payment provider (Paystack) to execute actual payouts to operator mobile money or bank accounts |
| Settlement state machine | System | Transactions move through: PENDING → HELD or FAST_PASS_ELIGIBLE → RELEASED / REVERSED → SETTLED |
| Payout visibility | Operator | Operator can see their payout status, hold reason, estimated release date, and settlement history in the mobile app |
| Liability windowing | System, Supervisors | The period of liability for each operator is clearly bounded: from the moment they take custody (receive scan) to the moment they hand off or deliver (next scan). Disputes reference this window |
M5: Capacity & Utilisation Attestation
How operators declare their vehicle capacity so the platform knows what load they can take.
| Feature | Who Uses It | What It Does |
|---|---|---|
| Start-of-day (SOD) attestation | Operator | At the start of each market day, operator takes 6 guided photos of their vehicle (interior from multiple angles). AI estimates usable capacity range |
| Per-journey attestation | Operator | Lighter-weight version: operator takes a single load photo before each journey (empty / partially full / full). Used for high-frequency operators |
| AI capacity inference | System (AI) | System estimates vehicle capacity from SOD photos. Confidence score attached. Low-confidence triggers manual review |
| Aggregation gating | System | Operators with no valid capacity attestation cannot be assigned aggregated loads |
| Policy configuration | System Admin | SOD attestation is mandatory for Tier 1; per-journey for higher tiers where appropriate. Configurable per corridor and vehicle class |
M6: Real-Time Orchestration Optimiser
How the platform recommends optimal cargo groupings and route assignments.
| Feature | Who Uses It | What It Does |
|---|---|---|
| Operator telemetry ingestion | System | Platform receives real-time GPS location, heading, speed, and remaining vehicle capacity from the mobile app |
| Aggregation candidate identification | System | System identifies operators carrying compatible cargo on overlapping routes who could consolidate their loads |
| Disaggregation candidate identification | System | System identifies loads that should be split (e.g. oversized, different delivery windows) |
| Play scoring | System | Each aggregation or disaggregation opportunity is scored based on vehicle utilisation improvement, carbon impact, corridor compatibility |
| Human approval (early phase) | Dispatcher, Ops Supervisor | In the first phase, all optimisation recommendations require a human to approve before operators are notified |
| Corridor automation policy | System Admin | Later phase: corridor-specific automation policy allows plays below a configurable risk threshold to execute without human approval |
M7: Fraud, Collusion & Trust Automation
How the platform detects and responds to suspicious behaviour.
| Feature | Who Uses It | What It Does |
|---|---|---|
| Replay / duplicate detection | System | Detects when the same video or evidence hash is submitted for multiple scans. Flags for review |
| GPS impossibility detection | System | Detects when an operator's GPS shows a physically impossible journey (e.g. appeared in two cities within 5 minutes) |
| Repeated dyad detection | System | Flags when the same two operators perform handoffs together more than 3 times in a time window, a signal of collusion |
| Relabelling anomaly detection | System | Detects patterns consistent with cargo substitution or label swapping between handoffs |
| Identity reuse detection | System | Flags when the same device, photo, or identity document is used to create or re-register multiple operator accounts |
| Repeated re-onboarding detection | System | Detects operators who repeatedly attempt to re-onboard after rejection, or who use slight variations of already-rejected identities |
| Risk flagging | System | When a fraud signal is detected, a risk flag is raised against the operator. The flag is visible to supervisors and may trigger: evidence escalation, trust tier downgrade, aggregation restriction, Fast-Pass revocation |
| Risk action explainability | Supervisors | Every automated risk action includes the specific signal that triggered it and the evidence referenced. Supervisor can see why the flag was raised |
| Facilitator concentration monitoring | System | Detects when a single facilitator controls an unusually high proportion of operators or transaction volume, a signal of centralised fraud |
M8: Adaptive UX Toolkit
How the app communicates with operators who may have low literacy or limited smartphone experience.
| Feature | Who Uses It | What It Does |
|---|---|---|
| Voice prompts | Operator | App speaks instructions aloud at each step ("Show the phone number on the container", "Tap to confirm"). Tuned for local accents and ambient noise |
| Voice confirmation | Operator | Operator can speak "yes" or a digit to confirm an action instead of tapping. Voice recording is stored as part of the evidence bundle |
| Icon-led UI | Operator | Core workflows use icons, colours, and simple visual cues rather than text instructions. Traffic-light status indicators (green / amber / red) for key states |
| Numeric keypad input | Operator | For critical entries (phone number confirmation, quantity), the app presents a large numeric keypad, no text keyboard required |
| Simple status cues | Operator | Scan states shown as simple labels: Captured → Queued → Uploading → Verified → Eligible / Hold / Fail |
| Facilitator batch flows | Facilitator | Market Facilitator can process multiple operator submissions in sequence without restarting the flow each time |
| Non-voice fallback | Operator | If voice fails (too noisy, microphone issue), all flows have a tap-only fallback. No workflow is blocked by voice failure |
| Onboarding voice guidance | Operator | Identity capture steps (selfie, document photo) are guided by voice with icon-led framing overlays |
M9: Offline Resilience & Market-Day Model
How the platform works when operators have no internet connectivity.
| Feature | Who Uses It | What It Does |
|---|---|---|
| Offline capture | Operator | Operator can perform all capture workflows (photos, video, metadata) without connectivity. Evidence is stored encrypted on-device |
| Encrypted local storage | Operator | All offline evidence is encrypted at rest on the device. Hash of evidence is computed at capture to detect tampering |
| Offline queue | Operator | A local FIFO queue holds all unsynced bundles. Operator sees the queue count at all times |
| Transaction counter | Operator | Prominently displayed count showing: N captured, M queued, K uploading, J verified, X failed |
| Background sync | Operator | When connectivity returns, the app automatically uploads queued bundles in sequence. Interrupted uploads resume where they left off |
| Queue thresholds | System | Per trust tier: warn operator when queue reaches threshold (e.g. 50 for Tier 2), block new assignments when queue exceeds gate threshold (e.g. 80 for Tier 2) |
| Risk escalation on long unsynced | System | If operator has not synced for 12+ hours, risk score escalates. If 24+ hours, settlement eligibility is blocked until sync is complete |
| Deferred validation | System | Server-side integrity assessment only runs after the evidence bundle has been uploaded and validated. Settlement eligibility is not granted offline |
| Fast-Pass pre-signal | System | A Fast-Pass eligible operator may see a pre-signal offline ("Eligible for Fast-Pass") but actual payout execution only happens after sync and server validation |
| Offline onboarding capture | Operator | New operator onboarding can be captured offline (photos, documents). Operator status remains PENDING until server validates the bundle |
M10: Governance, Guardrails & Audit Export
How the platform provides transparency to regulators and external institutions.
| Feature | Who Uses It | What It Does |
|---|---|---|
| Corridor guardrails | System Admin | Configurable per-corridor rules: max handoffs per container, unreadable-anchor remediation policy, evidence profile minimums |
| Guardrail violation visibility | Supervisors, Regulators | When a guardrail is violated (e.g. too many handoffs on a container), it is visible in the audit trail with the specific violation |
| Custody chain export | Regulators, Partners | Full custody timeline for any container can be exported: every event, operator identity, GPS, timestamp, integrity result, evidence links |
| Audit event stream export | Regulators | Structured export of all platform events within a scope (date range, corridor, operator subset). Format: JSON or CSV |
| Compliance metrics export | Regulators, Client Managers | Aggregated metrics: scan upload success rates, integrity outcome distributions, payout hold reasons, dispute outcomes, operator trust tier distribution |
| Machine-readable & human-readable | Regulators, Auditors | Exports available in both structured JSON (for automated processing) and formatted reports (for human review) |
| Evidence-linked audit entries | Regulators | Every audit entry references the specific evidence bundle that supports it. Click-through to view video and scan metadata |
M11: Carbon Impact Ledger
How the platform measures and reports on the environmental impact of transport operations.
| Feature | Who Uses It | What It Does |
|---|---|---|
| Carbon calculation per journey | System | For each completed journey: distance × emission factor per km (by vehicle class) = kgCO₂e |
| Baseline vs. realised comparison | Analysts, Partners | Compares the carbon cost of the actual route taken against a corridor baseline (what the journey would have cost without optimisation) |
| Aggregation carbon credit | System | When aggregation plays reduce vehicle movements, the carbon saving is recorded and attributed to the play |
| Corridor benchmarking | Client Managers, Partners | Carbon efficiency reported per corridor over time: average kgCO₂e per tonne-km, trend, benchmark vs. industry |
| ESG reporting export | Partner Organisations | Climate finance partners and ESG bodies can export structured carbon impact data for reporting purposes |
M12: Enterprise Client Portal
Web-based visibility dashboard for merchants, shippers, and enterprise clients.
| Feature | Who Uses It | What It Does |
|---|---|---|
| Live order tracking | Client Manager, Originator | Real-time visibility into all orders: current status, current operator, GPS location, estimated delivery |
| Exception dashboard | Client Manager | Surface all orders that are currently on HOLD, in dispute, or overdue. Allows quick triage |
| SLA monitoring | Client Manager | Track delivery time performance against agreed SLAs. Flag corridors or operators with consistent SLA breaches |
| Evidence access | Client Manager | View scan videos and integrity assessments for orders within their scope (subject to access policy) |
| Reporting | Client Manager | Aggregate reports: on-time delivery rate, cargo value settled, dispute resolution outcomes, operator performance |
| Webhooks | Client systems | External merchant systems can subscribe to events: order status changes, settlement released, dispute opened |
| API access | Client systems | Clients can create orders, check status, and retrieve custody chains via authenticated REST API |
| RBAC within portal | Client Manager | Client org can have multiple users with different access levels within their own scope |
M13: GovTech Formalisation
How the platform connects to government licensing and tax systems.
| Feature | Who Uses It | What It Does |
|---|---|---|
| Operator licensing visibility | Regulator | Regulator can view which operators have valid transport licences, linked to the platform's verified identity and transaction records |
| Licensing commission workflow | Regulator, Finance | Configurable commission on licensing renewals processed through the platform |
| Transaction-based tax remittance | Regulator, Finance | Structured exports of taxable transactions for government revenue authority. Processing commission tracked per corridor |
| Regulator data portal | Regulator | Dedicated read-only portal scoped to the regulatory agreement. Regulator sees only what their agreement allows |
Cross-Cutting Features (Apply to All Modules)
| Feature | Who Uses It | What It Does |
|---|---|---|
| OTP verification | All mobile users | 6-digit OTP sent via SMS for: operator login, designee delivery confirmation, re-authentication triggers |
| Push notifications | Operators, Dispatchers | Mobile push for: order assigned, hold notification, payout released, dispute updated |
| SMS fallback | All mobile users | For operators without smartphones or when push notifications fail: SMS-based alerts and OTPs |
| USSD fallback | Operators (low-connectivity) | USSD menu for core status checks (queue count, payout status) when data is unavailable |
| API rate limiting | All | Per-tenant and per-operator rate limits prevent abuse and protect platform stability |
| Encryption at rest | All | Evidence videos and sensitive data encrypted at rest (on-device and in cloud storage) |
| Encryption in transit | All | All API calls over TLS. Upload URLs are pre-signed and time-limited |
Open Questions
These are features described in the docs where a key decision is missing:
| Question | Why It Matters |
|---|---|
| How is payout value calculated? | What is the settled_amount? Per-container flat rate? % of cargo value? Negotiated per corridor? No formula exists in any doc |
| What happens if a designee never confirms? | OTP sent, no response. Does the order stay in limbo? Timeout after X hours? Supervisor override? |
| What is the dispute SLA? | How long does a supervisor have to review a held transaction before it auto-releases or escalates? |
| Which corridors are in scope for the Techiman pilot? | Determines geo validation boundaries, corridor guardrails, and Fast-Pass approvals |
| Who sets corridor risk levels? | System Admin? Kaya Sync ops? Auto-detected from historical integrity outcomes? |
| What triggers a trust tier downgrade? | Specific FAIL count? Risk flag? Manual supervisor action? Not specified |