Skip to content
RemoteRegister Cloud evidence engine
Open navigation

About

Software for the audit, not the pitch.

RemoteRegister exists because the hardest part of a learnership is not the training. It is proving what happened, months later, to someone with the authority to disallow the claim.

Why we built it

The evidence problem is a design problem

A provider can run an excellent programme and still fail an audit on paperwork. The common failure is not fraud; it is fragmentation. Attendance lives in a WhatsApp group, consent lives in a filing cabinet, stipends live in a spreadsheet, and the workplace logbook lives with the employer.

When the auditor asks a cross-cutting question — “show me this learner's attendance, consent, workplace attestation and stipend for March” — someone rebuilds the answer by hand. The rebuilt answer is slower, weaker and impossible to reproduce.

RemoteRegister was designed around that question. One learner record, one audit chain, one evidence pack. Every module writes evidence the next module can rely on, and the public verifier resolves a hash against a sealed ledger instead of trusting the document.

Principles

How we make decisions

Truthful claims

A simulator is labelled. A missing vendor credential is named. A hosting region is stated accurately. Trust is lost faster by one false claim than by ten honest gaps.

Minimum data

Templates instead of images. Payable days instead of full payroll copies. The platform collects what the evidence needs and nothing that merely looks impressive.

One record

No module gets its own copy of the learner. A correction propagates, and the audit entry records who changed what and why.

Offline reality

Training sites lose signal. The design assumes it: device cursors, idempotent batches and receipts that make a retry safe.

South African law first

POPIA, ECTA, SD5, NMW, SARS and SETA rules are specifications, not marketing themes. Where the law changes, the engine changes.

Separate duties

The person who captures, the person who verifies and the person who pays are different roles. The API enforces it.

The product

A platform, not a portal

The web application is the operational product. The marketing site, developer docs, public verification and status surfaces are separate hosts, so a learner or auditor never has to navigate the admin console to check a certificate.

  • Web admin portal for providers and tenants
  • Learner self-service for attendance, stipends and leave
  • Android edge app with USB fingerprint scanner support
  • OAuth-secured REST API and signed webhooks
  • Public verification and status surfaces

What we will not do

The refusal list

  • Claim a certification we have not earned.
  • Present a simulator as a live government or bank connection.
  • Store raw fingerprint images when a template is sufficient.
  • Sell or share learner data for marketing.
  • Promise a migration date before the data has been inspected.
  • Hide a limitation in an appendix.

If that sounds like the supplier you want,

start with the audit question that keeps costing you time.