System Requirements Document for college-result-checking

1. Introduction

college-result-checking is a deployable college application for checking examination results. It exists so that a student can look up their own result — the subject marks and grades for the subjects they took — and read it as one calm, trustworthy fact, without needing to ask a member of staff. It equally exists so that the college has a place to supply and maintain the result records that those lookups return.

The product is delivered as a real, deployable system with both a front end and a back end: a browser-facing application for students and college staff, and a server-side application with persistent storage that holds identity, result records, and lookup execution.

The audience is two roles inside one institution:

• Students, who arrive anxious, often on a phone, often late at night, to read one number that matters to them.
• College Staff / Result Administrator, a small institutional team who enter and maintain the result records that students look up.

The product intent is deliberately narrow. It is a result-checking application, not a student information system, not a course platform, and not an analytics dashboard. Everything in this document serves the single act of a result being recorded accurately and then read accurately.

2. System Overview

The system is a two-part deployable application:

• A front end — the browser application that students and staff use.
• A back end — the server application that owns identity, result records, lookup execution, and persistence.

The back end is authoritative for all durable state. The front end never holds the only copy of a result record; it requests and renders what the back end owns.

Actors

Accepted behavior at a glance

1. An anonymous visitor can read what the application is and how to begin.
2. A student can establish their own access and then look up their own result.
3. A returning student or staff member can verify themselves and resume.
4. A staff member can browse, create, and update the result records that student lookups depend on.
5. The back end persists identity and result records and executes lookups and writes.

Narrow exclusions

This document does not introduce, and the product does not include: fee payment, course registration, admissions, timetabling, attendance, messaging between students and staff, grade appeals workflows, transcript issuance, analytics dashboards, or any capability not listed above. Where a familiar product category would suggest such a module, it is out of scope here.

2a. Product Interpretation and Delivery Boundary

Delivery ownership. The application is first-party and self-contained. The front end and the back end are both part of this product and both must be deployable. There is no third-party result provider, no external identity provider, and no headless-only delivery: the accepted behavior is delivered through the application's own pages and its own server.

Identity ownership. The application owns identity. This is required because a student's result is private to that student and must remain bound to the correct person across visits, and because staff-only record management must remain bound to the correct staff member. Identity is established in two distinct ways that match the two roles:

• A student establishes their own access on first use, without an invitation, because the source establishes no separate enrollment or provisioning boundary for students.
• A staff member receives provisioned or invited access before staff-only record management, because staff access is granted by the institution rather than self-claimed.

Access boundary. The Landing page, Sign Up, and Login are reachable without an existing session — a protected destination cannot own the interaction that establishes access to itself. The Results page is restricted to the signed-in student and shows only that student's own result. The Result Records and Result Editor pages are restricted to signed-in staff.

Current versus future. Everything specified in this document is current. No future-horizon requirements were accepted in the authoritative thread; Section 11 records the boundaries that keep the current scope narrow.

2c. Page Content and Component Coverage

The page inventory below is the final, ordered page contract for this product. Each page appears exactly once.

Landing

• Information and state. Anonymous public entry. States the product name, what the application is for, who it serves (students and college staff), and how each begins. No session required; no protected data is shown here.
• Primary actions. "Check a result →" leading to Sign Up for a student who has no access yet; "Staff sign in" leading to Login. A returning student can reach Login from the same surface.
• Supporting actions. Navigation links to Sign Up and Login; a short explanation of the three-step process (establish access, look up your result, read your marks and grades).
• Domain entities. None owned here. The page describes the product and routes visitors; it holds no result data.
• Component responsibilities. Wordmark and top hairline rule; tracked uppercase label; display headline; one line of body copy; two text-link calls to action; a full-bleed still-life photograph band below the fold; three numbered ruled rows explaining the process.
• States. Loading: static content, no data fetch required. Empty: not applicable — the page is always fully populated with static content. Success: visitor reads the page and selects a route. Error: if the application cannot be reached, a plain message states the application is unavailable and offers a retry. Recovery: retry reloads the page; no state is lost because none is held.

Sign Up

• Information and state. Anonymous first-use surface for a student establishing their own access. Collects the minimum identity information needed to create a student account and to bind future results to the correct person.
• Primary actions. Submit the sign-up form to create the student's access.
• Supporting actions. Link to Login for a visitor who already has access; inline field-level validation messages.
• Domain entities. Student identity record (created on success).
• Component responsibilities. Underline-only input fields with labels; a single primary text-link action; validation messaging per field; a link across to Login.
• States. Loading: the submit action shows an in-progress state and the form is not double-submitted. Empty: the form is presented with empty fields and no error text. Success: access is created and the student is taken to the Results page to perform their first lookup. Error: a field-level error for invalid or missing input; a form-level error when the identity already exists, with a direct route to Login; a form-level error when the back end is unreachable, with the entered values preserved. Recovery: the student corrects the field or follows the Login route; on a back-end failure the form retains input and can be resubmitted.

Login

• Information and state. Anonymous returning-verification surface for both students and staff. Accepts the credentials of an existing account.
• Primary actions. Submit credentials to verify identity and resume.
• Supporting actions. Link to Sign Up for a student without access; inline validation messaging.
• Domain entities. Existing identity record (read and verified).
• Component responsibilities. Underline-only credential inputs; a single primary text-link action; validation messaging; a link across to Sign Up.
• States. Loading: the submit action shows an in-progress state and is not double-submitted. Empty: the form is presented with empty fields. Success: identity is verified and the person is routed by role — a student to Results, a staff member to Result Records. Error: a single non-revealing message for incorrect credentials; a distinct message when the back end is unreachable, with entered values preserved. Recovery: the person retries credentials or follows the Sign Up route; on a back-end failure the form retains input and can be resubmitted.

Results

• Information and state. The signed-in student's own workspace. Shows the student's identifying details as submitted for lookup, and, once a lookup succeeds, the returned result: subject rows with marks and grades, and the final grade. Restricted to the signed-in student; only that student's own result is ever shown.
• Primary actions. Submit identifying details to look up a personal examination result.
• Supporting actions. Re-run a lookup; return to a previously retrieved result within the session; sign out.
• Domain entities. Student identity; result record; subject entries (subject code, marks, grade); final grade.
• Component responsibilities. Underline-only lookup inputs; a single primary text-link action; the result sheet — a single surface panel with a left accent rule, subject rows separated by hairlines, tabular numerals, and the final grade as a large numeral with a seal-stamp mark beside it; a tracked label above the sheet identifying the examination period.
• States. Loading: the lookup action shows an in-progress state; the result sheet is not rendered until data returns. Empty: before any lookup, the page presents the lookup inputs and a short line explaining that the student's result will appear here. Success: the result sheet appears with subject rows, marks, grades, and the final grade. Error: a clear message when no result matches the submitted details, with the inputs preserved for correction; a distinct message when the back end is unreachable, with a retry. Recovery: the student corrects the identifying details and resubmits, or retries after a back-end failure; a previously retrieved result remains readable if a later lookup fails.

Result Records

• Information and state. The signed-in staff member's view of the durable collection of student result records that supports accurate student lookups. Restricted to signed-in staff. Presents records as a ruled register: aligned label/value rows separated by hairlines, tabular numerals, no row striping.
• Primary actions. Browse the collection; open a record to update it; begin a new record.
• Supporting actions. Search or narrow the collection by student identifier or examination period; move between pages of records when the collection is larger than one view.
• Domain entities. Result record collection; per-record student identifier, examination period, subject entries, and final grade.
• Component responsibilities. Ruled ledger layout with a thin vertical rule between columns; a tracked label above the title; a text-link action to begin a new record; per-row action to open a record in the Result Editor.
• States. Loading: the ledger shows a loading state in place of rows. Empty: when no records exist yet, the ledger area states that no result records have been entered and offers the action to create the first one. Success: records are listed with their identifying fields and can be opened. Error: a message when the collection cannot be loaded, with a retry; a message when a search returns nothing, distinct from the empty-collection state. Recovery: retry reloads the collection; a failed search can be cleared to return to the full list.

Result Editor

• Information and state. The signed-in staff member's focused workspace for entering a new student result record or updating an existing one. Restricted to signed-in staff. Shows the record's current values when editing, and an empty form when creating.
• Primary actions. Save a new record; save changes to an existing record.
• Supporting actions. Add, edit, and remove subject entries within the record; cancel and return to Result Records without saving.
• Domain entities. Result record; student identifier; examination period; subject entries (subject code, marks, grade); final grade.
• Component responsibilities. Underline-only inputs for record fields; a repeating subject-entry group with per-entry controls; a single primary text-link save action; a cancel action; validation messaging per field and per subject entry.
• States. Loading: when editing, the record's values are fetched and the form shows a loading state until they arrive. Empty: when creating, the form is presented with empty fields and one empty subject entry. Success: the record is saved and the staff member is returned to Result Records with the saved record reflected there. Error: field-level validation for missing or invalid values, including at least one subject entry and a valid final grade; a form-level error when the save fails at the back end, with all entered values preserved. Recovery: the staff member corrects the flagged fields and saves again; on a back-end failure nothing entered is lost and the save can be retried.

3. Functional Requirements

Each requirement below is a distinct story point. Provenance is marked as explicit, basic_default, or required_inference.

FR-1 — Deployable application with a front end and a back end (explicit) As a college deploying this product, I should receive an application that can be deployed and that includes both a front end and a back end, so that students and staff can use it as a running system rather than a prototype.

• Trigger/input: a deployment of the application.
• Observable result: the front end is reachable in a browser and the back end is running and serving it.
• Failure/recovery: if either part fails to start, the deployment is incomplete and must be corrected before the application is usable.
• Continuation: once running, the Landing page is reachable and the accepted journeys can begin.

FR-2 — Understand the application before committing (required_inference) As an anonymous visitor, I should be able to read what the application is, who it serves, and how to begin, so that I can choose the correct route without guessing.

• Trigger/input: opening the Landing page.
• Observable result: the page states the product's purpose, names students and college staff as its users, and offers a route for each.
• Access state: anonymous; no session required.
• Failure/recovery: if the application is unreachable, a plain unavailable message with a retry is shown.
• Continuation: the visitor selects "Check a result →" or "Staff sign in".

FR-3 — Student establishes their own access (required_inference) As a student using the application for the first time, I should be able to create my own access without an invitation, so that I can look up my result without staff help.

• Trigger/input: submitting the Sign Up form with the required identity information.
• Observable result: a student identity record is created and bound to me, and I am taken to the Results page.
• Access state: anonymous entry; the resulting identity is application-owned and private to me.
• Failure/recovery: invalid or missing input is flagged per field; an already-existing identity is reported with a route to Login; a back-end failure preserves my input and allows resubmission.
• Continuation: I proceed to my first lookup on the Results page.

FR-4 — Returning student or staff member verifies identity (required_inference) As a returning student or a staff member, I should be able to verify my identity, so that I can resume my own work and reach only what belongs to me.

• Trigger/input: submitting credentials on the Login page.
• Observable result: my identity is verified and I am routed by role — student to Results, staff to Result Records.
• Access state: anonymous entry; the resulting session is bound to my identity.
• Failure/recovery: incorrect credentials produce a single non-revealing message; a back-end failure produces a distinct message and preserves my input.
• Continuation: I continue in my role's workspace.

FR-5 — Staff access is provisioned before staff-only work (required_inference) As a College Staff / Result Administrator, I should hold access that was provisioned or invited by the institution before I can manage result records, so that staff-only record management is not self-claimed.

• Trigger/input: an institutional provisioning or invitation of my staff access.
• Observable result: I hold a staff identity that Login can verify and that grants access to Result Records and Result Editor.
• Access state: staff-only; provisioned, not self-service.
• Failure/recovery: if my access has not been provisioned, Login cannot verify me and I cannot reach staff-only pages.
• Continuation: once verified, I work in Result Records.

FR-6 — Student looks up their own result (required_inference) As a signed-in student, I should be able to submit my identifying details and receive my own examination result, so that I can see the marks and grades for the subjects I took.

• Trigger/input: submitting identifying details on the Results page.
• Observable result: the result sheet appears with my subject rows, marks, grades, and final grade.
• Access state: restricted to the signed-in student; only my own result is returned.
• Failure/recovery: no matching result produces a clear message with my inputs preserved; a back-end failure produces a distinct message with a retry.
• Continuation: I read my result, or correct my details and look up again.

FR-7 — Student reads subject marks and grades (required_inference) As a signed-in student, I should see each subject I took with its marks and grade, together with my final grade, so that the returned result is complete and legible.

• Trigger/input: a successful lookup on the Results page.
• Observable result: the result sheet lists subject rows with marks and grades and presents the final grade as a single prominent value.
• Access state: restricted to the signed-in student.
• Failure/recovery: if the record is incomplete, the sheet shows what is present and does not fabricate missing values.
• Continuation: I retain the result on screen for the session and can re-run the lookup.

FR-8 — Staff browses the durable result-record collection (required_inference) As a signed-in staff member, I should be able to browse the collection of student result records, so that I can see what has been entered and find a record to work on.

• Trigger/input: opening Result Records.
• Observable result: the collection is presented as a ruled register with each record's identifying fields.
• Access state: restricted to signed-in staff.
• Failure/recovery: a load failure shows a message with a retry; a search with no matches shows a distinct no-match state that can be cleared.
• Continuation: I open a record in the Result Editor or begin a new one.

FR-9 — Staff enters a new student result record (required_inference) As a signed-in staff member, I should be able to enter a new student result record, so that the student's lookup returns correct information.

• Trigger/input: opening the Result Editor to create, filling in the student identifier, examination period, subject entries, and final grade, and saving.
• Observable result: the record is persisted by the back end and appears in Result Records.
• Access state: restricted to signed-in staff.
• Failure/recovery: missing or invalid values are flagged per field, including at least one subject entry and a valid final grade; a back-end save failure preserves everything entered and allows a retry.
• Continuation: I return to Result Records with the new record reflected there.

FR-10 — Staff updates an existing student result record (required_inference) As a signed-in staff member, I should be able to update an existing student result record, so that published results stay accurate and available to students.

• Trigger/input: opening a record from Result Records, changing its values or subject entries, and saving.
• Observable result: the updated record is persisted and the change is reflected in Result Records and in subsequent student lookups.
• Access state: restricted to signed-in staff.
• Failure/recovery: validation errors are flagged per field; a back-end save failure preserves my changes and allows a retry; cancelling returns me to Result Records without altering the record.
• Continuation: I return to Result Records, or open another record.

FR-11 — Back end persists and executes (required_inference) As the application, I should persist identity and result records and execute lookups and record writes on the back end, so that the front end never holds the only copy of durable state.

• Trigger/input: requests from the front end for identity creation and verification, result lookup, record listing, record creation, and record update.
• Observable result: durable state is written and read consistently, and lookup responses reflect the current stored records.
• Access state: identity-bound; a lookup returns only the requesting student's own result, and record writes are accepted only from verified staff.
• Failure/recovery: a failed write leaves stored state unchanged; a failed read returns an error the front end can present with a retry.
• Continuation: the front end renders the returned state or the error.

4. User Personas

Student

Product context. A student at the college who has taken examinations and needs to read the outcome. They arrive at the application with a specific, personal question and usually on a phone, often late at night, often nervous. They are not exploring the product; they are here for one fact.

Primary goal. To obtain their own accurate examination result — the subject marks and grades for the subjects they took — without needing to ask a member of staff.

Distinct accepted responsibilities.

• Establishing their own access on first use, without an invitation or staff assistance.
• Verifying their identity on return visits.
• Submitting their identifying details to look up their own result.
• Reading the returned subject rows, marks, grades, and final grade.
• Correcting their identifying details and looking up again when no result matches.

Relevant inputs and decisions. Their identity information at first use; their credentials on return; their identifying details at lookup time; the decision to correct and resubmit versus to stop when a lookup returns nothing.

Interactions with other accepted participants. The student's outcome depends on the College Staff / Result Administrator having entered an accurate record for them. The student never interacts with staff inside the application; the dependency is expressed as data — a lookup that returns a correct result because a staff member recorded it, or a lookup that returns nothing because no record exists yet. The student's own access is self-established and does not depend on staff action.

Observable success. The result sheet appears with their subject rows, marks, grades, and final grade, and the values match what the college recorded for them.

What makes this role different. The student is a reader of one private record, not a manager of many. Their entire responsibility is bounded by a single lookup and a single sheet, and their access is self-established. They have no visibility into any other student's data and no ability to change any record.

College Staff / Result Administrator

Product context. A member of the college's small administrative team who is accountable for the accuracy of the result data the institution publishes to students. They work in a ruled register of records rather than in a personal result view, and their mistakes are visible to students as wrong marks or missing results.

Primary goal. To keep the stored result records accurate and complete so that student lookups return correct information.

Distinct accepted responsibilities.

• Holding institutionally provisioned access rather than self-claimed access.
• Verifying their identity on return visits.
• Browsing the durable collection of student result records.
• Entering new student result records, including subject entries and final grades.
• Updating existing records when marks or grades need correction.
• Finding a specific record within the collection.

Relevant inputs and decisions. The student identifier and examination period for each record; the subject entries with their marks and grades; the final grade; the decision of which record to open and what to change; the decision to save or to cancel without altering the record.

Interactions with other accepted participants. The staff member's work is the direct upstream cause of the student's outcome. Every record they enter or update determines what a student sees when that student looks up their result. The staff member does not interact with students inside the application; the handoff is the persisted record itself.

Observable success. Records are saved and reflected in the register, and students' lookups subsequently return the corrected marks and grades.

What makes this role different. The staff member is a writer and maintainer of many records with institution-granted access, not a reader of one private record. Their working context is the collection and the editor, their state is the durable register, and their failure mode is an inaccurate record that a student will read as fact.

5. Core User Flows

Flow A — A student checks their result for the first time

1. Starting context. The student has no access to the application and has just received word that results are out. They open the application on their phone.
2. Landing. The Landing page loads anonymously. The student reads the product's purpose and sees the two routes: "Check a result →" and "Staff sign in".
3. Route selection. The student selects "Check a result →" and arrives at Sign Up.
4. Identity establishment. On Sign Up, the student enters the required identity information and submits. The back end creates a student identity record bound to them.
5. Observable result of step 4. The student is taken to the Results page, signed in as themselves.
6. First lookup. On Results, the student enters their identifying details and submits the lookup.
7. Back-end execution. The back end resolves the lookup against the stored result records and returns only this student's own result.
8. Observable result of step 7. The result sheet appears: a single surface panel with a left accent rule, subject rows separated by hairlines, each with marks and grade, and the final grade as a large numeral with a seal-stamp mark beside it.
9. Reading. The student reads their subject marks and grades and their final grade.
10. Failure and recovery. If no result matches the submitted details, the page states this clearly and preserves the inputs; the student corrects the details and submits again. If the back end is unreachable, a distinct message appears with a retry, and the student retries without re-entering anything.
11. Continuation. The student retains the result on screen for the session, can re-run the lookup, and can sign out.

Flow B — A returning student checks their result again

1. Starting context. The student already has access from a previous visit and returns later, possibly on a different device.
2. Landing. The Landing page loads anonymously; the student selects the route toward Login.
3. Verification. On Login, the student submits their credentials. The back end verifies them.
4. Observable result of step 3. The student is routed by role to the Results page, signed in as themselves.
5. Lookup. The student submits their identifying details and receives their result sheet as in Flow A, steps 7–9.
6. Failure and recovery. Incorrect credentials produce a single non-revealing message and the student retries; a back-end failure preserves the entered credentials and allows resubmission.
7. Continuation. The student reads the result and signs out, or re-runs the lookup.

Flow C — A staff member signs in and browses the register

1. Starting context. A staff member has been provisioned access by the institution and needs to review the stored result records.
2. Landing. The Landing page loads anonymously; the staff member selects "Staff sign in".
3. Verification. On Login, the staff member submits their credentials. The back end verifies them against their provisioned staff identity.
4. Observable result of step 3. The staff member is routed by role to Result Records.
5. Browsing. Result Records presents the durable collection as a ruled register: aligned label/value rows separated by hairlines, tabular numerals, no row striping.
6. Finding a record. The staff member narrows the collection by student identifier or examination period.
7. Observable result of step 6. The register shows the matching records, or a distinct no-match state that can be cleared to return to the full list.
8. Failure and recovery. If the collection cannot be loaded, a message appears with a retry; retrying reloads the register.
9. Continuation. The staff member opens a record in the Result Editor or begins a new one.

Flow D — A staff member enters a new student result record

1. Starting context. The staff member is signed in and on Result Records, having just received a set of marks to record.
2. Beginning the record. The staff member selects the action to begin a new record and arrives at the Result Editor with an empty form and one empty subject entry.
3. Entry. The staff member enters the student identifier, the examination period, the subject entries with their marks and grades, and the final grade, adding subject entries as needed.
4. Commitment. The staff member saves the record.
5. Back-end execution. The back end validates and persists the new record.
6. Observable result of step 5. The staff member returns to Result Records with the new record reflected in the register.
7. Downstream effect. The student named in that record can now look up their result and receive these marks and grades.
8. Failure and recovery. Missing or invalid values — including no subject entry or an invalid final grade — are flagged per field and the record is not saved; a back-end save failure preserves everything entered and allows a retry. Cancelling returns the staff member to Result Records without creating a record.
9. Continuation. The staff member opens another record or begins another new one.

Flow E — A staff member corrects an existing result record

1. Starting context. The staff member is signed in and on Result Records, having found a record that contains a wrong mark.
2. Opening the record. The staff member opens the record and arrives at the Result Editor, which loads the record's current values.
3. Correction. The staff member changes the affected subject entry's marks or grade, or the final grade, and adds or removes subject entries as needed.
4. Commitment. The staff member saves the changes.
5. Back-end execution. The back end validates and persists the update.
6. Observable result of step 5. The staff member returns to Result Records with the corrected values reflected in the register.
7. Downstream effect. A subsequent student lookup returns the corrected marks and grades rather than the previous ones.
8. Failure and recovery. Validation errors are flagged per field and nothing is saved; a back-end save failure preserves the changes and allows a retry; cancelling returns the staff member to Result Records with the record unaltered.
9. Continuation. The staff member opens another record or signs out.

Flow F — A student's lookup finds no record yet

1. Starting context. A signed-in student submits their identifying details on the Results page.
2. Back-end execution. The back end finds no stored result record matching the submitted details.
3. Observable result. The Results page states clearly that no result matches the submitted details, and the student's inputs remain in place.
4. Recovery. The student corrects the identifying details and submits again, or stops and returns later.
5. Continuation. Once a staff member enters the record (Flow D), the student's next lookup succeeds and the result sheet appears.

6. Visuals, Colors and Theme

The visual direction is authoritative for this section. The muse is Kenya Hara, and the headline idea is "emptiness as the interface" — vast paper space, one calm object, a single thin rule, and type that whispers so that the mark can speak. The interface must get out of the way of one fact.

Color tokens

Light mode (primary):

Rules of use. No colour is ever used as a fill for a button rectangle. Colour appears only as rule, stamp, underline, or type. The accent #A8452E appears exactly once per screen: the grade stamp, the primary CTA underline, or a validation mark. Blue and indigo are forbidden anywhere, including links and focus rings.

Typography

• Headings: Zen Old Mincho, weights 300–400 only, wide letter-spacing (0.02em–0.06em), leading 1.35, sentence case — never all-caps except 11px tracked labels.
• Body: Zen Kaku Gothic New.
• Numerals: Zen Kaku Gothic New at weight 500, so marks and grades have mechanical clarity against the serif.
• Scale (1.5 modular, mobile → desktop):
  • Display: clamp(44px, 8.5vw, 104px)
  • H2: 28px → 40px
  • H3: 20px → 24px
  • Body: 16px → 17px at 1.7 leading
  • Label: 11px, tracked 0.16em, uppercase
  • Result numeral: 40px → 72px, tabular

Shape language

Almost no shape. Square corners everywhere (radius 0–2px). Structure is carried by 1px hairlines in #3E4A3C at 20–35% opacity and by empty space, not by cards. The only soft object is the result sheet: a #FBF9F4 panel with a 1px rule border and a 2px left rule in #A8452E, casting no shadow — it sits on the page like a sheet of paper on a desk. Inputs are underline-only: a 1px bottom rule that thickens to 2px in #3E4A3C on focus, with the accent red used only for error.

Layout

• Student flows: a single centred column of max 640px, inside a page with 96px+ side margin at 1280px and 24px at 375px.
• Staff Result Records: a wider 1120px ruled ledger — aligned label/value rows separated by hairlines, no zebra striping, no card grid.
• Section rhythm is vertical and slow: each result block separated by a 1px full-column rule and 64–96px of air.
• Navigation is a single thin top rule with the wordmark left, three text links centre, one text link right; no filled nav bar, no logo chip.
• Every page opens with a small tracked label (e.g. "SEMESTER 4 · 2024–25") above a large light serif title, then a long pause before content.

Imagery

No stock photography, no illustrations, no icons beyond 1px geometric marks. Imagery is material: a subtle paper grain overlay at 3% opacity across the ground; one full-bleed still-life photograph of a single object (a folded transcript, a hand resting on paper, an empty lecture-hall chair) used once on the Landing page as a 40vh band with no text over it; and thin topographic/rule diagrams for the admin ledger. The result itself is the imagery — big numerals on paper.

7. Signature Design Concept

The first screen is mostly empty paper.

The Landing page is a stacked, left-aligned editorial title page — not a centred SaaS hero, and with no image behind the text.

• Top 120px: a hairline rule with the wordmark left and "Student" / "Staff" text links right.
• Then ~14vh of pure #F4F1EA emptiness — no element at all. Roughly 40% of the viewport carries nothing.
• Then a small tracked uppercase label: "COLLEGE RESULT CHECKING".
• Then the display line: "Your result, in quiet." set in Zen Old Mincho 300 at clamp(44px, 8.5vw, 104px), left-aligned, wrapping to three lines and occupying the left 9 columns of a 12-column grid at 1280px.
• Below it: a 1px rule spanning the full column, then one 17px line of body copy in #8C877A, then two text links — "Check a result →" underlined in #A8452E and "Staff sign in" in #3E4A3C — pinned beneath, sitting on the baseline of the rule, not in buttons.
• The right third of the viewport is empty paper.
• Below the fold: one full-bleed 40vh still-life photograph band, then the process explained as three numbered ruled rows.

The only colour on the first screen is one persimmon-red underlined text link. Nothing overlaps the headline, the label, or the links at any width; the headline scales down and wraps rather than being cropped.

The same signature carries through the product: the result sheet on Results (a single #FBF9F4 sheet with a 2px #A8452E left rule, hairline-separated subject rows, and the final grade as a 72px numeral with a circular persimmon seal-stamp beside it), underline-only inputs and text-link CTAs everywhere, and the staff ledger on Result Records as a full-width ruled register with tabular numerals right-aligned and a thin vertical rule between every column.

8. Interaction Model & Motion Direction

Interaction Model: Static (direction) Motion Tempo: still Hero Dimensionality: flat

Landing Hero Motion Brief

• Focal subject. The display line "Your result, in quiet." set in Zen Old Mincho 300, left-aligned on empty paper, with the two text links sitting on the baseline of a 1px rule beneath it.
• Input → transformation → outcome thesis. On load, the page presents its composed first frame immediately; the only transformation is the 400ms opacity crossfade that brings the page in, and the 200ms left-to-right underline draw on hover over "Check a result →" and "Staff sign in". The outcome is a still, composed title page in which the visitor's eye lands on one line and one route.
• Motion vocabulary. Slow opacity crossfades (400ms), a single 600ms fade-in for the result sheet with a one-time 900ms ease-out count-up of its numerals, and a 200ms left-to-right underline draw on link hover. No parallax, no floating, no hover-lift, no bounce.
• Composed first frame. Hairline rule with wordmark left and "Student" / "Staff" right; ~14vh of empty #F4F1EA; the tracked label; the three-line display headline occupying the left nine columns; a full-column 1px rule; one line of #8C877A body copy; the two text links on the rule's baseline; the right third of the viewport empty.
• Reduced-motion state. With prefers-reduced-motion, everything appears immediately: no crossfade, no count-up on the result numerals, and the hover underline appears instantly rather than drawing.

9. Non-Functional Requirements

NFR-1 — Deployability (explicit) The application must be deployable as a running system. Both the front end and the back end must be deployable together, and the deployed front end must be able to reach the deployed back end. Rationale: the authoritative thread states the application must be deployable.

NFR-2 — Two-part architecture (explicit) The application must include both a back end and a front end. The back end owns persistence and execution; the front end renders and requests. Rationale: the authoritative thread states both a back end and a front end are required.

NFR-3 — Durable persistence (required_inference) Identity records and result records must survive restarts of the back end, because a student's result and a staff member's register must remain available across sessions and deployments. Rationale: required to make the accepted lookup and record-management journeys executable.

NFR-4 — Result privacy (required_inference) A result lookup must return only the requesting student's own result. No student may read another student's marks or grades through the Results page. Rationale: required to make the accepted student journey truthful — the result is private to the student.

NFR-5 — Staff-only record management (required_inference) Result Records and Result Editor must be reachable only by a verified staff identity. Rationale: required to keep the durable register under institutional control.

NFR-6 — Readable text and controls at every viewport (explicit, from the creative direction) Headlines, wordmarks, labels, numbers, and controls must stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling (for example font-size: clamp(...) with its mobile size) to fit, and no other element may cover any part of them. Imagery, decoration, and motion may be cropped, bled off an edge, rotated, overlapped, or cut as the direction asks, provided they cover no readable text or control. Rationale: stated as a hard readability rule in the creative direction.

NFR-7 — Reduced-motion support (explicit, from the creative direction) With prefers-reduced-motion, everything appears immediately: no count-up on result numerals, no crossfade, and hover underlines appear instantly. Rationale: stated in the creative direction's motion specification.

NFR-8 — No blue or indigo, no filled buttons (explicit, from the creative direction) Blue and indigo are forbidden anywhere, including links and focus rings. No filled coloured buttons, pill buttons, or buttons with a solid background may appear. Rationale: stated as an explicit avoidance in the creative direction.

10. Tech Stack

The authoritative thread specifies only that the application must be deployable and must include both a front end and a back end. It names no framework, language, or database. The following are therefore labeled defaults.

• Front end: React — [Default — not specified by user]. A browser application is required by the accepted journeys; React is the default choice for it.
• Back end: Python with FastAPI — [Default — not specified by user]. A server application owning identity, lookup, and record writes is required; FastAPI is the default choice for it.
• Storage: a relational database appropriate to the deployment, holding identity records and result records — [Default — not specified by user]. Durable persistence is required by NFR-3.
• Packaging and deployment: Docker with docker-compose for local and single-host deployment — [Default — not specified by user]. Deployability is an explicit requirement; container packaging is the default way to satisfy it.
• Orchestration: Kubernetes is not required by any accepted requirement and is not included. It may be added only if a deployment target demands it.

11. Assumptions and Constraints

Assumptions

• A-1. The college operates a single institution with one student population and one administrative team. Labeled assumption; the source names one college.
• A-2. A student's identifying details submitted at lookup time are sufficient to resolve their own stored result record. Labeled assumption; the source requires a lookup but does not name the exact identifying fields.
• A-3. A result record contains an examination period, one or more subject entries with marks and grades, and a final grade. Labeled assumption; the source requires subject marks and grades and a result, and this is the minimum structure that carries them.
• A-4. Staff access is provisioned or invited by the institution rather than self-claimed. Required inference; staff-only record management must be bound to the correct staff member.
• A-5. Students self-establish access without an invitation. Required inference; the source establishes no separate student enrollment or provisioning boundary.

Constraints

• C-1. The application must be deployable. (explicit)
• C-2. The application must include both a back end and a front end. (explicit)
• C-3. The page inventory in Section 2c is final and ordered: Landing, Sign Up, Login, Results, Result Records, Result Editor. No page is added, removed, merged, split, renamed, or reordered.
• C-4. Landing, Sign Up, and Login are reachable without an existing session. Results is restricted to the signed-in student. Result Records and Result Editor are restricted to signed-in staff.
• C-5. The visual direction in Sections 6–8 is binding: the palette, the two font families, the square-corner and hairline shape language, the underline-only inputs and text-link CTAs, the still motion tempo, and the flat hero dimensionality.
• C-6. The generic indigo/blue-on-white SaaS template is forbidden for this project.

Out of scope (current horizon)

Fee payment, course registration, admissions, timetabling, attendance, student–staff messaging, grade appeals, transcript issuance, analytics dashboards, and any capability not listed in Section 3. No future-horizon requirements were accepted in the authoritative thread.

12. Glossary

• Result — the outcome of a student's examination for a given examination period: the subject entries with their marks and grades, plus the final grade.
• Result record — the durable stored entry for one student in one examination period, containing the student identifier, the examination period, the subject entries, and the final grade. Result records are what student lookups resolve against.
• Subject entry — one subject within a result record, carrying the subject code, the marks obtained, and the grade awarded.
• Final grade — the single overall grade for a result record, presented as the prominent numeral on the result sheet.
• Result sheet — the single surface panel on the Results page that presents a student's returned result: hairline-separated subject rows and the final grade with a seal-stamp mark.
• Register — the ruled ledger presentation of the result-record collection on the Result Records page: aligned label/value rows, tabular numerals, a thin vertical rule between columns, and no row striping.
• Lookup — the student's action of submitting identifying details on the Results page to retrieve their own result.
• Student — the active human persona who reads their own result.
• College Staff / Result Administrator — the active human persona who enters and maintains result records under institutionally provisioned access.
• Provisioned access — staff access granted or invited by the institution, as distinct from a student's self-established access.
• Examination period — the term or semester a result record belongs to, shown as a tracked label above the result sheet and used to narrow the register.