Everything Nippur does, in detail

A direct conversation between a parent and a teacher or the office, with no group and no exposed numbers.

• Three ticks on every message: reached the server, opened on the recipient’s device, and confirmed by a person with an explicit tap. For a trip permission or a fee notice, the difference between “opened” and “confirmed” is the whole point.
• Every thread shows the teacher’s office hours, so the parent knows when to expect a reply and the teacher is not on call at 11 pm. There is deliberately no “typing…” indicator.
• A thread has a state — open, resolved, closed — and can be escalated to the office.
• A message is saved on the phone and sent when the connection returns, never twice.
• One guardian’s conversation does not appear on the other guardian’s phone.

The teacher records, the parent sees, and an absence request follows a clear path to a decision.

• The teacher takes lesson attendance from their phone and sees how many parents will be notified before saving.
• The parent sees the month day by day, each day with a colour and a word together: present, excused, unexcused, late, holiday. Colour is never the only signal.
• Weekend days are never recorded as absences, because the weekend is defined once for the whole system.
• An absence request is filed from the phone and followed: submitted, under review, decided. A rejection without a written reason is impossible at the database level.
• Editing a saved register needs a reason, and who edited it and when is recorded.

The teacher enters, the office approves, then the family sees — always in that order.

• There is no path in the system that lets a teacher publish grades directly; publishing is the office’s decision from the approvals screen.
• Anything unapproved never appears to a parent, and no zero or dash appears in its place to suggest the mark is zero.
• Correcting a published mark goes through a change request and an approval, and leaves its trace in the log.
• A mark cannot exceed its maximum, and a maximum cannot be lowered beneath a mark already entered.
• Class rank is off by default; whether to show it is the school’s decision.
• The teacher’s entry form accepts Arabic-Indic and Latin digits alike, so someone typing ٤٦٫٥ is not told to “enter a number”.

Amounts in full, never abbreviated, and a receipt number that never skips.

• The parent sees the instalment plan: what is due, what was paid, what remains, and when the next instalment falls. An amount is never abbreviated or cut off; the layout reflows to fit it.
• A parent can upload a proof of payment, and rejecting it needs a reason and the reviewer’s name.
• The accountant creates fee plans, assigns them to students, records cash payments and issues a receipt. The receipt number comes from a counter inside the same transaction, so if the payment fails to save, the number returns and is not lost.
• Voiding a payment does not erase it; it records a reversing entry with a written reason, so the ledger total stays right and the trace stays.
• Not built yetOverpayment is recorded as a credit for the family. Discounts, waivers and refunds are not built yet, because they are policy that needs an approval path, not a field on a form.
• Not built yetWithholding results over a late instalment is not built, and our recommendation is that it stays that way — the decision is the school’s.

Child safety is not an optional setting.

• The parent nominates someone to collect the child; the school approves. Nomination alone is not enough, and a parent cannot approve their own nomination.
• The most restrictive signal wins: an expired authorisation is void even if it was approved.
• Revoking names the person and the child explicitly and needs a reason, and stays in the record — because on the day of an incident it is the only record of who was allowed to collect.
• A one-time pickup code when needed, consumed once and never reused.
• Not built yetThe parent sees the child’s bus and its supervisor. Boarding and alighting records on the supervisor’s side are built in the server; the supervisor’s app itself is not built yet.

One calendar the school and the family both know.

• Exams, holidays, events and fee due dates in one calendar, and every event says who it concerns, when, and whether it needs consent or payment.
• Months carry their Levantine names, Kanun al-Thani through Kanun al-Awwal, and the weekend is defined once for the whole system.
• Every event carries its time on the school’s clock, so an 8:30 exam at school shows as 8:30 on a travelling father’s phone.
• An RSVP to an event counts per family, not per guardian, so no duplicate seats are booked for one child.
• Not built yetA teacher can publish a window for parent meetings that becomes bookable slots — built in the server; its screen is not built yet.

An announcement reaches the people it concerns, and is not lost under fifty messages.

• An announcement to one class, a grade level or the whole school, optionally requiring acknowledgement, so the school knows who has read it and who has not.
• A teacher’s announcement stays a draft until the office approves it, and nobody approves what they wrote themselves.
• An emergency broadcast always arrives, cannot be muted, and stays visible even if the app is opened late.
• Quiet hours defer a notification and never drop it.
• Push notifications: the plumbing is ready and the provider is a decision to be taken with the school. No SMS, deliberately.

Uploaded from the phone, reviewed from the office, and a rejection states its reason.

• The parent uploads the required documents from their phone and sees each one’s state: submitted, under review, accepted, or rejected with the reason verbatim.
• The registrar sees the document queue with its oldest item, so nobody is left waiting at the gate.
• Consent to a form is stored with its version: consent to version one never counts as consent to version two.
• Personal and medical files default to the most restrictive setting, and a medical flag cannot be recorded without an accompanying action.

The school decides who gets an account, and who sees what is written into the system, not into a setting.

• Sign-in with a code the school issues for one specific child: five unambiguous characters, single-use, expiring, revocable and reissuable.
• No SMS: no cost, and no code landing on a phone in the wrong hands. Whoever loses a phone goes back to the school.
• One account for all a family’s children, even at different schools.
• Two guardian slots per child with a relation chosen at sign-in, and eight sub-permissions the school controls: who reports an absence, who sees fees, who authorises pickup.
• Every significant change is written to an audit log the system keeps and nobody can edit or delete, from the app or from the office.