A surgical exercise. We triage the platform as it stands against the
school's own policies, procedures and flows, and record every lapse in
one register.
The exercise
The platform exists. The policies exist. This exercise tests one
against the other. For each scenario, the question is the same four
times over:
does the platform align with school policy in its deliverables; is
the information correct; is it reflected to those who should see it;
and are the people who must act — approving, scheduling, tracking,
notifying, responding — able to act?
We do not assume the system already handles what policy requires.
Where a lapse appears between the two, it is resolved by triage:
fix now if the correction is small;
flag to the next wave if it requires significant work;
bridge with a temporary workaround where operations cannot
wait. The attendance arrangement in the closing note is the model case
of the third path.
Every finding is recorded in the Lapse Register at the end of this
document, in those same three categories.
Test conditions — prepared once, used throughout
Population: 3 English-stream students, 2 Arabic-stream
students. Small enough that every account is tested by hand;
representative enough to exercise every flow.
Answer sheets: the testing team uses prepared answer sheets
to deliberately pass or fail each quiz and placement test, so that
every scenario below can be reproduced at will.
Placement outcomes, fixed in advance: Arabic — one student
fails half their placement subjects, one passes 3 of 4. English —
one fails 3 of 4, one passes 3 of 4, one lands in the middle.
Arabic stream is tested by an Arabic speaker, running the
identical logic checks as the English stream.
All courses and quizzes are already loaded. Payment flows are
excluded — the test students are already enrolled.
01
Course material — reading without friction
Context — what policy expects
Course material takes two core forms: the video presentation with
voiceover uploaded by the teacher, and the PDF lesson. A student
must be able to work through both comfortably on whatever device
they have. The PDF is read-only; the video is not downloadable.
(Broader protection of proprietary material against extraction by
normal means is noted for a later pass — not addressed in this
wave.)
Flow under test
Teacher uploads the video presentation with voiceover; student
plays it through — play, pause, seek, full-screen
Teacher uploads a PDF lesson and supporting resources
Student opens the PDF: full-screen, zoom, scroll, page
navigation — read-only, no download
Student downloads a resource file where downloads are intended
The same sequence is repeated on a phone
Lapse points
Video failing to play, buffering unusably, or lacking
full-screen
Video downloadable when it should not be
PDF readable only at a small fixed size, with no full-screen
option
Zoom absent, or resetting on every page turn
Resource download failing silently or arriving in an unusable
format
Any of the above working on desktop but not on a phone
Pass condition
Video plays cleanly with full controls and cannot be downloaded.
PDF is fully readable — full-screen, zoomable, paginated,
read-only — on desktop and phone alike. Resources download cleanly
where intended. These details are small individually and read as
unprofessional in aggregate.
02
Quiz passed — the result resolves everywhere
Context — what policy expects
A passed quiz advances the student. The score, the course
progress, and the running quiz average must all reflect the result
immediately and agree with one another on every screen where they
appear.
Flow under test
Tester sits the quiz using the answer sheet, scoring above 60%
Quiz is submitted
On completion, the student is led to the next lesson — not left
at a dead end or returned to the dashboard to search for what
comes next
Score, progress percentage and quiz average are checked on the
student view and the teacher view
Lapse points
Displayed score differing from the answers actually given
Progress percentage unchanged despite the pass
Module status remaining "in progress" after every lesson within
it is complete
Quiz average failing to recalculate
The student landing nowhere after submission, left to work out
the next step alone
Logged
Attempt and score, with time of submission — retained so any later
dispute over a result can be checked against the record.
Pass condition
Score, progress and average update at once and agree everywhere.
The student is carried forward to the next lesson without having
to think about navigation.
03
Quiz failed three times — lock, visibility, and role-scoped unlock
Context — what policy expects
Three consecutive failures lock the quiz. The Teacher, Academic
Director and Programme Director may unlock; the Coordinator and
Founder see the record but do not act — the separation preserves
accountability. Because locks will occur frequently, they are
tracked in a standing interface rather than broadcast as
notifications. Students on an academic success plan are expected
to generate repeated unlocks on the same course: that pattern is
signal, not noise — it shows precisely where the identified
difficulty lies.
Flow under test
Tester fails the same quiz three consecutive times using the
answer sheet
Confirm the quiz locks and a fourth unaided attempt is
impossible
Check each role's interface for visibility of the lock: Teacher,
Coordinator, Academic Director, Programme Director, Founder
Academic Director or Programme Director performs the unlock
Tester retakes the quiz
Lapse points
Lock failing to trigger at exactly three failed attempts
A role outside Teacher / AD / PD able to unlock
No standing view of locked quizzes — locks discoverable only by
accident
Individual notifications firing to every admin on every lock,
which at real volume becomes noise nobody reads
Logged
Every attempt, the lock event, and who unlocked it and when — the
unlock is an exercise of authority and must be attributable.
Pass condition
Lock triggers at three. Unlock is confined to Teacher, Academic
Director and Programme Director. Coordinator and Founder hold
view-only access to a tracking interface that shows all locks in
one place.
04
Academic success plan — placement-based, delivered, and opened
Context — what policy expects
The academic success plan belongs to the start of term. It is
written for a student who
failed a subject at the placement test — not for any
individual quiz score below 60%. A failed quiz is handled by the
retake path in Scenario 03; the success plan is the term-long
support structure for a difficulty identified before the course
began.
Flow under test
Confirm which test students failed which subjects at placement,
per the fixed outcomes
Teacher creates and uploads a success plan for each
failed-at-placement subject
Student is notified
Student opens the plan
Confirm the system records that the plan was opened — not merely
sent
Lapse points
Known lapse: the platform's own copy
currently states a plan is written "when a quiz score comes in
under 60%." This contradicts school policy and must be
corrected, or teachers and students will both operate on the
wrong rule.
Notification failing to fire, or reaching the wrong student
No record of whether the student ever opened the plan
Logged
Plan creation, delivery, and the opened event — the opened record
is what turns a sent document into evidence of support given.
Pass condition
A plan exists for every failed-at-placement subject and only
those. Teacher and Coordinator can confirm the student opened it.
05
Final assessment — upload, grade, review, provisional release
Context — what policy expects
On completing a course, the student sits a final assessment. The
teacher issues it once and it reaches every student identically.
Students submit individually; the teacher downloads each
submission, grades it, records remarks, and re-uploads. The
scoring engine computes the course grade at 80% quizzes, 20%
assessment. The student sees the result immediately as a
provisional grade, clearly captioned as such. The messaging
board cannot carry documents, so a dedicated upload location for
the assessment must exist — its presence is the first thing this
scenario establishes.
Flow under test
Student completes every lesson and quiz in a course; teacher is
notified of completion
Teacher uploads the final assessment; confirm it reaches all
enrolled students identically
Student downloads it in the correct format, completes it, and
uploads it back — confirm the upload location exists and works
Teacher downloads the submission, grades it, records remarks,
re-uploads the graded copy
Scoring engine computes the 80/20 course grade
Student sees the provisional grade at once, captioned as
provisional — not final
Programme Director's master view (Scenario 10) reflects the new
provisional grade
Lapse points
No upload location existing for the student's submission
Submission uploading but unreachable or unopenable for the
teacher
Teacher remarks dropped somewhere along the chain
80/20 computation not matching a manual calculation
Provisional grade displayed with no caption distinguishing it
from a final grade
Logged
Each handoff — issue, submission, grading, re-upload —
attributable, so the chain of custody of the assessment is never
in doubt.
Pass condition
The chain runs end to end with no dead end. The provisional grade
appears the moment the teacher uploads it, correctly computed and
clearly captioned.
06
Term close — verification, final grades, transcript
Context — what policy expects
Grades flow to students on a rolling, provisional basis through
the term. The final grade is released only at term close,
after the Academic Director's verification pass confirms that
everything computed or submitted is correct. The transcript is
generated only then. The cooling-off between provisional and final
is deliberate: the system's output is validated by a person before
it becomes the official record.
Flow under test
With a test student's courses complete and provisionally graded,
initiate the term-close sequence
Academic Director performs the verification pass; Programme
Director reviews grades and teacher remarks
Provisional grades convert to final
Transcript generates and credits release toward the 18-credit
total
Lapse points
Does a transcript format exist yet? Confirm. None has been
designed; a simple digital format approved by the Academic
Director or Programme Director is required.
Final grades releasing without the verification pass — the gate
not actually gating
Credits failing to convert on term close, so a completed course
still shows zero credit into the next term
Logged
The verification sign-off itself — who closed the term, and when.
This is the act the whole gate exists for.
Pass condition
Nothing final releases before sign-off. After sign-off, final
grades, credits and the transcript all agree with the verified
record.
07
Live class scheduling — twice weekly, dispatched to all
Context — what policy expects
Every course holds two live classes per week. When the teacher
publishes a session, every enrolled student receives it — same
information, same time, every account.
Flow under test
Teacher schedules and publishes a live session
All five test accounts are checked: does each dashboard show the
identical session, and did each account receive the
notification?
Students join at session time, each seeing the time rendered in
their own timezone
Lapse points
Are two live sessions per week actually being scheduled per
course? Confirm.
Some accounts receiving the dispatch and others not, with no
visible pattern
Different students in the same class seeing different times or
links
Pass condition
All five accounts see identical, correct session information, and
the twice-weekly rhythm is confirmed to be operating.
08
Session proof — a class that happened can be shown to have happened
Context — what policy expects
A live session's occurrence must be independently verifiable —
through its recording and its status — not dependent on anyone's
memory or word.
Flow under test
The scheduled session is held with the test students
Recording is captured and attached to the session
The session shows as held across the teacher, Coordinator and
Programme Director views
Lapse points
How do we know a session has been held? Confirm what the system
records. (And confirm how the recording itself will be captured
— the mechanism is not yet settled.)
Recording failing to attach, or attaching to the wrong session
Pass condition
Every held session leaves a verifiable trace: status and
recording, visible to the roles that supervise.
09
One-to-one sessions — booked through the system, traceable
Context — what policy expects
Every student is entitled to at least one one-to-one live session
per month. Priority in scheduling goes to students who did not
pass their placement test. (How entitlement beyond the monthly
session is handled for struggling students is left open for now —
noted for a later enhancement.) Sessions are booked through the
platform, not by exchanging links in private: the booking surfaces
on both calendars and the session's occurrence is recorded. What
is exchanged outside the system cannot be evidenced later.
Flow under test
A success-plan test student requests a one-to-one for the course
they failed at placement
The student books against the teacher's calendar, or the teacher
issues the session through the platform such that it appears on
the student's calendar
The session is held and its completion recorded, linked to the
success plan it serves
Lapse points
Teacher and student able to complete the whole arrangement by
direct link, leaving no trace
Booking absent from the student's calendar
No linkage between the session and the success plan it was meant
to support
Pass condition
The one-to-one is traceable from request to completion, tied to
the course and plan — the record that shows support was not only
planned but delivered.
10
Programme Director master view — the report that prevents flying
blind
Context — what policy expects
The Programme Director must be able to answer, from one screen,
who is progressing, who is struggling, in which course, and under
which teacher. The data already exists on individual dashboards;
what is required is one consolidated table. This is a requirement
we are specifying — without it, oversight at term start is manual,
error-prone and unprofessional.
Specification
One table, two tabs — English stream and
Arabic stream. One row per student-course pairing. A dash
wherever no data exists yet. Sortable and filterable on every
column. Row click opens the student's detail and Gradebook.
Column
Content
Student name
—
Course
one row per student-course pairing
Teacher name
the teacher assigned to that course
Placement result
pass / fail for this subject
Progress %
current position in the course
Quizzes taken
count
Quiz average
%
Assessment score
% once graded, dash before
Provisional grade
computed 80/20, dash until complete
Live sessions attended
count
One-to-one sessions
count
Time on platform
hours
Quiz unlocks
count
Lapse points
The data existing on individual pages but nowhere as one table
No sort or filter, leaving the data present but unusable at
scale
No stream separation, forcing manual cross-referencing between
English and Arabic
Pass condition
The Programme Director answers "who is struggling, where, and why"
from one screen. A success-plan student with mounting quiz unlocks
and low session attendance is visible at a glance — which is the
entire point of the view.
11
Teacher view — the same table, scoped to their own students
Context — what policy expects
Teachers carry the follow-up. They need the identical table from
Scenario 10, restricted to their own students and courses —
nothing beyond their scope, nothing missing within it.
Flow under test
Teacher opens their view and sees the Scenario 10 columns for
their own students only
Confirm no visibility into another teacher's students
Teacher records a private note against a specific student
Confirm the note is visible to admin roles and never to the
student
Lapse points
The view not existing, leaving teachers to track their students
from memory
Scope leaking — a teacher seeing students who are not theirs
Notes absent, or worse, visible to the student they concern
Pass condition
Each teacher holds a complete, correctly scoped picture of their
own students, with a private note-keeping channel that reaches
admin eyes only.
12
The 24-hour response rule — enforceable only if visible
Context — what policy expects
Every teacher responds to any student query within 24 hours. This
is a formal commitment. A rule of this kind is only enforceable if
the clock is visible: the teacher must be able to see what is
unanswered and for how long, before the deadline passes rather
than after.
Flow under test
Student posts a question through the lesson discussion or
messaging
Confirm the question registers as sent and reaches the teacher
Confirm the discussion board itself functions — students can
post, the teacher sees it
Leave a question unanswered and observe what the teacher's view
shows as time passes
Teacher responds; student sees the response
Lapse points
Is there any view showing a teacher their unanswered questions
and the time elapsed on each? Confirm — without it the rule
cannot be met or measured.
A question posted and simply disappearing, with no sent or
answered state
No visibility for the Programme Director into response-time
performance
Pass condition
A question cannot silently age past 24 hours. The teacher sees it
coming; the Programme Director can see whether the rule is being
kept.
Closing note to the development team — attendance, the model
workaround.
Attendance at live sessions is not tested in this wave, because the
system does not yet carry a per-session attendance and participation
record. The interim arrangement: each teacher keeps their own attendance
sheet offline, per session, and uploads it to the platform where the
Programme Director can review it. This gives partial visibility and a
documented backing — if a student falls behind, the record shows whether
they were attending — until proper fields are built in the maintenance
period. We flag the gap here so it is understood as a known weakness
with a working bridge, not an omission.
ExecutionTest Log
Each run against a scenario is recorded here as it happens — what was
exercised, whether it held, and which side ran it. Every entry is
shared: what one tester records, the next tester sees. A result marked
fail or blocked is a candidate for the Lapse Register
below, where it is triaged.
Not connected to the results store.Results cannot be loaded or recorded from this copy of the file —
open the deployed site instead.
—
When
Scen
What was tested
Result
Tested by
No results recorded yet.
FindingsLapse Register
Every lapse found during testing is entered here, triaged into one of
three paths — fix now if the correction is small,
next wave if it requires significant work,
workaround where operations cannot wait. The register is shared
and live: what one side enters, the other sees. The first two entries
were known before testing began.