School records that cannot be quietly changed

A proposed system architecture for administrative record-keeping at a school in Myanmar.

1. The problem, in your words

Read carefully, that sentence does not describe a missing feature. It describes a loss of trust in the school's own records. Adding more screens to a conventional system would not fix it, because the weakness is in how conventional systems store information in the first place.

Almost every school package on the market stores the present value of things. A student's mark is a box containing 71. When someone edits that box to 92, the 71 stops existing. Some products keep an activity log beside the data — but that log is itself an ordinary table, and anyone who can reach the database can edit the log too. That is precisely what appears to have happened at your school.

The architecture below starts from the opposite end. It is designed so that the sentence above cannot be true again, and so that this can be proven to a parent, an auditor or a ministry inspector rather than merely asserted.

2. The principle: a ledger, not a set of boxes

The system does not store what a record is. It stores every event that has ever happened to it, in order, and calculates the present value from that history whenever a screen is drawn.

Three consequences follow directly, and they are the whole proposal:

1. Nothing can be erased. Removing a student writes a new entry saying so. The student disappears from daily screens and reports; the record and its history stay in the ledger permanently.
2. Every change carries a name, a device, a time and a written reason. A change with no reason cannot be saved at all — the Save button refuses it.
3. There is no second copy of the data that someone could edit behind the system's back. What you see on screen is the ledger, recalculated.

3. Detecting change made outside the system

Rule 2 above still leaves one hole: a person with direct access to the stored files could, in principle, alter them without going through the system at all. Access control cannot close that hole — by definition this person has bypassed access control. So the design does not try to prevent it. It makes it impossible to do quietly.

Each ledger entry carries a short fingerprint calculated from its own contents and from the fingerprint of the entry before it. The entries therefore form a single chain. Altering the contents of any entry breaks its own fingerprint and every link after it, and the break points at the exact entry that was touched.

The daily seal — proof that lives outside the school

Every night at 22:00 the system sends the Principal a single line of e-mail:

The Principal does not need to understand how the code is produced. He needs to understand one thing: that code can never be reproduced if the day's records are altered afterwards, and it is sitting in his own mailbox, outside the school's database and outside the supplier's reach. To rewrite history undetected, a person would have to reach into that mailbox as well — and into every earlier one.

This is also the answer to a reasonable question your school should ask us: what stops the software supplier from changing the data? The seal does. We are inside the fence with everyone else.

The honest weakness, and how it is closed

A chain of fingerprints catches somebody who edits one link. On its own it does not catch somebody who rewrites the whole rope — delete everything, write a new history, recompute every fingerprint from scratch. For whoever operates the system, that takes seconds.

So the chain is not what protects you. The seal leaving the building is. A code that was in the owner's mailbox on 4 August cannot be un-sent, and to rewrite that day's history convincingly a person would need to reach into that mailbox and every earlier one. The chain's real job is narrower and still essential: it is what makes a twelve-character code able to stand for an entire ledger.

The daily seal, though, goes to people the school itself chose. So once a term the system takes one step further out.

The term anchor — a witness nobody at the school selected

At the end of each term every entry is reduced, through a Merkle tree, to a single value, and that one value is published somewhere no one connected to the school can reach — not the owner, not the principal, not us. Anybody, at any point in the future, can recompute that value from the school's own records and see whether it still matches.

This is the same batching trick Singapore's own OpenAttestation uses to anchor thousands of documents in a single operation: one published value covers every entry, so the cost does not grow with the size of the school.

“Why not simply use a blockchain?”

It is the right question, and the answer is that most of a blockchain is already here. A blockchain is three ideas, and this system deliberately takes two of them:

Adopting the third part would mean buying a machine to solve a problem the school does not have, and paying for it in cost, complexity, key management, and — in this country in particular — the banking and legal complications of handling cryptocurrency, which is not a burden a school should take on to keep a register.

What a public chain is genuinely good for is being an independent, permanent noticeboard. So the system uses exactly that much of it, and nothing else:

The demonstration implements this: open the Ledger screen and the published root is recomputed in your browser from the entries themselves. Press the red tampering button and the root no longer matches — recorded, timestamped and beyond the reach of anyone at the school.

4. Who can do what

Access levels were the second half of your message. The design uses four roles and one unusual rule: no account has the power to delete, including the Principal's and including ours.

Read the Registrar and Bursar rows together. One keeps the records and cannot touch money; the other takes money and cannot touch a record. Neither can approve. That single split is what stops a person from both collecting a fee and adjusting the record that says it was owed — the oldest financial control there is, and the one a school without a finance department almost never has.

Note what the Principal cannot do. This is deliberate, and it protects him: when a figure is later disputed, the ledger shows he never had the ability to touch it.

Four eyes on anything that matters

Marks, names, dates of birth, class and enrolment status are treated as sensitive. One person proposes the change; a different person accepts it; nobody can accept their own request. The old value survives either way, and a refusal is recorded just as permanently as an approval.

5. Designed for Myanmar, not adapted to it

It keeps working when the internet does not

So the app installs onto a phone or PC like an ordinary application and continues to run with no connection. Attendance and record entry carry on; entries are held on the device and join the ledger when the line returns.

There is a quiet elegance here that is worth pointing out, because it is a direct dividend of the decision in section 2. Because the ledger only ever adds entries, offline work can never conflict. Two teachers marking the same class on two phones with no signal cannot overwrite one another — when they reconnect, both sets of entries are simply appended in the order they were made. There is no merge, therefore no conflict, therefore no data silently lost. Conventional systems have to guess whose version wins; this one never has to ask.

Myanmar text is treated as a first-class problem, not an afterthought

• Unicode only. Myanmar text is stored as Unicode throughout. Where staff computers still produce Zawgyi, conversion happens once at the point of entry or import. Postponing this decision is the single most common way school databases in Myanmar become unreadable two years later, and it cannot be repaired cheaply afterwards.
• Every name is stored twice — Myanmar script and Latin script — on the same record. Staff work in Burmese; reports for you, for a ministry, or for a partner school print in English; there is one record underneath, not two lists that drift apart.
• The whole interface switches language with one button.

Practical fit

• Phones are first-class. Attendance is designed for a teacher standing in front of a class holding a phone, not for a desktop in an office.
• No e-mail or SMS required to log in. Accounts are issued by the school's administrator with a username and password. There is no public sign-up.
• Low bandwidth. The application is a few hundred kilobytes and is cached on the device; day-to-day use transfers only small entries.
• Excel is the front door. The school's existing spreadsheets import directly. Import always merges — it never replaces a data set, so an import can never wipe out records that were not in the file.

6. Data the school can never lose

Every night the complete records are exported to Excel and to a plain data file, delivered to the Principal's mailbox and to a second storage location. The rule behind this is simple: the school's data must exist in at least two places that no single person can reach.

This protects against the ordinary disasters — a failed disk, a lost password, a payment lapse — and it also protects the school from us. If this arrangement ever ends, the school already holds a complete, readable copy of everything, without needing our cooperation.

7. Printed documents that cannot be edited afterwards

Every register, mark sheet and certificate the system prints carries the seal of the ledger it was produced from, together with a scannable code. Scanning it returns the original record. A document edited in Word after printing no longer matches its own seal — which turns a printed page from a claim into evidence.

8. Four capabilities that follow from the design, and cannot be retro-fitted

Everything above is about trust. This section is about what that trust is worth in ordinary week-to-week work. All four of the following exist in the demonstration. None required extra machinery — they are consequences of keeping the history rather than overwriting it.

The time machine — the school on any past day

Pick a date. The system replays the ledger up to that day and shows the records exactly as they stood: who was in which class, what each mark was, who had left. Not a backup, not an export, not a restore — the same ledger, read to a different point. Values that are different today are highlighted next to their current value.

It is worth being concrete about why this is unusual. PowerSchool — the largest system of its kind — documents that its Change History is optional per data category, is kept for 365 days unless the school pays for longer, is recommended to be switched off during data migrations, and can only be searched in windows of 7 days for attendance and 31 days for everything else; reviewing a full school year therefore takes roughly 52 separate searches, and the vendor's own guidance for longer analysis is to export the data and work on it outside the product.

Every one of those limits is a symptom of the same thing: a side-log bolted onto a database that overwrites itself. None of them exist here, because there is no side-log — the history is the database. There is no retention setting to configure, no window to exceed, and nothing to switch off.

Ledger Watch — the system reading its own history

Nobody has to remember to look. Every time the ledger changes, a small set of plain arithmetic checks runs across it and raises anything that does not resemble the rest:

• A mark changed after the marks deadline — and how many days after
• An unusually large jump in a single mark
• A change made outside school hours
• Attendance entered days or weeks after the day it refers to
• One record corrected repeatedly in a short period

Severity comes from the combination, not from any single signal. A mark corrected a few days late, with a written reason, is ordinary and is shown quietly. A mark raised by fifteen points, thirteen days after the deadline, at 23:41, is not ordinary — and is shown loudly.

The screen also lists the checks that found nothing, which is the part most schools cannot answer at all today: no records deleted, no one approving their own request, no change saved without a reason, and no entry altered outside the system. Clearing an alert is itself written to the ledger — so the record shows who reviewed it, and when.

Ask — questions in plain language, answered with receipts

Typing a question and getting an answer is no longer unusual in this market; several established systems now do it with a language model. What they do not do is guarantee the answer. Arbor, the most widely used system of its kind in the United Kingdom, states in its own documentation that its answers “aren't always the same, even if you ask the same question twice.”

That is acceptable for drafting a letter. It is not acceptable for a school record. So this system answers by rule rather than by guess, and every answer arrives with three things attached:

1. The rows — the actual records behind the number, not just the number.
2. How the answer was produced — in plain sentences: which entries were read, which were kept, and on what test. A member of staff can repeat it by hand.
3. The ledger entries used, by number, each one openable and readable in full.

Each answer also carries a short fingerprint. Ask the same question next term, or after the staff who entered the data have left, and the fingerprint is identical — which is what makes an answer usable in a disagreement with a parent or an inspector.

The letter home that comes back — and is checked next term

Every school system sends parents a verdict: a mark, a grade, a line of praise written at eleven at night for the fortieth child. A parent can do nothing with a verdict. Three things here are deliberately different, and the third is the one no competitor can copy without rebuilding their storage.

First, the child is compared with themselves, never with classmates. The question is not where a child ranks but what they are already good at and what is moving. “English is five points above his own average across the term” is a sentence a family can act on. “Twelfth in the class” is not.

Second, every sentence comes from a number in the ledger. Nothing is generated to sound warm. If the school cannot answer “how do you know that?”, the sentence does not get sent — and if there are no marks recorded yet, the letter says so instead of inventing a comment to fill the space. The system also refuses to call a subject a strength when it is falling sharply, however good the average still looks; a parent notices that contradiction immediately, and the whole letter loses its credibility with it.

Third, and this is the part that requires the architecture: the letter asks for one sentence back, records what the family actually said, and next term reports whether it worked:

And when it has not worked, the letter says that too, in those words: “that does not mean the family did nothing — it means this plan is the wrong plan, and we should change it rather than repeat it.” If a family never replied, the next letter says so and suggests checking the phone number on file before asking again.

Closing that loop needs a permanent, dated history of both the marks and the promises. A system that keeps 365 days of purgeable log and overwrites last term's marks cannot do it at all — which is why, as far as we have been able to check, nobody does.

9. Overseeing a school from another country

An owner who is present can walk down a corridor and count children. An owner four hours away by plane cannot verify anything by looking — he can only read what the school chooses to send him, which is precisely the arrangement that lets value leak.

So this system does not ask him to trust a report. It gives him three counts that are collected by three different people for three different reasons, and shows him where they disagree:

This is the reason the roles are split the way they are. The Registrar keeps records and may not touch money. The Bursar takes money and may not alter a student record. The Principal approves and can do neither. Nobody holds two of the three counts, so nobody can quietly make them agree.

Cash, which is where schools actually lose money

Bank transfers look after themselves. Cash does not, so it is controlled the way a careful business controls it, and the system enforces the controls rather than hoping:

• Every cash payment consumes a numbered receipt from a book that was issued, in the ledger, to a named person. Receipts cannot be reused.
• A number that is issued but never used is reported. A receipt written for a parent while the money goes elsewhere leaves exactly this trace — a gap in the sequence — and it is the single most common way cash leaves a school.
• Cash taken is compared with cash banked. The difference is a number on the owner's statement every month, whether it is zero or not.
• Reductions and waivers are changes like any other — they need a reason, a second approval, and they appear as a line the owner can see. A discount is a payment out of his pocket.

The owner's statement

One page, produced from the ledger and sealed, delivered every month regardless of whether anyone at the school remembers to send it: children on the roll, how many are billed, fees billed and collected, cash against banked cash, the outstanding balance, and every question the system has raised and nobody has answered. It carries the same seal as the ledger it came from, so a statement that has been improved on the way is detectable.

10. Filling the seats — and only claiming what can be proved

Section 9 is about value leaking out of a school. This one is about value that never arrives. For whoever paid for the building, the two are the same problem seen from opposite ends, and the second is usually the larger number.

The clearest figure in the system

The system knows how many places each class has and how many are taken, so it can state plainly what an empty seat is: a term's fee that will not be collected. Not a percentage, not a satisfaction score — a figure in kyat, updated as children join and leave. Most schools do not have this number in front of them, because the roll lives in one place and the fee book in another.

Which advertising actually produces students

Every family who approaches the school is recorded with where they came from — word of mouth, the sign at the gate, Facebook, a former family, walking in — and followed through enquiry, visit, application and either enrolment or loss, with the reason for the loss written down.

That last detail changes the conversation. In the demonstration two of the losses read “never answered the follow-up call.” That is not a marketing problem and no amount of advertising will fix it. Without the reason recorded, the school would have concluded that Facebook does not work and spent the money somewhere else.

And before any of it: who is leaving. A school losing students it already has is a leaking bucket, and filling it faster does not fix it. Every departure needs a written reason before it can be recorded, so after a year that list is the most useful marketing document the school owns — it says, in the families' own words, why people go.

What a student costs, and what a student is worth

Almost no school system records advertising spend at all. That is why almost no school owner can answer the only question that matters about marketing: what did a student actually cost to get, and what is that student worth? Spend goes into the ledger by channel, enrolments are already there by source, and the division is arithmetic.

In the demonstration the answer is uncomfortable, and it is the kind of thing an owner four hours away would otherwise never learn:

The conclusion is not “stop advertising”. It is that the money bought attention the school then failed to answer, which is a far cheaper problem to fix than a marketing one. No report produced at the end of term would have said this; it only appears when spend, enquiries and outcomes sit in the same ledger.

One discipline is applied deliberately here. Measured figures and assumed figures are kept apart on the screen. Spend, enquiries and enrolments are measured. How long a child stays is an assumption — it is an input on the screen, marked as an assumption, and the lifetime value recalculates when it is changed. A return figure that quietly hides its own assumption is how software flatters the person paying for it.

Nobody has called these families

Open enquiries with no contact for six days appear as a named list with a price against each one. In the demonstration seven enquiries are silent, together worth MMK 9,450,000 a year — advertising the school has already paid for and is now wasting by not answering.

This is the difference between a report and a system. A report tells the owner at the end of term that conversion was disappointing. This puts a list on the office desk on a Monday morning, while the families are still interested.

The families doing the school's marketing for it

The enquiry record includes who sent each family. Three families in the demonstration have sent six others between them. These are the most valuable people connected to the school, and most schools do not know their names.

A satisfaction survey asks families what they say. This asks what they did — and a family that hands over its friends has given the strongest opinion available. Thanking them by name costs nothing and works better than the MMK 420,000 above.

The part competitors cannot copy

Every private school in the world advertises excellent results and caring teachers, and no parent believes any of it, because none of it can be checked. A school sitting on a sealed ledger can do something its competitors cannot: publish figures that carry the same seal as the records they came from, so a sceptical parent can verify the claim instead of being asked to trust it.

In a market where every school says the same three sentences, being the only one that can be checked is the advertisement.

Two lists, and the school may only print one

The screen divides its own figures into ready to publish and true, but do not print it yet, each with the threshold it would have to reach. In the demonstration, 39% of students improving and 50% of families replying sit in the second list — with a note that the first becomes advertisable above about 60%.

The system will not hide a weak number, and it will not let the school print one. The second list is a work plan, not a criticism — and a marketing claim that turns out to be unprovable costs a school more than never having made it.

Publishing — and the lock that matters more than the button

The school's Facebook page and its own website can be connected, and a post composed from the publishable figures in one click. That part is easy. This part is not:

One caution about the last step, stated plainly because it is the sort of thing that is usually glossed over in a proposal: posting to a real Facebook page needs a Page access token that only the school can issue, and Facebook's own review of the application — a week or two of paperwork rather than a technical problem. The composing, the privacy check and the record are built and working; the final connection is deliberately left unconnected in a demonstration, and nothing in it sends anything anywhere.

11. The family's own screen — deliberately the smallest one

Thank you for the portal screenshots. They changed a decision, and it is worth explaining how, because the change is not the obvious one.

We had planned no parent portal at all, on the grounds that a portal assumes a smartphone, a password and a habit, and in Myanmar that leaves out the families most likely to be missed. Having looked at what a live portal actually displays, we now think the right answer is a portal that deliberately shows less.

Look at those screenshots once more, not as a designer but as a parent. On a single screen: full name, date of birth, national learner reference number, home address, both parents' mobile numbers and e-mail addresses. Nothing there was done carelessly — that is simply what these systems display. But it means every screenshot anybody takes of that page is a copy of a child's complete identity, and people take screenshots constantly. That file reached us, in another country, from someone none of us has met, in an afternoon. No one did anything wrong; the design did it for them.

And this is the part worth pausing on. That is not a cheap system or a careless one. It belongs to a large, well-funded university with a real IT department, and it is competently built — clean, protected at the login, with an AI assistant of its own. It still puts a twelve-year-old's whole identity on one screen.

So this is not a quality problem that a better vendor solves. It is what an entire generation of school software assumes: that a portal's job is to display everything the institution holds about you. That assumption was made before anyone had thought hard about a phone camera, a group chat and a child. Changing it is not a feature — it is a different starting point, and it has to be chosen at the beginning because it cannot be added afterwards.

The protection here is not a permission setting that an administrator can loosen next year. It is that the data is never put on the screen in the first place. Every field displayed on a parent screen is a field that leaves the building the next time somebody photographs it — and for children's records the only reliable defence is to have shown less.

Opening the page is itself a ledger entry, so both “the school never told us” and “nobody ever looks at it” have answers.

12. How to check these claims without trusting us

You have been sold software before. Every school system ever demonstrated has looked good in the demonstration, so the only useful question is what it does badly — and a supplier who will not answer that is asking to be believed rather than checked.

The demonstration therefore has a screen called Proof. Seven claims, each with a button that performs the check in front of you, and beside each one, in the same row, where this design is weaker than the alternative:

The same screen lists what we have not verified: we have not claimed that no other product does these things — we examined two market leaders' documentation closely and others in passing, so the honest claim is not present in the products we checked. We have no reliable pricing for this market and will not invent a comparison. We could not establish from here how many school computers in Myanmar still run Zawgyi fonts, nor the current data-protection rules. And the largest risk in the project — whether the school will actually use the thing — no demonstration can settle.

13. What Phase 1 is — and what it is not

14. What we need from the school

1. Which records were altered? Marks, fees, attendance, the student list, staff records? The answer tells us where to place the four-eyes rule first. This is the most useful question in this document.
2. How many users, and on what? Roughly how many teachers, office staff and administrators, and do they work on PCs or on phones?
3. Interface language — Burmese, English, or both? If Burmese: are the school's computers on Unicode or still on Zawgyi?
4. One named administrator at the school. Somebody who is comfortable with Excel is enough. This is not a formality — a system of this kind without an owner inside the building will be abandoned within a term, whatever its quality.
5. Copies of the spreadsheets and forms in use today, so the system produces documents the staff already recognise instead of asking them to learn new ones.

15. Why we believe this can be delivered

Nothing in this document is research. Permanent change history, separation of roles, approval queues, tamper-evident sealing, Excel import that merges rather than replaces, bilingual reporting and a nightly export held off-site are all components we already run in daily production, in an organisation where the records carry legal weight and the numbers carry money. What is new here is the arrangement, not the parts — which is why a working demonstration exists at the proposal stage rather than after a contract.

The risk, stated plainly

The risk in this project is not the software. It is the two things software cannot fix:

• Whether the school has one named person who owns the system. Somebody comfortable with a spreadsheet is enough. Without that person, a system of this kind is quietly abandoned within a term, however good it is — and we would be paid for something nobody uses.
• Whether the people who today hold both the records and the money accept being separated. Every control in section 9 rests on that separation. If it is resisted, the controls will be worked around, and no amount of engineering will prevent it.

We would rather raise both now than discover them in month four. Neither is a question for us to answer, and neither costs anything to ask.

What we suggest happens next

1. You and anyone you trust at the school use the demonstration below, and tell us what is wrong or missing. It is meant to be argued with.
2. The school answers the five questions in section 11 — above all the first one, which decides where the strongest controls are placed.
3. We propose a fixed scope for Phase 1, for one school, with a defined end date and nothing hidden behind “phase two”.

A live walkthrough of the existing production system, and references, are available on request.

A working demonstration is available now → It opens the way the school will see it: signed in as an ordinary member of the office staff, on an ordinary screen. Look around it as a school first — students, register, marks, report cards, letters home, staff, notices, timetable, fees. Then switch the user at the top to School Owner and open Owner and Watch: the system has already found nine things nobody at the school has explained — a receipt issued and never used, MMK 900,000 taken in cash and never banked, a fee cut by two thirds with no approval, a child on the roll who has never once been in the classroom, and a child in the classroom who is on no fee bill at all. Open Growth and type a student's name into the draft post — the Publish button switches off. Then try Ask, set the time machine to 1 July 2026, try to delete a record, turn the connection off and keep working — and finally press the red button that edits the database directly, and watch the system catch it. All names and figures are fictional.

Appendix A — answering your comparison table directly

You sent a table comparing a Student Information System, a Learning Management System and a School Management System. It is the right way to frame the question, so here it is answered line by line — with the gaps left in rather than written around.

What is deliberately not built, and why

The whole Learning Management column. The requirement you gave was administrative, so we built the administrative system properly instead of a thin version of three things. If online teaching is wanted later it is a separate product and should be bought as one — an LMS bolted onto a records system is how both end up mediocre.

Ministry compliance reporting is missing because we have not seen the forms. It is roughly a week of work once we have them, and it has to match the real paperwork exactly rather than approximately, so guessing would be worse than waiting.