Skip to content

System Admin Journey

Role: Platform-level management: tenant onboarding, feature flags, policy configuration, operator onboarding
Org: Kaya Sync
Scope: Platform-wide


Preconditions

  • System Admin account provisioned at platform bootstrap
  • Has access to all configuration, policy, and user management functions

1. Tenant (Client) Onboarding

Step 1.1: Create Client Organisation

  • System Admin creates a new tenant/client on the platform
  • Fields: Organisation name, type (agribusiness, 3PL, FMCG, government, etc.), primary contact, billing tier

Step 1.2: Configure Feature Flags (Module Selection)

Each client gets a tailored set of modules. System Admin activates/deactivates per client:

ModuleNameNotes
M0Platform FoundationAlways included
M1Container ModelCore custody
M1AAI Produce Heap ScanEarly adoption or add-on
M2Operator Network & Device GovernanceCore for payout clients
M3Proof-of-CustodyCore
M4AI-Gated Settlement RailCore for payout clients
M5Start-of-Day CapacityRecommended
M6Real-Time Orchestration OptimiserAdd-on
M7Fraud & Collusion AutomationCore for payout clients
M8Low-Literacy UX ToolkitField operators
M9Offline ResilienceField operators
M10Governance & Audit ExportEnterprise / regulatory
M11Carbon Impact LedgerESG clients
M12Enterprise Portal & IntegrationsEnterprise clients
M13GovTech FormalisationGovernment clients only

Step 1.3: Set Policy Parameters (per client)

System Admin configures the policy engine for the client's corridor and operational context:

ParameterDescription
GEO_PROXIMITY_RADIUS_METRESMax distance for co-located handoffs
HANDOFF_TIME_WINDOW_SECONDSMax time between handover and receive scans
OCR_CONFIDENCE_MINMin OCR confidence for auto-accepting phone number extraction
INTEGRITY_PASS_CONFIDENCE_MINMin confidence for PASS vs PASS_WITH_TOLERANCE
MAX_HANDOFFS_PER_CONTAINERMax custody transfers per container
MIN_OPTIMISATION_SCOREMin score for surfacing aggregation/disaggregation plays
SCAN_RETENTION_DAYSMedia retention before archival

Step 1.4: Create Client Manager Account

  • System Admin creates account for the client's designated manager
  • Assigns to the client organisation
  • Client Manager account activated; login credentials sent via secure channel

2. Operator Onboarding (Supervised)

Step 2.1: Register Operator

  • System Admin (or delegated Onboarding Officer) creates operator profile:
    • fullName, phoneNumber, idType, idNumber, trustTier
  • Status set to PENDING_VERIFICATION
  • Errors: DUPLICATE_OPERATOR, INVALID_ID

Step 2.2: Assign Trust Tier

TierDescription
TIER_1_PAYGKaya Sync-issued PAYG device, highest trust, fastest payout
TIER_2_BYODOperator's own verified device, standard trust
TIER_3_UNVERIFIEDUnverified, restricted privileges, no aggregation

Step 2.3: Operator Activates Account

  • Operator logs in via phone + OTP
  • Binds their device
  • Status moves to ACTIVE

3. Device Management

Step 3.1: Manage Bound Devices

  • View all devices bound to operators on the platform
  • Revoke device binding if device is lost or compromised
  • Block a specific device fingerprint: sets DEVICE_BLOCKED status

Step 3.2: PAYG Device Integration (optional)

  • If MTN Enterprise PAYG device supply is active:
    • Device provisioning hooks managed by System Admin
    • Devices shipped pre-configured with TIER_1_PAYG binding

4. Platform Monitoring & Audit

Step 4.1: View Audit Log

  • All administrative actions are fully traceable
  • System Admin can view: who did what, on which entity, at what time
  • Logs are immutable. Cannot be modified or deleted

Step 4.2: Observability

  • System Admin has access to platform-wide metrics:
    • Scan upload success rates
    • Integrity outcome distributions
    • Payout hold rates and reasons
    • System latency SLA compliance
    • Telemetry volume by corridor

Step 4.3: Security & Compliance

  • PII minimisation enforced: only necessary phone numbers and ID data stored
  • RBAC enforced: each role can only access what their scope permits
  • All access to sensitive data (scans, payouts) is logged

Edge Cases

ScenarioBehaviour
Duplicate operator phone number submittedDUPLICATE_OPERATOR error; Admin reviews and resolves manually
Client requests a module not in their bundleSystem Admin adds module via feature flag update; may trigger billing change
Device reported stolenAdmin immediately revokes device binding; operator must re-bind to a new device
Policy parameter change mid-active ordersChange applies to new scans/transfers only; in-flight operations follow the policy at the time of creation

Kaya Sync Internal Documentation