FaceValue — Requirements

Goals

• Let a ticket buyer check, in under a minute, whether a listing already shows the real total price or is going to add fees at checkout.
• Score resale markup and service fees against the caps now showing up in law and settlements, so a buyer can tell "expensive" apart from "against the rules."
• Turn a canceled show, a postponed show, or a flagged listing into a refund or complaint letter the buyer can actually send.

Primary user

A concertgoer or sports fan who buys tickets several times a year, from a mix of primary sellers and resale marketplaces. They've been surprised by a checkout total before and don't have time to track which state or settlement rule applies to which purchase — they want the app to know that part.

Functional requirements

• FR1: The price checker must let a user enter marketplace type (primary or resale), seller, state, face value, listed price, and total charged at checkout.
• FR2: The price checker must recompute all flags immediately when any input changes, with no submit button required.
• FR3: The checker must flag a listing as a disclosure risk when the total charged exceeds the listed price by more than a 1% rounding tolerance.
• FR4: For resale listings, the checker must compute markup percentage over face value.
• FR5: The checker must compare resale markup against the Massachusetts 110%-of-face-value cap only when the selected state is Massachusetts, and must label that cap as proposed, not yet enacted.
• FR6: The checker must compute service fee as a percentage of the total charged.
• FR7: When the seller is Ticketmaster or another Live Nation-owned brand, the checker must compare the service fee percentage against the 15% cap from the March 2026 DOJ settlement.
• FR8: The checker must produce an overall transparency read (clear / caution / flagged) summarizing the individual flags.
• FR9: The ticket tracker must list all sample purchases with event, venue, date, seller, price paid, and event status (upcoming, postponed, canceled, completed).
• FR10: Selecting a tracked purchase must open a detail view showing its full fee breakdown and any flags computed the same way as the price checker.
• FR11: A tracked purchase with any flag, or with a postponed/canceled status, must expose a "draft a letter" action.
• FR12: The drafted letter must cite the specific basis for the ask — the FTC's Rule on Unfair or Deceptive Fees for disclosure flags, the seller's own advertised refund terms for cancellations, and the relevant cap (state-proposed or settlement) for markup and fee flags — and must not overstate a proposed law as if it were already enacted.
• FR13: The letter view must include a copy-to-clipboard control.
• FR14: All seller, purchase, and cap-reference data must load from sample-data.json at page load via fetch.

User stories

• As a buyer looking at a resale listing, I want to know if the price I see is the price I'll pay, so that I don't get surprised at checkout.
• As a buyer comparing two resale listings for the same show, I want to see which one is closer to face value, so that I'm not overpaying without realizing it.
• As a fan who bought from Ticketmaster, I want to know if the service fee is within the cap from the DOJ settlement, so that I know whether the charge is in line with what Live Nation agreed to.
• As a Massachusetts resident, I want to see how a resale price compares to the state's proposed cap, so that I understand what's at stake if the bill passes.
• As someone whose show got postponed, I want a refund letter drafted for me, so that I don't have to figure out what to say from scratch.
• As a buyer with several tracked tickets, I want the ones with problems to stand out, so that I check those first.

Non-functional requirements

• The app must run entirely client-side from index.html, no build step, no server dependency beyond serving static files.
• All computation happens in the browser; no purchase data leaves the page.
• The layout must stay usable on a mobile-width viewport (single-column below 720px).
• Flags must be paired with text labels, not conveyed by color alone.
• Tracked-purchase data resets on page reload; there is no persistence layer in this prototype.

Out of scope (for the prototype)

• Live pricing data or marketplace API integration — the dataset is a hand-built snapshot.
• User accounts, authentication, or saved history across sessions.
• Filing a complaint automatically with the FTC or a state attorney general — the letter is generated for the user to send themselves.
• Tracking legislation changes automatically; cap references are current as of the date in metadata.md and would need manual upkeep.
• Browser extension packaging or checkout-page auto-detection.

Open questions

• Would buyers check this before purchase, when the friction of switching listings is highest, or mostly after the fact when something already feels wrong?
• The Massachusetts cap is a filed bill, not law — how should the product handle the moment it either passes or stalls, and how many other states will file something similar?
• Is a flat monthly subscription the right model for something people use in bursts around tour announcements, or does a per-claim price fit the actual usage pattern better?