System Requirements Document for sweet-proper

1. Introduction

sweet-proper is a multi-role event management system. Its product intent is to let four distinct kinds of participants — Admin, Organizer, Attendee, and Venue Manager — each carry out their own part of the event lifecycle inside one platform, while the platform itself enforces proper validation on the data they enter and proper security over who may reach which capability and record.

The system is built around the premise that events only run properly when the underlying rules hold: registrations carry valid input, venue bookings do not collide with existing commitments, and each role sees and changes only what its scope permits. The audience is event professionals, venue staff, and platform administrators who work in dense schedules and records, together with attendees who need to browse events, register, and keep track of their own participation.

This document defines the current delivery of that system: its actors, its pages, its functional requirements, its validation and security obligations, and the visual and interaction direction that governs how it is presented.

2. System Overview

sweet-proper is a first-party web application with application-owned identity. Anonymous visitors arrive at a public Landing surface, establish an identity through self-service Sign Up, and return through Login. Once identity is established, each user acts within one of four roles — Admin, Organizer, Attendee, or Venue Manager — and reaches the destinations that role owns.

The current system covers:

• Admin work: managing user accounts and role assignments, and reviewing and enforcing platform-wide validation and security rules.
• Organizer work: creating and editing event details, schedules, and venue arrangements, and viewing and managing the attendees registered for organizer-owned events.
• Attendee work: browsing available events, viewing an event's details, submitting a validated registration, and viewing and managing personal registrations.
• Venue Manager work: creating and maintaining venue information and availability, and managing venue bookings and coordinating with organizers.

Cross-cutting obligations run through all of it: validation on user, event, registration, venue, availability, and booking data; role-appropriate authorization over shared durable records; and conflict checking on venue availability before a booking is accepted.

2a. Product Interpretation and Delivery Boundary

sweet-proper is delivered as a custom first-party application with its own identity. Because no provisioning or invitation boundary is established for initial product use, identity is established by self-service enrollment on Sign Up, and returning users verify themselves on Login. Landing, Login, and Sign Up are reachable without an established identity; every other destination requires one and is scoped to the roles that own it.

Role is the organizing fact of the product. A user's role determines which destinations they can reach and which records they can read or change: Admin reaches Users and Security; Organizer reaches Event Details and Attendees; Attendee reaches Events, Event View, Registration, and My Registrations; Venue Manager reaches Venues and Bookings. This is differentiated control over shared product state, not merely a label — the platform's records are shared, and role-appropriate authorization is what keeps each role inside its permitted scope.

The current delivery horizon covers everything described in this document. No future-horizon capabilities are asserted here; anything not stated as current is out of scope for this generation.

2b. Source Content Inventory

Not applicable. No reference directive in this project declares a content_source, so no source content inventory is produced.

2c. Page Content and Component Coverage

Landing

• Information and state: Anonymous public entry. Presents the system's purpose, the four roles it serves, and the core event workflows it supports. No identity required.
• Primary actions: Proceed to Sign Up ("CREATE AN ACCOUNT"); proceed to Login ("SIGN IN").
• Supporting actions: Read the role descriptions and the system's validation and conflict-checking promises.
• Domain entities: Role (Admin, Organizer, Attendee, Venue Manager); the system's validation and conflict-checking rules as presented content.
• Component responsibilities: Full-bleed poster hero carrying the headline "RUN THE EVENT. GUARD THE DOOR."; a black marquee band naming the four roles and the system's validation promises; four unequal role stamps (Admin widest, Attendee narrowest) each carrying its role colour and uppercase label; primary and secondary entry controls.
• States: Loading — poster frame resolves with type and colour blocks in place. Empty — not applicable; the surface is static content. Success — not applicable. Error — not applicable. Recovery — not applicable.

Login

• Information and state: Anonymous returning-verification surface shared by all four roles. Collects credentials and reports verification outcome.
• Primary actions: Submit credentials to verify identity and enter the application.
• Supporting actions: Navigate to Sign Up when no identity exists yet.
• Domain entities: User identity; role assignment associated with the verified identity.
• Component responsibilities: Two-column label/value credential form on a white panel; inline red error text per field; yellow validation banner for form-level failures; red access-denial banner with a rule number where verification fails.
• States: Loading — submit control indicates verification in progress. Empty — form presented with empty fields. Success — identity verified and the user is routed to the destinations their role owns. Error — invalid credentials produce inline field errors and a yellow validation banner; denied access produces a red banner with a rule number. Recovery — the user corrects input and resubmits, or navigates to Sign Up.

Sign Up

• Information and state: Anonymous self-service enrollment surface. Collects the information required to create an application identity.
• Primary actions: Submit enrollment to create an identity.
• Supporting actions: Navigate to Login when an identity already exists.
• Domain entities: User identity; role assignment.
• Component responsibilities: Two-column label/value enrollment form on a white panel; inline red error text per field; yellow validation banner for form-level failures; explicit statement of what is required for a valid submission.
• States: Loading — submit control indicates enrollment in progress. Empty — form presented with empty fields. Success — identity created and the user proceeds to verification and role-appropriate access. Error — invalid or incomplete input produces inline field errors and a yellow validation banner. Recovery — the user corrects the flagged fields and resubmits.

Users

• Information and state: Admin workspace, role-restricted. Lists user accounts and their current role assignments across Admin, Organizer, Attendee, and Venue Manager.
• Primary actions: Assign or change a user's role.
• Supporting actions: Inspect an individual account's current role and status; filter and scan the account list.
• Domain entities: User account; role assignment; account status.
• Component responsibilities: Ruled poster table with a sticky black header row and tabular numerals; role stamps rendered in each role's colour; row-level role assignment control; yellow validation banner for rejected changes; red access-denial banner where an action falls outside permitted scope.
• States: Loading — table frame with header row present while records resolve. Empty — no accounts to display, with the ruled table structure retained. Success — role assignment applied and reflected in the row's role stamp. Error — invalid assignment produces a yellow validation banner with a rule number; out-of-scope action produces a red access-denial banner. Recovery — the Admin corrects the assignment and reapplies it.

Security

• Information and state: Admin workspace, role-restricted. Presents the platform-wide validation and security rules and the permission matrix that maps each role to the capabilities and records it may reach.
• Primary actions: Review and enforce platform-wide validation and security rules.
• Supporting actions: Inspect the permission matrix as a printed grid; identify which role holds which permission.
• Domain entities: Validation rule; security rule; permission matrix entry mapping role to capability and record scope.
• Component responsibilities: Ruled system diagram drawing the permission matrix as a printed grid; rule entries carrying rule numbers and uppercase labels; role stamps in each role's colour; yellow banners for validation-rule states and red banners for access-denial states.
• States: Loading — grid frame and rule list resolve. Empty — no rules configured, with the grid structure retained. Success — a rule or permission change is applied and reflected in the matrix. Error — an invalid rule change produces a yellow validation banner; an out-of-scope change produces a red access-denial banner. Recovery — the Admin corrects the rule and reapplies it.

Events

• Information and state: Attendee destination, role-restricted. Lists available events for browsing and beginning event discovery.
• Primary actions: Browse the available events and select one to view.
• Supporting actions: Scan event titles, dates, and venue information; move from the list into an event's detail view.
• Domain entities: Event; event schedule; venue associated with the event; availability status.
• Component responsibilities: Ruled poster table or ruled list of events with a sticky black header row and tabular numerals; instant black-on-white row flip on hover; the black marquee band reused above the list; row selection leading to Event View.
• States: Loading — list frame with header row present while events resolve. Empty — no available events, with the ruled structure retained. Success — events listed and selectable. Error — failure to load events surfaces a yellow banner with a rule number. Recovery — the Attendee retries the list.

Event Details

• Information and state: Organizer workspace, role-restricted. Holds the editable definition of an event: its details, its schedule, and its venue arrangements.
• Primary actions: Create an event; edit an existing event's details, schedule, and venue arrangements.
• Supporting actions: Select a venue arrangement for the event; review validation feedback before committing changes.
• Domain entities: Event; event schedule; venue arrangement; venue availability.
• Component responsibilities: Two-column label/value form rows on white panels; inline red error text per field; yellow validation banners for field errors and conflict warnings, each with a black 2px rule and a rule number; red access-denial banner where an action falls outside permitted scope.
• States: Loading — form frame resolves with existing values. Empty — a new event form presented with empty fields. Success — event details, schedule, and venue arrangements saved and reflected. Error — invalid input produces inline field errors and a yellow validation banner; a venue conflict produces a yellow conflict warning with a rule number; an out-of-scope action produces a red access-denial banner. Recovery — the Organizer corrects the flagged fields or selects a non-conflicting venue arrangement and resubmits.

Event View

• Information and state: Attendee destination, role-restricted. Presents the details of a single available event.
• Primary actions: Read the event's details and proceed to register for it.
• Supporting actions: Review the event's schedule and venue information before deciding.
• Domain entities: Event; event schedule; venue; availability status.
• Component responsibilities: Poster-style event header with the event title set as display type; ruled detail rows with tabular numerals; role stamp and status badges as rectangular stamps; primary control leading to Registration.
• States: Loading — event frame resolves. Empty — not applicable; the surface presents one selected event. Success — event details presented with the registration path available. Error — failure to load the event surfaces a yellow banner with a rule number. Recovery — the Attendee returns to Events and reselects.

Attendees

• Information and state: Organizer destination, role-restricted. Lists the attendees registered for organizer-owned events.
• Primary actions: View and manage the attendees registered for organizer-owned events.
• Supporting actions: Scan registrations per event; inspect an individual attendee's registration record.
• Domain entities: Registration; attendee identity; event ownership.
• Component responsibilities: Ruled poster table with a sticky black header row and tabular numerals; instant black-on-white row flip on hover; role stamps in each role's colour; yellow validation banner for rejected changes; red access-denial banner where an action falls outside permitted scope.
• States: Loading — table frame with header row present while registrations resolve. Empty — no attendees registered for the organizer's events, with the ruled structure retained. Success — attendee records listed and manageable. Error — failure to load or an out-of-scope action surfaces a yellow validation banner or a red access-denial banner respectively. Recovery — the Organizer retries the list or corrects the action.

Registration

• Information and state: Attendee workflow, role-restricted. Collects the input required to submit a validated registration for a selected event.
• Primary actions: Submit a validated registration for the event.
• Supporting actions: Review the event's details before committing; correct flagged fields.
• Domain entities: Registration; event; attendee identity; registration status.
• Component responsibilities: Two-column label/value form rows on white panels; inline red error text per field; yellow validation banner for field errors and conflict warnings with a rule number; red access-denial banner where the action falls outside permitted scope.
• States: Loading — form frame resolves with the selected event's context. Empty — form presented with empty fields. Success — registration accepted and reflected in the Attendee's registrations. Error — invalid input produces inline field errors and a yellow validation banner; a capacity or availability conflict produces a yellow conflict warning with a rule number; an out-of-scope action produces a red access-denial banner. Recovery — the Attendee corrects the flagged fields and resubmits, or returns to Events to select a different event.

My Registrations

• Information and state: Attendee destination, role-restricted. Lists the Attendee's own event registrations and their current status.
• Primary actions: View and manage personal event registrations.
• Supporting actions: Inspect an individual registration's details; move from a registration into the corresponding event's view.
• Domain entities: Registration; event; registration status.
• Component responsibilities: Ruled poster table with a sticky black header row and tabular numerals; instant black-on-white row flip on hover; status badges as rectangular stamps; yellow validation banner for rejected changes; red access-denial banner where an action falls outside permitted scope.
• States: Loading — table frame with header row present while registrations resolve. Empty — no registrations yet, with the ruled structure retained and a path back to Events. Success — registrations listed and manageable. Error — failure to load or an out-of-scope action surfaces a yellow validation banner or a red access-denial banner respectively. Recovery — the Attendee retries the list or corrects the action.

Venues

• Information and state: Venue Manager workspace, role-restricted. Holds venue information and availability maintained by the Venue Manager.
• Primary actions: Create and maintain venue information and availability.
• Supporting actions: Review existing venue records; update availability so that bookings can be conflict-checked against it.
• Domain entities: Venue; venue availability; booking.
• Component responsibilities: Ruled poster table with a sticky black header row and tabular numerals; two-column label/value form rows on white panels for venue records; inline red error text per field; yellow validation banners for field errors and conflict warnings with a rule number; red access-denial banner where an action falls outside permitted scope.
• States: Loading — table frame with header row present while venues resolve. Empty — no venues yet, with the ruled structure retained and a path to create the first venue. Success — venue information and availability saved and reflected. Error — invalid input produces inline field errors and a yellow validation banner; an availability conflict produces a yellow conflict warning with a rule number; an out-of-scope action produces a red access-denial banner. Recovery — the Venue Manager corrects the flagged fields and resubmits.

Bookings

• Information and state: Venue Manager destination, role-restricted. Lists venue bookings and their status, and carries the coordination between the Venue Manager and organizers.
• Primary actions: Manage venue bookings and coordinate with organizers.
• Supporting actions: Review a booking's venue, dates, and status; act on a booking that conflicts with existing commitments.
• Domain entities: Booking; venue; venue availability; organizer; event.
• Component responsibilities: Ruled poster table with a sticky black header row and tabular numerals; instant black-on-white row flip on hover; status badges as rectangular stamps; yellow conflict warnings with a rule number; red access-denial banner where an action falls outside permitted scope.
• States: Loading — table frame with header row present while bookings resolve. Empty — no bookings yet, with the ruled structure retained. Success — booking managed and reflected in the list and in venue availability. Error — a booking that conflicts with an existing commitment produces a yellow conflict warning with a rule number; an out-of-scope action produces a red access-denial banner. Recovery — the Venue Manager resolves the conflict or corrects the action and retries.

3. Functional Requirements

FR-01 — Multi-role platform (explicit) As an Admin, I should operate a platform in which the four distinct roles Admin, Organizer, Attendee, and Venue Manager all exist and act, so that each participant's work is separated by role.

• Trigger/input: Platform operation with users holding each of the four roles.
• Observable result: All four roles exist as distinct roles, and each user's role determines the destinations and records they may reach.
• Access state: Identity required for role-scoped work; Landing, Login, and Sign Up reachable without identity.
• Failure/recovery: A user without an assigned role reaches no role-scoped destination; the Admin assigns the role on Users.
• Continuation: The user proceeds into the destinations their role owns.

FR-02 — Role-specific capabilities (explicit) As an Admin, I should ensure each of the four roles has its own capabilities, so that role-specific work is possible for every participant.

• Trigger/input: A user acting within their assigned role.
• Observable result: Admin reaches Users and Security; Organizer reaches Event Details and Attendees; Attendee reaches Events, Event View, Registration, and My Registrations; Venue Manager reaches Venues and Bookings.
• Access state: Role-restricted destinations require an established identity and the matching role.
• Failure/recovery: An attempt to reach a destination outside the user's role produces a red access-denial banner with a rule number.
• Continuation: The user returns to a destination their role owns.

FR-03 — Validation on user input and event/registration data (explicit) As an Admin, I should have proper validations enforced on user input and on event and registration data, so that invalid data does not enter the platform.

• Trigger/input: Any submission of user input, event data, or registration data.
• Observable result: Invalid submissions are rejected with inline red error text per field and a yellow validation banner carrying a rule number.
• Access state: Applies wherever the submitting role has access.
• Failure/recovery: The submitter corrects the flagged fields and resubmits.
• Continuation: A valid submission is accepted and reflected in the relevant record.

FR-04 — Security and role-appropriate access control (explicit) As an Admin, I should have proper security enforced, including role-appropriate access control, so that capabilities and data are reachable only within each role's permitted scope.

• Trigger/input: Any attempt to reach a capability or record.
• Observable result: Access within the role's permitted scope succeeds; access outside it is denied with a red access-denial banner carrying a rule number.
• Access state: Identity required; role determines permitted scope.
• Failure/recovery: The denied user returns to a destination their role owns.
• Continuation: The user continues within their permitted scope.

FR-05 — Self-service enrollment (required_inference) As an Attendee, I should create my own application identity through self-service enrollment before protected use, so that I can reach the destinations my role owns.

• Trigger/input: An anonymous visitor submits the enrollment form on Sign Up.
• Observable result: An application identity is created for the visitor.
• Access state: Anonymous entry on Sign Up; protected state remains unavailable until identity is established.
• Failure/recovery: Invalid or incomplete input produces inline field errors and a yellow validation banner; the visitor corrects the fields and resubmits.
• Continuation: The visitor proceeds to verification and role-appropriate access.

FR-06 — Returning verification for every role (required_inference) As an Organizer, I should verify my identity on return, so that I can resume my role-scoped work.

• Trigger/input: A returning user submits credentials on Login.
• Observable result: Identity is verified and the user reaches the destinations their role owns.
• Access state: Anonymous entry on Login; protected state becomes available only after verification.
• Failure/recovery: Invalid credentials produce inline field errors and a yellow validation banner; denied access produces a red access-denial banner with a rule number. The user corrects input and resubmits, or navigates to Sign Up.
• Continuation: The verified user continues into their role's destinations.

FR-07 — Role assignment before role-specific access (required_inference) As an Admin, I should assign each user's role so that the platform establishes whether they act as Admin, Organizer, Attendee, or Venue Manager before role-specific access is granted.

• Trigger/input: The Admin assigns or changes a role on Users.
• Observable result: The user's role assignment is recorded and reflected in the row's role stamp, and role-specific access follows from it.
• Access state: Users is role-restricted to Admin.
• Failure/recovery: An invalid assignment produces a yellow validation banner with a rule number; an out-of-scope action produces a red access-denial banner. The Admin corrects the assignment and reapplies it.
• Continuation: The affected user reaches the destinations their assigned role owns.

FR-08 — Validation across user, event, registration, venue, availability, and booking data (required_inference) As an Admin, I should have validation applied to user, event, registration, venue, availability, and booking data, so that every record type in the platform holds valid data.

• Trigger/input: Any submission or change touching user, event, registration, venue, availability, or booking data.
• Observable result: Invalid data is rejected with inline red error text per field and a yellow validation banner carrying a rule number.
• Access state: Applies wherever the submitting role has access.
• Failure/recovery: The submitter corrects the flagged fields and resubmits.
• Continuation: Valid data is accepted and reflected in the relevant record.

FR-09 — Role-appropriate authorization over shared durable records (required_inference) As an Admin, I should have role-appropriate authorization protect shared durable records, so that no role reaches records outside its permitted scope.

• Trigger/input: Any read or change of a shared durable record.
• Observable result: Reads and changes within the role's permitted scope succeed; those outside it are denied with a red access-denial banner carrying a rule number.
• Access state: Identity required; role determines permitted scope over shared records.
• Failure/recovery: The denied user returns to a destination their role owns.
• Continuation: The user continues within their permitted scope.

FR-10 — Venue availability and booking conflict checking (required_inference) As a Venue Manager, I should have venue availability and booking conflicts checked before bookings are accepted, so that no booking collides with an existing commitment.

• Trigger/input: A booking is submitted against a venue.
• Observable result: A booking that does not conflict is accepted; a booking that conflicts with an existing commitment is rejected with a yellow conflict warning carrying a rule number.
• Access state: Bookings and Venues are role-restricted to Venue Manager; venue arrangements on Event Details are role-restricted to Organizer.
• Failure/recovery: The Venue Manager resolves the conflict or selects a non-conflicting arrangement and retries.
• Continuation: The accepted booking is reflected in the booking list and in venue availability.

FR-11 — Event creation and maintenance (explicit) As an Organizer, I should create and edit event details, schedules, and venue arrangements, so that events are published with valid, complete information.

• Trigger/input: The Organizer creates an event or edits an existing event on Event Details.
• Observable result: Event details, schedule, and venue arrangements are saved and reflected.
• Access state: Event Details is role-restricted to Organizer.
• Failure/recovery: Invalid input produces inline field errors and a yellow validation banner; a venue conflict produces a yellow conflict warning with a rule number; an out-of-scope action produces a red access-denial banner. The Organizer corrects the flagged fields or selects a non-conflicting arrangement and resubmits.
• Continuation: The saved event becomes available for attendee discovery.

FR-12 — Attendee tracking for organizer-owned events (explicit) As an Organizer, I should view and manage the attendees registered for organizer-owned events, so that attendance is tracked accurately.

• Trigger/input: The Organizer opens Attendees.
• Observable result: Registrations for organizer-owned events are listed and manageable.
• Access state: Attendees is role-restricted to Organizer.
• Failure/recovery: Failure to load or an out-of-scope action surfaces a yellow validation banner or a red access-denial banner respectively; the Organizer retries or corrects the action.
• Continuation: The Organizer continues managing the listed registrations.

FR-13 — Event browsing (explicit) As an Attendee, I should browse available events, so that I can begin event discovery.

• Trigger/input: The Attendee opens Events.
• Observable result: Available events are listed and selectable.
• Access state: Events is role-restricted to Attendee.
• Failure/recovery: Failure to load events surfaces a yellow banner with a rule number; the Attendee retries the list.
• Continuation: The Attendee selects an event and proceeds to Event View.

FR-14 — Event detail viewing (explicit) As an Attendee, I should view the details of an available event, so that I can decide whether to register.

• Trigger/input: The Attendee selects an event from Events.
• Observable result: The event's details, schedule, and venue information are presented with the registration path available.
• Access state: Event View is role-restricted to Attendee.
• Failure/recovery: Failure to load the event surfaces a yellow banner with a rule number; the Attendee returns to Events and reselects.
• Continuation: The Attendee proceeds to Registration.

FR-15 — Validated registration submission (explicit) As an Attendee, I should submit a validated registration for an event, so that my registration completes with valid input.

• Trigger/input: The Attendee submits the registration form on Registration.
• Observable result: A valid registration is accepted and reflected in the Attendee's registrations.
• Access state: Registration is role-restricted to Attendee.
• Failure/recovery: Invalid input produces inline field errors and a yellow validation banner; a capacity or availability conflict produces a yellow conflict warning with a rule number; an out-of-scope action produces a red access-denial banner. The Attendee corrects the flagged fields and resubmits, or returns to Events to select a different event.
• Continuation: The accepted registration appears in My Registrations.

FR-16 — Personal registration management (explicit) As an Attendee, I should view and manage my own event registrations, so that my event participation details remain accessible to me.

• Trigger/input: The Attendee opens My Registrations.
• Observable result: The Attendee's own registrations and their current status are listed and manageable.
• Access state: My Registrations is role-restricted to Attendee.
• Failure/recovery: Failure to load or an out-of-scope action surfaces a yellow validation banner or a red access-denial banner respectively; the Attendee retries or corrects the action.
• Continuation: The Attendee continues managing their registrations or moves into the corresponding event's view.

FR-17 — Venue information and availability maintenance (explicit) As a Venue Manager, I should create and maintain venue information and availability, so that venue details are accurate and bookings can be conflict-checked against them.

• Trigger/input: The Venue Manager creates or updates a venue record on Venues.
• Observable result: Venue information and availability are saved and reflected.
• Access state: Venues is role-restricted to Venue Manager.
• Failure/recovery: Invalid input produces inline field errors and a yellow validation banner; an availability conflict produces a yellow conflict warning with a rule number; an out-of-scope action produces a red access-denial banner. The Venue Manager corrects the flagged fields and resubmits.
• Continuation: The updated availability governs subsequent booking conflict checks.

FR-18 — Venue booking management and organizer coordination (explicit) As a Venue Manager, I should manage venue bookings and coordinate with organizers, so that bookings do not conflict with existing commitments.

• Trigger/input: The Venue Manager opens Bookings and acts on a booking.
• Observable result: The booking is managed and reflected in the booking list and in venue availability.
• Access state: Bookings is role-restricted to Venue Manager.
• Failure/recovery: A booking that conflicts with an existing commitment produces a yellow conflict warning with a rule number; an out-of-scope action produces a red access-denial banner. The Venue Manager resolves the conflict or corrects the action and retries.
• Continuation: The resolved booking stands and venue availability reflects it.

4. User Personas

Admin

Product context: The Admin oversees the whole event management system. Their work is not event production but platform governance: the accounts that exist, the roles those accounts hold, and the validation and security rules that govern what every other role may do.

Primary goal: Every role operates within its permitted scope, and platform-wide data and access remain secure.

Distinct accepted responsibilities: Managing user accounts and role assignments across Admin, Organizer, Attendee, and Venue Manager on Users; reviewing and enforcing platform-wide validation and security rules on Security, including the permission matrix that maps each role to the capabilities and records it may reach.

Relevant inputs and decisions: Which role a given account should hold; whether a validation or security rule should stand as configured; whether an attempted change falls inside or outside permitted scope.

Interactions with other accepted participants: The Admin's role assignments determine what every other persona can reach. An Organizer, Attendee, or Venue Manager who cannot reach their destinations is resolved by the Admin's assignment on Users. The Admin does not create events, register for events, or manage venue bookings.

Observable success: Role assignments are recorded and reflected in the account list; validation and security rules are in force; attempts outside a role's permitted scope are denied with a red access-denial banner carrying a rule number.

Organizer

Product context: The Organizer produces events. Their work is the event definition itself — what the event is, when it runs, and where it is held — together with the record of who has registered for the events they own.

Primary goal: Events are published with valid, complete information, and attendance is tracked accurately.

Distinct accepted responsibilities: Creating and editing event details, schedules, and venue arrangements on Event Details; viewing and managing the attendees registered for organizer-owned events on Attendees.

Relevant inputs and decisions: Event details, schedule, and venue arrangement selections; which venue arrangement to commit to given availability; which registrations to manage for organizer-owned events.

Interactions with other accepted participants: The Organizer's venue arrangements depend on the availability the Venue Manager maintains, and a conflicting arrangement is surfaced as a yellow conflict warning rather than silently accepted. The Organizer's published events are what Attendees browse and register for, and those registrations appear in the Organizer's Attendees view. The Organizer's access to Event Details and Attendees depends on the role the Admin assigned.

Observable success: Event details, schedule, and venue arrangements save without validation errors; the attendee list for organizer-owned events reflects actual registrations.

Attendee

Product context: The Attendee is the participant the events are staged for. Their work is discovery and participation: finding events, deciding whether to attend, registering, and keeping track of what they have signed up for.

Primary goal: Registration completes with valid input, and their event participation details are accessible to them.

Distinct accepted responsibilities: Browsing available events on Events; viewing an event's details on Event View; submitting a validated registration on Registration; viewing and managing personal registrations on My Registrations.

Relevant inputs and decisions: Which event to view; whether to register for it; the registration input they submit; which of their own registrations to manage.

Interactions with other accepted participants: The Attendee registers for events the Organizer published, and their registration appears in the Organizer's Attendees view. Their registration is subject to the validation and conflict rules the Admin enforces. The Attendee's access to Events, Event View, Registration, and My Registrations depends on the role the Admin assigned.

Observable success: A valid registration is accepted and appears in My Registrations with its current status; invalid input is flagged inline with a yellow validation banner rather than accepted.

Venue Manager

Product context: The Venue Manager owns the physical capacity side of the system. Their work is keeping venue information and availability accurate and keeping bookings free of collisions with existing commitments.

Primary goal: Venue details are accurate and bookings do not conflict with existing commitments.

Distinct accepted responsibilities: Creating and maintaining venue information and availability on Venues; managing venue bookings and coordinating with organizers on Bookings.

Relevant inputs and decisions: Venue information and availability windows; which bookings to accept, and how to resolve a booking that conflicts with an existing commitment.

Interactions with other accepted participants: The availability the Venue Manager maintains is what Organizer venue arrangements are checked against, and a conflicting arrangement surfaces as a yellow conflict warning. The Venue Manager coordinates with organizers over bookings. Their access to Venues and Bookings depends on the role the Admin assigned.

Observable success: Venue information and availability save without validation errors; a booking that conflicts with an existing commitment is rejected with a yellow conflict warning carrying a rule number, and accepted bookings are reflected in the booking list and in venue availability.

5. Core User Flows

Flow 1 — Admin assigns a role and enforces platform rules

1. The Admin verifies identity on Login and reaches the destinations the Admin role owns.
2. The Admin opens Users and scans the ruled account table, reading each account's current role stamp.
3. The Admin selects an account and assigns or changes its role among Admin, Organizer, Attendee, and Venue Manager.
4. If the assignment is invalid, the row shows a yellow validation banner with a rule number and inline red error text; the Admin corrects the assignment and reapplies it.
5. If the action falls outside permitted scope, a red access-denial banner with a rule number appears; the Admin returns to a destination the Admin role owns.
6. On success, the account's role stamp updates and the affected user's role-specific access follows from the new assignment.
7. The Admin opens Security and reviews the platform-wide validation and security rules and the permission matrix drawn as a printed grid.
8. The Admin enforces a rule change; an invalid change produces a yellow validation banner with a rule number, and an out-of-scope change produces a red access-denial banner. The Admin corrects the change and reapplies it.
9. On success, the matrix reflects the change and the rule governs subsequent platform behavior.

Flow 2 — Organizer creates an event and tracks its attendees

1. The Organizer verifies identity on Login and reaches the destinations the Organizer role owns.
2. The Organizer opens Event Details and creates a new event, entering its details, schedule, and venue arrangements in the two-column label/value form.
3. If input is invalid, inline red error text appears per field with a yellow validation banner carrying a rule number; the Organizer corrects the flagged fields and resubmits.
4. If the selected venue arrangement conflicts with existing commitments, a yellow conflict warning with a rule number appears; the Organizer selects a non-conflicting arrangement and resubmits.
5. If the action falls outside permitted scope, a red access-denial banner with a rule number appears; the Organizer returns to a destination the Organizer role owns.
6. On success, the event's details, schedule, and venue arrangements are saved and the event becomes available for attendee discovery.
7. The Organizer opens Attendees and views the registrations for organizer-owned events in the ruled table.
8. The Organizer manages those registrations; a rejected change produces a yellow validation banner with a rule number, and an out-of-scope action produces a red access-denial banner. The Organizer corrects the action and retries.
9. On success, the attendee records reflect the Organizer's management.

Flow 3 — Attendee discovers an event and registers

1. The Attendee verifies identity on Login and reaches the destinations the Attendee role owns.
2. The Attendee opens Events and browses the available events in the ruled list, scanning titles, dates, and venue information.
3. If the list fails to load, a yellow banner with a rule number appears; the Attendee retries.
4. The Attendee selects an event and lands on Event View, where the event's details, schedule, and venue information are presented with the registration path available.
5. If the event fails to load, a yellow banner with a rule number appears; the Attendee returns to Events and reselects.
6. The Attendee proceeds to Registration and submits the registration form.
7. If input is invalid, inline red error text appears per field with a yellow validation banner carrying a rule number; the Attendee corrects the flagged fields and resubmits.
8. If a capacity or availability conflict arises, a yellow conflict warning with a rule number appears; the Attendee corrects the submission or returns to Events to select a different event.
9. If the action falls outside permitted scope, a red access-denial banner with a rule number appears; the Attendee returns to a destination the Attendee role owns.
10. On success, the registration is accepted and appears in My Registrations with its current status.
11. The Attendee opens My Registrations, views and manages their own registrations, and can move from a registration into the corresponding event's view. A rejected change produces a yellow validation banner with a rule number, and an out-of-scope action produces a red access-denial banner; the Attendee corrects the action and retries.

Flow 4 — Venue Manager maintains a venue and resolves a booking conflict

1. The Venue Manager verifies identity on Login and reaches the destinations the Venue Manager role owns.
2. The Venue Manager opens Venues and creates or updates a venue record, entering its information and availability.
3. If input is invalid, inline red error text appears per field with a yellow validation banner carrying a rule number; the Venue Manager corrects the flagged fields and resubmits.
4. If an availability conflict arises, a yellow conflict warning with a rule number appears; the Venue Manager corrects the availability and resubmits.
5. If the action falls outside permitted scope, a red access-denial banner with a rule number appears; the Venue Manager returns to a destination the Venue Manager role owns.
6. On success, the venue information and availability are saved and govern subsequent booking conflict checks.
7. The Venue Manager opens Bookings and reviews the venue bookings and their status in the ruled table.
8. The Venue Manager acts on a booking. A booking that conflicts with an existing commitment is rejected with a yellow conflict warning carrying a rule number; the Venue Manager resolves the conflict and retries. An out-of-scope action produces a red access-denial banner.
9. On success, the booking is reflected in the booking list and in venue availability, and the Venue Manager coordinates with the organizer over the booking.

Flow 5 — New user establishes identity and reaches role-scoped work

1. An anonymous visitor arrives at Landing and reads the system's purpose, its four roles, and its validation and conflict-checking promises.
2. The visitor selects "CREATE AN ACCOUNT" and lands on Sign Up.
3. The visitor submits the enrollment form. If input is invalid or incomplete, inline red error text appears per field with a yellow validation banner carrying a rule number; the visitor corrects the flagged fields and resubmits.
4. On success, an application identity is created for the visitor.
5. The visitor proceeds to Login and submits credentials. Invalid credentials produce inline field errors and a yellow validation banner; denied access produces a red access-denial banner with a rule number. The visitor corrects input and resubmits, or returns to Sign Up.
6. On success, identity is verified and the user reaches the destinations their role owns.
7. A user without an assigned role reaches no role-scoped destination; the Admin assigns the role on Users, after which the user reaches the destinations that role owns.

6. Visuals Colors and Theme

The visual direction is typography as architecture, after the muse Paula Scher: words filling the frame, colour blocks colliding, energy over polish. The headline idea is that a role-and-permission system should read like a public-institution poster system — a control room with a poster on the wall — rather than a calm admin panel. Role coding is the palette's job: four roles, four colour codes, four poster bands.

Colour tokens (light mode)

Rules of use: poster red #E63329 is the dominant colour block — hero band, primary buttons, active nav underline, Admin role badge. Poster yellow #F2C300 is the second block, used for Organizer and for the validation/success signal, always as a flat fill with black type on it, never as a tint. Deep poster blue #2B4C9B is used only as a small Venue Manager badge fill, never as a page or button ground. Muted #6E6A63 is for metadata, timestamps, and helper text on the newsprint ground — never for body copy on red or yellow, where black is the only text colour. No gradients anywhere; every colour is a flat field with a hard edge.

Typography

• Headings: Anton, at display scale, uppercase, tracking -0.01em, leading 0.88–0.92 so stacked lines lock together as a block. Headlines are set as the image: three to five words per line, ragged-left, allowed to run the full viewport width as a single line at 1280px. Section titles step down to Anton at 28–40px.
• Card titles: Archivo 700 uppercase at 14px with 0.14em tracking.
• Body: Archivo.
• Numerals: Archivo with tabular figures in tables and stat blocks, so columns align like a printed schedule.

Type scale (1.25 modular with poster jumps):

Mobile display floor 52px; desktop ceiling 132px.

Shape language

Hard edges only: zero border-radius on panels, buttons, inputs, and badges. Structure comes from 2px and 4px black rules, full-bleed colour bands, and diagonal cuts at 8–12 degrees where two colour blocks meet. Buttons are solid rectangles with a 3px black offset shadow that shifts 3px on press instead of rounding or glowing. Badges are rectangular stamps with black 2px borders and uppercase 11px labels. No blobs, no pills, no soft shadows.

Layout

A visible 12-column poster grid with black column rules showing on the landing and dashboard surfaces. Sections are full-bleed horizontal bands alternating newsprint, white, red, and yellow, each band carrying one idea. The landing hero is a typographic stack bleeding off the right edge; role blocks are four unequal columns (Admin widest, Attendee narrowest) rather than an even card grid. Inside the app, the left rail is a black column of uppercase nav items with a red active block, and every data screen is a ruled table with a sticky black header row — Users, Registrations, Bookings, and Venues all share this tabular spine. Forms are two-column label/value rows on white panels with red inline error text and yellow validation banners. At 375px the band stack becomes single-column, the 12-column rules collapse to a single 2px left rule, and tables become horizontally scrollable ruled rows with the first column pinned.

Imagery

Typography is the image: oversized role names, event titles, and validation rules set as the visual content. Where photography appears it is high-contrast, tightly cropped audience and stage shots reduced to two-tone black/red duotone, used as full-bleed band backgrounds with type sitting on a solid colour block over them — never as a card thumbnail grid. Supporting graphics are flat pictograms for the four roles drawn as chunky 2px-stroke symbols, and a ruled "system diagram" on the Security page that draws the permission matrix as a printed grid.

7. Signature Design Concept

The public entry is a full-bleed poster, not a centred SaaS hero.

A newsprint ground #F4F1EA carries a 2px black rule grid. The headline "RUN THE EVENT. GUARD THE DOOR." is set in Anton at clamp(52px, 9vw, 132px), uppercase, stacked in three lines that span the viewport and bleed slightly past the right edge, black on newsprint. Behind the second line sits a solid red #E63329 block 38% of viewport height that cuts diagonally into a yellow #F2C300 block at the lower right. Across the bottom, a black band 96px tall runs a slow uppercase marquee: ADMIN · ORGANIZER · ATTENDEE · VENUE MANAGER · VALIDATED · CONFLICT-CHECKED.

The primary CTA is a solid red rectangle with a black 3px offset shadow pinned bottom-left of the red block, labelled "CREATE AN ACCOUNT" in Archivo 700 uppercase; the secondary is a black outlined rectangle labelled "SIGN IN". Four flat role stamps sit on the rule grid at mid-right, each a rectangle with its role colour and uppercase label, sized unequally — Admin widest, Attendee narrowest.

No centred text, no gradient, no illustration. The type is the hero image.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief

• Focal subject: The oversized Anton headline "RUN THE EVENT. GUARD THE DOOR." stacked in three lines across the full viewport width, with the solid red #E63329 block and the diagonal yellow #F2C300 block cutting across it.
• Input → transformation → outcome thesis: On entry, the headline's three lines rise 24px each with 60ms offsets and settle into their locked stack, while the red panel wipes over the white ground in 320ms on cubic-bezier(0.2,0.8,0.2,1) and the yellow block resolves at the lower right. The outcome is the composed poster: type as architecture, role stamps on the rule grid, and the black marquee band running the four role names and the system's validation promises.
• Motion vocabulary: Colour-block wipes (a red panel sliding over a white one on section entry, 320ms, cubic-bezier(0.2,0.8,0.2,1)); staggered word reveals on the hero (each line rising 24px with 60ms offsets); a slow uppercase type marquee on the landing band naming the roles. Hover on nav and table rows flips the row to black with white type instantly, no easing. No bounce, no float, no parallax.
• Composed first frame: Newsprint ground with the 2px black rule grid visible; the headline's first line already in place; the red block at 38% viewport height behind the second line; the yellow block resolving at the lower right; the four role stamps on the rule grid at mid-right; the red "CREATE AN ACCOUNT" rectangle with its black 3px offset shadow pinned bottom-left of the red block; the black outlined "SIGN IN" rectangle beside it; the black marquee band across the bottom.
• Reduced-motion state: Under prefers-reduced-motion, all wipes and reveals resolve to their final state and the marquee becomes a static wrapped row of role words. The poster composition is unchanged; only the motion is removed.

9. Non-Functional Requirements

NFR-01 — Role-appropriate access control (explicit) Proper security must be enforced, including role-appropriate access to capabilities and data. Rationale: the platform holds shared durable records across four roles, and access must remain within each role's permitted scope. Denials are surfaced as a red access-denial banner with a rule number.

NFR-02 — Validation on data entry and event/registration flows (explicit) Proper validations must be applied to data entry and event/registration flows. Rationale: invalid data entering the platform undermines both event integrity and booking correctness. Validation failures are surfaced as inline red error text per field and a yellow validation banner carrying a rule number.

NFR-03 — Four distinct roles (explicit) Multiple distinct roles must exist: Admin, Organizer, Attendee, and Venue Manager. Rationale: role separation is the product's organizing constraint, and each role's capabilities depend on it.

NFR-04 — Conflict-free venue booking (required_inference) Venue availability and booking conflicts must be checked before bookings are accepted. Rationale: a booking that collides with an existing commitment breaks the venue's real-world commitments. Conflicts are surfaced as a yellow conflict warning carrying a rule number.

NFR-05 — Readable text and controls at every viewport (explicit, from the creative direction) Headlines, wordmarks, labels, numbers, cards' text, and controls must stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling (for example font-size: clamp(...) with its mobile size) to fit, and no other element may cover any part of them. Imagery, decoration, and motion may be cropped, bled off an edge, rotated, overlapped, or cut as the direction asks, as long as they cover no readable text or control. Moving and scrollable content (marquees, tickers, horizontally scrollable rows) may cross the viewport or container edge by design and is judged by whether it actually moves or scrolls and whether every item becomes fully readable as it passes. Under prefers-reduced-motion, a usable static arrangement is provided: items wrap into rows or scroll horizontally so each item can be brought fully into view.

NFR-06 — No gradients, no rounded corners, no soft shadows (explicit, from the creative direction) Every colour is a flat field with a hard edge. Zero border-radius on panels, buttons, inputs, and badges. No gradients, glassmorphism, soft drop shadows, or hover-lift cards. Blue or indigo is forbidden as a page, button, or hero ground; blue appears only as the small Venue Manager stamp.

NFR-07 — Black text on colour fields (explicit, from the creative direction) Muted grey body copy is forbidden on red or yellow blocks; black is the only text colour on colour fields.

10. Tech Stack

No technology choices were specified by the user. The following are coherent defaults for this project, labelled as such.

• Frontend: React — [Default — not specified by user]. The application is a custom first-party web UI with role-restricted destinations, ruled data tables, and form-heavy validation surfaces.
• Backend: Python / FastAPI — [Default — not specified by user]. The platform requires server-side enforcement of validation, role-appropriate authorization, and venue availability and booking conflict checking, none of which can be trusted to the client.
• Storage: A relational database — [Default — not specified by user]. The domain is relational and constraint-driven: users hold roles, events carry schedules and venue arrangements, registrations bind attendees to events, and bookings must be checked for conflicts against venue availability.
• Containerization: Docker and docker-compose — [Default — not specified by user]. Sufficient for local development and a single-host deployment of this application.
• Orchestration: Kubernetes is not included. [Default — not specified by user] — no deployment requirement in the sources calls for it.

11. Assumptions and Constraints

Constraints (source-backed, binding)

• Multiple distinct roles must exist: Admin, Organizer, Attendee, and Venue Manager.
• Proper validations must be applied to data entry and event/registration flows.
• Proper security must be enforced, including role-appropriate access to capabilities and data.
• The visual direction is authoritative for palette, typography, shape language, layout, imagery, and motion, and its prohibitions (no border-radius, no gradients, no soft shadows, no blue or indigo page/button/hero grounds, no even grids of identical cards, no neutral geometric sans as the heading voice, no parallax or bouncy easing) are binding.
• Readable text and controls stay whole at 375px, 768px, and 1280px.

Assumptions (narrow, labelled)

• [Assumption] Identity is application-owned and established by self-service enrollment, because no provisioning or invitation boundary is established for initial product use. Landing, Login, and Sign Up are reachable anonymously; every other destination requires an established identity.
• [Assumption] Role assignment is the mechanism that grants role-specific access. A user without an assigned role reaches no role-scoped destination until the Admin assigns one on Users.
• [Assumption] Role-appropriate authorization is differentiated control over shared product state, not merely a label: the platform's records are shared across roles, and each role's permitted scope is what the Security permission matrix expresses.
• [Assumption] Validation and conflict failures are surfaced in the interface as printed states — yellow banners with black uppercase text and a rule number for field errors and conflict warnings, red banners with a rule number for access denial — consistent with the creative direction.
• [Assumption] The current delivery horizon covers everything described in this document. No future-horizon capabilities are asserted.

12. Glossary

• Admin — The platform administrator role. Manages user accounts and role assignments on Users, and reviews and enforces platform-wide validation and security rules on Security.
• Attendee — The participant role that browses events, views event details, submits validated registrations, and manages personal registrations.
• Attendees (page) — The Organizer's role-restricted destination for viewing and managing attendees registered for organizer-owned events.
• Booking — A venue commitment held by the Venue Manager, checked against venue availability before acceptance.
• Bookings (page) — The Venue Manager's role-restricted destination for managing venue bookings and coordinating with organizers.
• Conflict warning — A yellow #F2C300 full-width banner with black uppercase text, a black 2px rule, and a rule number, surfaced when a submission collides with an existing commitment.
• Event — A scheduled occurrence with details, a schedule, and a venue arrangement, created and maintained by an Organizer and discoverable by Attendees.
• Event Details (page) — The Organizer's role-restricted workspace for creating and editing event details, schedules, and venue arrangements.
• Event View (page) — The Attendee's role-restricted destination for viewing the details of a single available event.
• Events (page) — The Attendee's role-restricted destination for browsing available events.
• Landing (page) — The anonymous public entry surface explaining the system, its four roles, and its core event workflows.
• Login (page) — The anonymous returning-verification surface shared by all four roles.
• My Registrations (page) — The Attendee's role-restricted destination for viewing and managing personal event registrations.
• Organizer — The role that creates and manages events, including event details, scheduling, and venue arrangements, and monitors who has registered.
• Permission matrix — The printed grid on Security mapping each role to the capabilities and records it may reach.
• Registration — The record binding an Attendee to an event, submitted through validated input.
• Registration (page) — The Attendee's role-restricted workflow for submitting a validated registration for an event.
• Role stamp — A rectangular badge with a black 2px border and an uppercase 11px label, filled with the role's colour: Admin #E63329, Organizer #F2C300, Attendee #1F7A6B, Venue Manager #2B4C9B.
• Rule number — The identifier printed on validation, conflict, and access-denial banners (for example, "RULE 04 — VENUE CONFLICT").
• Security (page) — The Admin's role-restricted workspace for reviewing and enforcing platform-wide validation and security rules.
• Sign Up (page) — The anonymous self-service enrollment surface that creates an application identity.
• Users (page) — The Admin's role-restricted workspace for managing user accounts and assigning roles.
• Validation banner — A yellow #F2C300 full-width banner with black uppercase text, a black 2px rule, and a rule number, surfaced for field errors and conflict warnings.
• Venue — A physical location with information and availability maintained by the Venue Manager, against which bookings are conflict-checked.
• Venue Manager — The role that maintains venue information and availability and coordinates venue bookings with organizers.
• Venues (page) — The Venue Manager's role-restricted workspace for creating and maintaining venue information and availability.