System Requirements Document for indigo-bareilly

1. Introduction

This document specifies the requirements for indigo-bareilly, a campus navigation system for the RBMI Group of Institution, Bareilly branch. The system is built to run on a robot that assists visitors inside the college: a visitor physically present at the Bareilly campus who does not know the layout states or selects where they want to go, and the system returns a clear route from their current position to that destination.

The product intent is a wayfinding instrument, not a marketing site. It must be understood in three seconds from two metres away, work for a first-time visitor who may be a parent, a prospective student, an external examiner, or a delivery person, and it must be as fast as possible with a beautiful UI. Scope is limited to the RBMI Group of Institution Bareilly branch campus.

2. System Overview

indigo-bareilly is a first-party web application delivered as the interface of a visitor-assistance robot at the RBMI Group of Institution Bareilly branch. It presents a schematic campus plan of the Bareilly branch, lets a visitor choose or search a destination within that campus, and returns a step-by-step route from the visitor's current position to that destination.

Actors. The accepted active-human catalog is closed: Campus Visitor and Robot Navigation Assistant. The Campus Visitor is the person physically present at the campus who needs to reach a specific location. The Robot Navigation Assistant is the in-product role that serves the visitor at the robot — presenting the campus map, accepting the destination, and returning route guidance. No other personas are introduced.

Accepted behavior. The system provides a navigation map for the RBMI Group of Institution Bareilly branch; it is delivered for use on a robot that helps visitors navigate inside the college; it must be fast to load and respond; and it must have a beautiful UI.

Ownership. All three accepted destinations — Campus Map, Destinations, and Route — are application-owned custom pages with no access requirement. The robot is the delivery context for the interface; the interface itself is first-party.

Exclusions. No campus outside the RBMI Group of Institution Bareilly branch is in scope. No account, login, or identity management is introduced. No adjacent capabilities (timetabling, admissions, fee payment, staff directories beyond wayfinding labels, transport booking) are part of this product.

2a. Product Interpretation and Delivery Boundary

The product is a kiosk-style wayfinding surface mounted on a robot that moves through the RBMI Group of Institution Bareilly branch. It is anonymous by design: a visitor walks up, sees the campus plan, says or selects where they want to go, and receives a route. There is no sign-in, no profile, and no persistent visitor account, because the accepted journeys do not require a visitor to privately own or resume durable state — each visit is a self-contained wayfinding session.

The delivery boundary is the Bareilly branch campus only. The map, the destination catalog, and the routes all describe that one campus. Nothing in this document authorizes a multi-campus or inter-city navigation product, and nothing authorizes a mobile app, a public website, or a staff-facing administration console.

The current horizon covers the three accepted destinations and the visitor journeys they serve. Future ideas (multi-campus expansion, indoor positioning hardware integration, voice-only interaction, accessibility routing preferences) are explicitly out of the current scope and are recorded only in the future section.

2b. Source Content Inventory

Not applicable. No reference directive in the planning scope declares content_source, so no source content inventory is produced.

2c. Page Content and Component Coverage

The page contract is versioned and final. The three pages below are copied exactly, in order, with their access and identity ownership unchanged.

Campus Map

• Information and state. The schematic plan of the RBMI Group of Institution Bareilly branch, drawn on a strict orthogonal grid. The visitor's current position is shown as a "you are here" pin near the entrance. Category coding is visible as transit-line strokes and chip dots. The current selection state (no destination chosen / destination chosen) is reflected in the rail.
• Primary actions. Browse the campus plan; pan and zoom the plan; tap a category chip to filter the destination list; tap a room rectangle on the plan to select it as a destination; type into the search field to find a room, department, or person.
• Supporting actions. Reset the plan viewport; clear the search field; open the numbered key for rooms too small to label in place.
• Domain entities. Campus, Block, Floor, Room, Room Code, Category (Academic, Administration, Library, Hostel, Canteen, Sports, Medical, Parking), Current Position, Destination.
• Component responsibilities. Full-height deep-blue left rail carrying the institution wordmark, the question "Where do you want to go?", the search field, and the categorised destination list; campus plan surface on warm paper with the faint blueprint grid; "you are here" pin; category chip row; numbered key below the plan; room rectangles with in-place labels.
• States. Loading: the plan and destination list render a skeleton of the grid and rail rows. Empty: if a search returns no match, the rail shows a plain "No matching place" message with the search field still focused. Success: a destination is selected and the rail highlights the row while the plan highlights the corresponding rectangle. Error: if the campus plan data fails to load, the plan area shows a plain message and a retry control, and the rail remains usable for search. Recovery: retry reloads the plan without losing the current search text or selection.

Destinations

• Information and state. The full catalog of places within the RBMI Group of Institution Bareilly branch, grouped by category, each row showing the place name, its room code in Fira Sans Condensed, and its category dot. The currently selected destination, if any, is marked.
• Primary actions. Search or filter the catalog; select a destination to route to; confirm the selection and proceed to the route.
• Supporting actions. Clear the current selection; switch category filter; return to the map view.
• Domain entities. Destination, Category, Room Code, Floor, Block, Distance from current position, Estimated walk time.
• Component responsibilities. Search field pinned to the top of the viewport on mobile; category filter strip; categorised destination rows with instant 120ms tap highlight; selection confirmation control; empty and no-match messaging.
• States. Loading: destination rows render as skeleton rows. Empty: when a category has no entries, the list shows a plain message for that category. Success: a destination is selected and the confirmation control becomes active. Error: if the catalog fails to load, the list shows a plain message and a retry control. Recovery: retry reloads the catalog and preserves the active filter.

Route

• Information and state. The chosen destination name at display scale, the route drawn as a signal-red transit-style line over the campus plan, and the numbered step list. Each step shows a blue numeral square, the instruction, and the distance and estimated walk time right-aligned in Fira Sans Condensed small caps.
• Primary actions. Follow the numbered steps; tap a step to snap the map viewport to that segment; start over with a new destination.
• Supporting actions. Re-read the destination name and floor; return to the destination list; return to the campus map.
• Domain entities. Route, Route Segment, Step, Distance, Estimated Walk Time, Destination, Current Position.
• Component responsibilities. Route overlay on the plan with 45-degree rounded corners; numbered blue square step markers; step list of ruled rows; destination header; "start over" control.
• States. Loading: the route draws in with a 600ms stroke-dashoffset sweep; the step list renders as skeleton rows until the route is ready. Empty: if no destination has been chosen, the page shows the plan with the "you are here" pin and a prompt to choose a destination. Success: the route is fully drawn and the step list is complete. Error: if a route cannot be computed to the chosen destination, the page states plainly that no route is available and offers a return to the destination list. Recovery: choosing another destination recomputes the route without leaving the page.

3. Functional Requirements

Each requirement below is a distinct story point with provenance, lifecycle facts, and observable acceptance.

FR-1 — Campus navigation map for the Bareilly branch (explicit) As a Campus Visitor, I should see a navigation map of the RBMI Group of Institution Bareilly branch so that I can understand the campus layout.

• Trigger/input: the visitor approaches the robot; the Campus Map page loads.
• Observable result: the schematic plan of the Bareilly branch is displayed with labelled room rectangles, category coding, and the "you are here" pin.
• Access state: anonymous; no sign-in.
• Failure/recovery: if the plan fails to load, a plain message and retry control appear; retry reloads the plan.
• Continuation: the visitor can pan, zoom, filter by category, or search.

FR-2 — Robot-delivered visitor assistance (explicit) As a Robot Navigation Assistant, I should present the campus navigation map and route guidance on the robot so that a visitor at the robot can be helped without staff assistance.

• Trigger/input: a visitor stands at the robot.
• Observable result: the Campus Map page is the entry surface; the visitor can reach Destinations and Route from it.
• Access state: anonymous; the robot surface is the delivery context.
• Failure/recovery: if the interface fails to respond, the visitor can retry from the entry surface.
• Continuation: the visitor selects a destination and follows the route.

FR-3 — Fast load and response (explicit) As a Campus Visitor, I should get the map, the destination list, and the route quickly so that I am not kept waiting at the robot.

• Trigger/input: any page load, search keystroke, category filter, or route computation.
• Observable result: the interface responds without perceptible delay; the plan and lists render promptly.
• Access state: anonymous.
• Failure/recovery: if a request is slow, a loading state is shown rather than a blank surface.
• Continuation: the visitor proceeds once content is available.

FR-4 — Beautiful, legible UI (explicit) As a Campus Visitor, I should see a clear, well-designed interface so that I can read it from a standing distance and trust it.

• Trigger/input: any page view.
• Observable result: the interface follows the typographic and colour system in section 6, with readable type at distance and no decorative clutter.
• Access state: anonymous.
• Failure/recovery: not applicable to a static presentation requirement.
• Continuation: the visitor reads the map and acts.

FR-5 — Browse the campus plan (required_inference) As a Campus Visitor, I should browse the schematic plan of the Bareilly branch so that I can orient myself before choosing a destination.

• Trigger/input: the visitor pans or zooms the plan on the Campus Map page.
• Observable result: the plan pans and zooms; labels stay whole and inside their rectangles.
• Access state: anonymous.
• Failure/recovery: if the plan cannot be panned, the default view remains readable.
• Continuation: the visitor selects a room or opens the destination list.

FR-6 — Search for a place (required_inference) As a Campus Visitor, I should search for a room, department, or person so that I can find a destination I cannot locate on the plan.

• Trigger/input: the visitor types into the search field on the Campus Map or Destinations page.
• Observable result: matching destinations are listed; non-matching entries are removed.
• Access state: anonymous.
• Failure/recovery: if there is no match, a plain "No matching place" message is shown and the search field stays focused.
• Continuation: the visitor selects a match or clears the search.

FR-7 — Filter destinations by category (required_inference) As a Campus Visitor, I should filter destinations by category so that I can narrow the list to the kind of place I need.

• Trigger/input: the visitor taps a category chip (Academic, Administration, Library, Hostel, Canteen, Sports, Medical, Parking).
• Observable result: the destination list shows only that category; the chip is marked active.
• Access state: anonymous.
• Failure/recovery: if a category has no entries, a plain message is shown for that category.
• Continuation: the visitor selects a destination or switches category.

FR-8 — Select a destination (required_inference) As a Campus Visitor, I should select a destination from the list or the plan so that the system knows where I want to go.

• Trigger/input: the visitor taps a destination row or a room rectangle.
• Observable result: the row highlights with an instant 120ms background fill; the corresponding rectangle is highlighted on the plan; the confirmation control becomes active.
• Access state: anonymous.
• Failure/recovery: if the selection does not register, the visitor can tap again; the previous selection is preserved.
• Continuation: the visitor confirms and proceeds to the Route page.

FR-9 — Receive a route from current position to destination (required_inference) As a Campus Visitor, I should receive a route from my current position to the chosen destination so that I can walk there.

• Trigger/input: the visitor confirms a destination.
• Observable result: the Route page shows the destination name at display scale, the route drawn as a signal-red transit-style line over the plan, and the numbered step list.
• Access state: anonymous.
• Failure/recovery: if no route can be computed, the page states plainly that no route is available and offers a return to the destination list.
• Continuation: the visitor follows the steps.

FR-10 — Follow step-by-step route instructions (required_inference) As a Campus Visitor, I should follow numbered step instructions so that I can reach the destination without asking staff.

• Trigger/input: the visitor reads the step list or taps a step row.
• Observable result: each step shows a blue numeral square, the instruction, and the distance and estimated walk time; tapping a step snaps the map viewport to that segment in 250ms ease-out.
• Access state: anonymous.
• Failure/recovery: if the visitor loses their place, tapping the step re-snaps the viewport.
• Continuation: the visitor continues to the next step until arrival.

FR-11 — Start over with a new destination (required_inference) As a Campus Visitor, I should be able to start over with a new destination so that I can make a second trip or correct a wrong choice.

• Trigger/input: the visitor taps "start over" on the Route page.
• Observable result: the current route is cleared and the visitor returns to the destination selection surface.
• Access state: anonymous.
• Failure/recovery: if the reset does not register, the visitor can navigate back to the Campus Map.
• Continuation: the visitor selects a new destination.

FR-12 — Robot Navigation Assistant presents the map and route (required_inference) As a Robot Navigation Assistant, I should present the campus map, accept the visitor's destination, and return the route so that the visitor reaches the intended location.

• Trigger/input: the visitor interacts with the robot surface.
• Observable result: the Campus Map, Destinations, and Route pages are presented in sequence as the visitor progresses.
• Access state: anonymous.
• Failure/recovery: if a page fails to load, the assistant surface shows a plain message and a retry control.
• Continuation: the visitor completes the journey or starts over.

4. User Personas

Campus Visitor

Product context. A person physically present at the RBMI Group of Institution Bareilly branch who does not know the campus layout. They may be a parent, a prospective student, an external examiner, or a delivery person. They are often in a hurry, often reading Hindi-accented English, and sometimes have low literacy in wayfinding systems. They are standing in front of a robot kiosk in a lobby or corridor.

Primary goal. Reach a specific campus destination — a department, an office, a facility — without asking staff for help.

Distinct accepted responsibilities. State or select where they want to go; read the campus plan to orient themselves; choose a destination from the list or the plan; follow the numbered route steps to arrive.

Relevant inputs or decisions. The destination they need; whether to search by name or browse by category; whether to accept the shown route or start over with a different destination.

Interactions with other accepted participants. The Campus Visitor interacts with the Robot Navigation Assistant, which presents the map and returns the route. The visitor does not interact with any other human role in this product.

Observable success. The visitor arrives at the intended campus location without staff help, having followed the route from the robot.

What makes this role different. The Campus Visitor is the only human actor who initiates a wayfinding request and physically walks the route. Their work is defined by a single, time-pressured decision (where do I want to go?) followed by physical execution of the returned steps.

Robot Navigation Assistant

Product context. The in-product role that serves the visitor at the robot. It is the surface through which the visitor sees the campus map, states a destination, and receives route guidance. It is not a separate human operator; it is the robot's presentation role within the product.

Primary goal. A visitor who reaches the intended campus location without staff help.

Distinct accepted responsibilities. Present the campus navigation map; accept the visitor's destination; return the route guidance the visitor follows; keep the interface fast and legible at standing distance.

Relevant inputs or decisions. The visitor's stated or selected destination; the current position on the campus plan; the route computed to that destination.

Interactions with other accepted participants. The Robot Navigation Assistant serves the Campus Visitor directly and is the only participant on the robot side of the interaction.

Observable success. The visitor completes the journey from the robot to the chosen destination using the presented route.

What makes this role different. The Robot Navigation Assistant does not choose a destination and does not walk the route. Its work is presentation and handoff: it must make the map, the destination choice, and the route legible and fast enough that a first-time visitor can act on them in seconds.

5. Core User Flows

Flow A — Campus Visitor finds a destination by browsing the plan

1. The Campus Visitor approaches the robot at the RBMI Group of Institution Bareilly branch. The Campus Map page loads as the entry surface, showing the schematic plan of the Bareilly branch with the "you are here" pin near the entrance.
2. The visitor pans and zooms the plan to orient themselves. Room labels stay whole and inside their rectangles; the numbered key below the plan covers rooms too small to label in place.
3. The visitor taps a category chip (for example, Academic) to narrow the destination list in the left rail. The list shows only that category and the chip is marked active.
4. The visitor taps a destination row. The row highlights with an instant 120ms background fill, the corresponding rectangle is highlighted on the plan, and the confirmation control becomes active.
5. The visitor confirms. The Route page opens: the destination name appears at display scale, the route draws in with a 600ms stroke-dashoffset sweep in signal red, and the numbered step list appears.
6. The visitor reads the steps and taps a step row. The map viewport snaps to that segment in 250ms ease-out.
7. The visitor follows the steps to the destination. Observable result: the visitor arrives at the intended campus location without staff help.
8. Failure/recovery: if the plan fails to load, a plain message and retry control appear; retry reloads the plan without losing the current search text or selection. If no route can be computed, the Route page states plainly that no route is available and offers a return to the destination list.
9. Continuation: the visitor can tap "start over" on the Route page to clear the route and return to destination selection for a second trip.

Flow B — Campus Visitor searches for a place by name

1. The Campus Visitor stands at the robot. The Campus Map page is shown.
2. The visitor types a room, department, or person into the search field in the left rail.
3. Matching destinations appear in the rail; non-matching entries are removed.
4. The visitor taps a match. The row highlights and the confirmation control becomes active.
5. The visitor confirms and the Route page opens with the destination name, the drawn route, and the numbered steps.
6. The visitor follows the steps to the destination. Observable result: the visitor arrives at the intended location.
7. Failure/recovery: if there is no match, a plain "No matching place" message is shown and the search field stays focused so the visitor can correct the query.
8. Continuation: the visitor can clear the search and browse by category instead.

Flow C — Campus Visitor selects a destination from the Destinations page

1. The Campus Visitor opens the Destinations page from the Campus Map.
2. The visitor sees the full catalog of places within the Bareilly branch, grouped by category, each row showing the place name, its room code in Fira Sans Condensed, and its category dot.
3. The visitor filters by category or searches, then selects a destination. The row highlights with an instant 120ms background fill and the confirmation control becomes active.
4. The visitor confirms and the Route page opens with the route and step list.
5. The visitor follows the steps. Observable result: the visitor arrives at the intended location.
6. Failure/recovery: if the catalog fails to load, the list shows a plain message and a retry control; retry reloads the catalog and preserves the active filter. If a category has no entries, a plain message is shown for that category.
7. Continuation: the visitor can return to the Campus Map or start over with a new destination.

Flow D — Robot Navigation Assistant serves a visitor at the robot

1. A visitor stands at the robot. The Robot Navigation Assistant presents the Campus Map page as the entry surface.
2. The assistant accepts the visitor's destination, either from the search field, the category-filtered list, or a tap on a room rectangle.
3. The assistant presents the Route page with the destination name, the drawn route, and the numbered step list.
4. The visitor follows the steps. Observable result: the visitor reaches the intended campus location without staff help.
5. Failure/recovery: if a page fails to load, the assistant surface shows a plain message and a retry control; the visitor can retry from the entry surface.
6. Continuation: the visitor can start over with a new destination, and the assistant presents the destination selection surface again.

6. Visuals Colors and Theme

The creative direction is authoritative for this section. The muse is Erik Spiekermann; the headline idea is typographic infrastructure for a campus that must be walkable at a glance. The register is reassurance and legibility, not delight or luxury: the product is a wayfinding instrument, like a transit map or an airport sign, understood in three seconds from two metres away.

Colour tokens (light mode)

No gradients anywhere. All colour is flat and printed. The generic indigo/blue-on-white SaaS template is forbidden for this project.

Typography

• Headings: Fira Sans, weight 700, sentence case, no letterspacing tricks.
• Numeric and data display: Fira Sans Condensed, weight 600, tight tracking — room codes, distances, floor labels.
• Body: Fira Sans, 17px with 1.6 line-height.
• Labels: 12px small caps, letter-spacing 0.08em, weight 500 — every label such as "DESTINATION", "FLOOR", "EST. WALK".
• Scale: 1.25 modular on a 4px baseline — 96 / 72 / 48 / 32 / 24 / 18 / 16 / 14 / 12.
• Hero destination name: clamp(40px, 7vw, 96px).
• Section headings: 32px desktop / 24px mobile.
• Data and room codes: 18px Fira Sans Condensed 600.
• Minimum readable size: never below 14px for anything a visitor must read standing up.
• The gesture is scale contrast, not style contrast: a 96px destination name above 14px metadata in the same family.

Shape language

Rectilinear and honest. 2px radius on buttons and chips, 4px on panels — barely rounded, like printed signage with a trimmed corner. 1px hairline rules in #D8D2C6 divide every block; 3px rules in transit blue mark section boundaries. Map rooms are flat rectangles with 1px ink outlines and no shadows. One deliberate exception: the "you are here" pin is a filled red circle with a 2px white ring and a 12px pulsing halo — the only circular, the only animated, the only soft form in the whole interface.

Layout

A 12-column grid with a hard left rail.

• Desktop 1280px: left rail 320px holds the destination list (search + categorised rows); right 960px holds the campus plan edge-to-edge with a 24px inset.
• Tablet 768px: rail collapses to a horizontal scrollable category strip above the plan.
• Mobile 375px: plan goes full-width at the top (aspect ratio 4:5, pannable and zoomable), destination list below as full-width rows; the search field is pinned to the top of the viewport.
• The plan is drawn on a strict orthogonal grid — corridors are 1:1 horizontal/vertical, no diagonal paths.
• Every room is a labelled rectangle; labels sit inside their rectangle and truncate with an ellipsis only if the room is smaller than 64px wide, in which case the label moves to a numbered key below.
• Nothing readable ever crosses an edge — the plan pans, the labels stay whole.

Imagery

No photography. The imagery IS the map: flat vector floor plans, transit-style route lines with 45-degree rounded corners at turns, numbered step markers as filled blue squares with white numerals, and a small set of 24px pictograms drawn on a 2px stroke grid (staircase, lift, washroom, canteen, library, auditorium, parking, reception). One decorative element only: a faint 8% opacity blueprint grid (32px squares) behind the campus plan.

7. Signature Design Concept

The public entry is a working instrument, not a marketing hero. It looks like the control surface of a wayfinding kiosk, because that is what it is.

• Left third: a deep transit-blue panel (#0F2A5C) running full viewport height. At the top, "RBMI GROUP OF INSTITUTIONS" set in 14px small-caps white letterspaced type. Below it, the oversized question "Where do you want to go?" in Fira Sans 700 at clamp(40px, 5vw, 72px) white. Directly beneath it, a white search field with a red 2px left edge and the placeholder "Type a room, department or person".
• Right two-thirds: the campus plan on warm paper #F4F1EA with the 8% blueprint grid, the red "you are here" pin already pulsing near the bottom-centre entrance, and eight category chips (Academic, Administration, Library, Hostel, Canteen, Sports, Medical, Parking) laid as a horizontal row along the bottom edge of the plan, each with a coloured dot.
• No centred headline, no subtext paragraph, no button in the middle, no gradient.

The signature moves that carry the concept:

1. Transit-line route overlay. The path from robot to destination is drawn as a 6px signal-red line with 45-degree rounded corners and numbered blue square step markers, exactly like a metro diagram, laid over the flat floor plan — the route is the only curved thing on the page.
2. Labelled rectangles, never pins on photos. Every campus destination is a labelled rectangle inside a schematic plan, with room codes set in Fira Sans Condensed 600 and a numbered key below the plan for rooms too small to label in place.
3. Full-height deep-blue left rail carrying the question at up to 72px, the search field, and the categorised destination list — the rail stays fixed while the plan pans and zooms beside it.
4. Category coding as transit lines. Academic (mustard #E8A33D), Administration (transit blue #0F2A5C), Facilities (teal #1F7A6B) appear as 3px strokes on the map and 8px dots on chips, so a visitor learns the campus by colour the way they learn a subway system.
5. Step-by-step route instructions as a numbered list of ruled rows — blue numeral square, 18px instruction in Fira Sans, distance and estimated walk time right-aligned in Fira Sans Condensed small caps — with the corresponding map segment snapping into view as each row is tapped.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief

• Focal subject. The campus plan on warm paper with the "you are here" pin pulsing near the bottom-centre entrance, and the deep-blue left rail carrying the question "Where do you want to go?".
• Input → transformation → outcome thesis. The visitor types or taps a destination in the rail → the route draws in with a 600ms stroke-dashoffset sweep in signal red over the flat plan → the numbered step list appears and the visitor follows it to the destination.
• Motion vocabulary. Functional, transit-signage motion. Route draws in with a 600ms stroke-dashoffset sweep in signal red, then holds. The "you are here" pin pulses a 12px halo at 2s intervals, opacity 0.35 to 0, only while idle. Destination rows highlight with an instant 120ms background fill on tap, no easing theatrics. Step changes in the route list snap the map viewport to the corresponding segment in 250ms ease-out.
• Composed first frame. Left third: deep transit-blue panel with the wordmark, the oversized question, and the white search field with a red 2px left edge. Right two-thirds: the campus plan on warm paper with the blueprint grid, the red "you are here" pin already pulsing, and the eight category chips along the bottom edge.
• Reduced-motion state. Under prefers-reduced-motion: the route appears fully drawn, the pin halo is static at 0.35 opacity, and viewport snaps become instant cuts.

9. Non-Functional Requirements

NFR-1 — Performance (explicit) The interface must be as fast as possible. Page loads, search keystrokes, category filters, and route computations must respond without perceptible delay. Rationale: the visitor is standing at a robot and must not be kept waiting.

NFR-2 — Legibility at distance (explicit, from creative direction) Type must be readable from two metres away. No text a visitor must read may be set below 14px. Rationale: the product is a wayfinding instrument used standing up.

NFR-3 — Campus scope (explicit) The map, destination catalog, and routes cover only the RBMI Group of Institution Bareilly branch campus. Rationale: explicit hard constraint in the authoritative source.

NFR-4 — Robot delivery context (explicit) The interface is delivered for use on a robot that assists visitors navigating inside the college. Rationale: explicit hard constraint in the authoritative source.

NFR-5 — Anonymous access (required_inference) All three pages are reachable without sign-in. No account, profile, or identity management is introduced. Rationale: the accepted journeys are self-contained wayfinding sessions that do not require durable visitor state.

NFR-6 — Responsive integrity (from creative direction) Readable text and needed content stay whole at 375px, 768px, and 1280px. Headlines, wordmarks, labels, numbers, cards, and controls stay entirely inside the viewport and their container, wrapping or scaling to fit. No other element covers any part of them. Crops, bleeds, and off-edge placement are for decoration only. Rationale: the direction's readable-text rule.

NFR-7 — Reduced motion (from creative direction) Under prefers-reduced-motion, the route appears fully drawn, the pin halo is static at 0.35 opacity, and viewport snaps become instant cuts. Rationale: accessibility and the direction's motion contract.

NFR-8 — No photography, no gradients (from creative direction) No photographic campus aerial shots or stock student imagery. No gradients anywhere. Rationale: the direction's imagery and colour rules.

10. Tech Stack

• Frontend: React (web), delivered as the robot kiosk interface. Rationale: the accepted delivery shape is custom UI on a robot surface; React supports the fast, component-driven rendering the performance constraint requires.
• Styling: plain CSS with the token system in section 6 (custom properties for colour, type scale, and spacing). Rationale: the direction's flat, printed aesthetic does not need a component library, and avoiding one helps the "as fast as possible" constraint.
• Map rendering: inline SVG for the schematic campus plan and the route overlay. Rationale: the plan is a flat vector schematic on an orthogonal grid; SVG gives crisp labels, small payloads, and direct control over the stroke-dashoffset route animation.
• Backend: Python / FastAPI serving the campus plan data, the destination catalog, and route computation. Rationale: a small, fast API is sufficient for the accepted scope and keeps the kiosk payload light.
• Storage: a lightweight relational store (SQLite for a single-campus deployment) holding campus blocks, floors, rooms, room codes, categories, and the corridor graph used for routing. Rationale: the data is small, structured, and single-campus.
• Deployment: Docker / docker-compose for the API and the static frontend bundle. Rationale: a single-campus kiosk deployment does not require Kubernetes.

11. Assumptions and Constraints

• A-1. The campus plan data for the RBMI Group of Institution Bareilly branch (blocks, floors, rooms, room codes, categories, corridors) is supplied as structured data. [Assumption — not specified by user]
• A-2. The robot provides the visitor's current position on the campus plan. [Assumption — not specified by user]
• A-3. The robot surface has a touch input and a display large enough for the layout in section 6. [Assumption — not specified by user]
• A-4. The interface language is English, with the typographic legibility rules in section 6 applied. [Assumption — not specified by user]
• A-5. No authentication, account management, or role-based permissions are in scope. [Required inference from the accepted journeys]
• C-1. Scope is limited to the RBMI Group of Institution Bareilly branch campus. (explicit)
• C-2. The navigation system is delivered for use on a robot that assists visitors navigating inside the college. (explicit)
• C-3. Performance must be as fast as possible. (explicit)
• C-4. The UI must be beautiful. (explicit)
• C-5. The generic indigo/blue-on-white SaaS template is forbidden for this project. (from creative direction)

Future Requirements (not in current scope)

• Multi-campus expansion beyond the Bareilly branch.
• Integration with indoor positioning hardware for automatic current-position tracking.
• Voice-only interaction mode.
• Accessibility routing preferences (step-free routes, lift-only routes).

12. Glossary

• Bareilly branch — the RBMI Group of Institution campus at Bareilly, the sole campus in scope.
• Campus plan — the schematic, orthogonal-grid vector drawing of the Bareilly branch used as the map surface.
• Category — one of Academic, Administration, Library, Hostel, Canteen, Sports, Medical, Parking; used to filter destinations and to code the map with transit-line colours.
• Destination — a place within the Bareilly branch that a visitor wants to reach.
• Room code — the short alphanumeric identifier for a room, set in Fira Sans Condensed 600.
• Route — the path from the visitor's current position to the chosen destination, drawn as a signal-red transit-style line with numbered step markers.
• Step — one numbered instruction in the route list, with distance and estimated walk time.
• "You are here" pin — the filled red circle with a 2px white ring and a 12px pulsing halo marking the visitor's current position; the only circular, animated, soft form in the interface.
• Robot Navigation Assistant — the in-product role that presents the campus map, accepts the visitor's destination, and returns route guidance at the robot.
• Campus Visitor — the person physically present at the Bareilly branch who needs to reach a specific destination.