System Requirements Document for topaz-instagram

1. Introduction

topaz-instagram is a read-only data portrait of a single Instagram account — @Deep_sardaeni712. It is not a management tool, not an analytics dashboard, and not a scheduling or growth product. It is a gallery piece: the account's public body of work (posts, reels, likes, saves, comment threads, follower growth) is rendered as a living, generative visual form that the account owner — and anyone they choose to share the link with — can stand in front of and see.

The product intent is derived directly from the authoritative requirement thread: the user asked about their own Instagram account Deep_sardaeni712, confirmed they wanted to proceed with building something around it, and accepted the project name topaz-instagram. The specific tool, dashboard, or site was never named by the user; the accepted scope is a product built around that Instagram account, with one binding exclusion: the product must not pull up or manage anyone's Instagram account, and no Instagram account access or credential handling is part of it.

The audience is therefore the Instagram account owner — the person who holds @Deep_sardaeni712 — plus the people they share the portrait with. The owner's recurring responsibility is to state what they want built and to use the resulting product; the product's job is to give their account a presence you can stand in front of, fed entirely by data the owner supplies themselves (an exported archive or manually pasted post metrics), never by a live authenticated connection.

2. System Overview

topaz-instagram is delivered as a single first-party custom web surface — the Landing page — which is the anonymous public entry to the portrait. There is no login, no account linking, no OAuth handshake with Instagram, and no server-side credential store. The Landing page is reachable by anyone with the link, and it is the only page in the current information architecture.

The current delivery shape is a custom UI (custom_ui: true) with one interaction surface:

Actors. The only accepted active human persona is the Instagram account owner. There are no system, provider, or external-service personas in the current scope; the product has no outbound integration with Instagram or any other provider.

Accepted behavior. The Landing page presents the account as a data portrait: a full-bleed generative hero, a metric band, a horizontally-scrolling post archive, a ruled "topography" ledger of per-post figures, and a closing statement band. All figures shown are supplied by the owner from an exported archive or pasted metrics. The page is read-only with respect to Instagram: it never authenticates, never fetches from Instagram's API, and never writes back to the account.

Ownership. All accepted human-facing behavior is owned by the Landing page. There is no separate backend service, no queue worker, and no provider surface in the current scope. Any data ingestion is a local, owner-initiated act of supplying an export or pasting metrics into the portrait.

Narrow exclusions. No Instagram account access, no credential handling, no account management, no posting, no scheduling, no follower automation, no direct messages, and no live Instagram API integration. These are binding and are not softened by the presence of Instagram-related vocabulary elsewhere in the document.

2a. Product Interpretation and Delivery Boundary

The product is a read-only portrait, not an admin panel. The distinction matters for every downstream decision: the owner does not log in to topaz-instagram to operate their Instagram account; they open it to look at their account as an artefact. The emotional register is gallery-like awe plus personal pride.

Because the product cannot and must not connect to Instagram, the data that drives the portrait arrives one of two ways, both owner-initiated and both local:

1. Exported archive — the owner exports their Instagram data through Instagram's own tooling and supplies that export to the portrait.
2. Manually pasted post metrics — the owner pastes per-post figures (date, caption, reach, saves, comments, likes) directly.

The portrait then renders those figures as a generative field, a metric band, an aperture strip, and a ledger. Nothing about this flow requires an account on topaz-instagram, and nothing about it touches Instagram's servers on the product's behalf.

Current vs. future. Everything described in this document is current. There is no accepted future horizon in the authoritative thread; no roadmap items, no "phase two" capabilities, and no deferred integrations have been accepted. The only forward-looking statement permitted here is the explicit exclusion itself: live Instagram integration is out of scope, not deferred.

Access boundary. The Landing page is anonymous and public (access_requirement: none). This is not a provisional negative — it is the correct boundary for a read-only portrait that the owner shares by link. There is no protected destination in the current scope, so there is no identity-establishment journey to design, and no account-management capability is implied.

2b. Source Content Inventory

Not applicable. No reference directive in the authoritative thread declares content_source, so no source content inventory is rendered.

2c. Page Content and Component Coverage

Landing

The Landing page is the anonymous public entry to the portrait. It is a vertical museum sequence, not a dashboard: five full-bleed sections stacked in order, each separated by a full-width 1px hairline rule. On mobile (390px and below) every section collapses to a single column with 20px gutters; the archive strip remains horizontally scrollable.

Information and state

• The account handle DEEP_SARDAENI712, set in the product's own type — never in Instagram's brand lockup or gradient.
• A read-only status pill in the top-right corner: READ-ONLY · NO ACCOUNT ACCESS.
• Three headline metrics: total posts, total followers, average engagement.
• A per-post ledger: date, caption, reach, saves, comments.
• A generative field whose density, hue, and drift are driven by the account's own numbers.
• A data-source state: whether the portrait is currently rendering from a supplied export, from pasted metrics, or is empty.

Primary actions

• Enter the portrait — the single text link with a 1px amber underline, pinned to the bottom-left corner of the hero, which scrolls the visitor from the hero into the metric band.
• Supply the account data — the owner's act of providing an exported archive or pasting post metrics, which populates every downstream section.

Supporting actions

• Scroll through the museum sequence (hero → metric band → aperture strip → topography ledger → closing band).
• Horizontally scroll the post archive strip to bring each aperture fully into view.
• Hover (or focus) a post aperture to trigger a soft luminous bloom and a caption fade-in.
• Re-supply or replace the account data to re-render the portrait.

Domain entities

• Account — the single Instagram account @Deep_sardaeni712; the subject of the portrait. Read-only.
• Post — a unit of the account's public body of work: date, caption, reach, saves, comments, likes, and a thumbnail reference.
• Metric — a headline figure (posts, followers, average engagement) derived from the supplied data.
• Data source — the owner-supplied export or pasted metrics that feed the portrait.
• Generative field — the rendered particle system whose parameters are bound to the account's numbers.

Component responsibilities

• Hero canvas — full-bleed, 100vh, near-black ground #05060A. Hosts the WebGL particle field. Asymmetric composition: the field's dense mass is pushed to the right two-thirds; type is anchored in the lower-left third. Carries the stacked headline, the A DATA PORTRAIT · NOT A DASHBOARD label, the Enter the portrait → link, and the read-only pill.
• Metric band — three oversized Fraunces numerals separated by full-height 1px hairlines that run edge-to-edge across the viewport. No cards, no shadows, no rounded corners.
• Aperture strip — a horizontally-scrolling row of circular post apertures with hairline rings, captions fading in beneath on hover. Bleeds off both viewport edges by design.
• Topography ledger — a ruled ledger where each post is a row of tabular IBM Plex Mono numerals (date · reach · saves · comments), aligned like instrument readouts.
• Closing band — a full-bleed amber #E8B54A band carrying one oversized Fraunces statement in near-black. The only bright surface in the entire product.
• Data-source control — the owner-facing affordance for supplying an export or pasting metrics, and for seeing which source is currently active.

States

• Loading — while the generative field initializes and the supplied data is being parsed, the hero renders its near-black ground with the headline and read-only pill already legible; the field fades in rather than popping. The metric band and ledger show their hairline rules with numerals held at reduced opacity until values resolve.
• Empty — when no export or pasted metrics have been supplied, the portrait renders the hero, the headline, the read-only pill, and the Enter the portrait → link, with the metric band showing placeholder rules and the aperture strip and ledger showing a single ruled row that states no account data has been supplied yet. The data-source control is the only actionable element.
• Success — the field renders with density, hue, and drift bound to the supplied numbers; the metric band shows the three headline figures; the aperture strip scrolls with captions on hover; the ledger lists every post as a ruled row.
• Error — when a supplied export cannot be parsed or pasted metrics are malformed, the portrait keeps the last successfully rendered state visible and surfaces a hairline-bordered notice naming the problem (unreadable export, missing required fields, unrecognized format). The data-source control remains available for a corrected supply.
• Recovery — the owner re-supplies a corrected export or corrected metrics; the portrait re-renders from the new source without requiring a reload, and the previous state is replaced rather than merged.

3. Functional Requirements

Each requirement below is a distinct story point with provenance, lifecycle facts, and observable acceptance. Provenance values are explicit, basic_default, or required_inference.

FR-1 — Public entry to the portrait As an Instagram account owner, I should be able to open a public link to topaz-instagram and immediately see my account presented as a data portrait, so that I can share my presence as a form rather than an admin panel.

• Provenance: required_inference (the source never names a page; the Landing surface is the anonymous first impression).
• Actor: Instagram account owner (and anyone the owner shares the link with).
• Trigger/input: navigating to the Landing page URL.
• Observable result: the hero renders full-bleed with the account handle DEEP_SARDAENI712 in Fraunces light, the label A DATA PORTRAIT · NOT A DASHBOARD, the Enter the portrait → link, and the READ-ONLY · NO ACCOUNT ACCESS pill.
• Access state: anonymous, no identity required.
• Failure/recovery: if the generative field fails to initialize, the hero still renders its near-black ground with all readable text and the read-only pill intact.
• Continuation: the visitor can scroll into the metric band or follow Enter the portrait →.

FR-2 — Read-only boundary As an Instagram account owner, I should be able to use topaz-instagram knowing it never logs in to, pulls from, or manages my Instagram account, so that my credentials and account control are never involved.

• Provenance: explicit (hard constraint from the authoritative thread).
• Actor: Instagram account owner.
• Trigger/input: any interaction with the product.
• Observable result: the READ-ONLY · NO ACCOUNT ACCESS pill is visible in the hero; no authentication flow, credential field, or account-linking control exists anywhere in the product.
• Access state: anonymous.
• Failure/recovery: not applicable — the boundary is structural, not a runtime state.
• Continuation: the owner supplies data themselves (FR-3).

FR-3 — Supply the account data As an Instagram account owner, I should be able to supply my account's data by providing an exported archive or pasting post metrics, so that the portrait can be rendered without any live Instagram connection.

• Provenance: required_inference (the read-only constraint makes owner-supplied data the only viable feed for the accepted portrait).
• Actor: Instagram account owner.
• Trigger/input: the owner provides an exported archive file or pastes per-post metrics (date, caption, reach, saves, comments, likes).
• Observable result: the portrait re-renders from the supplied source; the metric band, aperture strip, and topography ledger populate from it.
• Access state: anonymous.
• Failure/recovery: if the export cannot be parsed or the pasted metrics are malformed, the last successful state remains visible and a hairline-bordered notice names the problem; the owner can re-supply.
• Continuation: the owner can replace the source at any time to re-render the portrait.

FR-4 — Generative hero field As an Instagram account owner, I should be able to see my account's numbers rendered as a living particle field, so that my presence reads as a form rather than a chart.

• Provenance: required_inference (the accepted portrait concept requires a visual binding between the account's numbers and the rendered form).
• Actor: Instagram account owner (and shared viewers).
• Trigger/input: the supplied account data.
• Observable result: a full-bleed WebGL point cloud glows in topaz amber #E8B54A with teal counter-currents #38E0C8; particle count follows post frequency, brightness follows engagement, and position along the drift axis follows recency.
• Access state: anonymous.
• Failure/recovery: under prefers-reduced-motion, the field renders as a single static frame.
• Continuation: scrolling condenses the field into a band as the visitor enters the metric band, then disperses it.

FR-5 — Metric band As an Instagram account owner, I should be able to read my three headline figures as oversized numerals, so that the scale of my account is legible at a glance.

• Provenance: required_inference (the accepted portrait requires the account's headline figures to be presented).
• Actor: Instagram account owner (and shared viewers).
• Trigger/input: the supplied account data.
• Observable result: three oversized Fraunces numerals — posts, followers, average engagement — separated by full-height 1px hairlines running edge-to-edge across the viewport. No cards, no shadows.
• Access state: anonymous.
• Failure/recovery: when no data has been supplied, the band shows its hairline rules with placeholder treatment and points to the data-source control.
• Continuation: the visitor scrolls into the aperture strip.

FR-6 — Post archive as aperture strip As an Instagram account owner, I should be able to browse my posts as a horizontally-scrolling strip of circular apertures, so that my body of work reads as a sequence of data points rather than a photo grid.

• Provenance: required_inference (the accepted portrait requires the account's posts to be presented).
• Actor: Instagram account owner (and shared viewers).
• Trigger/input: the supplied account data.
• Observable result: a horizontally-scrolling row of circular apertures with hairline rings, heavily darkened thumbnails, captions fading in beneath on hover, bleeding off both viewport edges by design.
• Access state: anonymous.
• Failure/recovery: under prefers-reduced-motion, the strip becomes a normal horizontally-scrollable row so every item can be brought fully into view.
• Continuation: the visitor scrolls into the topography ledger.

FR-7 — Topography ledger As an Instagram account owner, I should be able to read every post as a ruled row of tabular figures, so that my account's detail is legible like an instrument readout.

• Provenance: required_inference (the accepted portrait requires per-post detail to be presented).
• Actor: Instagram account owner (and shared viewers).
• Trigger/input: the supplied account data.
• Observable result: each post is a ruled row of tabular IBM Plex Mono numerals — date · reach · saves · comments — aligned in columns.
• Access state: anonymous.
• Failure/recovery: when no data has been supplied, the ledger shows a single ruled row stating that no account data has been supplied yet.
• Continuation: the visitor scrolls into the closing band.

FR-8 — Closing statement band As an Instagram account owner, I should be able to reach a closing statement that names what the portrait is, so that the piece ends on its own terms rather than trailing off.

• Provenance: required_inference (the accepted portrait sequence requires a terminal section).
• Actor: Instagram account owner (and shared viewers).
• Trigger/input: scrolling to the end of the museum sequence.
• Observable result: a full-bleed amber #E8B54A band carrying one oversized Fraunces statement in near-black — the only bright surface in the product.
• Access state: anonymous.
• Failure/recovery: not applicable — the band is static content.
• Continuation: the visitor can scroll back up or share the link.

4. User Personas

Instagram account owner

Product context. The owner holds the Instagram account @Deep_sardaeni712. They asked about their own account and confirmed they wanted to proceed with building something around it. The specific tool, dashboard, or site was never specified by them — what they accepted is a product built around that account, with the binding exclusion that it must not pull up or manage anyone's Instagram account.

Primary goal. To see their account as an artefact — a presence they can stand in front of — rather than to operate, grow, schedule, or administer it.

Distinct accepted responsibilities.

• Stating what they want built and using the resulting product (their recurring responsibility per the accepted persona rationale).
• Supplying the account's data themselves, by providing an exported archive or pasting post metrics, because the product cannot and must not fetch it.
• Sharing the portrait by link with anyone they choose.

Relevant inputs and decisions.

• The decision of which data source to supply: an exported archive or manually pasted post metrics.
• The per-post figures they paste or export: date, caption, reach, saves, comments, likes.
• The decision to replace or re-supply the data to re-render the portrait.

Interactions with other accepted participants. There are no other accepted human personas in the current scope. The owner's only counterparties are the people they share the link with, who are viewers of the portrait rather than participants in a workflow. There is no handoff, no approval, and no counterparty decision in the current product.

Observable success. The owner opens the link and sees their account rendered as a generative field, a metric band, an aperture strip, and a ruled ledger — all populated from data they supplied, with the READ-ONLY · NO ACCOUNT ACCESS pill confirming that nothing about their Instagram credentials was involved.

What makes this role's work different. The owner is not an operator. They do not log in, do not manage, do not schedule, and do not respond to anything inside the product. Their only recurring act is to supply data and then look at what it becomes. Every design decision in topaz-instagram follows from that: the product has no admin surface, no settings, no permissions, and no notifications, because the owner's job is to stand in front of the portrait, not to run it.

5. Core User Flows

Flow 1 — The owner opens their portrait for the first time

1. The owner opens the topaz-instagram link in a browser. No login is requested; the Landing page is anonymous.
2. The hero renders full-bleed at 100vh on a near-black ground #05060A. The account handle DEEP_SARDAENI712 appears in Fraunces light at clamp(48px, 9vw, 132px), anchored in the lower-left third. Beneath it, in 11px uppercase IBM Plex Mono with 0.18em tracking, reads A DATA PORTRAIT · NOT A DASHBOARD.
3. In the top-right corner, a hairline-bordered pill reads READ-ONLY · NO ACCOUNT ACCESS. The owner sees immediately that no credential is involved.
4. Because no data has been supplied yet, the portrait is in its empty state: the metric band shows its hairline rules with placeholder treatment, and the aperture strip and ledger each show a single ruled row stating that no account data has been supplied yet.
5. The owner uses the data-source control to supply their account's data — either by providing an exported archive or by pasting per-post metrics (date, caption, reach, saves, comments, likes).
6. Success: the portrait re-renders. The generative field fades in with density, hue, and drift bound to the supplied numbers — particle count following post frequency, brightness following engagement, position along the drift axis following recency. The metric band resolves to three oversized Fraunces numerals. The aperture strip populates with circular post apertures. The ledger fills with ruled rows.
7. Failure: if the export cannot be parsed or the pasted metrics are malformed, the last successfully rendered state stays visible and a hairline-bordered notice names the problem — unreadable export, missing required fields, or unrecognized format. The owner corrects the source and re-supplies it; the portrait re-renders from the new source without a reload.
8. Continuation: the owner follows Enter the portrait → or scrolls into the metric band.

Flow 2 — The owner walks the museum sequence

1. From the hero, the owner follows the Enter the portrait → link — a single text link with a 1px amber underline, pinned to the bottom-left corner.
2. As the page scrolls, the generative field condenses from a dispersed cloud into a condensed band, then disperses as the owner continues past it. The transition is a slow crossfade, choreographed on an 8–20 second cycle; nothing snaps or pops.
3. The owner arrives at the metric band: three oversized Fraunces numerals — posts, followers, average engagement — separated by full-height 1px hairlines that run edge-to-edge across the viewport. No cards, no shadows.
4. The owner continues into the aperture strip: a horizontally-scrolling row of circular post apertures with hairline rings, bleeding off both viewport edges by design. Hovering an aperture produces a soft luminous bloom and fades in its caption beneath.
5. The owner continues into the topography ledger: every post as a ruled row of tabular IBM Plex Mono numerals — date · reach · saves · comments — aligned like instrument readouts.
6. The owner reaches the closing band: a full-bleed amber #E8B54A band carrying one oversized Fraunces statement in near-black — the only bright surface in the entire product, arriving after four screens of void.
7. Failure/recovery: if the owner has prefers-reduced-motion enabled, the field renders as a single static frame and the archive strip becomes a normal horizontally-scrollable row, so every aperture can still be brought fully into view. The sequence remains fully readable.
8. Continuation: the owner scrolls back up, or shares the link.

Flow 3 — The owner shares the portrait

1. The owner copies the topaz-instagram link.
2. The owner sends the link to someone they choose.
3. The recipient opens the link. Because the Landing page requires no identity, the recipient sees the portrait immediately — the same hero, the same read-only pill, the same metric band, aperture strip, ledger, and closing band.
4. The recipient scrolls the museum sequence and hovers apertures to read captions.
5. Failure/recovery: if the recipient's environment has prefers-reduced-motion enabled, the static arrangement applies and the portrait remains fully usable.
6. Continuation: the recipient can scroll back up or close the page. Nothing about the recipient's visit changes the owner's portrait, because the product is read-only.

Flow 4 — The owner replaces the account data

1. The owner returns to the portrait and decides the supplied data is out of date or incomplete.
2. The owner uses the data-source control to supply a new export or a new set of pasted metrics.
3. Success: the portrait re-renders from the new source. The field's density, hue, and drift rebind to the new numbers; the metric band, aperture strip, and ledger all repopulate. The previous state is replaced rather than merged.
4. Failure: if the new source cannot be parsed, the previously rendered portrait remains visible and a hairline-bordered notice names the problem. The owner corrects the source and re-supplies it.
5. Continuation: the owner walks the sequence again or shares the updated link.

6. Visuals, Colors and Theme

The creative direction is authoritative for this section. The muse is Refik Anadol; the headline is "Data made physical: an Instagram account turned into a living data sculpture."

Palette (dark mode)

The generative field itself supplies the colour, glowing in topaz amber #E8B54A with a cool teal counter-current #38E0C8 — the two hues of a gemstone under light, and a deliberate nod to the project name. Warm ivory #F4F1EA is reserved for readable text only. Surfaces #0B0E18 are barely-there panels with 1px #1C2233 hairlines, never white glass. No blue, no violet, no gradient blobs. The generic indigo/blue-on-white SaaS template is forbidden for this project.

Typography

• Headings: Fraunces at light optical size (wght 300, opsz 144) with a slight soft-serif warmth — an art-catalogue voice, not a tech voice. Headlines set large with tight leading (0.92) and slightly negative tracking. Small caps for museum labels.
• Body: IBM Plex Sans 400 with generous 1.7 leading.
• Numerals: IBM Plex Mono for every metric, so figures align like instrument readouts.
• Scale: 1.4 modular — 24 / 34 / 48 / 68 / 96 / clamp(48px, 9vw, 132px) for the display hero. Body 17px desktop / 16px mobile. Labels 11px uppercase, 0.18em tracking.
• Inter, Roboto, Poppins, Lato, and any system-ui default are excluded for headings and body.

Shape language

No cards with rounded corners and drop shadows. Full-bleed canvas edges, hairline 1px rules that run the full width of the viewport, and circular aperture frames for post thumbnails — everything reads as a lens or a plinth. Panels are flat rectangles with a single top hairline. The only curves are the particle field's own organic flow and the circular post apertures.

Layout

A vertical museum sequence, not a dashboard:

1. Hero — full-bleed generative canvas, with type sitting in the lower-left third over the dark part of the field.
2. Metric band — three huge numerals separated by full-height hairlines (posts / followers / avg. engagement). No cards.
3. Aperture strip — the post archive as a horizontally-scrolling strip of circular apertures with captions beneath, bleeding off both edges.
4. Topography — each post as a row in a ruled ledger (date · caption · reach · saves) using tabular mono numerals.
5. Closing statement — oversized Fraunces on a solid amber band.

On mobile everything collapses to one column with 20px gutters; the archive strip stays horizontally scrollable.

Imagery

The generative field is the imagery — a WebGL point cloud of thousands of particles whose density and hue are driven by the account's own numbers (post frequency → particle count, engagement → brightness, recency → position along the drift axis). Post thumbnails appear only as small circular apertures, heavily darkened, treated as data points rather than photographs. Supporting imagery: fine topographic contour lines drawn in #1C2233, and a single amber data-wash gradient that runs behind the closing statement. Stock photography of phones, hands, or people scrolling is excluded.

7. Signature Design Concept

The portrait as a standing wave.

The public entry is a full-bleed near-black canvas #05060A filling 100vh, in which a slow-drifting WebGL particle field glows in topaz amber with teal counter-currents — the account's own data made physical. The composition is deliberately asymmetric: the field's dense mass is pushed to the right two-thirds, and the type is anchored in the lower-left third over the dark part of the field.

Over that dark left edge sits a stacked headline in Fraunces light — DEEP_SARDAENI712 at clamp(48px, 9vw, 132px) — and beneath it, in 11px uppercase IBM Plex Mono with 0.18em tracking, A DATA PORTRAIT · NOT A DASHBOARD. Below that, pinned to the bottom-left corner, a single text link with a 1px amber underline: Enter the portrait →. In the top-right corner, a hairline-bordered pill reads READ-ONLY · NO ACCOUNT ACCESS.

Nothing is centred. There is no blue button and no gradient blob — the field itself is the hero. The account name is set in our type, never in Instagram's brand lockup or gradient.

The concept recomposes only accepted content, states, and controls: the handle, the read-only pill, the entry link, and the generative field bound to the owner-supplied numbers. It introduces no new behaviour, page, or destination.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief

Focal subject. A full-bleed WebGL point cloud of thousands of particles, glowing in topaz amber #E8B54A with cool teal counter-currents #38E0C8, drifting slowly against a near-black void #05060A.

Input → transformation → outcome thesis. The owner-supplied account data (post frequency, engagement, recency) is the input. That data is transformed into the field's physical parameters — particle count, brightness, and position along the drift axis. The outcome is a portrait that breathes: the account's own numbers made into a form the visitor can stand in front of, with the field's dense mass pushed to the right two-thirds and the type anchored in the lower-left third.

Motion vocabulary. Continuous slow generative drift — the field breathes and slowly rotates. Scroll-linked morphing condenses the field as the visitor moves into the metrics band, then disperses it. Hovering a post aperture causes a soft luminous bloom and a caption fade-in. Section transitions are slow crossfades. Everything is choreographed at 8–20 second cycles: nothing snaps, nothing pops. No bouncy, springy, or snap-in motion.

Composed first frame. The near-black canvas fills the viewport. The particle field is already drifting, its dense mass to the right. The headline DEEP_SARDAENI712 sits in the lower-left third in Fraunces light, with A DATA PORTRAIT · NOT A DASHBOARD beneath it in 11px uppercase Plex Mono. The Enter the portrait → link is pinned to the bottom-left corner with its 1px amber underline. The READ-ONLY · NO ACCOUNT ACCESS pill sits in the top-right corner behind a hairline border.

Reduced-motion state. Under prefers-reduced-motion, the field renders as a single static frame — the composed first frame above, held still. The archive strip becomes a normal horizontally-scrollable row so every aperture can be brought fully into view. All readable text and controls remain whole and legible.

Landing Hero 3D Scene Brief — DIRECTION-DERIVED

The direction's hero dimensionality is webgl, so a real-time 3D scene is expected. One crafted object: a particle field — a point cloud of thousands of particles arranged along a slow drift axis, rendered in topaz amber #E8B54A with teal #38E0C8 counter-currents against the void #05060A. The scene shows the product's defining state: the account's own numbers made physical. Particle count is bound to post frequency, brightness to engagement, and position along the drift axis to recency. The field breathes and slowly rotates on an 8–20 second cycle, and morphs under scroll — condensing as the visitor enters the metric band, then dispersing. Under prefers-reduced-motion, the scene renders as a single static frame.

9. Non-Functional Requirements

NFR-1 — Read-only with respect to Instagram. The product must not pull up or manage anyone's Instagram account. No Instagram account access, credential handling, OAuth flow, or management capability is included. Provenance: explicit. Rationale: binding hard constraint from the authoritative thread.

NFR-2 — Anonymous public access. The Landing page requires no identity. There is no login, no account creation, and no session continuity requirement, because the product holds no per-user durable state. Provenance: required_inference. Rationale: the accepted page contract sets access_requirement: none, and a read-only portrait shared by link has no state that must remain bound to a participant.

NFR-3 — Owner-supplied data only. All figures rendered by the portrait originate from data the owner supplies — an exported archive or manually pasted post metrics. The product performs no live fetch from Instagram or any other provider. Provenance: required_inference. Rationale: the read-only constraint makes owner-supplied data the only viable feed for the accepted portrait.

NFR-4 — Readable text and controls stay whole. Headlines, wordmarks, labels, numbers, and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling (for example font-size: clamp(...) with its mobile size) to fit. No other element covers any part of them. Provenance: explicit (creative direction). Rationale: accessibility and legibility of the portrait's readable content.

NFR-5 — Reduced-motion support. Under prefers-reduced-motion, the generative field renders as a single static frame and the archive strip becomes a normal horizontally-scrollable row, so every item can be brought fully into view. Provenance: explicit (creative direction). Rationale: the portrait must remain usable without motion.

NFR-6 — Scrollable content may bleed by design. The aperture strip may cross the viewport edge by design; it is judged by whether it actually scrolls and whether every item becomes fully readable as it passes. A scrollable row need not show every item fully at once. Provenance: explicit (creative direction). Rationale: the museum-sequence layout depends on the strip bleeding off both edges.

NFR-7 — No generic SaaS visual language. Blue, indigo, or violet accents on a white ground are excluded. Rounded white glass cards in a grid with hover-lift shadows are excluded. Inter, Roboto, Poppins, Lato, and system-ui defaults are excluded for headings and body. Provenance: explicit (creative direction). Rationale: the portrait must read as a gallery piece, not a social dashboard.

NFR-8 — No Instagram brand assets. Instagram's own brand gradient and logo lockup are excluded. The account name is set in the product's own type, never in Instagram's. Provenance: explicit (creative direction). Rationale: the portrait is the product's own artefact, not an Instagram surface.

10. Tech Stack

The authoritative thread specifies no technology choices. The following are the minimal, coherent defaults needed to deliver the accepted behavior, labeled as defaults.

• Frontend: React with a WebGL renderer for the generative hero field. [Default — not specified by user]
• Styling: CSS with custom properties for the palette tokens in Section 6. [Default — not specified by user]
• Fonts: Fraunces (headings), IBM Plex Sans (body), IBM Plex Mono (numerals), loaded as web fonts. [Default — not specified by user]
• Data ingestion: client-side parsing of the owner-supplied export or pasted metrics. [Default — not specified by user]
• Storage: none required for the current scope; the portrait holds no durable per-user state. [Default — not specified by user]
• Backend: none required for the current scope. The product performs no live fetch and holds no server-side state. [Default — not specified by user]
• Deployment: static hosting of the built frontend. [Default — not specified by user]

No Python/FastAPI service, no Docker/docker-compose stack, and no Kubernetes deployment are required by the accepted behavior. If a future accepted requirement introduces server-side work, a single shared backend should be preferred over multiple services.

11. Assumptions and Constraints

Assumptions

• A-1. The owner has access to their own Instagram data export, or is willing to paste per-post metrics manually. This is the only viable feed given the read-only constraint. [Assumption — required_inference]
• A-2. The portrait is shared by link, and recipients are viewers rather than participants. No recipient-side workflow has been accepted. [Assumption — required_inference]
• A-3. The account handle @Deep_sardaeni712 is the single subject of the portrait. No multi-account support has been accepted. [Assumption — required_inference]

Constraints

• C-1. The product must not pull up or manage anyone's Instagram account. No Instagram account access or management capability is included. [Explicit — binding]
• C-2. The Landing page is the only page in the current information architecture, and it is anonymous. [Explicit — page contract]
• C-3. The Instagram account owner is the only accepted active human persona. [Explicit — persona contract]
• C-4. The palette, typography, shape language, layout, motion tempo, and imagery described in Sections 6–8 are binding for the current delivery. [Explicit — creative direction]
• C-5. No future horizon has been accepted. Live Instagram integration is out of scope, not deferred. [Explicit — binding]

12. Glossary

• Portrait — the product's central artefact: the account's public body of work rendered as a generative visual form.
• Generative field — the WebGL point cloud whose density, hue, and drift are bound to the account's own numbers.
• Aperture — a circular, heavily darkened post thumbnail with a hairline ring, treated as a data point rather than a photograph.
• Aperture strip — the horizontally-scrolling row of apertures that bleeds off both viewport edges by design.
• Topography ledger — the ruled ledger where each post is a row of tabular IBM Plex Mono numerals (date · reach · saves · comments).
• Metric band — the three oversized Fraunces numerals (posts / followers / average engagement) separated by full-height hairlines.
• Closing band — the full-bleed amber #E8B54A band carrying one oversized Fraunces statement in near-black.
• Data source — the owner-supplied export or pasted metrics that feed the portrait.
• Read-only — the product's binding posture toward Instagram: it never authenticates, fetches, or writes back.
• Museum sequence — the vertical, five-section layout of the Landing page, as distinct from a dashboard grid.