1. Introduction: the operating reality
Three facts shape record-keeping for multi-campus school groups in Nigeria and much of anglophone Africa. First, connectivity is intermittent: campus networks and inter-campus links fail routinely, and any system that requires a live connection to function stops working precisely when the school is busiest. Second, records are long-lived and contested: a result sheet or a fee receipt may be challenged years after it was written, by a parent, an examination body, or a court, and the institution's credibility rests on being able to show the record was not altered. Third, the institution — not a vendor — must own the data: schools that entrusted records to remote cloud platforms have experienced outages on results day, unreachable support, and, in the worst cases, effective loss of their own records when a vendor relationship ended.
Indelo was designed against these facts, and validated against the requirements of a multi-campus Nigerian school group operating ten campuses. The design question it answers is precise: how can roughly fifty teacher laptops per campus, a campus server, and a distant head office maintain one trustworthy body of records when the network between them cannot be relied upon — and how can anyone later prove that no link in that chain quietly rewrote history?
In plain terms. Most school software assumes the internet is always there and asks you to trust the vendor. Indelo
assumes the internet is often absent and is built so that trust can be checked, not assumed: every campus can prove its records were never quietly changed — even to head office, even years later.
2. Design principles
Nine principles govern every mechanism described below. (1) Offline-first is primary: every workflow completes
with zero connectivity; moving data by USB drive or local file share is the designed transport, and networks are an
optimization. (2) The institution owns the data: records live on school-owned machines; nothing readable passes
through third parties. (3) Tamper-evidence survives distribution: integrity proofs remain checkable after data
crosses machines. (4) One writer per logical row: authorship rules make write conflicts structurally impossible
instead of algorithmically resolved. (5) The receiving tier is the serialization point: apply order at the receiver is
authoritative, so nothing depends on the accuracy of a laptop's clock. (6) Synchronized data passes the same
guards as local data: sync cannot bypass business rules. (7) State is derived, not stored: balances, placements
and statuses are computed from history, so they cannot drift from it. (8) Soft deletion only propagates between
tiers. (9) Version discipline: data never crosses schema versions; machines converge on the application version
first.
3. System architecture
Indelo is a three-tier system with one synchronization mechanism applied at two scales. Teacher spokes are
Windows laptops running the full application in a restricted “spoke mode” against a fully encrypted local database
(SQLite with SQLCipher, AES-256 at rest). Each spoke holds a term-scoped working set — only the classes and
subjects assigned to that teacher — not a replica. The campus hub is the licensed authority for its campus, running Microsoft SQL Server, where registrars, bursars and administrators work and where results are locked. The head office (HQ) is a SQL Server consolidation point to which each campus hub relates exactly as a teacher laptop relates to its hub: the campus is HQ's spoke, with the whole campus as its scope. One mechanism, two tiers, ldiffering only in the scope filter.
In plain terms. A teacher's laptop carries only that teacher's classes, fully encrypted. The campus office computer is the authority for the campus. Head office receives every campus's records the same way the campus receives each teacher's — so the whole group runs on one, well-tested pipeline rather than several fragile ones.
4. Synchronization methodology
4.1 Authorship: conflicts designed out, not resolved
Multi-writer synchronization systems ordinarily invest heavily in conflict resolution [5]. Indelo removes the problem at its source. Every table declares exactly one authoring tier — master data (students, staff, structure, calendars, fee schedules) is hub-authored and flows downward as read-only reference; transactional records (marks, attendance, remarks) are spoke-authored and flow upward; locks and group policy are hub- and HQ-authored respectively.
Crucially, spoke authorship is assignment-scoped: a laptop is provisioned with precisely the class-subject pairs of
its teacher's official teaching assignment, and the platform's uniqueness invariants (one teacher per class-subject
per term; one form teacher per class per term) guarantee those scopes are disjoint across all fifty laptops. Two
spokes therefore can never author the same logical row, and the records themselves carry natural keys (student,
subject, term, component), so replaying an entry at the destination is a well-defined merge with no ambiguity to
resolve. Residual ordering questions (e.g., an office correction and a late teacher entry) resolve by principle 5:
application order at the hub is authoritative, and every superseded version survives in the journal and audit history.
In plain terms. Instead of asking “what happens when two people edit the same mark?”, Indelo arranges school reality so that two laptops never legitimately hold the same mark: each teacher carries only their own classes, as officially assigned.
No mysterious merge rules; nothing to argue about later.
4.2 Change capture: a journaled outbox in the same transaction
Every repository write to a synchronized table appends a canonical serialization of the row to a local sync journal
inside the same database transaction as the write itself — if the write rolls back, no journal entry survives, so the
journal cannot lie about what happened. Journal entries carry a per-origin, gapless sequence number. Serialization
is canonical (fixed field order, invariant culture, fixed decimal notation), which matters because the bytes are later
covered by cryptographic verification.
4.3 The package: chained, signed, and verified on exact bytes
Journal entries travel in packages: single files with a line-oriented layout (UTF-8 without byte-order mark, LF
separators) comprising a header, the journal entries, and a trailer bearing an HMAC-SHA256 [1] over the exact raw bytes preceding it. Verification therefore never re-serializes data — the importer hashes what it received and
compares; there is no canonicalization step at verify time and hence no canonicalization bug at verify time. Each
package additionally records the hash of its predecessor to the same peer, forming a per-peer hash chain: a
missing, duplicated, reordered or substituted package breaks the chain arithmetic and is refused by name. Headers carry the schema migration level (principle 9) and a frozen format identifier; readers tolerate unknown header fields within a version but refuse unknown format versions outright. The transport is deliberately file-first: a package is equally valid on a USB drive, a LAN share, or a VPN transfer, and its guarantees come from the file, not the channel.
In plain terms. Think of each batch of updates as a numbered, wax-sealed envelope that also names the seal of the envelope before it. A broken seal, a missing number, or a swapped envelope is detected immediately — whether the envelope travelled by flash drive or by network makes no difference.
4.4 Import: idempotent and interruption-safe
The importer is a strict state machine: verify (HMAC and chain arithmetic; duplicates are a clean no-op; gaps and
tampering are refusals with copyable diagnostics, and nothing is applied), version-gate, then apply — each entry in its own transaction, routed through the ordinary repositories with a per-peer watermark advanced in the same
transaction as each entry. Because entries are natural-key upserts and the watermark records exactly how far
application progressed, a power failure mid-import is harmless: re-importing the same file skips what was applied
and continues from the interruption, and the final state is byte-identical to an uninterrupted run. Re-inserting the
same USB drive twice changes nothing. These are not aspirations; they are named, executable tests (§6).
In plain terms. If NEPA takes the light in the middle of a sync, nothing is lost and nothing is doubled: plug the same flash drive in again and the system continues exactly where it stopped.
4.5 Guard parity, quarantine, and the notification loop
Imported entries pass through the same repositories — and therefore the same business guards — as locally
entered data (principle 6). The canonical case: once a term's results are locked at the hub, a late mark arriving from a laptop is rejected by the same guard, with the same message, as a local edit would be. Rejections do not fail the package; they are quarantined with the guard's reason for administrator review, the watermark advances (so re-imports do not duplicate the quarantine), and a notice is authored for the originating teacher. The notice is itself ordinary synchronized data: it rides down in the next package, is displayed on the teacher's laptop, and the teacher's acknowledgment journals back up — so “was the teacher told, and when?” has a provable, on-the-record answer.
Infrastructure failures, by contrast, abort the package cleanly at the watermark and resume later; the classification
between the two is explicit in the code.
4.6 Consolidation at head office
HQ receives each campus's stream and warehouses it in per-campus, composite-keyed storage: every row is keyed by (origin, source key), so ten campuses whose internal identifiers collide coexist without renumbering. The design rejected the conventional alternative — remapping identifiers on arrival — for a security reason rather than a convenience: Indelo's integrity signatures cover source keys, so remapping would rewrite the very values under the signatures and destroy the ability to re-verify a campus's history at HQ. Preserving source keys verbatim means the same verification code that runs at a campus runs unchanged over that campus's slice at head office. Chained histories (§5.2) are warehoused append-only and are never merged into HQ's own chains — each origin's history remains its own, permanently attributable.
5. Security methodology
5.1 Encryption at rest and key custody
Every teacher laptop's database is encrypted in full with SQLCipher (AES-256) [3]; a stolen or lost laptop exposes
nothing readable. Keys are held per machine in a keystore protected by the Windows Data Protection API at
machine scope [4] — keys never exist in configuration files or code. Every installation completes a mandatory
recovery ceremony before first use: key material is exported into a recovery bundle protected by a high-entropy
code (PBKDF2, 600,000 iterations [2]; AES-CBC with encrypt-then-MAC composition, and MAC-verified before any decryption is attempted), so the death of a machine is a restore, not a data loss. Escrow follows the organizational hierarchy: each laptop's bundle is escrowed at its campus hub; each campus's bundle is warehoused at head office.
Commissioning a laptop is itself a designed ceremony. At enrollment the hub generates the spoke's keys (a random database passphrase — deliberately not derived from the hub's key, so one compromise cannot cascade — plus a per-spoke signing key) and retains them under machine-scope protection. Provisioning produces two artifacts for the USB drive: the encrypted, teacher-scoped genesis database, and a transport bundle wrapping the keys under a one-time setup code that travels out of band on paper. The bundle's authenticated label carries a 14-day expiry; adoption on the laptop verifies the code, checks identity and expiry, installs the keys into the laptop's own protected keystore exactly once (a second use is refused), and binds the machine's fingerprint, which is reported upward in the spoke's first package — a cloned bundle on a second machine surfaces as a fingerprint conflict the hub refuses and flags. A lost USB drive containing both files but no code exposes nothing.
In plain terms. Teacher laptops are safes, not filing cabinets: losing one loses hardware, not records. Setting one up requires a one-time code handed over in person — a lost flash drive is useless to whoever finds it, and a copied one betrays itself.
5.2 Hash-chained histories: results and money under the same discipline
Two categories of record receive an append-only, HMAC-chained treatment in which every entry's signature covers its content and the previous entry's signature. The audit log chains every consequential action per origin. The financial cashbook applies the same construction to money: the ledger's only operations are append and reverse — update and delete do not exist in its programming interface, so corrections are visible reversing entries, never erasures, which is simultaneously orthodox bookkeeping and cryptographic tamper-evidence. Receipt numbers are covered by the signatures, so the number on the parent's paper must match the chained record forever. Verification walks each chain and recomputes every link with a single shared implementation (one code path for writer and verifier, so the two cannot drift); a broken chain places the installation in a read-only investigable state in which nothing further can be written but everything can be examined.
5.3 Frozen results: the snapshot discipline
When a term's results are locked, the system computes, ranks, and freezes each student's complete result as a
self-contained, signed snapshot carrying its own schema version. Report cards render from the frozen snapshot,
never from live tables, and the renderer verifies before it prints — a tampered snapshot yields a refusal, not a card.
Presentation is configurable per campus (section order, optional blocks, per-subject attendance display) and is
proven ordering-invariant: reconfiguring a card's layout changes not one byte of the frozen record. Unlocking for
correction is a deliberate, audited ceremony, and the schema version mechanism has already carried one evolution (per-subject lesson attendance) with old snapshots rendering exactly as issued.
5.4 Group-wide verification: the head-office proof
Because campus bundles are warehoused at HQ and source keys are preserved (§4.6), head office can recover a campus's verification keys and re-run the full integrity verification over that campus's audit chain, result snapshots, and financial ledger — detecting an altered record at any campus without visiting it, and isolating the finding: a tampered campus is flagged by name while its siblings verify clean. A verification board presents, per campus, the last verification time and a VALID / TAMPERED verdict with the failing chain named. This converts tamper-evidence from a per-machine property into an institutional capability of the group.
In plain terms. From head office, the proprietor can press one button and mathematically confirm that no campus has rewritten a result, erased a receipt, or doctored its books — and if one has, see exactly which campus and which record, while every other campus stands clean.
6. Threat model and evaluation
The design maintains an explicit threat table, and the project's rule is that every row must cite the named, executable test that proves the system's response. A representative subset:
Threat / failure Designed outcome (each a named test)
Package altered in transit Signature verification fails; refused; nothing applied.
Threat / failure Designed outcome (each a named test)
Package withheld, duplicated, or reordered Per-peer chain arithmetic detects; duplicates are clean no-ops; gaps refused naming expected-vs-received.
Power failure mid-import Per-entry watermark; re-import resumes; final state identical to an uninterrupted run.
Late entry into a locked term Same guard as local entry; quarantined with reason; teacher notified on the record.
Lost or stolen teacher laptop Full-database encryption; enrollment revoked at hub; subsequent packages refused;
exposure bounded to un-synced entries and visible via watermark.
Cloned setup bundle on a second machine Fingerprint conflict on first package; refused and flagged for investigation.
Rogue laptop fabricating data Can write only its provisioned scope under its own key; every entry attributable to
origin and user.
Campus attempts to rewrite history HQ re-verification over escrowed keys detects the alteration and names the campus and chain; siblings verify clean.
Inaccurate laptop clock Irrelevant by design: receiver order is authoritative; timestamps are advisory.
Schema version mismatch between machines
Version gate refuses with instruction to update; data never crosses versions.
The evaluation discipline is continuous rather than terminal. The platform's cumulative verification suite —
approximately 1,200 checks across 64 suites at the time of writing — runs on two database engines
(SQLite/SQLCipher and Microsoft SQL Server) so that engine-specific behaviour cannot hide defects, and includes an end-to-end fixture that stands up head office, a campus hub, and two teacher spokes with disjoint assignments and drives a complete term — enrollment, provisioning, offline work, upward sync, locking, downward lock propagation, acknowledgment, revocation — asserting the threat table row by row in that composed world. A deterministic seeding utility generates a realistic campus (twelve class arms, ~480 students, full assignment coverage, partially completed terms) for human acceptance walks, and a parameterized stress profile scales the fixture into the thousands of students for volume behaviour. Human acceptance testing on physically separate machines — moving packages by USB drive and by LAN share — is part of the release gate, and has already contributed design corrections that no automated harness could surface.
7. Honest limitations
Precision about what the methodology does not claim is part of its trustworthiness.
(1) Tamper-evidence proves a record was not altered after entry; it cannot prove the entry matched reality — a bursar who records less than was received is a procedural problem, addressed by printed chained receipts in the parent's hands and head-office reconciliation, not by cryptography.
(2) Offline setup codes cannot be remotely revoked, only expired (14 days), physically controlled, and — if cloned — detected by fingerprint conflict; cryptographic revocation requires re-enrollment. (3) Machine-scope key protection trusts the physical machine's administrator; the design accepts this boundary explicitly and mitigates it with escrow and verification rather than pretending it away. (4) Verification detects rewriting; it does not prevent a campus from withholding data, which surfaces instead as visible staleness on the head-office board. (5) The head-office verification of campus chains currently relies on escrowed symmetric keys under head-office custody; an asymmetric-signature evolution, for which the verification interfaces are already in place, would remove even that custody requirement.
8. Relation to other approaches
Cloud-first school platforms centralize trust and availability in a vendor; they serve well where connectivity is
dependable and vendor longevity is assumed, and poorly otherwise. Generic optimistic-replication and “local-first”
systems [5][6] solve multi-writer convergence in the general case, at the cost of conflict-resolution machinery and
without domain-specific integrity guarantees. Indelo's contribution is the combination: it narrows the synchronization problem using the school domain's own authority structure (assignments, locks, tiers) until conflicts vanish by construction, and spends the saved complexity on end-to-end, distribution-surviving tamper-evidence — the property school records actually require and general-purpose synchronization does not provide.
9. Conclusion
A school group's records can be simultaneously offline-capable, institutionally owned, and cryptographically
accountable. The methodology described here achieves this by letting the school's real authority structure shape the synchronization design, by treating every integrity claim as a testable, named behaviour rather than a brochure sentence, and by stating its residual limits plainly. For proprietors, the practical consequence is a group whose results and books remain verifiable from head office across any number of campuses, on infrastructure the school already owns, under connectivity as it actually is — with the proof always one verification away.
References
[1] H. Krawczyk, M. Bellare, R. Canetti. HMAC: Keyed-Hashing for Message Authentication. IETF RFC 2104, 1997.
[2] K. Moriarty, B. Kaliski, A. Rusch. PKCS #5: Password-Based Cryptography Specification v2.1 (PBKDF2). IETF RFC 8018, 2017.
[3] Zetetic LLC. SQLCipher: Design and Security. Technical documentation.
[4] Microsoft Corporation. Windows Data Protection API (DPAPI). Platform documentation.
[5] Y. Saito, M. Shapiro. Optimistic Replication. ACM Computing Surveys 37(1), 2005.
[6] M. Kleppmann, A. Wiggins, P. van Hardenberg, M. McGranaghan. Local-First Software: You Own Your Data, in Spite of the Cloud. Ink & Switch, 2019.
© 2026 Computer Aided Business Systems (CABS), Lagos. Prepared as the basis for a presentation to the
Association of School Proprietors and Principals