System Requirements Document for gaming-dashboard

1. Introduction

Product intent. gaming-dashboard is a large, single-purpose gaming dashboard whose structure, sections, and visual presentation are modeled on the reference website https://noterplus-157.web.app. The user's stated commitment is explicit and current: build a big gaming dashboard that is almost identical to that reference site, and treat that site as the authoritative model for the dashboard's structure, sections, and visual presentation.

Audience. The product serves a single active human role, the Gaming Dashboard Viewer — a player who opens the dashboard to browse its gaming content and panels, navigate its sections, and read the presented gaming information. Success is a dashboard experience that closely matches the reference site.

Important source limitation. The reference site could not be inspected: it returned only a blank/loading indicator with no observable structure, features, or visuals. The reference directive remains authoritative for intent (replicate the reference's dashboard structure, sections, and visual presentation as closely as possible), but no concrete section list, feature list, or visual facts could be verified from it. Where the reference cannot supply a fact, this document relies on the supplied authoritative creative direction (a cinematic future-tech command deck) to define the concrete dashboard shell, panels, and visual language, and labels any such fill as a default or required inference rather than as a verified reference fact.

2. System Overview

gaming-dashboard is a first-party, browser-delivered gaming dashboard with two current destinations:

• Landing — the public entry surface that introduces the gaming dashboard and leads the viewer into it.
• Dashboard — the large gaming command surface itself: a fixed left rail, a top command bar, a full-bleed hero scene, radial stat gauges, a live matches telemetry table, a squad roster panel, and an activity stream.

Both destinations are application-owned custom pages with no access requirement (no sign-in, no account, no provider gate). The product is read/browse-oriented: the viewer navigates sections and reads presented gaming information. No account management, social features, purchases, or competitive matchmaking are part of the accepted scope.

2a. Product Interpretation and Delivery Boundary

Delivery ownership. The dashboard is a first-party web application. All current behavior is delivered by the application's own pages; there is no provider-owned surface, no external destination, and no headless-only delivery in the current scope.

Access. Both Landing and Dashboard are openly reachable with no identity requirement. The accepted outcome is a dashboard a viewer can open and browse; nothing in the authoritative thread requires private, per-user, or resumable state, so no application identity, sign-in, or account lifecycle is introduced.

Current vs. future. Current scope is exactly the two destinations above and the dashboard content they present. The reference site's exact section inventory could not be verified; the dashboard's concrete panels are therefore defined by the supplied creative direction and this document's defaults, and are treated as the current presentation of the accepted "big gaming dashboard" outcome. Any future expansion to match newly inspectable reference content is a future consideration, not current scope.

2b. Source Content Inventory

The reference directive declares content_source authority for https://noterplus-157.web.app. However, the verified source observation records that the page returned only a blank/loading state and that content_source, structure_reference, feature_reference, and visual_inspiration were all null — no factual entities, collections, fields, values, descriptions, dates, contacts, links, or media references could be verified.

Verified inventory: none. No reference-site content items can be preserved because none were observable. This document does not invent reference-site facts to fill the inventory; the dashboard's concrete content is defined by the creative direction and labeled defaults in Section 2c.

2c. Page Content and Component Coverage

Landing

• Purpose and information/state. Public entry surface introducing the gaming dashboard and its command-deck character, then leading the viewer into the Dashboard. Anonymous, no access requirement.
• Primary action. Enter the Dashboard (magenta primary CTA pinned beneath the hero headline).
• Supporting actions. Read the hero headline and telemetry readouts; observe the hero scene.
• Domain entities. None persisted; presentation-only content (headline, CTA, three telemetry readouts: rank, win rate, session time).
• Component responsibilities.
  • Full-bleed dark hero scene: glowing faceted 3D core right-of-centre, orbited by thin cyan particle rings, over a faint topographic grid floor receding into black.
  • Glassy HUD frame with corner brackets overlaying the scene.
  • Left-aligned oversized Space Grotesk headline "YOUR NEXT MATCH STARTS HERE" stacked in three lines at clamp(48px, 9vw, 128px).
  • Magenta primary CTA pinned directly beneath the headline.
  • Row of three monospace telemetry readouts (rank, win rate, session time) along the bottom edge.
• States.
  • Loading: hero scene initializes; headline, CTA, and readouts render immediately as static text so entry is never blocked.
  • Empty: not applicable (no data collections).
  • Success: scene renders and CTA is available.
  • Error/recovery: if the WebGL scene fails to initialize, fall back to a static framed hero (same headline, CTA, readouts) so the viewer can still enter the Dashboard.
  • Reduced motion: static framed scene, instant state changes.

Dashboard

• Purpose and information/state. The large gaming command surface: a dense but ordered 12-column grid presenting gaming content and panels, closely mirroring the reference site's dashboard structure and presentation as far as the reference could be modeled.
• Primary action. Navigate dashboard sections via the left rail and read the presented gaming information.
• Supporting actions. Use the top command bar (search, season selector, player chip); read radial stat gauges; scan the live matches telemetry table; read the squad roster panel; read the activity stream.
• Domain entities. Stat gauges (four radial metrics), live matches (rows with right-aligned monospace numbers), squad roster (members), activity stream (events). All are presented content; no user-authored persistence is accepted.
• Component responsibilities.
  • Fixed left rail: icon + uppercase micro-label navigation with a cyan glow marker that slides to the active item.
  • Top command bar: search, season selector, player chip.
  • Full-bleed hero scene spanning columns 1–12.
  • Row of four radial stat gauges with luminous cyan arcs and counting numerals that sweep once on load.
  • Wide "live matches" telemetry table: hairline row rules, right-aligned monospace numbers, pulsing cyan data-stream line on the active row.
  • Squad roster panel.
  • Activity stream.
  • Panels float with 24px gutters; glassy surfaces with hairline cyan-tinted borders.
• States.
  • Loading: panels render their frames immediately; gauges and table populate as content becomes available.

• Empty: a panel with no content shows its frame with a muted "no data" label rather than collapsing the grid.
• Success: all panels populated; active row pulses; gauges show final counted values.
• Error/recovery: if a panel's content fails to load, that panel shows an inline error with a retry affordance while the rest of the dashboard remains usable.
• Reduced motion: counting numerals show final values instantly; no pulsing data-stream line; static framed hero.

3. Functional Requirements

FR-1 — Build a big gaming dashboard almost identical to the reference site. As a Gaming Dashboard Viewer, I should open a large gaming dashboard whose structure, sections, and visual presentation closely mirror https://noterplus-157.web.app, so that I get the reference-modeled dashboard experience the product promises.

• Provenance: explicit.
• Lifecycle: viewer opens the application → Dashboard renders its command-deck layout → viewer browses sections and reads gaming information.
• Access: none (openly reachable).
• Failure/recovery: if a panel fails to load, it shows an inline error with retry while the rest of the dashboard stays usable.
• Continuation: viewer continues navigating sections via the left rail.
• Acceptance: the Dashboard presents the full command-deck layout (left rail, top command bar, hero scene, four radial gauges, live matches table, squad roster, activity stream) with minimal deviation from the reference's intended structure and presentation.

FR-2 — Reference site is the authoritative model for structure, sections, and visual presentation. As a Gaming Dashboard Viewer, I should see the dashboard's structure, sections, and visual presentation follow the reference site as the authoritative model, so that the result reads as an almost identical copy.

• Provenance: explicit.
• Lifecycle: viewer compares the dashboard's layout and presentation against the reference model; deviations are minimal.
• Access: none.
• Failure/recovery: where the reference could not be verified (blank/loading), the supplied creative direction supplies the concrete presentation; this is a documented limitation, not a deviation from intent.
• Continuation: viewer continues browsing.
• Acceptance: dashboard structure and presentation are modeled on the reference; any unverifiable reference detail is filled from the creative direction and labeled as such.

FR-3 — Public Landing entry into the dashboard. As a Gaming Dashboard Viewer, I should land on a public entry surface that introduces the gaming dashboard and lets me enter it, so that I can reach the dashboard from a clear starting point.

• Provenance: required_inference (indispensable anonymous entry for the accepted dashboard outcome).
• Lifecycle: viewer arrives at Landing → reads headline and telemetry readouts → activates the magenta CTA → Dashboard opens.
• Access: none.
• Failure/recovery: if the hero scene fails, a static framed hero still presents the headline, CTA, and readouts.
• Continuation: viewer is now on the Dashboard and can navigate its sections.
• Acceptance: Landing renders the hero headline, CTA, and three telemetry readouts; activating the CTA opens the Dashboard.

FR-4 — Navigate dashboard sections via the left rail. As a Gaming Dashboard Viewer, I should navigate the dashboard's sections from a fixed left rail with icon + uppercase micro-labels and a cyan glow marker on the active item, so that I can move between panels and know where I am.

• Provenance: required_inference (indispensable navigation for browsing the accepted dashboard sections).
• Lifecycle: viewer selects a rail item → glow marker slides to it → the corresponding section is shown/emphasized.
• Access: none.
• Failure/recovery: if a section's content fails, the rail remains usable and the section shows an inline error with retry.
• Continuation: viewer selects another section.
• Acceptance: the active rail item is marked by a sliding cyan glow; selecting an item changes the active section.

FR-5 — Read radial stat gauges. As a Gaming Dashboard Viewer, I should read four radial stat gauges with luminous cyan arcs and counting numerals that sweep once on load, so that I can take in my headline stats at a glance.

• Provenance: required_inference (indispensable presentation of the dashboard's stat content).
• Lifecycle: Dashboard loads → gauges sweep once → numerals settle at final values → viewer reads them.
• Access: none.
• Failure/recovery: if gauge data is unavailable, the gauge shows its frame with a muted "no data" label.
• Continuation: viewer continues to other panels.
• Acceptance: four radial gauges render with cyan arcs and final counted numerals; under reduced motion the final values appear instantly.

FR-6 — Scan the live matches telemetry table. As a Gaming Dashboard Viewer, I should scan a wide live matches table styled as a telemetry feed with hairline row rules, right-aligned monospace numbers, and a pulsing cyan data-stream line on the active row, so that I can follow live match information.

• Provenance: required_inference (indispensable presentation of the dashboard's live match content).
• Lifecycle: Dashboard loads → table rows render → active row pulses → viewer reads match data.
• Access: none.
• Failure/recovery: if match data fails to load, the table shows an inline error with retry.
• Continuation: viewer continues scanning or moves to another panel.
• Acceptance: table renders rows with right-aligned monospace numbers and a pulsing active row; under reduced motion the pulse is omitted.

FR-7 — Read the squad roster panel. As a Gaming Dashboard Viewer, I should read a squad roster panel, so that I can see the squad's members within the dashboard.

• Provenance: required_inference (indispensable presentation of the dashboard's squad content).
• Lifecycle: Dashboard loads → roster panel renders → viewer reads members.
• Access: none.
• Failure/recovery: if roster data is unavailable, the panel shows its frame with a muted "no data" label.
• Continuation: viewer continues to other panels.
• Acceptance: roster panel renders within the dashboard grid.

FR-8 — Read the activity stream. As a Gaming Dashboard Viewer, I should read an activity stream, so that I can follow recent activity within the dashboard.

• Provenance: required_inference (indispensable presentation of the dashboard's activity content).
• Lifecycle: Dashboard loads → activity stream renders → viewer reads events.
• Access: none.
• Failure/recovery: if activity data is unavailable, the panel shows its frame with a muted "no data" label.
• Continuation: viewer continues to other panels.
• Acceptance: activity stream renders within the dashboard grid.

FR-9 — Use the top command bar. As a Gaming Dashboard Viewer, I should use a top command bar carrying search, a season selector, and a player chip, so that I can orient and filter the dashboard's presented content.

• Provenance: required_inference (indispensable orientation controls for the accepted dashboard shell).
• Lifecycle: viewer uses search / season selector / player chip → the dashboard's presented content reflects the selection.
• Access: none.
• Failure/recovery: if a selection yields no content, affected panels show their empty state.
• Continuation: viewer adjusts the selection or continues browsing.
• Acceptance: the command bar renders search, season selector, and player chip; changing the season selector updates the presented content.

4. User Personas

Gaming Dashboard Viewer

Product context. The viewer is a player who lives inside competitive, high-volume game data and wants the feeling of a mission-control HUD: dark, luminous, volumetric, with motion as the hero. They arrive at gaming-dashboard expecting a big gaming dashboard that closely mirrors the reference site's structure and presentation.

Primary goal. Open the dashboard and browse its gaming content and panels — navigating sections and reading the presented gaming information — in an experience that closely matches the reference site.

Distinct accepted responsibilities.

• Enter the dashboard from the public Landing surface.
• Navigate the dashboard's sections via the fixed left rail.
• Read the four radial stat gauges.
• Scan the live matches telemetry table.
• Read the squad roster panel.
• Read the activity stream.
• Use the top command bar (search, season selector, player chip) to orient and filter presented content.

Relevant inputs or decisions. Which section to view; which season to select; what to search for; which match row to focus on.

Interactions with other accepted participants. None. The viewer is the sole active human role; there is no counterparty, recipient, or decision-maker whose state the dashboard changes. All dashboard content is presented for reading.

Observable success. The viewer reaches the Dashboard from Landing, moves between sections with a clear active marker, and reads populated gauges, live matches, squad roster, and activity stream in a layout that closely matches the reference site's intended structure and presentation.

Constraints. The dashboard must be almost identical to the reference site; deviations from its structure and presentation should be minimal. The reference site itself could not be inspected, so the concrete presentation is supplied by the authoritative creative direction.

5. Core User Flows

Flow A — Enter the dashboard from Landing

1. The Gaming Dashboard Viewer opens the application and arrives at Landing (anonymous, no access requirement).
2. Landing presents the full-bleed dark hero scene: a glowing faceted 3D core right-of-centre, orbited by thin cyan particle rings, over a faint topographic grid floor, framed by glassy HUD corner brackets.
3. The viewer reads the left-aligned oversized headline "YOUR NEXT MATCH STARTS HERE" and the three monospace telemetry readouts (rank, win rate, session time) along the bottom edge.
4. The viewer activates the magenta primary CTA pinned beneath the headline.
5. Observable result: the Dashboard opens.
6. Failure/recovery: if the WebGL hero fails to initialize, Landing falls back to a static framed hero with the same headline, CTA, and readouts, and the viewer can still enter the Dashboard.
7. Continuation: the viewer is on the Dashboard and proceeds to Flow B.

Flow B — Browse dashboard sections

1. The viewer is on the Dashboard; the fixed left rail shows icon + uppercase micro-label navigation with a cyan glow marker on the active item.
2. The viewer selects a rail item.
3. Observable result: the cyan glow marker slides to the selected item and the corresponding section is shown/emphasized.
4. Failure/recovery: if a section's content fails to load, that section shows an inline error with a retry affordance while the rail and other sections remain usable.
5. Continuation: the viewer selects another section or moves to Flow C.

Flow C — Read the dashboard's panels

1. The viewer is on the Dashboard; the 12-column grid presents the hero scene (columns 1–12), a row of four radial stat gauges, the live matches telemetry table, the squad roster panel, and the activity stream.
2. On load, the four radial gauges sweep once with luminous cyan arcs and counting numerals that settle at final values.
3. The viewer scans the live matches table: hairline row rules, right-aligned monospace numbers, and a pulsing cyan data-stream line on the active row.
4. The viewer reads the squad roster panel and the activity stream.
5. Observable result: the viewer has taken in the dashboard's presented gaming information.
6. Failure/recovery: any panel whose content fails to load shows its frame with an inline error and retry; a panel with no content shows a muted "no data" label rather than collapsing the grid.
7. Continuation: the viewer moves to Flow D or returns to Flow B.

Flow D — Orient and filter via the top command bar

1. The viewer is on the Dashboard; the top command bar carries search, a season selector, and a player chip.
2. The viewer enters a search term, selects a season, or inspects the player chip.
3. Observable result: the dashboard's presented content reflects the selection.
4. Failure/recovery: if a selection yields no content, the affected panels show their empty state.
5. Continuation: the viewer adjusts the selection or continues browsing.

6. Visuals Colors and Theme

Muse and headline. Gleb Kuznetsov — Cinematic future-tech command deck. A gaming dashboard for players who live inside competitive, high-volume game data; the emotional register is adrenaline plus technical mastery, not calm utility.

Mode. Dark mode only. No light-mode ground.

Color tokens (exact hex by role).

Glows sit behind or beside text, never under body text.

Typography.

• Headings: Space Grotesk, 500–700 weight, tight tracking (-0.02em), uppercase for section titles and HUD micro-labels; oversized hero numerals and match titles at very large scale with generous letter-spacing on micro-caps.
• Body: IBM Plex Mono.
• Scale (1.4 modular): 96 / 68 / 48 / 32 / 20 / 16 / 13; hero display clamp(48px, 9vw, 128px); HUD micro-labels 11–12px uppercase with 0.18em tracking; body 15–16px monospace with 1.6 line-height.

Shape language. Full-bleed dark scene; floating glass panels with 16–20px radii and hairline cyan-tinted borders; thin luminous strokes; radial gauge rings for stats; chamfered corners on data chips; hairline grid lines reading like a HUD overlay. No soft blobby gradients — light is directional and volumetric.

Layout. Dashboard shell: fixed left rail (icon + label nav) with a top command bar carrying search, season selector, and player chip. Main area is a 12-column grid: full-bleed hero scene spanning columns 1–12, then a row of four radial stat gauges, a wide live matches telemetry table, a squad roster panel, and an activity stream. Panels float with 24px gutters; dense but ordered; monospace numerals right-aligned in tables.

Imagery. One crafted abstract 3D hero subject — a faceted, glowing polygonal core orbited by particle rings and thin luminous arcs — plus HUD-style telemetry graphics: radial gauges, sparkline waveforms, radar plots, and a topographic grid floor. No stock photos, no flat clip art, no cartoon characters.

Readability constraint. Headlines, wordmarks, labels, numbers, cards' text and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling to fit; no other element covers any part of them. Imagery and decoration may crop, bleed, rotate, overlap, or cut as the direction asks, provided they cover no readable text or control.

Forbidden. Centred headline + subtext + blue button SaaS hero; gradient blobs or soft pastel washes; stock photography of people or esports crowds; cartoon or flat vector characters; white or light-mode ground; Inter, Roboto, Arial, Helvetica, Poppins, or system-ui; identical hover-lift card grid; bouncy or playful spring easing; the generic indigo/blue-on-white SaaS template.

7. Signature Design Concept

"Command Deck Entry." The Landing's first screen is a full-bleed dark scene: a large glowing faceted 3D core floats right-of-centre, orbited by thin cyan particle rings, over a faint topographic grid floor receding into black. A glassy HUD frame with corner brackets overlays the scene. Left-aligned, oversized Space Grotesk headline "YOUR NEXT MATCH STARTS HERE" stacks in three lines at clamp(48px, 9vw, 128px), with a magenta primary CTA pinned directly beneath it and a row of three monospace telemetry readouts (rank, win rate, session time) along the bottom edge. No centred headline, no gradient blob. The CTA is the only path forward and opens the Dashboard.

This concept recomposes only accepted Landing content — headline, CTA, telemetry readouts, and the hero scene — and introduces no new behavior or destination.

8. Interaction Model & Motion Direction

Interaction Model: Animated Motion Tempo: cinematic Hero Dimensionality: webgl

Landing Hero Motion Brief

• Focal subject. The faceted, glowing polygonal core orbited by thin cyan particle rings, over a receding topographic grid floor.
• Input → transformation → outcome thesis. On load, the core's orbit begins slowly and the particle rings sweep; as the viewer scrolls, the camera tilts with the scroll position, deepening the sense of a live command deck. The outcome is a first frame that feels like a live mission-control HUD, with the headline, CTA, and telemetry readouts held steady and fully readable throughout.
• Motion vocabulary. One continuous slow orbit; scroll-scrubbed camera tilt; light sweeps across panel edges on hover; counting numerals on stat gauges; data-stream lines pulsing along table rows. No bouncy or playful spring easing.
• Composed first frame. Dark ground #05060B; glowing core right-of-centre; cyan particle rings; faint topographic grid floor; glassy HUD corner brackets; left-aligned three-line headline; magenta CTA beneath; three monospace telemetry readouts along the bottom edge.
• Reduced-motion state. Static framed scene: the core and rings hold a fixed pose, no scroll-scrubbed tilt, no light sweeps, no counting animation (final values shown instantly), no pulsing data-stream line. All content remains fully readable and the CTA remains available.

Landing Hero 3D Scene Brief — DIRECTION-DERIVED

A real-time WebGL/R3F scene of one crafted abstract object: a faceted, glowing polygonal core with emissive cyan edges, orbited by two or three thin particle rings and luminous arcs, suspended above a faint topographic grid floor that recedes into black. The scene shows the product's defining state — a live, luminous command surface — with a slow continuous orbit and a scroll-scrubbed camera tilt. Lighting is directional and volumetric; glows sit behind or beside the headline, CTA, and readouts, never under them. Under prefers-reduced-motion, the scene renders as a static framed composition.

9. Non-Functional Requirements

• NFR-1 — Reference fidelity. The dashboard must be almost identical to https://noterplus-157.web.app; deviations from the reference site's structure and presentation should be minimal. (Provenance: explicit. Rationale: explicit hard constraint in the authoritative user evidence.)
• NFR-2 — Reference as authoritative model. The reference site is the authoritative model for the dashboard's structure, sections, and visual presentation. (Provenance: explicit.)
• NFR-3 — Reference unverifiable. The reference site returned only a blank/loading state during verification; no structure, features, or visuals could be observed. Where the reference cannot supply a fact, the creative direction supplies the concrete presentation, and this limitation is documented rather than hidden. (Provenance: explicit source observation.)
• NFR-4 — Readability at every viewport. Readable text and controls stay whole at 375px, 768px, and 1280px, wrapping or scaling to fit; no other element covers any part of them. (Provenance: explicit design constraint.)
• NFR-5 — Reduced motion. All motion respects prefers-reduced-motion, falling back to a static framed scene and instant state changes. (Provenance: explicit creative direction.)
• NFR-6 — Dark mode only. The product is dark-mode only; no light-mode ground. (Provenance: explicit creative direction.)
• NFR-7 — No forbidden template look. The generic indigo/blue-on-white SaaS template is forbidden. (Provenance: explicit design constraint.)
• NFR-8 — No account requirement. Both destinations are openly reachable with no identity requirement; no account management is introduced. (Provenance: required_inference from the accepted open-browse outcome.)

10. Tech Stack

• Frontend: React (single-page application) with a component-based dashboard shell.
• 3D hero: React Three Fiber / Drei for the Landing's WebGL hero scene, with a static fallback when WebGL is unavailable or reduced motion is requested.
• Styling: CSS with the exact tokens in Section 6 (Space Grotesk and IBM Plex Mono via web fonts; CSS custom properties for the palette).
• Backend: Python/FastAPI serving the dashboard's presented content (stat gauges, live matches, squad roster, activity stream) as read-only endpoints.
• Storage: a lightweight store for the dashboard's presented content; no user-authored persistence is required.
• Deployment: Docker / docker-compose for the frontend and backend services.

11. Assumptions and Constraints

• A-1. The reference site could not be inspected; its exact section inventory and visual facts are unavailable. The dashboard's concrete panels and visual language are therefore supplied by the authoritative creative direction and this document's defaults, and are treated as the current presentation of the accepted "big gaming dashboard" outcome. (Labeled assumption; consistent with NFR-3.)
• A-2. The dashboard's presented content (gauges, matches, roster, activity) is read-only presentation; no user-authored data, accounts, or persistence are accepted. (Required inference from the accepted browse-only outcome.)
• A-3. The Landing is a required-inference public entry surface; it introduces the dashboard and leads into it, and introduces no capability beyond that. (Required inference.)
• A-4. The dashboard's concrete content values (specific stats, match rows, roster members, activity events) are not specified by the authoritative source and are filled as presentation defaults; they do not create new product capabilities.
• A-5. No differentiated permissions, RBAC, or role-based visibility are established; the single persona has uniform access to both destinations.

12. Glossary

• Gaming Dashboard Viewer — the sole active human role; a player who opens the dashboard to browse its gaming content and panels.
• Landing — the public entry surface introducing the dashboard and leading into it.
• Dashboard — the large gaming command surface with the left rail, top command bar, hero scene, radial gauges, live matches table, squad roster, and activity stream.
• Command deck — the cinematic future-tech HUD visual language defined by the creative direction.
• Radial stat gauge — a circular gauge with a luminous cyan arc and a counting numeral.
• Live matches telemetry table — the wide table of live match rows styled as a telemetry feed.
• Squad roster panel — the dashboard panel listing squad members.
• Activity stream — the dashboard panel listing recent activity events.
• HUD micro-label — an 11–12px uppercase label with 0.18em tracking.
• Reduced motion — the prefers-reduced-motion state in which motion falls back to a static framed scene and instant state changes.