System Requirements Document for pamm-money-manager

1. Introduction

pamm-money-manager is a PAMM (Percentage Allocation Management Module) investment platform styled after a broker platform such as Headway. The platform serves two distinct audiences in one product:

• Investor — retail investors who browse Money Managers, evaluate their performance, allocate capital to a chosen manager, and monitor their resulting portfolio over time.
• Admin — platform operators who curate the Money Manager catalog and process incoming submissions so that the catalog investors browse stays accurate and managed.

The product intent is a single, trustworthy workspace where capital allocation decisions are made against legible, instrumented performance data, and where the catalog behind those decisions is actively maintained. The register is trust-through-precision: numbers are tabular and comparable, performance reads as measured rather than marketed, and the interface behaves like a serious tool used by people committing real capital.

The reference to the Headway broker platform is used only as domain context and feature-scope inspiration. It is not a binding specification, and no Headway branding, copy, or proprietary content is reproduced.

2. System Overview

pamm-money-manager is delivered as a first-party web application with a custom interface and application-owned identity. Two accepted human personas use it: Investor and Admin.

Current delivery. The platform is a custom-UI application backed by a server-side service layer that durably stores Money Manager catalog entries, investor allocations, portfolio positions, and submissions. Identity is application-owned: investors establish their own access through self-service enrollment, admins are provisioned or invited, and both verify themselves on return before reaching protected work.

Accepted behavior. Investors browse the Money Manager catalog, open a manager's details, allocate capital to a selected manager, and monitor their portfolio and allocations. Admins browse and manage the Money Manager catalog — adding, updating, and removing entries — and review and process incoming submissions.

Ownership. All accepted human-facing work is owned by first-party application surfaces. Durable state (allocations, portfolios, catalog entries, submissions) is owned by the platform's backend. No third-party provider surface or external destination owns any accepted capability.

Narrow exclusions. This document does not introduce adjacent capabilities that the source did not accept — for example, no trading of individual securities, no payment-gateway or withdrawal workflow, no messaging between investors and managers, no reporting/analytics suite beyond portfolio monitoring, and no account-management features beyond establishing and verifying access. The Headway reference supplies domain context only and does not import Headway's feature set.

2a. Product Interpretation and Delivery Boundary

The platform is a first-party product: every screen an investor or admin uses is built and owned by this application, and every durable fact — which managers exist, who allocated what, which submissions are pending — lives in the platform's own backend.

Access is application-owned. Because an investor's allocation and portfolio are durable, private, and must remain bound to the correct person across visits, the platform establishes identity itself rather than delegating it. An investor creates their own access through self-service enrollment; an admin's access is established by provisioning or invitation rather than open self-service. Both then verify themselves on return before reaching protected work. The anonymous entry surface and the identity surfaces are deliberately separate from the protected destinations: a protected destination never owns the interaction that grants access to itself.

The current delivery horizon covers the full accepted lifecycle for both personas — discovery, allocation, monitoring, catalog management, and submission processing. Nothing in this document is deferred to a future horizon; there are no accepted future requirements in the source.

2b. Source Content Inventory

Not applicable. No reference directive in this project declares a content_source use, so no verified factual inventory is carried into this document. The Headway reference is declared inspiration_only for domain_context and feature_reference and supplies no product names, copy, facts, or capabilities.

2c. Page Content and Component Coverage

The page inventory below is the closed, ordered page contract for this generation. Each page appears exactly once.

Landing

• Information/state. Anonymous public entry. Explains what the platform is: a PAMM investment platform where investors browse Money Managers, allocate capital, and monitor portfolios, and where admins curate the catalog and process submissions. Presents the value of evaluating managers on measured performance rather than marketing.
• Primary actions. Enter the platform as an investor (proceed to Sign Up); proceed to Login for returning users.
• Supporting actions. Navigate to the Money Managers catalog preview or explanation of how allocation works; read how the admin side keeps the catalog managed.
• Domain entities. Money Manager (name, performance figures), allocation concept, portfolio concept, role concept (Investor, Admin).
• Component responsibilities. Hero statement with a single primary CTA and a ghost secondary; a dark instrument panel presenting a live-looking manager performance table with tabular numerals and a sparkline; a section divider rule; explanatory sections describing browsing, allocating, and monitoring; a section describing catalog and submission management.
• States. Loading: static content, no data dependency for the shell; the performance panel shows a skeleton table while figures resolve. Empty: if no managers are published yet, the panel shows a neutral "catalog being prepared" state instead of a table. Success: full hero, panel, and explanatory sections render. Error: if the panel's figures fail to load, the panel renders its frame with a muted "figures unavailable" note and the rest of the page remains usable. Recovery: the panel retries on next load; the CTA path is never blocked by panel failure.

Login

• Information/state. Anonymous identity-verification surface for both Investor and Admin. Collects returning-user credentials and routes the verified user to their role-appropriate destination.
• Primary actions. Submit credentials to verify identity and continue.
• Supporting actions. Navigate to Sign Up for users without access; return to Landing.
• Domain entities. Account identity, role (Investor or Admin).
• Component responsibilities. Credential form with labeled fields and inline validation; submit control; error region; link to Sign Up.
• States. Loading: submit control shows a pending state and is disabled during verification. Empty: form renders with empty fields and no error. Success: identity verified, user routed to the destination appropriate to their role. Error: invalid credentials show a specific, non-revealing message and preserve entered values; repeated failures do not lock the account in this scope. Recovery: user can correct and resubmit, or navigate to Sign Up.

Sign Up

• Information/state. Anonymous self-service enrollment surface for investors. Establishes a new application-owned identity so the investor can reach protected work.
• Primary actions. Submit enrollment details to create an investor identity.
• Supporting actions. Navigate to Login for users who already have access; return to Landing.
• Domain entities. New investor identity, credentials.
• Component responsibilities. Enrollment form with labeled fields and inline validation; submit control; error region; link to Login.
• States. Loading: submit control shows a pending state and is disabled during creation. Empty: form renders with empty fields and no error. Success: identity created and the investor proceeds to their protected destinations. Error: validation failures are shown per field; a duplicate-identity failure is shown clearly without revealing unrelated account details. Recovery: the investor corrects the offending field and resubmits; entered values are preserved.

Money Managers

• Information/state. Browsable list of available Money Managers, presented as a comparable catalog. Each entry exposes the manager's identity and performance figures in tabular form so entries can be compared at a glance.
• Primary actions. Open a manager's details.
• Supporting actions. Sort or scan the list; return to the investor's other destinations.
• Domain entities. Money Manager (name, performance figures, availability).
• Component responsibilities. Manager list/grid with hairline-bordered cards or rows; tabular numeric columns for performance; per-entry affordance to open details; empty and error regions.
• States. Loading: list region shows placeholder rows/cards. Empty: a clear "no managers available yet" message with guidance to check back. Success: populated list with comparable figures. Error: list region shows a retryable error while the rest of the surface remains navigable. Recovery: retry reloads the list.

Manager Details

• Information/state. Full detail for one Money Manager, sufficient for an allocation decision: identity, performance figures, and the context needed to commit capital.
• Primary actions. Proceed to allocate capital to this manager.
• Supporting actions. Return to the Money Managers list; move to the investor's portfolio.
• Domain entities. Money Manager (identity, performance figures), allocation intent.
• Component responsibilities. Detail header with manager identity; tabular performance figures; sparkline or equivalent 1px-stroke performance trace; primary allocation CTA; back navigation.
• States. Loading: detail region shows a skeleton while figures resolve. Empty: not applicable for a selected manager; if the manager is no longer available, a clear "no longer available" state replaces the detail with a route back to the list. Success: full detail with allocation CTA enabled. Error: detail load failure shows a retryable error. Recovery: retry reloads the detail; if the manager was removed, the investor is returned to the list.

Allocation

• Information/state. Focused investor workspace for allocating capital to the selected Money Manager. Shows the selected manager, the amount being allocated, and the resulting position as it is entered.
• Primary actions. Enter an allocation amount and commit the allocation.
• Supporting actions. Adjust the amount before committing; cancel and return to the manager's details.
• Domain entities. Allocation (manager, amount, resulting position), Money Manager.
• Component responsibilities. Allocation panel/drawer with a numeric amount input; live rendering of the resulting position size and related figures in tabular numerals as the amount changes; commit control; cancel control; validation and error regions.
• States. Loading: the panel opens with the selected manager's context and a pending state while any supporting figures resolve. Empty: no amount entered yet — the resulting-position area shows a neutral placeholder rather than a zero figure. Success: allocation committed, a confirmation is shown, and the investor is offered continuation to their portfolio. Error: invalid amounts (non-numeric, zero, or otherwise unacceptable) are rejected with a specific message and the commit control is disabled; a commit failure preserves the entered amount and offers retry. Recovery: the investor corrects the amount and resubmits, or retries a failed commit without re-entering data.

Portfolio

• Information/state. The investor's recurring monitoring destination. Shows the investor's portfolio and the allocations they have made, with the portfolio total and per-allocation figures presented in tabular form.
• Primary actions. Review the portfolio total and the individual allocations that compose it.
• Supporting actions. Open a manager from an allocation to revisit its details; return to the Money Managers list to make a further allocation.
• Domain entities. Portfolio (total value), Allocation (manager, amount, current figures).
• Component responsibilities. Portfolio total display with tabular numerals; allocation list/table with left-aligned labels and right-aligned numeric columns; per-allocation link back to the manager; empty and error regions.
• States. Loading: total and allocation rows show placeholders while figures resolve. Empty: an investor with no allocations sees a clear "no allocations yet" state with a route to browse Money Managers. Success: portfolio total and allocation rows render with current figures. Error: a figures-load failure shows a retryable error without discarding the known allocation list. Recovery: retry reloads figures.

Catalog

• Information/state. The admin's recurring view of the Money Manager catalog. Lists catalog entries so the admin can see what is published and what needs attention.
• Primary actions. Open an entry for editing; start adding a new entry.
• Supporting actions. Scan and locate entries; move to Submissions.
• Domain entities. Catalog entry / Money Manager (identity, performance figures, publication state).
• Component responsibilities. Admin chrome with a numbered left rail marking the active section; catalog table with hairline row rules and tabular numeric columns; per-entry edit affordance; add-entry affordance; empty and error regions.
• States. Loading: table region shows placeholder rows. Empty: a clear "catalog is empty" state with a direct route to add the first entry. Success: populated catalog table. Error: table load failure shows a retryable error. Recovery: retry reloads the catalog.

Catalog Editor

• Information/state. Focused admin workspace for a single catalog entry. Supports adding a new entry and updating an existing one, and hosts the removal action for an entry.
• Primary actions. Save a new or updated catalog entry; remove an existing entry.
• Supporting actions. Cancel and return to the Catalog without saving; return to the Catalog after a successful save or removal.
• Domain entities. Catalog entry / Money Manager (identity, performance figures, publication state).
• Component responsibilities. Entry form with labeled fields and inline validation; save control; remove control with a confirmation step; cancel control; success and error regions.
• States. Loading: for an existing entry, fields populate from a pending state; for a new entry, the form renders empty. Empty: a new-entry form with no values entered and no error. Success: save or removal is confirmed and the admin is returned to the Catalog with the change reflected. Error: validation failures are shown per field; a save or removal failure preserves the admin's input and offers retry. Recovery: the admin corrects fields and resaves, retries a failed save, or cancels back to the Catalog.

Submissions

• Information/state. The admin's workspace for reviewing and processing incoming submissions. Lists submissions with the information needed to judge each one and its current processing state.
• Primary actions. Review a submission and process it to a decision.
• Supporting actions. Filter or scan the submission list; move to the Catalog.
• Domain entities. Submission (submitting party, submitted content, processing state).
• Component responsibilities. Admin chrome with the numbered left rail marking the active section; submission list with per-item state; detail/review region; processing controls; empty and error regions.
• States. Loading: list and detail regions show placeholders. Empty: a clear "no submissions" state. Success: a processed submission shows its updated state and leaves the pending list. Error: a processing failure leaves the submission in its prior state with a retryable error. Recovery: retry processing, or leave the submission pending and return later.

3. Functional Requirements

Each requirement is a distinct story point with provenance, lifecycle facts, and observable acceptance. Provenance is explicit for source-stated behavior, basic_default for accepted defaults, and required_inference for indispensable inferred mechanics.

FR-1 — Browse Money Managers As an Investor, I should browse the available Money Managers so that I can find managers worth allocating capital to.

• Provenance: explicit.
• Trigger/input: the investor opens the Money Managers list.
• Observable result: a comparable list of available Money Managers with their performance figures, each openable for detail.
• Access state: protected; requires a verified investor identity.
• Failure/recovery: if the list fails to load, a retryable error is shown and the rest of the surface stays navigable.
• Continuation: the investor opens a manager's details.

FR-2 — Review Money Manager Details As an Investor, I should open a Money Manager's details so that I can judge whether to allocate capital to that manager.

• Provenance: explicit.
• Trigger/input: the investor selects a manager from the list.
• Observable result: the manager's identity and performance figures are shown, with a route to allocate capital.
• Access state: protected; requires a verified investor identity.
• Failure/recovery: a detail load failure is retryable; if the manager is no longer available, the investor is told and returned to the list.
• Continuation: the investor proceeds to allocate capital, or returns to the list.

FR-3 — Allocate Capital to a Money Manager As an Investor, I should allocate capital to a selected Money Manager so that I can commit funds to that manager's strategy.

• Provenance: explicit.
• Trigger/input: the investor enters an allocation amount for the selected manager and commits it.
• Observable result: the allocation is durably recorded against the investor and the selected manager, and the resulting position is shown.
• Access state: protected; requires a verified investor identity, and the allocation is bound to that investor.
• Failure/recovery: invalid amounts are rejected with a specific message and the commit control is disabled; a commit failure preserves the entered amount and offers retry.
• Continuation: the investor is offered continuation to their portfolio.

FR-4 — Monitor Portfolio As an Investor, I should monitor my portfolio so that I can see my allocations and how they are developing.

• Provenance: explicit.
• Trigger/input: the investor opens their portfolio.
• Observable result: the portfolio total and the investor's individual allocations are shown with current figures.
• Access state: protected; requires a verified investor identity, and only that investor's own allocations are shown.
• Failure/recovery: a figures-load failure is retryable without discarding the known allocation list.
• Continuation: the investor opens a manager from an allocation, or returns to the Money Managers list to allocate further.

FR-5 — Manage the Money Manager Catalog As an Admin, I should manage the Money Manager catalog so that the list investors browse stays accurate and current.

• Provenance: explicit.
• Trigger/input: the admin opens the catalog and chooses to add a new entry or open an existing one.
• Observable result: catalog entries can be added and updated, and the catalog reflects the change.
• Access state: protected; requires a verified admin identity.
• Failure/recovery: validation failures are shown per field; a save failure preserves the admin's input and offers retry.
• Continuation: the admin returns to the catalog with the change reflected, or continues editing.

FR-6 — Remove a Catalog Entry As an Admin, I should remove a catalog entry so that managers no longer offered stop appearing to investors.

• Provenance: explicit (the catalog editor is the admin workspace that "menjalankan penghapusan" — carries out removal).
• Trigger/input: the admin invokes removal for an existing entry and confirms it.
• Observable result: the entry is removed from the catalog and no longer appears in the investor-facing list.
• Access state: protected; requires a verified admin identity.
• Failure/recovery: a removal failure leaves the entry intact and offers retry.
• Continuation: the admin returns to the catalog with the entry gone.

FR-7 — Review and Process Submissions As an Admin, I should review and process incoming submissions so that requests reaching the platform are handled.

• Provenance: explicit.
• Trigger/input: the admin opens the submissions workspace and reviews a submission.
• Observable result: the submission is processed to a decision and its state reflects that decision.
• Access state: protected; requires a verified admin identity.
• Failure/recovery: a processing failure leaves the submission in its prior state with a retryable error.
• Continuation: the admin continues with the next submission, or leaves it pending and returns later.

FR-8 — Investor Self-Service Enrollment As an Investor, I should be able to establish my own access so that I can begin using the platform without waiting on provisioning.

• Provenance: required_inference.
• Trigger/input: an anonymous visitor submits enrollment details on the Sign Up surface.
• Observable result: an application-owned investor identity is created and the investor can reach protected investor work.
• Access state: anonymous entry; the resulting identity is protected.
• Failure/recovery: per-field validation errors are shown; a duplicate-identity failure is reported clearly without revealing unrelated account details; entered values are preserved.
• Continuation: the investor proceeds to browse Money Managers.

FR-9 — Admin Invitation or Provisioning As an Admin, I should have my access established by invitation or provisioning rather than open self-service, so that admin capability is not self-granted.

• Provenance: required_inference.
• Trigger/input: an admin access is provisioned or invited through a platform-controlled path.
• Observable result: the admin holds a verified admin identity able to reach admin destinations.
• Access state: admin access is established outside open self-service; the resulting identity is protected.
• Failure/recovery: an unusable or expired invitation is reported to the admin, who requests a new one.
• Continuation: the admin verifies on return and reaches the catalog.

FR-10 — Returning Verification for Investor and Admin As an Investor or Admin, I should verify myself on return so that my durable allocations, portfolio, and admin work remain bound to me.

• Provenance: required_inference.
• Trigger/input: a returning user submits credentials on the Login surface.
• Observable result: identity is verified and the user is routed to the destination appropriate to their role.
• Access state: anonymous entry; the destinations reached are protected.
• Failure/recovery: invalid credentials produce a specific, non-revealing message and preserve entered values; the user can correct and resubmit or navigate to Sign Up.
• Continuation: the investor reaches Money Managers or Portfolio; the admin reaches Catalog or Submissions.

FR-11 — Durable Backend Execution As the platform, I should durably store allocations, portfolios, catalog entries, and submissions so that accepted work survives across sessions and remains correct.

• Provenance: required_inference.
• Trigger/input: any accepted write — an allocation commit, a catalog save or removal, or a submission decision.
• Observable result: the change is persisted and is reflected on the next read of the affected surface.
• Access state: not human-facing; executed by the backend on behalf of a verified actor.
• Failure/recovery: a failed write is reported to the initiating surface as a retryable error and does not leave partial state.
• Continuation: the initiating actor retries or continues from the surface's success state.

4. User Personas

Investor

Product context. The Investor is a retail investor in Indonesia evaluating where to place capital. They arrive without prior knowledge of which managers exist on the platform and need to compare managers on measured performance rather than on marketing claims. Their work is decision-oriented: they are choosing between alternatives and then living with the consequences of that choice.

Primary goal. Find a Money Manager worth allocating capital to, commit capital to that manager, and then keep watching how the resulting position develops.

Distinct accepted responsibilities.

• Browsing the Money Manager catalog to discover what is available (FR-1).
• Opening a manager's details to judge it before committing (FR-2).
• Allocating capital to a selected manager (FR-3).
• Monitoring the resulting portfolio and its individual allocations over time (FR-4).
• Establishing their own access through self-service enrollment (FR-8) and verifying themselves on return (FR-10).

Relevant inputs and decisions. The Investor's key inputs are the amount of capital to allocate and the choice of manager. Their central decision is which manager to commit to, made against the comparable performance figures shown in the catalog and on the manager's detail surface. Their monitoring decision is whether to allocate further or leave existing allocations in place.

Interactions with other accepted participants. The Investor does not interact directly with the Admin. The relationship is indirect and material: the Admin's catalog management determines which managers the Investor can see and allocate to, and the Admin's removal of an entry determines when a manager stops being available. The Investor's own allocations are private to them and are not visible to other investors.

Observable success. The Investor can find a manager that suits them, complete an allocation that is durably recorded against their identity, and open their portfolio to see that allocation and its current figures. Success is a complete loop: discover, decide, commit, monitor.

What makes this role different. The Investor's work is evaluative and cumulative — every action either informs a capital decision or reflects the outcome of one. Their state is private and personal, and it must persist and remain bound to them across sessions. This is unlike the Admin, whose work is operational and shared: the Admin changes what everyone else sees.

Admin

Product context. The Admin operates the platform's supply side. They are responsible for the catalog of Money Managers that investors browse, and for handling the submissions that arrive at the platform. Their work is custodial: they keep the catalog accurate so that investor-facing decisions are made against correct information.

Primary goal. Keep the Money Manager catalog managed and correct, and process incoming submissions so that nothing reaching the platform goes unhandled.

Distinct accepted responsibilities.

• Browsing the catalog to see what is published and what needs attention (FR-5).
• Adding new catalog entries and updating existing ones (FR-5).
• Removing catalog entries that should no longer be offered (FR-6).
• Reviewing and processing incoming submissions to a decision (FR-7).
• Having access established by invitation or provisioning rather than self-service (FR-9), and verifying on return (FR-10).

Relevant inputs and decisions. The Admin's inputs are the catalog entry fields they author or amend and the submission content they review. Their decisions are whether an entry should be added, changed, or removed, and how each submission should be processed.

Interactions with other accepted participants. The Admin does not interact directly with the Investor, but the Admin's work directly shapes the Investor's experience: what the Admin publishes is what the Investor can browse and allocate to, and what the Admin removes disappears from the Investor's options. This makes the Admin's accuracy consequential rather than clerical.

Observable success. The Admin can add, update, and remove catalog entries and see the catalog reflect each change, and can process a submission to a decision and see its state update. Success is a catalog that matches reality and a submission queue that does not silently accumulate.

What makes this role different. The Admin's work is authoritative and shared — it changes the state that other people act on. Their access is deliberately not self-service, because the capability they hold affects the whole platform. This is unlike the Investor, whose work is private, evaluative, and self-established.

5. Core User Flows

Flow A — Investor discovers and allocates capital

1. Starting context. The visitor is anonymous and has no platform identity.
2. On Landing, the visitor reads what the platform is and what allocating capital to a Money Manager involves, then chooses to begin as an investor.
3. On Sign Up, the visitor submits enrollment details. The platform creates an application-owned investor identity. If a field is invalid, the error is shown against that field and the entered values are preserved; the visitor corrects it and resubmits. If the identity already exists, the visitor is told clearly and routed to Login instead.
4. On Money Managers, the now-verified Investor sees the available managers with comparable performance figures. If the catalog is empty, the Investor sees a clear "no managers available yet" state and can return later.
5. The Investor opens a manager and lands on Manager Details, where the manager's identity and performance figures are shown. If the manager is no longer available, the Investor is told and returned to the list.
6. The Investor chooses to allocate and proceeds to Allocation. The selected manager's context is carried into the workspace.
7. On Allocation, the Investor enters an amount. The resulting position is rendered live in tabular figures as the amount changes. If the amount is invalid, the commit control is disabled and a specific message explains why.
8. The Investor commits the allocation. The allocation is durably recorded against the Investor and the selected manager. If the commit fails, the entered amount is preserved and the Investor can retry without re-entering it.
9. Observable result. The Investor sees confirmation of the allocation and is offered continuation to their portfolio.
10. Next step. The Investor continues to Portfolio.

Flow B — Investor monitors their portfolio

1. Starting context. The Investor has at least one recorded allocation and returns to the platform.
2. On Login, the Investor submits credentials. If they are invalid, a specific, non-revealing message is shown, entered values are preserved, and the Investor can correct and resubmit.
3. On verification, the Investor is routed to their investor destinations and opens Portfolio.
4. On Portfolio, the Investor sees the portfolio total and the individual allocations that compose it, with figures in tabular form. If figures fail to load, a retryable error is shown and the known allocation list is not discarded.
5. If the Investor has no allocations, Portfolio shows a clear "no allocations yet" state with a route to browse Money Managers.
6. The Investor reviews the total and the per-allocation figures. They may open a manager from an allocation to revisit Manager Details.
7. Observable result. The Investor has an up-to-date view of their portfolio and its constituent allocations.
8. Next step. The Investor either leaves the platform, or returns to Money Managers to make a further allocation, re-entering Flow A at step 4.

Flow C — Admin manages the catalog

1. Starting context. The Admin's access has been established by invitation or provisioning, and the Admin returns to the platform.
2. On Login, the Admin submits credentials. If the invitation or access is unusable or expired, the Admin is told and requests a new one. If credentials are invalid, a specific, non-revealing message is shown and the Admin can correct and resubmit.
3. On verification, the Admin is routed to their admin destinations and opens Catalog.
4. On Catalog, the Admin sees the catalog entries with the numbered left rail marking the active section. If the catalog is empty, a clear state offers a direct route to add the first entry.
5. Adding or updating. The Admin opens Catalog Editor — either for a new entry or an existing one. They complete or amend the entry fields and save. If a field is invalid, the error is shown against that field. If the save fails, the Admin's input is preserved and they can retry.
6. Observable result. The save is confirmed and the Admin returns to Catalog with the change reflected.
7. Removing. From Catalog Editor for an existing entry, the Admin invokes removal and confirms it. If the removal fails, the entry remains intact and the Admin can retry.
8. Observable result. The entry is removed from the catalog and no longer appears in the investor-facing Money Managers list.
9. Next step. The Admin continues managing the catalog or moves to Submissions.

Flow D — Admin processes submissions

1. Starting context. The Admin is verified and has reached their admin destinations.
2. The Admin opens Submissions from the numbered left rail.
3. On Submissions, the Admin sees the incoming submissions with their current processing state. If there are none, a clear "no submissions" state is shown.
4. The Admin reviews a submission's content in the detail region.
5. The Admin processes the submission to a decision. If processing fails, the submission remains in its prior state and a retryable error is shown.
6. Observable result. The submission's state reflects the decision and it leaves the pending list.
7. Next step. The Admin continues with the next submission, or leaves a submission pending and returns to it later.

Flow E — Admin access is established

1. Starting context. A person is to become an Admin but has no admin identity.
2. Admin access is established through a platform-controlled invitation or provisioning path — not through open self-service enrollment.
3. Observable result. The Admin holds a verified admin identity able to reach admin destinations.
4. Next step. The Admin verifies on return via Login (Flow C, step 2) and proceeds to Catalog.

6. Visuals, Colors and Theme

The creative direction is authoritative for this section. It names Rasmus Andersson as the muse and the headline register as systematic product craft with a hot accent — a trading terminal that feels authored, not bootstrapped. The translation into concrete tokens follows.

Color tokens — light mode (primary mode).

Color rules. Warm paper ground carries roughly 60% of every screen; white surfaces hold cards, tables, and forms with 1px #E5E0D8 hairlines. Ink #141517 is the primary for type, buttons, and the dark hero panel — near-black, never blue. Tangerine #E4572E is the single hot accent and is used sparingly and meaningfully. Muted #8A857D is for labels, metadata, and secondary numerals. Deep graphite #141517 is used for the hero panel and admin chrome so dark inserts read as instrument panels. No blue, no indigo, no gradients. The generic indigo/blue-on-white SaaS template is forbidden for this project.

Typography.

• Headings: Space Grotesk at 600–700, tracking −0.02em to −0.04em. Sentence case for editorial headings; uppercase for micro-labels with +0.12em tracking. Display sizes are large and confident but never decorative; numerals in headings use tabular figures.
• Body: Inter Tight.
• Scale: 1.25 modular on a 4/8pt rhythm — 128 / 72 / 48 / 32 / 24 / 18 / 16 / 14 / 13.
• Display: clamp(44px, 9vw, 128px) for the hero statement.
• Section headings: clamp(28px, 4vw, 48px).
• Body: 16px / 1.6.
• Micro-labels: 13px uppercase, +0.12em tracking.
• Numerals: all tabular, via font-variant-numeric: tabular-nums.

Shape language. Compact, precise, rectilinear. 8px radii on cards and inputs; 6px on buttons and chips; 4px on tags and table cells. Hairline 1px borders instead of shadows for structure. A single soft elevation — 0 1px 2px rgba(20,21,23,0.06) — only on floating menus. No pills except status tags. No blobs, no organic curves; every corner is a decision.

Layout. Strict 12-column grid on a 4/8pt spacing scale, max content width 1240px, gutters at 24/32/48px. Manager cards are 3-up at 1280px, 2-up at 768px, 1-up at 375px. Tables are the signature surface: left-aligned label column, right-aligned tabular numeric columns, hairline row rules, no zebra striping. Admin surfaces use a fixed 240px left rail with a numbered section list; investor surfaces use a top bar with the live portfolio value pinned right. Every numeric figure sits in a fixed-width column so digits never shift.

Imagery. The interface is the imagery: real rendered tables, sparkline charts drawn as 1px strokes, an allocation donut rendered in CSS, and schematic diagrams of how PAMM allocation flows. Where a photograph is needed (manager avatar, hero side panel), it is a tight studio-lit portrait or a macro of a printed performance report on warm paper — never stock trading floors, never handshakes, never blue-tinted cityscapes.

Accessibility of text and controls. Headlines, wordmarks, labels, numbers, card text, 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, and no other element covers any part of them. Imagery, decoration, and motion may be cropped, bled off an edge, rotated, overlapped, or cut as the direction asks, provided they cover no readable text or control.

7. Signature Design Concept

The instrument panel hero. The public entry is a split hero on warm paper. The left 7 columns hold a stacked oversized headline — "Allocate capital to proven money managers." — set in Space Grotesk at clamp(44px, 9vw, 128px) with −0.04em tracking, ink #141517 on #F6F3EE, with a single line of body copy beneath and one tangerine CTA button plus a ghost secondary. The right 5 columns hold a dark graphite panel (#141517) that bleeds off the right edge of the viewport, containing a live-looking mock of a manager performance table: tabular numerals in white and tangerine, hairline row rules, a small sparkline, and the label LIVE ALLOCATION in 13px uppercase with +0.12em tracking. A thin 2px tangerine rule runs the full width beneath the hero as a section divider.

The concept's argument is that the product's core artefact — the performance table an investor actually decides against — is the hero image. Nothing is illustrated that the product does not do. The panel is a composition of accepted content: manager identity, performance figures, and the allocation concept. It introduces no new behavior, page, or destination. The headline, body copy, and both CTAs remain fully inside the viewport at every breakpoint; the graphite panel is the element permitted to bleed off the edge, and it carries no readable text or control across the boundary.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief.

• Focal subject. The dark graphite instrument panel bleeding off the right edge, holding the live-looking manager performance table with tabular numerals in white and tangerine, hairline row rules, and a small sparkline.
• Input → transformation → outcome thesis. On load, the panel's figures resolve from a skeleton table into their final values, and the portfolio-style total performs a single count-up tween in tangerine. The transformation communicates that these are measured, live figures rather than a static marketing image; the outcome is a hero that reads as an instrument panel already running.
• Motion vocabulary. Functional 120–200ms transitions on cubic-bezier(0.2, 0.8, 0.2, 1): hover states on rows and cards, focus rings that snap in, a single count-up tween on the total (600ms, ease-out), and a 200ms slide-in for the allocation drawer. No parallax, no decorative loops, no bounces.
• Composed first frame. Warm paper ground with the oversized ink headline fully set on the left; the graphite panel already in place at the right edge with its table frame and hairline rules drawn, its figures in their skeleton state, and the LIVE ALLOCATION micro-label visible.
• Reduced-motion state. With prefers-reduced-motion, everything collapses to instant state changes: the panel renders its final figures immediately with no count-up and no skeleton-to-value transition, and all hover, focus, and drawer transitions become instantaneous. The composed layout is unchanged and fully usable.

9. Non-Functional Requirements

NFR-1 — Durable state. Allocations, portfolios, catalog entries, and submissions must persist durably and survive across sessions. Provenance: required_inference (durable state is required for the accepted lifecycles to be usable). Rationale: an allocation is a commitment of capital and a portfolio is a cumulative record; neither is meaningful if it does not persist.

NFR-2 — Identity-bound private state. An investor's allocations and portfolio must remain bound to that investor and must not be visible to other investors. Provenance: required_inference. Rationale: the accepted behavior creates a durable, private, value-bearing relationship that must stay attached to the correct participant.

NFR-3 — Admin access is not self-granted. Admin capability must be established through invitation or provisioning rather than open self-service enrollment. Provenance: required_inference. Rationale: admin work changes shared platform state that investors act on.

NFR-4 — Numeric legibility. All return, allocation, and portfolio figures must be rendered with tabular numerals in fixed-width columns so digits do not shift and values remain comparable across rows. Provenance: explicit (creative direction). Rationale: the product's core content is comparable performance figures; legibility is a functional requirement, not decoration.

NFR-5 — Responsive integrity of text and controls. Headlines, wordmarks, labels, numbers, card text, and controls must remain entirely inside the viewport and their container at 375px, 768px, and 1280px, and no other element may cover any part of them. Provenance: explicit (creative direction). Rationale: the platform is used on phones and desktops, and a misread figure is a real capital risk.

NFR-6 — Reduced-motion support. With prefers-reduced-motion, all motion must collapse to instant state changes while the layout remains fully usable. Provenance: explicit (creative direction).

NFR-7 — No blue or indigo in the primary/accent role. The palette must not use blue or indigo in primary or accent roles, and the generic indigo/blue-on-white SaaS template is forbidden. Provenance: explicit (creative direction).

NFR-8 — Retryable failure surfaces. Every data-loading and data-writing surface must present a retryable error state that does not discard the user's entered data or known list content. Provenance: required_inference. Rationale: the accepted lifecycles require material failure and recovery to be usable.

10. Tech Stack

• Frontend: React (web), custom UI. Provenance: required_inference — the planning scope establishes custom_ui: true and a first-party web application; React is the default choice for that delivery shape.
• Backend: Python / FastAPI, providing the API and domain logic for Money Manager catalog entries, allocations, portfolios, and submissions. Provenance: required_inference — the planning scope establishes requires_backend_integration: true and durable backend execution for these entities.
• Storage: a relational database appropriate to durable, identity-bound records (catalog entries, allocations, portfolios, submissions). Provenance: required_inference — required by NFR-1 and NFR-2.
• Packaging and local orchestration: Docker and docker-compose for the frontend and backend services. Provenance: [Default — not specified by user].
• Deployment: Kubernetes is not required by any accepted requirement and is not included. Provenance: [Default — not specified by user].

No source-specified technology is overridden; the source names no technology, so the above are the minimal defaults consistent with the accepted delivery shape.

11. Assumptions and Constraints

Assumptions.

• A-1. The Headway reference is used only as domain context and feature-scope inspiration. No Headway branding, copy, proprietary data, or feature set is reproduced. Basis: the reference directive declares authority: inspiration_only with uses: [domain_context, feature_reference].
• A-2. Identity is application-owned, and the platform establishes it itself. Basis: the planning scope establishes app_owned_identity: true, and the accepted lifecycles require durable, private, identity-bound state.
• A-3. Admin access is established by invitation or provisioning rather than open self-service. Basis: required_inference from the accepted admin lifecycle and the differentiated nature of admin capability.
• A-4. The page inventory in section 2c is the closed, ordered page contract for this generation. Basis: page_contract_version=1.
• A-5. The two accepted personas are Investor and Admin, and no others. Basis: the closed persona catalog in the planning scope.
• A-6. All accepted requirements are current; there are no accepted future requirements. Basis: every requirement in the planning scope carries delivery_horizon: current.

Constraints.

• C-1. No blue or indigo in primary or accent roles; no gradients; the generic indigo/blue-on-white SaaS template is forbidden.
• C-2. Headings use Space Grotesk; body uses Inter Tight. Inter, Roboto, Arial, Helvetica, Open Sans, Lato, and Poppins are excluded as heading or body fonts.
• C-3. No gradient-blob heroes, glassmorphism panels, or floating 3D shapes.
• C-4. No grid of identical hover-lift cards with drop shadows; manager cards use hairline borders with no hover-lift.
• C-5. No stock photography of trading floors, handshakes, or blue-tinted skylines.
• C-6. Pills are reserved for status tags only; not every control is a rounded pill button.
• C-7. No centred hero headline with subtext and a single blue button.
• C-8. No zebra-striped tables, and no emoji used as data icons.
• C-9. Readable text and controls stay whole at every viewport; imagery and decoration may bleed, but never over readable text or control.
• C-10. No adjacent capabilities are introduced beyond the accepted scope: no individual securities trading, no payment-gateway or withdrawal workflow, no investor–manager messaging, no analytics suite beyond portfolio monitoring, and no account-management features beyond establishing and verifying access.

12. Glossary

• PAMM (Percentage Allocation Management Module). An investment structure in which an investor's capital is allocated to a money manager's strategy and the investor's share of the resulting performance is tracked proportionally.
• Money Manager. A manager whose strategy investors can allocate capital to. Money Managers are the entries in the platform's catalog and the subjects of the investor's browsing and allocation decisions.
• Catalog. The admin-managed collection of Money Manager entries that investors browse. Managed on the Catalog and Catalog Editor surfaces.
• Catalog Entry. A single Money Manager record within the catalog, with its identity, performance figures, and publication state.
• Allocation. A durable commitment of a specific amount of an investor's capital to a specific Money Manager. Created on the Allocation surface and bound to the investor who made it.
• Portfolio. The cumulative record of an investor's allocations and their current figures, shown on the Portfolio surface.
• Submission. An incoming request reaching the platform that an Admin reviews and processes to a decision on the Submissions surface.
• Investor. The accepted persona who browses Money Managers, allocates capital, and monitors a portfolio.
• Admin. The accepted persona who manages the Money Manager catalog and processes submissions.
• Tabular numerals. Numerals rendered with font-variant-numeric: tabular-nums so every digit occupies the same width, keeping figures aligned and comparable across rows and columns.
• Hairline border. A 1px border used instead of a shadow to give structure to cards, tables, and forms.
• Instrument panel. The dark graphite (#141517) surface used for the hero's performance table and for admin chrome, so dark inserts read as measurement instruments rather than decoration.