Document control

Revision history

Approvals

Contents

1. Executive summary
2. Background and problem
3. Objectives and success measures
4. Scope
5. Stakeholders and users
6. Solution overview
7. Functional requirements
8. Non-functional requirements
9. System architecture
10. Hardware
11. Data model
12. Security, privacy and compliance
13. Integrations
14. Implementation plan
15. Team and governance
16. Commercials
17. Risks
18. Assumptions and dependencies
19. Open decisions
20. Appendices

1. Executive summary

Almost every institutional building in Uganda — regulators such as UCC and CAA, banks, telcos, government offices and multi-tenant commercial blocks — controls visitors with a paper "blue book". The visitor surrenders an ID, writes their name, date, host, reason and times in a book, and receives a reusable visitor card. Some buildings keep one book per tenant; some require the same details in up to three books.

The book gives the appearance of control without the substance. Entries are unverified and often illegible, IDs are held at a desk where they can be lost or copied, and the books are rarely if ever consulted. When an alarm sounds, nobody can say which visitors are still inside.

Code::Core proposes a visitor management system (VMS) built in Uganda for Ugandan conditions. A kiosk at the gate or reception reads the visitor's National ID or passport once, decodes and checks the NIN, runs the organisation's own entry procedure (induction video, safety test, NDA, speaking with the host), notifies the host by SMS, WhatsApp or intercom, prints a time-limited badge, releases the turnstile and records everything for reporting and audit.

The platform is built on Django with an offline-first edge agent on each kiosk, so check-in continues through power and internet outages. It is configurable per organisation and supports many tenants behind one entrance.

The proposal is led by an engineer who has previously built and operated a comparable system in a data centre environment.

2. Background and problem

2.1 Current process

1. Visitor arrives at the gate; guard requests an ID.
2. Visitor writes name, date, person to visit, reason and time in in the blue book.
3. ID is retained; a numbered visitor card is issued.
4. In multi-tenant buildings, steps 2–3 may repeat at the lobby and again at the tenant's own reception.
5. On exit, the visitor writes the time out (often skipped) and swaps the card for the ID.

2.2 Problems

3. Objectives and success measures

4. Scope

4.1 In scope

• Visitor self-service kiosk application (gate and reception variants).
• Reception / security dashboard with live occupancy and evacuation roll call.
• Organisation admin console: hosts, tenants, visitor types, workflow builder, devices, reports.
• Host notification and approval by SMS, WhatsApp and SIP intercom.
• Pre-registration and QR invites sent by hosts.
• Badge printing (PVC card or sticker) and time-limited access credentials.
• Integration with turnstiles and door controllers via relay, Wiegand or OSDP.
• Multi-tenant operation: many organisations behind one entrance.
• Reporting, audit logs and data exports.
• Supply, installation, training and support for the hardware in each package.

4.2 Out of scope (phase 1)

• Live verification against the NIRA register (planned as phase 2, subject to an agreement with NIRA).
• Staff time and attendance.
• Vehicle number-plate recognition.
• Civil works for new turnstiles or gates (coordinated with the client's contractor).
• Replacement of an existing access-control system; the VMS integrates with it.

5. Stakeholders and users

6. Solution overview

The VMS has three parts: a cloud platform (Django) that holds configuration, records and reports; a kiosk at each entrance running a local edge agent that drives the hardware and keeps working offline; and communications channels that reach hosts wherever they are.

6.1 Visitor journey (example: regulator, meeting visitor)

6.2 Configurable steps

Each organisation assembles its own workflow per visitor type from: ID scan, live photo, host lookup, induction video, safety test, NDA / e-signature, speak with host, host approval, badge print, turnstile release and check-out. A contractor flow can require induction and a test; a delivery flow may need only an ID scan and a sticker badge.

7. Functional requirements

Priority: M must have for go-live, S should have, C could have (later phase).

8. Non-functional requirements

9. System architecture

The system is split between a central platform and a hardened edge at each entrance. The edge is the source of truth during an outage; the platform is the source of truth for configuration and history.

9.1 Key flows

• Online check-in: kiosk → edge agent → platform API; notification jobs queued in Celery; dashboard updated over WebSocket.
• Offline check-in: edge agent validates against local data, prints the badge and pushes the credential to the local controller; host reached through local SIP; events queued and replayed in order on reconnect.
• Evacuation: fire-panel contact on the edge agent triggers a local roll-call print and SMS to marshals, independent of the cloud.

10. Hardware

Two kiosk tiers run the same software. Models are suggestions to be confirmed with Kampala suppliers for availability, warranty and local support. Prices are planning estimates in UGX, excluding VAT.

11. Data model

12. Security, privacy and compliance

12.1 Data Protection and Privacy Act, 2019

• Code::Core and each client register with the Personal Data Protection Office as required; roles of data controller (client) and processor (Code::Core) defined in a data processing agreement.
• Consent notice shown and recorded at every check-in, stating purpose, retention and contact.
• Data minimisation: identifiers stored hashed; full document image stored only where the organisation's policy requires it.
• Retention configurable per organisation (default 90 days for visit records, 30 days for photos), with automatic purge and legal-hold override.
• Subject access, correction and erasure requests handled through the admin console and logged.
• Personal data hosted in Uganda by default; any cross-border transfer documented and agreed with the client.

12.2 Security controls

13. Integrations

14. Implementation plan

14.1 Product build

14.2 Per-site rollout (Reception package, ~8 weeks)

15. Team and governance

A steering meeting with each client is held fortnightly during rollout and monthly during support. Changes to scope follow a written change request with impact on cost and timeline.

16. Commercials

16.1 Sizing method

Sites are sized for the morning peak, not the daily average. The peak hour is taken as about 25% of daily visitors. One kiosk clears about 30 check-ins an hour (around 2 minutes for a first visit, 30 seconds for returning or pre-invited visitors).

Example: 100 visitors a day → 25 at peak → 1 kiosk, plus a reception tablet as backup and for walk-ups.

16.2 Packages (one-off, UGX, including 18% VAT)

16.3 Reception package breakdown (UGX 115M)

16.4 Terms

• Payment: 50% on signing, 40% on installation, 10% on go-live acceptance.
• Where the client is a designated withholding agent, 6% withholding tax is deducted at payment and credited to Code::Core with URA; the package price does not change.
• Support renewal after the included period: 15% of the ex-VAT package price per year, plus VAT. Covers software updates, remote support, next-business-day on-site response in Kampala, and messaging up to the package's visitor volume.
• Consumables (blank cards, ribbons, labels) supplied at cost after the first year.
• Final quote follows a site survey. Tax treatment to be confirmed with a tax adviser before quoting.

17. Risks

L / I = likelihood / impact: H high, M medium, L low.

18. Assumptions and dependencies

• Client provides a powered, networked location at each entrance and access for cabling.
• Client provides an up-to-date host list and a named project owner.
• Where turnstiles exist, they accept a relay, Wiegand or OSDP input.
• Uganda National IDs in circulation carry a readable MRZ.
• Messaging costs are based on current aggregator and WhatsApp rates; large rate changes may be passed through.
• Prices assume current UGX/USD exchange rates for imported hardware; quotes are valid for 30 days.

19. Open decisions

Appendix A — Uganda NIN format

The National Identification Number issued by NIRA has 14 characters, letters and digits, with no spaces.

The system uses these rules to check that a NIN is well formed and that its sex and birth year agree with the document. This is a consistency check, not proof of identity; NIRA has not published a check digit, and confirming that a NIN belongs to the holder requires a lookup with NIRA.

Appendix B — Proposed screens

Visual mock-ups are in the Project Hub, Screens tab.

Appendix C — Glossary