System Requirements Document for math-science-homework

1. Introduction

math-science-homework is a web application that helps students with math and science homework. A student brings a homework problem — algebra, chemistry, physics, or similar — and the app returns a step-by-step explanation of how the problem is solved, so the student understands the method rather than only receiving a final answer.

The product intent is comprehension, not answer delivery. The app exists so that a student working alone at night on an algebra, chemistry, or physics problem can follow a legible, ordered method: the problem statement and its given data stay visible while the numbered solution steps advance, and each step is labelled, sequenced, and checkable.

The audience is any student — not only the original requester. Any student can create their own account, return later, and resume getting homework help. The product is delivered as a first-party web application with application-owned identity, a public landing surface, a self-service identity surface, and a protected homework-help workspace.

2. System Overview

math-science-homework is a browser-delivered web application. It has three current pages:

• Landing — the anonymous public entry. It explains what the app does, who it is for, and how it works, and it offers the entry action into the product.
• Login — the identity surface. A student creates their own account here, and a returning student verifies their identity here to resume homework help.
• Homework Help — the protected core workspace. A signed-in student submits a math or science homework problem and receives a step-by-step explanation they can follow to understand and complete the problem.

Actors. The only active human actor is the Student. The application itself owns identity, session continuity, problem intake, and the generation and presentation of step-by-step explanations. There are no other human roles, no instructors, no administrators, and no differentiated permission tiers: every signed-in student has the same access to the same product behavior over their own work.

Accepted behavior. A student can (a) learn what the app is from the public entry, (b) create their own account, (c) verify their identity on return, (d) submit a math or science homework problem, (e) receive a step-by-step explanation that shows the method, and (f) keep the problem statement, given data, and units in view while working through the steps.

Exclusions. This document does not add grading, class rosters, teacher dashboards, social or sharing features, cross-device sync, payment, or content-authoring tools. Nothing in the accepted requirement thread asks for them.

2a. Product Interpretation and Delivery Boundary

Delivery. The product is a first-party web application. The student interacts with custom pages owned by the application; there is no provider-owned or external-only surface in the current scope, and no headless-only delivery.

Access ownership. Identity is application-owned. The Landing page is anonymously reachable and carries no protected state. The Login page is anonymously reachable because a student who has no account yet must be able to create one, and a returning student who is not yet verified must be able to verify — a protected destination cannot own the interaction that establishes access to itself. Homework Help is protected: it requires a verified student identity, because a student's submitted problems and their step-by-step explanations are durable, student-specific work that must remain bound to the correct student and be resumable on return.

Current vs. future. Everything described in sections 2 through 5 is current. No future-horizon requirements were accepted in the authoritative thread; section 11 records the narrow assumptions that hold the current scope together.

2b. Source Content Inventory

No reference directive in this project declares content_source authority, so no source content inventory is included.

2c. Page Content and Component Coverage

Landing

• Information and state. Anonymous, no protected state. States the product's purpose (help with math and science homework), its audience (any student), and its method (step-by-step explanations, not just answers). No student data is shown.
• Primary action. Start a problem — the entry action that leads a student into the product. Because the student is not yet verified, this action routes to the Login surface to establish or verify identity before protected work begins.
• Supporting actions. A secondary, lower-emphasis path for a student who already has an account and wants to verify identity directly.
• Domain entities. None persisted. The page presents product description content only.
• Component responsibilities.
  • Hero composition — the asymmetric poster composition described in section 7: a ruled problem-statement block in the left rail and the oversized flush-left display headline in the right field, with the vermilion bar and the Start a problem control beneath it.
  • Problem-statement block — a real worked problem shown as a statement plus label/value given-data pairs, demonstrating the product's method without being a live submission.
  • Method preview — a numbered, rule-separated sequence of steps illustrating how an explanation is presented, with the active-step marker on one step.
  • Category tabs — the colour-coded math / science / check chips used as wayfinding.
  • Entry control — the Start a problem action and the returning-student path.
• States.

• Loading — static content; no data fetch is required to render the page.
• Empty — not applicable; the page always has descriptive content.
• Success — the page renders fully and the entry control is reachable.
• Error — if the entry action cannot reach the identity surface, the control reports the failure inline and remains retryable.
• Recovery — the student can retry the entry action or reload the page; no state is lost because none is held.

Login

• Information and state. Anonymous, no protected state. Two modes on one surface: creating a new student account, and verifying an existing student's identity. The surface states which mode is active and what is required.
• Primary action. Create account in enrollment mode; Sign in in returning mode. Both are self-service — no invitation, provisioning, or administrator involvement.
• Supporting actions. Switching between the two modes; correcting a rejected input and resubmitting.
• Domain entities. Student identity (the student's own account, created by the student), and the session that carries verified identity into Homework Help.
• Component responsibilities.
  • Mode switch — moves between account creation and returning verification without leaving the surface.
  • Credential form — collects the student's identity inputs; labels are explicit and inputs are hard-edged with no border radius.
  • Submit control — the black rectangular action, flush-left, uppercase.
  • Inline validation and error region — reports missing, malformed, or rejected inputs next to the field concerned, and reports a failed verification attempt without discarding what the student typed.
• States.
  • Loading — the submit control shows a pending state while the identity request is in flight and is not double-submittable.
  • Empty — the form renders with empty fields and no error text.
  • Success — account creation succeeds and the student proceeds to Homework Help; or verification succeeds and the student resumes Homework Help.
  • Error — invalid or incomplete input, or a rejected verification attempt, is reported inline; the student's entered values are preserved.
  • Recovery — the student corrects the input and resubmits, or switches modes if they chose the wrong one.

Homework Help

• Information and state. Protected; requires a verified student identity. Holds the student's current problem and its step-by-step explanation. The problem statement, given data, and units remain visible in the left rail while the solution column advances.
• Primary action. Submit a problem — the student enters a math or science homework problem and requests the step-by-step explanation.
• Supporting actions. Choosing the subject category (math or science) so the explanation is framed correctly; marking a step as check this; scrolling the solution column while the left rail stays pinned; starting another problem.
• Domain entities. The submitted problem (statement, given data with labels and units, subject category), and the resulting explanation as an ordered sequence of numbered steps, each with its own heading and body.
• Component responsibilities.
  • Problem intake — the input where the student enters the problem statement and its given data, with the subject category selector.
  • Left rail — the pinned problem statement, given data, and units, so the student never loses sight of the question.
  • Solution column — the numbered, rule-separated step blocks, each opened by an oversized tabular step numeral and closed by a 1px rule.
  • Active-step marker — the 6px vermilion bar that wipes down the left rail to the current step.
  • Category tabs — the 4px colour-coded chips with uppercase tracked labels (blue = math, green = science, yellow = check).
  • Diagram block — where a step calls for it, a pure geometric line drawing (axis-and-vector, free-body, molecule skeleton, unit-circle arc, periodic-table cell) cropped to the grid and flush-left with the text it explains, with the unknown rendered in vermilion.

• Step heading hover rule — a 1px vermilion rule drawn instantly under a step heading on hover.
• States.
  • Loading — while the explanation is being produced, step blocks slide in from the left on a 180ms linear-out as the explanation streams, and the active-step bar advances to the current step.
  • Empty — before any problem is submitted, the workspace shows the intake with no steps and no stale content from a previous problem.
  • Success — the full numbered sequence is present, each step readable, and the student can follow the method to complete the problem.
  • Error — if the explanation cannot be produced, the workspace reports the failure in place of the step sequence, keeps the student's submitted problem statement and given data intact, and offers a retry.
  • Recovery — the student retries the same problem, edits the problem statement or given data and resubmits, or starts a new problem; the previous problem's content is not silently mixed into the new one.

3. Functional Requirements

FR-1 — Understand what the app is before signing in As a Student, I should be able to read what math-science-homework does, who it is for, and how it helps me, before I create an account, so that I can decide whether to use it.

• Provenance: explicit (product purpose and audience) with required_inference for the anonymous public entry surface.
• Lifecycle: initiated by an anonymous visitor on Landing; input is none; observable result is a rendered description of the product, its audience, and its step-by-step method; access state is anonymous with no protected state shown.
• Failure/recovery: if the page cannot render its entry control, the control reports the failure inline and remains retryable.
• Continuation: the student uses the entry action to proceed toward identity establishment.

FR-2 — Create my own account As a Student, I should be able to create my own account, so that I can begin using the product without needing an invitation or an administrator.

• Provenance: required_inference (indispensable prerequisite for the accepted current journey; self-service chosen because the audience is any student and no source establishes invitation, provisioning, or deployment bootstrap).
• Lifecycle: initiated by an anonymous visitor on Login in enrollment mode; input is the student's identity inputs; observable result is a created student account and a verified session; access state is anonymous before submission and verified after.
• Failure/recovery: missing, malformed, or rejected input is reported inline next to the field concerned, the student's entered values are preserved, and the student can correct and resubmit.
• Continuation: on success the student proceeds to Homework Help.

FR-3 — Verify my identity to resume homework help As a returning Student, I should be able to verify my identity, so that I can get back to my homework help.

• Provenance: required_inference (indispensable for resuming durable, student-specific work).
• Lifecycle: initiated by an anonymous returning visitor on Login in returning mode; input is the student's identity inputs; observable result is a verified session bound to that student's own work; access state is anonymous before submission and verified after.
• Failure/recovery: a rejected verification attempt is reported inline without discarding what the student typed; the student can retry or switch to account creation if they do not yet have an account.
• Continuation: on success the student resumes Homework Help.

FR-4 — Submit a math or science homework problem As a Student, I should be able to submit a math or science homework problem, so that I can get help with the assignment I am working on.

• Provenance: explicit.
• Lifecycle: initiated by a verified Student on Homework Help; input is the problem statement, its given data with labels and units, and the subject category (math or science); observable result is the submitted problem held in the workspace with its explanation requested; access state is protected — a verified student identity is required.
• Failure/recovery: if the submission cannot be accepted, the workspace reports the failure and keeps the student's entered problem statement and given data intact so nothing must be retyped.
• Continuation: the explanation is produced and presented as the numbered step sequence.

FR-5 — Receive a step-by-step explanation, not just an answer As a Student, I should receive a step-by-step explanation of my problem, so that I understand the steps and can complete the problem myself rather than only copying a final answer.

• Provenance: explicit.
• Lifecycle: initiated by the Student's submission on Homework Help; input is the submitted problem; observable result is an ordered sequence of numbered steps, each with its own heading and body, presented as rule-separated blocks; access state is protected.
• Failure/recovery: if the explanation cannot be produced, the workspace reports the failure in place of the step sequence, preserves the submitted problem, and offers a retry.
• Continuation: the student reads and follows the steps to complete the assignment, or starts another problem.

FR-6 — Keep the question in view while working through the method As a Student, I should keep the problem statement, its given data, and its units in view while I move through the solution steps, so that I never lose sight of what I am solving.

• Provenance: explicit (the app must help the student understand the steps of a problem) with required_inference for the pinned-rail mechanics that make the method followable.
• Lifecycle: initiated by the Student scrolling the solution column on Homework Help; input is scroll position; observable result is the left rail remaining pinned with the problem statement, given data, and units while the solution column advances, and the active-step marker tracking the current step; access state is protected.
• Failure/recovery: if the rail cannot stay pinned, the problem statement remains reachable in the workspace rather than being lost.
• Continuation: the student continues through the remaining steps.

FR-7 — Mark a step to check As a Student, I should be able to mark a step as one to check, so that I can flag the part of the method I am unsure about and come back to it.

• Provenance: explicit (the creative direction's accepted "check this" category signal) — the check affordance is part of the accepted presentation of a solution.
• Lifecycle: initiated by the Student on Homework Help; input is the student's selection of a step; observable result is that step carrying the check signal; access state is protected.
• Failure/recovery: if the mark cannot be applied, the step remains readable and unmarked and the student can retry.
• Continuation: the student continues through the solution with the flagged step identifiable.

FR-8 — Start another problem As a Student, I should be able to start another problem, so that I can keep working through my homework without leaving the product.

• Provenance: required_inference (continuation of the accepted core journey).
• Lifecycle: initiated by the Student on Homework Help; input is the student's choice to begin a new problem; observable result is a cleared intake with no stale content from the previous problem; access state is protected.
• Failure/recovery: if the workspace cannot be cleared, the student is told and the previous problem is not silently mixed into the new one.
• Continuation: the student submits the next problem.

4. User Personas

Student

Product context. The Student is any student — the requester and every other student like them — working on math and science homework, typically alone, often at night, on algebra, chemistry, or physics problems. They are frequently confused and sometimes anxious about the material, and they need clarity and authority rather than playfulness. They arrive with a specific problem in front of them and a deadline behind it.

Primary goal. To understand the steps of the problem in front of them well enough to complete the assignment themselves — not merely to obtain a final answer to copy.

Distinct accepted responsibilities.

• Deciding whether the product is worth using, from the public entry, before committing to an account.
• Creating their own account, self-service, with no invitation or administrator.
• Verifying their identity on return so they can get back to their homework help.
• Entering the problem statement and its given data, with labels and units, and choosing whether it is a math or a science problem.
• Reading and following the numbered steps, keeping the question in view, and flagging a step they need to check.
• Starting another problem when the current one is done.

Relevant inputs and decisions. The problem statement and its given data; the subject category (math or science); which step they are unsure about; whether to retry a problem that failed to produce an explanation or to edit and resubmit it.

Interactions with other accepted participants. The Student is the only active human actor. Their work is mediated entirely by the application: the application owns their identity, holds their submitted problem, produces the step-by-step explanation, and presents the method. There is no instructor, grader, or peer in the current scope.

Observable success. The Student reaches a numbered, rule-separated explanation whose steps they can follow, with the original problem statement, given data, and units still visible beside it, and they can complete the problem themselves. On return, they verify their identity and get back to their homework help.

What makes this role distinct. The Student is simultaneously the requester of help and the person who must do the understanding. Every accepted behavior is shaped by that: the product must show method rather than output, must keep the question visible while the method advances, and must let the student flag the part they are unsure of — none of which would be true of a role that only wanted answers or that was accountable for someone else's learning.

5. Core User Flows

Flow A — A new student discovers the app and starts working

1. Starting context. A student has a math or science homework problem in front of them and has not used the product before. They are not signed in.
2. On Landing, the student reads what the app does, who it is for, and that it explains problems step by step rather than only giving answers. The hero shows a real problem statement with its given data and a preview of the numbered method, so the student can see the shape of the help before committing.
3. The student selects Start a problem. Because they are not yet verified, this routes them to Login rather than into protected work.
4. On Login, the student switches to enrollment mode and enters their identity inputs, then submits Create account.
5. Observable result. The account is created and the student's session is verified. If any input is missing, malformed, or rejected, the error appears inline next to the field concerned, the student's typed values are preserved, and they correct and resubmit.
6. Next step. The student arrives at Homework Help and submits their first problem (Flow C).

Flow B — A returning student resumes homework help

1. Starting context. A student who already has an account returns to the product, not signed in, with homework still to finish.
2. On Landing, the student takes the returning-student path to Login.
3. On Login, the student enters their identity inputs and submits Sign in.
4. Observable result. The session is verified and bound to that student's own work. If verification is rejected, the error is reported inline without discarding what the student typed; the student retries, or switches to account creation if they do not yet have an account.
5. Next step. The student resumes Homework Help and continues with their homework.

Flow C — A student submits a problem and follows the steps

1. Starting context. A verified student is on Homework Help with a specific problem to solve.
2. The student enters the problem statement and its given data, with labels and units, and chooses the subject category — math or science.
3. The student submits the problem.
4. Observable result (in progress). The explanation streams in: step blocks slide in from the left on a 180ms linear-out, and the 6px vermilion active-step bar wipes down the left rail to the current step.
5. Observable result (complete). The workspace shows an ordered sequence of numbered steps, each opened by an oversized tabular step numeral and closed by a 1px rule, with the student's problem statement, given data, and units pinned in the left rail. Where a step calls for it, a geometric line diagram — axis-and-vector, free-body, molecule skeleton, unit-circle arc, or periodic-table cell — sits flush-left with the text it explains, with the unknown drawn in vermilion.
6. The student scrolls the solution column. The left rail stays pinned with the question, so the student never loses sight of what they are solving, and the active-step marker tracks their position.
7. Where the student is unsure, they mark that step as one to check, and the step carries the check signal so they can find it again.
8. Failure and recovery. If the explanation cannot be produced, the workspace reports the failure in place of the step sequence, keeps the student's submitted problem statement and given data intact, and offers a retry. The student retries the same problem, or edits the statement or given data and resubmits.
9. Next step. The student follows the steps to complete the problem themselves, then starts another problem (Flow D).

Flow D — A student starts another problem

1. Starting context. A verified student has finished working through one problem on Homework Help and has another to do.
2. The student chooses to start another problem.
3. Observable result. The intake is cleared with no stale content from the previous problem; the previous problem's steps are not mixed into the new one.
4. Next step. The student submits the next problem and returns to step 2 of Flow C.

6. Visuals, Colors and Theme

The creative direction is authoritative for this section. Muse: Josef Müller-Brockmann; headline: Swiss geometric rigour for the blackboard of the web.

Mode. Light mode only.

Colour tokens by role.

The category colours appear only as 4px category tabs and step-number chips — never as large fills. No gradients anywhere. The generic indigo/blue-on-white SaaS template is forbidden for this project; blue is only the math category chip.

Typography. Headings and body both in Archivo.

• Headings: flush-left, ragged-right, never centred; weight 700–800; tracking -0.02em.
• Labels and step numbers: 11px uppercase, 0.14em tracking.
• Numerals are the ornament: tabular, oversized, set in the grid as step markers.
• Body: weight 400, 17px / 1.65 line height, held to a 62-character measure.
• Scale: 1.333 modular — 88 / 66 / 44 / 28 / 20 / 17 / 14 / 11px, with clamp() so display steps down to 40 / 32px on mobile.

Shape language. Hard edges, zero border-radius on every container, button, and input. Geometry is the content: circles, quarter-circles, and ruled rectangles drawn in black hairline or solid vermilion. Rules are 1px at full column width. The only thick element is the 6px vermilion bar marking the active step. Everything aligns to a visible 12-column grid with 24px gutters, and grid lines are sometimes printed faintly on the surface.

Layout. A strict 12-column modular grid, asymmetric: a 3-column left rail holds the problem statement, units, and given data; the 9-column right field holds the numbered solution steps. Step blocks are separated by full-bleed 1px rules, not cards. On the landing page the grid is exposed and labelled in the margin ("col 1–3: the problem", "col 4–12: the method"). Mobile collapses to a single column with the step-number chip pinned to the left edge of each step.

Spacing rhythm. 24px gutters; full-bleed 1px rules as the primary separator; generous vertical rhythm between step blocks so each reads as a sheet of paper on a desk.

Imagery style. No photography, no illustration. Imagery is diagrammatic: axis-and-vector line drawings, free-body diagrams, molecule skeletons, unit-circle arcs, and periodic-table cells drawn as pure geometry in black with one vermilion element showing the unknown. Every diagram is cropped to the grid and flush-left with the text it explains.

Readable text and controls. Headlines, wordmarks, labels, numbers, card text, and controls 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, with no other element covering any part of them. Imagery, decoration, and motion may be cropped, bled, rotated, overlapped, or cut as the direction asks, provided they cover no readable text or control.

7. Signature Design Concept

The poster that is also a worked solution.

The public entry is a full-viewport asymmetric composition on warm paper-white (#F4F2ED), built on the exposed 12-column grid.

• Left 3 columns. A black ruled block containing a real problem statement — "A 2.5 kg block slides down a 30° incline, μ = 0.15. Find its acceleration." — set at 28px, with its given data listed beneath as label/value pairs. This is the question, held in the rail exactly where it will stay during real use.
• Right 9 columns. An oversized display headline in Archivo 800 at clamp(40px, 9vw, 88px), flush-left, tight tracking, reading "SHOW ME / THE STEPS." The second line is indented to column 5, so the two lines bracket the white space between them — the gap is part of the composition, not leftover margin.
• Beneath the headline. A single 6px vermilion bar runs the full width of the right field. The CTA "Start a problem" sits flush-left under the bar as a black rectangle with white 14px uppercase text.
• Margin labels. The grid is labelled in the margin — "col 1–3: the problem", "col 4–12: the method" — so the page teaches the product's own information design before the student has submitted anything.
• No image, no gradient, no centred stack. The composition is a poster, not a SaaS hero.

The concept recomposes only accepted content and controls: the problem statement, the given data, the method preview, the category chips, and the entry action. It introduces no new behavior, page, or destination.

8. Interaction Model & Motion Direction

Interaction Model: Animated Motion Tempo: restrained Hero Dimensionality: flat

Landing Hero Motion Brief.

• Focal subject. The asymmetric poster composition: the ruled problem-statement block in the left rail and the oversized two-line display headline in the right field, joined by the 6px vermilion bar.
• Input → transformation → outcome thesis. As the student scrolls the entry page, the exposed grid's margin labels and the method preview advance in step with the solution column, so the composition demonstrates the product's own sequencing — the question stays in the rail while the method moves past it — and the student arrives at the Start a problem control already understanding how the app presents a solution.
• Motion vocabulary. Geometric and rhythmic. Step blocks slide in from the left on a 180ms linear-out. The 6px active-step bar wipes down the left rail to the current step. Hover on a step draws a 1px vermilion rule under its heading instantly. Scroll-linked: the left rail's problem statement stays pinned while the solution column advances. Nothing bounces; nothing fades decoratively.
• Composed first frame. Warm paper-white ground, faint printed grid lines, the black ruled problem block occupying columns 1–3, the two-line Archivo 800 headline flush-left across columns 4–12 with its deliberate column-5 indent, the full-width vermilion bar beneath it, and the black rectangular Start a problem control flush-left under the bar.
• Reduced-motion state. With prefers-reduced-motion, the composition renders as a static poster: no slide-in, no wipe, no scroll-linked pinning. The method preview wraps into rows so every step is fully readable, and the entry control remains reachable and whole.

No user-requested 3D/WebGL scene exists for this project, and the direction's hero dimensionality is flat, so no Canvas/R3F/Drei hero is required.

9. Non-Functional Requirements

• NFR-1 — Readable text and controls at every viewport. Headlines, wordmarks, labels, numbers, card text, and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling to fit, with no other element covering any part of them. Provenance: explicit (creative direction). Rationale: a student reading a worked solution on a phone at night must be able to read every step and reach every control.
• NFR-2 — Reduced-motion support. With prefers-reduced-motion, the product provides a usable static arrangement: step blocks appear without slide-in, the active-step bar does not wipe, scroll-linked pinning is disabled, and any row of items wraps or scrolls so each item can be brought fully into view. Provenance: explicit (creative direction). Rationale: motion is presentational here, never load-bearing.
• NFR-3 — No gradients, no border radius, no soft shadows. Every container, button, and input has zero border-radius; no gradients, glass panels, soft shadows, or floating cards appear anywhere. Provenance: explicit (creative direction). Rationale: the grid is the shape.
• NFR-4 — Protected work stays bound to the correct student. A student's submitted problems and their step-by-step explanations are accessible only within that student's verified session. Provenance: required_inference. Rationale: the accepted journey requires a returning student to resume their homework help, which is only meaningful if the work remains bound to the correct participant.
• NFR-5 — No cross-device sync. A student's work is not synchronized across devices in the current scope. Provenance: explicit boundary (no accepted requirement asks for it; the only persistence skill offered is explicitly local and states "No authentication or cross-device sync"). Rationale: keeps the current scope honest.

• NFR-6 — Streaming presentation of the explanation. The step sequence is presented progressively as it is produced, with the active-step marker tracking the current step, rather than appearing only when complete. Provenance: explicit (creative direction's motion vocabulary). Rationale: the student should be able to begin reading the method as it arrives.

10. Tech Stack

No technology choices were specified by the user. The following are coherent defaults for the accepted scope, labeled as defaults.

• Frontend: React (web), TypeScript. [Default — not specified by user]
• Backend: Python with FastAPI, serving the identity, problem-submission, and explanation endpoints. [Default — not specified by user]
• Storage: A relational database for student identities and submitted problems with their explanations. [Default — not specified by user]
• Explanation generation: A server-side AI service invoked by the backend to produce the step-by-step explanation. [Default — not specified by user]
• Packaging and run: Docker with docker-compose.yml for the frontend, backend, and database. [Default — not specified by user]
• Kubernetes: Not required for the current scope. [Default — not specified by user]

11. Assumptions and Constraints

• A-1. The audience is any student, not only the requester. This is explicit and governs every access and identity decision.
• A-2. Identity is application-owned and self-service. No invitation, provisioning, or deployment bootstrap is established by any source, so account creation is open to any student. required_inference.
• A-3. The Landing and Login surfaces are anonymously reachable; Homework Help requires a verified student identity. A protected destination cannot own the interaction that establishes access to itself. required_inference.
• A-4. There is exactly one active human role, the Student. No differentiated permissions, role-based visibility, or permission controls exist, because no source establishes differentiated control or visibility over shared product state. Every signed-in student has the same access to the same behavior over their own work.
• A-5. The product is delivered as a first-party web application with custom UI. No provider-owned, external-only, or headless delivery is accepted.
• A-6. The subject category is limited to math and science, matching the accepted product scope. No other subject areas are added.
• A-7. The "check this" signal is a student-applied mark on a step within their own solution, not a request routed to another person. No reviewer, instructor, or peer role exists.
• A-8. No future-horizon requirements were accepted. Everything in sections 2 through 5 is current scope.
• A-9. The creative direction is authoritative for section 6, section 7, and section 8, and its constraints (zero border-radius, no gradients, no photography, no mascots or emoji, no decorative animation) are binding on the implementation.

12. Glossary

• Student — the only active human actor. Any student who needs help with math and science homework and wants to understand the steps of a problem rather than only receive an answer.
• Problem statement — the homework question a student submits, together with its given data, labels, and units.
• Given data — the known quantities supplied with a problem, presented as label/value pairs with their units.
• Step — one numbered block of the explanation, opened by an oversized tabular step numeral and closed by a 1px rule, with its own heading and body.
• Active step — the step currently in view, marked by the 6px vermilion bar wiping down the left rail.
• Left rail — the 3-column region holding the pinned problem statement, given data, and units while the solution column advances.
• Solution column — the 9-column region holding the numbered, rule-separated step blocks.
• Category chip — the 4px colour-coded tab with an uppercase tracked label identifying math (blue), science (green), or check (yellow).
• Check this — the student-applied mark flagging a step they are unsure about and want to revisit.
• Vermilion — #E1341E, the single signal colour: active step, submit action, current-line underline, and the unknown in a diagram.
• Verified session — the state in which a student's identity has been established or confirmed, granting access to Homework Help.