System Requirements Document for kartavya

1. Introduction

kartavya is a mapping and wayfinding instrument. It lets a person build a complete map of a real place — starting with their own college campus — and design a 3D layout of that whole place from pictures they already have or can capture. The same workflow then extends to any campus, hospital, shopping mall, or home, so that each of those places can be mapped and navigated.

The product intent is a public-information instrument, not a lifestyle app: it turns photographs into drawn maps, drawn maps into navigable routes, and a set of pictures into a sober axonometric 3D massing model of an entire venue. The audience spans a design-literate student creator mapping their own college, an operations-minded builder producing maps and navigation for hospitals, malls, and homes, and an impatient first-time visitor who simply needs to follow a route to a ward, a shop, or a room.

This document defines the current delivery: the pages, the personas, the functional requirements, the flows, the visual system, and the technical constraints.

2. System Overview

kartavya is a first-party web application with application-owned identity. A person can begin anonymously on the Landing surface, enroll themselves through Sign Up, and return through Login. Once verified, a creator works across a revisitable Venues overview, a focused Venue Builder, a Media workspace for importing or capturing pictures, and a 3D Layout workspace that assembles a whole-venue model from those pictures. Completed work is shared through a Venue Viewer, and a Venue Navigator follows turn-by-turn guidance inside a completed map on the Navigation surface.

The core accepted behavior is:

• Making a whole map of a college campus.
• Designing a 3D layout of the whole college using pictures.
• Using pictures as the input for both the map and the 3D layout.
• Making maps or navigation for any campus, hospital, shopping mall, and home.

Actors are the Campus Map Creator, the Multi-Venue Map Builder, and the Venue Navigator. Identity is application-owned: self-service enrollment establishes a first-use identity, and returning verification resumes durable venue maps, media, 3D layouts, viewing, and navigation. Authorization distinguishes venue-building control from navigation and viewing access.

Narrow exclusions: this document does not add adjacent capabilities such as social feeds, messaging, payments, or third-party marketplace listings. It does not treat decorative photography as product content; uploaded pictures are evidence framed and captioned as such.

2a. Product Interpretation and Delivery Boundary

kartavya is delivered as a first-party application with its own custom interface and its own identity. The Landing surface is anonymously reachable and explains what the product does. Sign Up and Login are the anonymous entry boundaries through which a person establishes or verifies identity; protected venue maps, media, 3D layouts, viewing, and navigation remain unavailable until identity is established.

Building control (Venues, Venue Builder, Media, 3D Layout) is restricted to creators. Viewing a completed venue map and its 3D layout is available to any verified person. Following navigation guidance inside a completed map is restricted to the navigator role.

Everything described in this document is current. No future-horizon capabilities are asserted here; anything not listed as a current requirement is out of scope for this generation.

2b. Source Content Inventory

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

2c. Page Content and Component Coverage

Landing

• Information/state: Anonymous first impression explaining that kartavya creates picture-based maps, 3D layouts, and navigation for campuses, hospitals, shopping malls, and homes. Full-bleed working map as the hero: a single colour-coded campus plan drawn in black rules on #F4F2ED, one red route line running diagonally from bottom-left to a red circle marker at centre-right, a yellow zone fill behind the library block. KARTAVYA set into the map in Archivo 800 at 96px, flush-left at the top-left grid intersection, overlapping building outlines, with a 2px red rule beneath it spanning the viewport width. A small black caption block to the right of the marker reads COLLEGE · HOSPITAL · MALL · HOME in 12px uppercase tracked +0.08em. A horizontal floor strip (G / 1 / 2 / 3) runs along the bottom edge as the only other chrome.
• Primary actions: One bordered red rectangle button OPEN THE BUILDER at the bottom-left grid line, leading to Sign Up for a first-time visitor or Login for a returning one.
• Supporting actions: Navigate to Login; navigate to Sign Up.
• Domain entities: Venue type (college, hospital, mall, home), route line, zone fill, floor level.
• Component responsibilities: Hero map canvas (static, drawn); app mark; venue-type caption block; primary CTA; floor strip; left rail with the venue line selector.
• States: Loading — hero map draws in as a static composition. Empty — not applicable (static hero). Success — CTA routes to Sign Up or Login. Error — if the CTA target is unreachable, the button remains visible and the visitor can retry. Recovery — the visitor can reach Login or Sign Up from the left rail at any time.

Login

• Information/state: Returning verification surface for creators resuming durable venue maps and for navigators accessing the application. Ruled label/value rows for credentials, 2px horizontal rules between rows, no floating cards.
• Primary actions: Verify identity and continue to the intended protected destination.
• Supporting actions: Navigate to Sign Up for a person who has not yet enrolled.
• Domain entities: Identity credential, session.
• Component responsibilities: Credential form; submit control; link to Sign Up; error region.
• States: Loading — submit control shows an in-progress state. Empty — form fields empty on arrival. Success — verified identity continues to the requested protected destination. Error — invalid credentials show a ruled error row and the form remains filled. Recovery — the person can retry or move to Sign Up.

Sign Up

• Information/state: Self-service enrollment surface providing a truthful first-use path for people who independently begin creating or using venue maps. Ruled label/value rows for the enrollment fields.
• Primary actions: Establish a first-use identity and continue into the application.
• Supporting actions: Navigate to Login for a person who already has an identity.
• Domain entities: Identity, enrollment record.
• Component responsibilities: Enrollment form; submit control; link to Login; error region.
• States: Loading — submit control shows an in-progress state. Empty — form fields empty on arrival. Success — identity established and the person continues to the intended destination. Error — a ruled error row explains the failure and the form remains filled. Recovery — the person can correct and resubmit, or move to Login.

Venues

• Information/state: Revisitable venue overview for locating and continuing work on college campuses and other supported venue maps. Tabular layout: aligned label/value pairs, ruled rows, no floating cards. Each venue appears as a numbered, colour-coded row in the left rail exactly like a transit line, with a 4px vertical colour bar tagging the venue by code.
• Primary actions: Open a venue to continue work in the Venue Builder.
• Supporting actions: Start a new venue; filter or scan by venue type (college, hospital, mall, home).
• Domain entities: Venue, venue type, venue line number, venue colour code, venue status.
• Component responsibilities: Venue line selector rail; ruled venue rows; venue-type badges; new-venue control.
• States: Loading — ruled rows render as placeholders. Empty — a ruled empty state explains that no venues exist yet and offers the new-venue control. Success — rows list each venue with its line number and colour chip. Error — a ruled error row explains the failure and offers retry. Recovery — the person can retry loading or start a new venue.

Venue Builder

• Information/state: Focused workspace for creating and editing a complete map of a selected venue. Split layout: a flat 2D plan on the left two-thirds and a data/attribute column on the right, separated by a 2px vertical rule. A horizontal floor selector strip (G / 1 / 2 / 3) across the top behaves exactly like a transit line diagram, with the active floor marked by a filled red circle. Map surfaces are drawn: flat fills, 1px building outlines, pictograms for stairs, lifts, toilets, wards, parking, and exits.
• Primary actions: Draw and edit the venue plan; switch floors; commit map changes.
• Supporting actions: Open the Media workspace to add pictures; open the 3D Layout workspace; return to Venues.
• Domain entities: Venue, floor level, building outline, zone, pictogram, attribute row.
• Component responsibilities: 2D plan canvas; floor selector strip; attribute column; pictogram palette; save control.
• States: Loading — plan canvas and attribute column render as ruled placeholders. Empty — a new venue opens with an empty plan and a ruled prompt to begin drawing or to add pictures. Success — committed changes persist to the venue. Error — a ruled error row explains the failure and unsaved changes remain in place. Recovery — the person can retry the commit or continue editing.

Media

• Information/state: Workspace for importing or capturing pictures and using them as construction inputs for a venue map. Each uploaded photo appears as a ruled evidence card with a thin black rule frame and a caption block underneath (timestamp, GPS, floor, contributor initials), plus a small pictogram showing what it contributed (facade, corridor, sign, entrance). A red diagonal stitch line connects each card to the point on the plan it generated.
• Primary actions: Import or capture pictures; assign each picture to a floor and a contribution type; commit pictures as construction inputs.
• Supporting actions: Open the Venue Builder to see the plan point a picture generated; open the 3D Layout workspace.
• Domain entities: Picture, caption block (timestamp, GPS, floor, contributor initials), contribution pictogram, stitch line, venue, floor level.
• Component responsibilities: Evidence card grid; caption block; contribution pictogram; stitch line overlay; import/capture control; floor assignment control.
• States: Loading — evidence cards render as ruled placeholders. Empty — a ruled empty state explains that no pictures have been added and offers the import/capture control. Success — each picture appears as a captioned evidence card with its stitch line. Error — a ruled error row explains a failed import or capture and the picture is not committed. Recovery — the person can retry the import or capture.

3D Layout

• Information/state: Workspace for generating and refining a whole-venue 3D layout from provided pictures. The layout is presented as a paper axonometric massing model on the same #F4F2ED ground, with a measured scale bar, north arrow, and floor-count ruler in the corner — an instrument, not a showcase. Floors stack upward in sequence as the picture-derived geometry resolves, each floor snapping into place with a 1px rule sweeping across it.
• Primary actions: Generate the 3D layout from the venue's pictures; refine the generated geometry; commit the layout.
• Supporting actions: Open the Media workspace to add or correct pictures; open the Venue Viewer to see the completed result.
• Domain entities: 3D layout, floor mass, scale bar, north arrow, floor-count ruler, source picture.
• Component responsibilities: Axonometric massing canvas; floor stack control; scale bar; north arrow; floor-count ruler; generate/refine controls.
• States: Loading — floors stack upward in sequence as geometry resolves. Empty — a ruled empty state explains that no pictures are available and offers the Media workspace. Success — the committed layout is available in the Venue Viewer. Error — a ruled error row explains a failed generation and the previous layout remains. Recovery — the person can retry generation or return to Media to correct inputs.

Venue Viewer

• Information/state: Shared viewing destination for completed venue maps and their 3D layouts. Split layout: the flat 2D plan on the left two-thirds and a data/attribute column on the right, separated by a 2px vertical rule, with the floor selector strip across the top. The 3D layout is available alongside the plan.
• Primary actions: View a completed venue map and its 3D layout; switch floors; switch between the plan and the 3D layout.
• Supporting actions: Open the Navigation surface to follow guidance inside the map.
• Domain entities: Venue, floor level, building outline, zone, 3D layout.
• Component responsibilities: 2D plan canvas; 3D layout canvas; floor selector strip; attribute column; navigation entry control.
• States: Loading — plan and 3D canvases render as ruled placeholders. Empty — a ruled empty state explains that the venue has no completed map yet. Success — the completed map and 3D layout render. Error — a ruled error row explains the failure and offers retry. Recovery — the person can retry loading or return to Venues.

Navigation

• Information/state: Destination for following navigation guidance within a completed campus, hospital, shopping mall, or home map. Full-viewport map with a bottom status bar that reads like a departure board: destination in 24px Archivo, distance and ETA in tabular numerals, next waypoint in uppercase 12px. A red route stroke draws itself at constant speed, like a pen on a map.
• Primary actions: Select a destination; follow the route; advance through waypoints.
• Supporting actions: Switch floors as the route crosses them; return to the Venue Viewer.
• Domain entities: Route, destination, waypoint, distance, ETA, floor level.
• Component responsibilities: Full-viewport map canvas; route stroke; you-are-here marker; bottom status bar; floor selector strip.
• States: Loading — the map renders and the route stroke begins drawing. Empty — a ruled empty state explains that no destination has been selected. Success — the route draws and the status bar shows destination, distance, ETA, and next waypoint. Error — a ruled error row explains that a route could not be produced and offers retry. Recovery — the person can select a different destination or retry.

3. Functional Requirements

FR-1 — Whole campus map creation As a Campus Map Creator, I should be able to make a whole map of my college campus, so that the entire campus exists as one complete, usable map.

• Provenance: explicit
• Lifecycle: Initiator — Campus Map Creator. Trigger — the creator opens the Venue Builder for their college venue. Observable result — a complete campus map is committed and available in the Venue Viewer. Access state — protected; requires verified identity. Failure/recovery — a failed commit shows a ruled error row and unsaved changes remain in place for retry. Continuation — the creator can proceed to the 3D Layout workspace or return to Venues.

FR-2 — 3D layout of the whole college from pictures As a Campus Map Creator, I should be able to design a 3D layout of my whole college using pictures, so that the entire college exists as a 3D model derived from the pictures I provide.

• Provenance: explicit
• Lifecycle: Initiator — Campus Map Creator. Trigger — the creator opens the 3D Layout workspace for their college venue. Observable result — a whole-college 3D layout is generated and committed. Access state — protected; requires verified identity. Failure/recovery — a failed generation shows a ruled error row and the previous layout remains. Continuation — the creator can refine the layout or open the Venue Viewer.

FR-3 — Pictures as construction input As a Campus Map Creator, I should be able to use pictures as the input for the campus map and the 3D layout, so that the map and the 3D layout are built from the pictures I have or capture.

• Provenance: explicit
• Lifecycle: Initiator — Campus Map Creator. Trigger — the creator imports or captures pictures in the Media workspace. Observable result — each picture appears as a captioned evidence card with a stitch line to the plan point it generated. Access state — protected; requires verified identity. Failure/recovery — a failed import or capture shows a ruled error row and the picture is not committed. Continuation — the creator can retry the import or capture, or open the Venue Builder or 3D Layout workspace.

FR-4 — Maps and navigation for any campus, hospital, shopping mall, and home As a Multi-Venue Map Builder, I should be able to make maps or navigation for any campus, hospital, shopping mall, and home, so that each of those venue types has a working map or navigation experience.

• Provenance: explicit
• Lifecycle: Initiator — Multi-Venue Map Builder. Trigger — the builder starts a new venue of the required type from Venues. Observable result — a working map or navigation experience exists for that venue. Access state — protected; requires verified identity. Failure/recovery — a failed venue creation or commit shows a ruled error row and the builder can retry. Continuation — the builder can continue in the Venue Builder, Media, or 3D Layout workspace.

FR-5 — Self-service enrollment As a Campus Map Creator, Multi-Venue Map Builder, or Venue Navigator, I should be able to enroll myself on the Sign Up surface, so that I can begin creating or using venue maps without waiting for someone else to create my identity.

• Provenance: required_inference
• Lifecycle: Initiator — any of the three personas. Trigger — the person opens Sign Up from Landing or Login. Observable result — a first-use identity is established and the person continues to the intended destination. Access state — anonymous entry; protected state remains unavailable until identity is established. Failure/recovery — a ruled error row explains the failure and the form remains filled for correction. Continuation — the person continues to the intended protected destination.

FR-6 — Returning verification As a Campus Map Creator, Multi-Venue Map Builder, or Venue Navigator, I should be able to verify my identity on the Login surface, so that I can resume my durable venue maps, media, 3D layouts, viewing, or navigation.

• Provenance: required_inference
• Lifecycle: Initiator — any of the three personas. Trigger — the person opens Login. Observable result — verified identity resumes the requested protected destination. Access state — anonymous entry; protected state remains unavailable until identity is verified. Failure/recovery — invalid credentials show a ruled error row and the form remains filled. Continuation — the person continues to the requested protected destination or moves to Sign Up.

FR-7 — Authorization distinguishing building from viewing and navigation As a Campus Map Creator or Multi-Venue Map Builder, I should have building control over venue maps, media, and 3D layouts, while viewing is available to any verified person and navigation is available to the Venue Navigator, so that building control is not conflated with viewing or navigation access.

• Provenance: required_inference
• Lifecycle: Initiator — the application enforcing access. Trigger — a person requests a protected destination. Observable result — building control is granted only to creators; viewing is granted to any verified person; navigation is granted to the navigator role. Access state — protected; requires verified identity. Failure/recovery — an unauthorized request is refused and the person is returned to an allowed destination. Continuation — the person continues in an allowed destination.

FR-8 — Venue overview and continuation As a Campus Map Creator or Multi-Venue Map Builder, I should be able to locate and continue work on my venue maps from the Venues overview, so that I can resume a venue without losing my place.

• Provenance: required_inference
• Lifecycle: Initiator — Campus Map Creator or Multi-Venue Map Builder. Trigger — the creator opens Venues. Observable result — each venue appears as a numbered, colour-coded row and opens into the Venue Builder. Access state — protected; requires verified identity. Failure/recovery — a failed load shows a ruled error row and offers retry. Continuation — the creator opens a venue or starts a new one.

FR-9 — Shared viewing of completed maps and 3D layouts As a Campus Map Creator, Multi-Venue Map Builder, or Venue Navigator, I should be able to view a completed venue map and its 3D layout in the Venue Viewer, so that the completed work is visible to anyone verified.

• Provenance: required_inference
• Lifecycle: Initiator — any of the three personas. Trigger — the person opens the Venue Viewer for a completed venue. Observable result — the completed map and 3D layout render. Access state — protected; requires verified identity. Failure/recovery — a failed load shows a ruled error row and offers retry. Continuation — the person can switch floors, switch to the 3D layout, or open Navigation.

FR-10 — Following navigation guidance As a Venue Navigator, I should be able to follow navigation guidance within a completed campus, hospital, shopping mall, or home map, so that I reach my destination in that venue.

• Provenance: required_inference
• Lifecycle: Initiator — Venue Navigator. Trigger — the navigator selects a destination on the Navigation surface. Observable result — a red route stroke draws at constant speed and the bottom status bar shows destination, distance, ETA, and next waypoint. Access state — protected; requires verified identity and the navigator role. Failure/recovery — a route that cannot be produced shows a ruled error row and offers retry. Continuation — the navigator advances through waypoints or selects a different destination.

4. User Personas

Campus Map Creator

The Campus Map Creator is the person who wants to build a complete map of their own college campus and a 3D layout of the whole college using pictures. Their product context is a single, deeply known venue: they walk the campus, they have photographs of facades, corridors, signs, and entrances, and they need those pictures to become a drawn map and a 3D massing model of the whole college.

Their primary goal is a complete, usable map and 3D layout of their college. Their distinct accepted responsibilities are making the whole campus map (FR-1), designing the 3D layout of the whole college from pictures (FR-2), and using pictures as the construction input for both (FR-3). Their relevant inputs are the pictures they import or capture, the floor each picture belongs to, and the contribution type of each picture (facade, corridor, sign, entrance). Their relevant decisions are where a picture's stitch line lands on the plan and whether the generated 3D geometry is acceptable.

They interact with the Multi-Venue Map Builder only in the sense that both are creators with building control; they interact with the Venue Navigator as the person who will eventually follow a route inside the map they built. Their observable success is a committed campus map and a committed whole-college 3D layout, both visible in the Venue Viewer.

What makes this role's work different is its depth on one venue: the creator is not surveying many places, they are reconstructing one place completely, and the quality of the reconstruction depends on the pictures they supply.

Multi-Venue Map Builder

The Multi-Venue Map Builder is the person who must make maps or navigation for any campus, hospital, shopping mall, and home. Their product context is breadth: they reuse the same mapping and 3D-layout workflow across venue types that have different conventions — a hospital has wards and lifts, a mall has shops and parking, a home has rooms.

Their primary goal is a working map or navigation experience for each of those venue types. Their distinct accepted responsibility is FR-4, starting and building maps or navigation for venues beyond the original college. Their relevant inputs are the venue type, the venue name, and the pictures for each venue. Their relevant decisions are which venue type a new venue belongs to and when a venue's map or navigation is complete enough to be used.

They interact with the Campus Map Creator as a peer creator with the same building control, and with the Venue Navigator as the person who will use each finished venue. Their observable success is a working map or navigation experience for each venue they build.

What makes this role's work different is that its success is measured across venues rather than within one: the builder must produce a coherent result for a hospital, a mall, and a home, not just a single campus.

Venue Navigator

The Venue Navigator is the person using a produced map to find their way. Their product context is a venue they do not know well — a hospital where they need a ward, a mall where they need a shop, a campus where they need a building, or a home where they need a room.

Their primary goal is to reach a destination in that venue. Their distinct accepted responsibilities are viewing a completed venue map and its 3D layout (FR-9) and following navigation guidance within it (FR-10). Their relevant inputs are the destination they select and the route the app draws. Their relevant decisions are which destination to select and when to advance to the next waypoint.

They interact with the Campus Map Creator and the Multi-Venue Map Builder as the recipient of the maps those creators produce. Their observable success is reaching the destination in that venue.

What makes this role's work different is that it is purely consumptive and time-pressured: the navigator does not build or edit anything, and the interface must read like signage that already works.

5. Core User Flows

Flow 1 — Campus Map Creator builds a whole campus map

1. The Campus Map Creator arrives on the Landing surface anonymously and sees the full-bleed working map hero with the OPEN THE BUILDER button.
2. The creator selects OPEN THE BUILDER and is taken to Sign Up, since no identity exists yet.
3. On Sign Up, the creator enrolls, establishing a first-use identity, and continues to Venues.
4. On Venues, the creator starts a new venue of type college and opens it in the Venue Builder.
5. In the Venue Builder, the creator sees an empty plan and a ruled prompt to begin drawing or to add pictures.
6. The creator opens the Media workspace and imports or captures pictures of the campus.
7. Each picture appears as a ruled evidence card with a thin black rule frame and a caption block underneath (timestamp, GPS, floor, contributor initials), plus a pictogram showing what it contributed (facade, corridor, sign, entrance).
8. The creator assigns each picture to a floor and a contribution type; a red diagonal stitch line connects each card to the point on the plan it generated.
9. If an import or capture fails, a ruled error row explains the failure, the picture is not committed, and the creator retries.
10. The creator returns to the Venue Builder, where the plan now carries the geometry derived from the pictures, and completes the whole campus map across floors using the floor selector strip (G / 1 / 2 / 3).
11. The creator commits the map. If the commit fails, a ruled error row explains the failure and unsaved changes remain in place for retry.
12. The committed campus map is available in the Venue Viewer. The creator continues to the 3D Layout workspace.

Flow 2 — Campus Map Creator designs the 3D layout of the whole college from pictures

1. The Campus Map Creator, already verified, opens the 3D Layout workspace for their college venue.
2. The workspace generates the layout from the venue's pictures. Floors stack upward in sequence as the picture-derived geometry resolves, each floor snapping into place with a 1px rule sweeping across it.
3. The layout is presented as a paper axonometric massing model on the #F4F2ED ground, with a measured scale bar, north arrow, and floor-count ruler in the corner.
4. If no pictures are available, a ruled empty state explains this and offers the Media workspace; the creator adds pictures and returns.
5. If generation fails, a ruled error row explains the failure and the previous layout remains; the creator retries or returns to Media to correct inputs.
6. The creator refines the generated geometry and commits the layout.
7. The committed whole-college 3D layout is available in the Venue Viewer alongside the campus map.

Flow 3 — Multi-Venue Map Builder produces a map or navigation for a hospital, mall, or home

1. The Multi-Venue Map Builder, already verified, opens Venues.
2. The builder starts a new venue and selects its type — hospital, shopping mall, or home.
3. The builder opens the new venue in the Venue Builder and sees an empty plan.
4. The builder opens Media and imports or captures pictures for that venue, assigning each to a floor and a contribution type.
5. Each picture appears as a captioned evidence card with a stitch line to the plan point it generated.
6. The builder returns to the Venue Builder and completes the venue map, using the floor selector strip to move between floors.
7. The builder opens the 3D Layout workspace and generates the venue's 3D layout from its pictures.
8. The builder commits the map and the layout. If a commit fails, a ruled error row explains the failure and the builder retries.
9. The venue now has a working map or navigation experience, visible in the Venue Viewer.
10. The builder repeats the flow for each remaining venue type.

Flow 4 — Venue Navigator reaches a destination in a venue

1. The Venue Navigator arrives on the Landing surface anonymously and selects OPEN THE BUILDER.
2. Since the navigator has no identity, they are taken to Sign Up; if they already have one, they use Login instead.
3. After enrolling or verifying, the navigator opens the Venue Viewer for the completed venue.
4. The navigator sees the completed map and its 3D layout, and switches floors as needed.
5. The navigator opens the Navigation surface and selects a destination.
6. A red route stroke draws itself at constant speed, like a pen on a map, and the bottom status bar reads like a departure board: destination in 24px Archivo, distance and ETA in tabular numerals, next waypoint in uppercase 12px.
7. The navigator follows the route, switching floors as the route crosses them.
8. If a route cannot be produced, a ruled error row explains this and the navigator retries or selects a different destination.
9. The navigator advances through waypoints until they reach the destination in that venue.

6. Visuals Colors and Theme

The muse is Massimo Vignelli, and the headline is Systematic wayfinding — every place gets a line, a colour and a number. The direction is authoritative for this section.

Colour tokens (light mode):

Proportion: 70% paper, 22% black rules and type, 6% red, 2% yellow/code colours. No more than four coded map colours, and colour is never used without a legend.

Typography: Headings and body both use Archivo. Grotesque, flush-left ragged-right, tight tracking (-0.01em), heavy 700/800 weights at very large sizes for wayfinding headlines, uppercase for station-style labels and section markers, sentence case for prose. Hierarchy comes from weight and rules, not from many sizes. Scale is 1.25 modular on a 4pt baseline: 96 / 64 / 40 / 24 / 17 / 14 / 12. Display 96–64 for page titles and venue names, 40 for section heads, 24 for card titles, 17 body, 14 metadata, 12 uppercase micro-labels with +0.08em tracking. Numerals are always tabular.

Shape language: Hard edges everywhere — 0px radius on panels, cards, buttons, and inputs. Geometry carries meaning: circles are you-are-here markers and floor nodes, 2px horizontal rules separate every data row, 4px vertical colour bars tag a venue or zone by code, and the grid is drawn, not implied. Buttons are rectangles with a 2px black or red border, no shadow. The only soft form in the product is the 3D model itself.

Layout: A 12-column grid with a permanently visible left rail: the venue line selector (one colour-coded row per venue — college, hospital, mall, home — each with a line number and colour chip) topped by the app mark and a hairline rule. Pages are tabular: aligned label/value pairs, ruled rows, no floating cards. The builder and viewer screens are split — a flat 2D plan on the left two-thirds and a data/attribute column on the right, separated by a 2px vertical rule, with a horizontal floor selector strip (G / 1 / 2 / 3) across the top that behaves exactly like a transit line diagram.

Imagery: Diagrams over photographs. Uploaded venue pictures are always shown framed in a thin black rule with a caption block underneath (timestamp, GPS, floor, contributor initials) — they are evidence, not decoration. Map surfaces are drawn: flat fills, 1px building outlines, pictograms for stairs, lifts, toilets, wards, parking, and exits. The 3D layout is rendered as a clean axonometric massing model in paper-white with red route lines and yellow zone fills, never as a glossy game render. Pictograms are the only illustration permitted.

7. Signature Design Concept

The public entry is a full-bleed working map, not a headline-over-blob. A single colour-coded campus plan fills the viewport edge to edge, drawn in black rules on #F4F2ED, with one red route line running diagonally from bottom-left to a red circle marker at centre-right and a yellow zone fill sitting behind the library block.

Type is set into the map: KARTAVYA in Archivo 800 at 96px, flush-left, positioned at the top-left grid intersection and allowed to overlap the map's building outlines, with a 2px red rule running beneath it the full width of the viewport. To the right of the marker, a small black caption block reads COLLEGE · HOSPITAL · MALL · HOME in 12px uppercase tracked +0.08em.

There is no centred text, no subheadline paragraph, no gradient, and no button pair. One bordered red rectangle button OPEN THE BUILDER sits at the bottom-left grid line, and a horizontal floor strip (G / 1 / 2 / 3) runs along the bottom edge as the only other chrome. The composition recomposes only accepted content, states, and controls: the venue types, the route, the zone fill, the floor levels, and the entry control.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief

• Focal subject: The full-bleed working campus plan — black rules on #F4F2ED, one red route line running diagonally from bottom-left to a red circle marker at centre-right, a yellow zone fill behind the library block, and KARTAVYA set into the map at the top-left grid intersection.
• Input → transformation → outcome thesis: The visitor's attention moves along the red route line from the bottom-left grid line to the red circle marker; the route resolves into the OPEN THE BUILDER control at the bottom-left grid line, and the visitor's selection carries them into Sign Up or Login. No accepted behaviour is added — the route, the marker, the venue-type caption, and the entry control are all accepted content.
• Motion vocabulary: Minimal and informational. Instant state changes with 120ms linear transitions; no easing theatrics. Hover on a venue row shifts the colour bar's width from 4px to 8px; nothing scales, nothing lifts.
• Composed first frame: The map is already drawn at full bleed. KARTAVYA sits at the top-left grid intersection with the 2px red rule beneath it spanning the viewport width. The red route line is complete from bottom-left to the red circle marker at centre-right. The caption block reads COLLEGE · HOSPITAL · MALL · HOME. The OPEN THE BUILDER button sits at the bottom-left grid line, and the floor strip (G / 1 / 2 / 3) runs along the bottom edge.
• Reduced-motion state: The hero is already static, so the reduced-motion state is identical to the composed first frame: no transitions, no route drawing, no floor-strip animation. The 120ms linear transitions elsewhere in the product become instant.

9. Non-Functional Requirements

• NFR-1 — Picture evidence framing. Uploaded venue pictures must always be shown framed in a thin black rule with a caption block underneath (timestamp, GPS, floor, contributor initials). Provenance: explicit (creative direction). Rationale: pictures are evidence, not decoration.
• NFR-2 — Drawn map surfaces. Map surfaces must be drawn: flat fills, 1px building outlines, pictograms for stairs, lifts, toilets, wards, parking, and exits. Provenance: explicit (creative direction). Rationale: the product is a wayfinding instrument, not a photographic showcase.
• NFR-3 — Axonometric 3D presentation. The 3D layout must be rendered as a clean axonometric massing model in paper-white with red route lines and yellow zone fills, with a measured scale bar, north arrow, and floor-count ruler in the corner. Provenance: explicit (creative direction). Rationale: the 3D layout is an instrument, not a showcase.
• NFR-4 — Coded colour discipline. No more than four coded map colours, and colour must never be used without a legend. Blue #1B5FA8 and green #2E7D4F are permitted only inside the map legend, never in UI chrome. Provenance: explicit (creative direction). Rationale: colour is coded information.
• NFR-5 — Hard-edge geometry. 0px radius on panels, cards, buttons, and inputs; no shadows; buttons are rectangles with a 2px black or red border. Provenance: explicit (creative direction). Rationale: geometry carries meaning.
• NFR-6 — Tabular numerals. Numerals must always be tabular. Provenance: explicit (creative direction). Rationale: distances, ETAs, coordinates, and floor labels must align.
• NFR-7 — Motion restraint. Instant state changes with 120ms linear transitions; no easing theatrics, bounces, springs, or scroll-jacking. Provenance: explicit (creative direction). Rationale: the product must feel like signage that already works.
• NFR-8 — Floor stacking choreography. The only choreographed moment is the 3D layout assembling: floors stack upward in sequence as the picture-derived geometry resolves, each floor snapping into place with a 1px rule sweeping across it. Provenance: explicit (creative direction). Rationale: the assembly communicates that the model is derived from pictures.
• NFR-9 — Route drawing. Route drawing animates as a single continuous stroke at constant speed, like a pen on a map. Provenance: explicit (creative direction). Rationale: the route must read as a drawn line, not a rendered effect.
• NFR-10 — Identity continuity. Venue maps, media, 3D layouts, viewing, and navigation must remain bound to the correct verified identity so that a creator can resume durable work and a navigator can access the application. Provenance: required_inference. Rationale: accepted journeys require durable, resumable state bound to the correct participant.
• NFR-11 — Authorization separation. Building control must be distinguishable from viewing and navigation access. Provenance: required_inference. Rationale: the accepted planning scope establishes differentiated control over shared product state.

10. Tech Stack

• Frontend: React (web application with custom UI).
• Backend: Python / FastAPI.
• Storage: Appropriate persistent storage for venues, floors, building outlines, zones, pictures with caption metadata, 3D layouts, routes, and identities.
• Containerization: Docker and docker-compose.
• Orchestration: Kubernetes only if deployment requires it.

No source-specified technology choices were provided beyond the product requirements; the items above are the minimal stack needed to deliver the accepted behavior.

11. Assumptions and Constraints

• A-1 [Assumption — required_inference]: Identity is application-owned. Self-service enrollment through Sign Up and returning verification through Login are the anonymous entry boundaries; protected venue maps, media, 3D layouts, viewing, and navigation remain unavailable until identity is established.
• A-2 [Assumption — required_inference]: Building control (Venues, Venue Builder, Media, 3D Layout) is restricted to creators; viewing a completed venue map and its 3D layout is available to any verified person; following navigation guidance is restricted to the navigator role.
• A-3 [Assumption — required_inference]: A venue belongs to exactly one venue type from the accepted set: college campus, hospital, shopping mall, or home.
• A-4 [Assumption — required_inference]: Pictures are assigned to a floor and a contribution type (facade, corridor, sign, entrance) so that each picture can be stitched to the plan point it generated.
• C-1 [Constraint — explicit]: The product must support making a whole map of the user's college campus.
• C-2 [Constraint — explicit]: The product must support designing a 3D layout of the whole college using pictures.
• C-3 [Constraint — explicit]: Pictures must be usable as the input for the campus map and the 3D layout.
• C-4 [Constraint — explicit]: The product must support making maps or navigation for any campus, hospital, shopping mall, and home.
• C-5 [Constraint — explicit, creative direction]: Rounded corners, pill buttons, glassmorphism, floating card shadows, blue/indigo primary or bootstrap-blue CTAs on white, gradient-blob heroes, glossy 3D game renders, particle fields, grids of identical hover-lift cards, Inter/Roboto/Poppins/system-ui or any neutral default sans, decorative uncaptioned photography, decorative animation, bounces, springs, and scroll-jacking are all excluded.
• C-6 [Constraint — explicit, creative direction]: The generic indigo/blue-on-white SaaS template is forbidden for this project.
• C-7 [Constraint — explicit, creative direction]: No more than four coded map colours, and colour must never be used without a legend.

12. Glossary

• Venue: A place that is mapped and navigated — a college campus, hospital, shopping mall, or home.
• Venue line: The numbered, colour-coded row in the left rail that represents a venue, exactly like a transit line.
• Venue type: One of the four accepted categories: college campus, hospital, shopping mall, home.
• Floor selector strip: The horizontal control (G / 1 / 2 / 3) modelled on a line diagram, with the active floor marked by a filled red circle.
• Evidence card: A ruled card showing an uploaded picture framed in a thin black rule with a caption block underneath (timestamp, GPS, floor, contributor initials) and a pictogram showing what it contributed.
• Stitch line: The red diagonal line connecting an evidence card to the point on the plan it generated.
• Contribution type: What a picture contributed to the map — facade, corridor, sign, or entrance.
• Axonometric massing model: The paper-white 3D presentation of a venue, with a measured scale bar, north arrow, and floor-count ruler in the corner.
• You-are-here marker: The red circle marker showing the current position on a map.
• Waypoint: A point along a route that the navigator advances through.
• Route stroke: The red line drawn at constant speed from the current position to the destination.
• Building control: The authorization to create and edit venue maps, media, and 3D layouts.
• Navigator role: The authorization to follow navigation guidance within a completed venue map.