> **September 19 positioning update:** ThesisTape now leads with a personal trading memory: identity, markets, specialty, self-reported strengths and blind spots, goals, and rules. The landing page uses an interactive, illustrative category map (not a scored assessment), deep ink / muted gold / porcelain colors, and memory-first copy. The live profile now persists these additional fields with validation and backward-compatible defaults. Automated AI memory, historical data connections, and counterfactual backtesting remain planned. Earlier visual specifications below are historical where they conflict with this update.

# ThesisTape — Product blueprint

Version 0.1 · September 18, 2026 · Living document

## Purpose and positioning

ThesisTape helps traders replay their actual executions, explain what they were thinking, and turn those reviews into an evidence-linked personal journal. The central promise is: **Replay your trades. Talk through your decisions. Understand your patterns.**

The primary user is a self-directed stock or options trader who already has execution history but finds manual journaling tedious. The first experience is a narrow trade inbox on the left, a large replay surface in the middle, and a light conversation panel on the right. Select a position, revisit entry and exit decisions, save reflections at a timestamp, and return to the next trade.

The founding price hypothesis is $19.99/month. It is not a committed commercial offer yet. Validate willingness to pay, retention, and cost per active reviewer before setting allowances. The product does not need profitable-trader claims, signals, or brokerage execution to be useful.

## Status of this first build

### Implemented

- Responsive landing page with a functioning route into the product.
- Brand mark, wordmark, favicon, palette, voice guidelines, and downloadable SVG assets.
- Review, Journal, Insights, and My approach workspace views.
- Illustrative demo positions with synthetic underlying-market bars, visibly labeled.
- Play/pause, speed, next bar, jump to entry, and a replay scrubber.
- Future candles hidden beyond the cursor; realized exit values hidden until exit in replay.
- Stock/option identifiers with company logos and underlying-versus-contract labeling.
- Canonical CSV import of closed positions, including long/short direction, fees, quantity, and contract multiplier.
- Field validation and deterministic duplicate detection scoped to the authenticated user.
- Optional underlying OHLCV CSV attachment for each imported position.
- RSI (Wilder 14), bar volume, supplied-period VWAP, and VWAP distance computed through the cursor.
- Persistent timestamped retrospective reflections, with planned/unplanned/uncertain tags.
- Browser dictation where supported; no audio storage.
- Confirmed goal, setups, risk rule, and reflective/direct review preference.
- Descriptive closed-position results, exposure summaries, costs, profit concentration, latest planned/unplanned comparisons, and same-instrument sizing after losses, all with evidence links and limitations.
- JSON export and confirmed deletion of the active saved workspace.
- Server-side identity checks and owner-scoped persistence for each data operation.
- Private preview notice, explicit capability limits, and product roadmap.

### Explicitly not implemented or connected yet

- External LLM conversation, model-generated insights, or automated long-term memory extraction.
- Licensed historical market-data retrieval, options quotes, Greeks, or true live prices.
- Broker-native fill parsing, automatic sync, multi-leg options, assignment, exercise, or partial-position accounting.
- Statistically validated behavioral-pattern detection or personalized outcome predictions.
- Live brokerage execution, automated order placement, or account guardrails.
- Public commercial account onboarding, paid subscriptions, invoicing, or usage metering.
- Production legal policies, commercial trademark clearance, or domain purchase.

The current conversation panel is honestly labeled **Guided reflection**. Prompts are deterministic and adapt to the confirmed review goal and chosen tone; they are not represented as LLM responses.

## Core journeys

1. **First visit:** understand the product on the landing page, open the demo, and replay one trade without submitting personal data.
2. **First import:** sign in, download the canonical template, upload closed positions, see validation errors before saving, and receive a count of inserted versus duplicate rows.
3. **Review:** select a trade, inspect the underlying market at a cursor, record intent, and save a timestamped reflection. A reflection written after the event stays labeled retrospective.
4. **Journal:** revisit notes and jump back into the associated replay.
5. **My approach:** confirm a goal, setups, risk rule, and coaching style. Edits are deliberate; inferred opinions do not overwrite explicit preferences.
6. **Insights:** examine descriptive results and the trades supporting each observation. Small samples carry visible limitations.
7. **Control:** export a complete active workspace or delete it after explicit confirmation.

## Import and market-data contract

Current trade CSV headers:

`symbol,instrument,asset,side,entry_time,exit_time,quantity,entry_price,exit_price,fees,multiplier`

- One row is one fully closed position. This is not an arbitrary broker statement importer.
- `asset`: stock or option. `side`: long or short.
- Times are ISO 8601 with Z or an explicit offset; UI times are New York.
- Fees represent the full position's round-trip fees.
- Stock multiplier is 1; options use the supplied contract multiplier, ordinarily 100 but not assumed for adjusted contracts.
- Net P&L = (exit − entry) × direction × quantity × multiplier − fees.
- Identical normalized rows are deduplicated per owner. Two legitimately identical executions need distinct source IDs in the future broker adapter; the current closed-position format cannot disambiguate them.
- Initial request bounds: 500 closed positions and 1.5 MB per import.

OHLCV headers: `time,open,high,low,close,volume`. Times must ascend strictly. Bars must cover entry through exit. Validate nonnegative finite prices/volume and OHLC ordering. The attachment is underlying data, never an inferred option-price series. Initial limit is 1,500 bars per attachment.

Indicator calculations must declare their input range. Current VWAP accumulates only supplied bars; it is session VWAP only when the upload begins at that session's open. RSI needs sufficient warm-up history and is not guaranteed to equal a broker's continuously seeded indicator. Relative volume requires a same-time historical baseline and is intentionally not fabricated from a single session.

For production, preserve adjusted/unadjusted flags, exchange calendar, session boundaries, market timezone, bar completeness, provider symbol IDs, licensing entitlement, quote age, and gaps. Corporate actions and adjusted option contracts need explicit treatment.

## Individual learning architecture

Personalization should combine four separate stores rather than an opaque single summary:

| Layer                    | Source                     | Example                                                   | Update rule                                        |
| ------------------------ | -------------------------- | --------------------------------------------------------- | -------------------------------------------------- |
| Confirmed profile        | Explicit trader input      | “I focus on failed breakouts.”                            | Editable, versioned, user-approved                 |
| Episodic record          | Trade-linked reflections   | “I exited because volume dried up.”                       | Preserve original text and timestamp               |
| Observed behavior        | Deterministic calculations | “Position size increased after losses in these sessions.” | Recompute from evidence, retain definition/version |
| Interpretation candidate | Model or pattern engine    | “Could the prior loss have influenced sizing?”            | Tentative until reviewed; never a diagnosis        |

A proposed memory record should include: id, owner_id, kind, statement, source_note_ids, source_trade_ids, event_time, recorded_time, status (suggested/confirmed/rejected/superseded), confidence, calculation_version, valid_from, valid_to, and deletion lineage.

Use event time and recorded time separately. A later explanation must never be backdated into a pre-entry plan. Contradictions should surface as a clarification question; explicit user correction has priority over a model inference. Deleting an underlying note or trade must invalidate dependent summaries and embeddings.

The current build implements an editable confirmed profile and persistent episodes. Versioned memory candidates, correction history, and automated extraction are the next milestone.

## Conversation design

- The assistant knows which position and replay cursor are selected.
- Default to one short observation or question, not a lecture after every candle.
- Respect reflective versus direct preference and allow silence during playback.
- Separate “what the market showed,” “what you told me,” and “a possible interpretation.”
- Let users type or dictate, correct transcripts, and approve the journal summary.
- All factual numerical claims must reference a supplied computed field or a deterministic tool result.
- Do not infer emotion, motives, or intent from P&L alone. Ask instead.
- At a historical cursor, prevent future candles, future indicators, exit outcome, and later reflections from leaking into a before-entry analysis. Offer an explicit post-trade review mode when future results are intended.
- Do not execute trades or recommend personalized positions.

### Planned LLM boundary

Build a server-side conversation endpoint with authentication, per-owner rate limits, model spend caps, request timeouts, and a versioned prompt. The server retrieves only authorized records. It constructs a bounded context containing confirmed preferences, selected trade facts visible at the cursor, indicator definitions, and relevant confirmed memories. Raw imported fields and journal content are data, not system instructions.

Use deterministic functions for calculations; an LLM should explain or ask, not calculate account P&L. Require structured proposed insights with evidence IDs and uncertainty. Reject unknown evidence IDs and unsupported numeric claims. Persist messages only after successful validation. If the provider is unavailable, preserve the draft and fall back visibly to guided reflection.

No API credential, broker password, or market-data key should appear in the browser. Voice provider choice, audio retention, and transcript handling require explicit privacy disclosure before enabling a hosted audio pipeline.

## Pattern engine and research safeguards

Start with descriptive patterns that can be precisely defined:

- Entry notional and position size distribution, separated by instrument type.
- Holding duration, entry time, fees, and realized results.
- Planned versus unplanned tags as user-supplied assessments.
- Changes in sizing after a loss, only with complete ordered session history.
- Exit behavior relative to a timestamped explicit plan, only when that plan was actually recorded.
- Maximum favorable/adverse excursion only when the correct instrument price path is available.

Each insight includes definition, data window, sample count, missing-data caveats, effect size, evidence links, and whether it is descriptive or tested prospectively. Correlations are not causal explanations. Multiple exploration attempts should be logged; filtered historical performance must not be sold as a validated edge.

A new user begins with questions and factual summaries. As evidence accumulates, introduce candidate patterns with uncertainty. There is no universal trade-count threshold that makes an insight reliable. Instrument mix, market conditions, dependence among trades, and selection bias matter. Track changes against a frozen definition on subsequent trades.

## Architecture and data ownership

Current stack: React/Vinext, Cloudflare-compatible Worker routes, D1 persistence, and platform-provided authenticated identity in a private Site. Read/write requests enforce owner identity server-side. Browser storage is not the source of truth for trading records.

Current tables:

- trades: id, owner, payload, created_at; indexed by owner.
- notes: id, owner, trade_id, payload, created_at; indexed by owner/trade.
- profiles: owner, payload, updated_at.

`GET /api/workspace` retrieves the owner's records. `POST /api/workspace` supports import, note, profile, candles, and deleteAll. Validation happens again on the server. Original files are not retained as blobs in this version.

Production evolution: normalized accounts/import_jobs/executions/positions/position_legs; market-data references; conversations/messages; versioned profiles/memories/insights; subscriptions/usage; audit events and retention jobs. Move large market datasets out of position JSON into licensed storage with indexed metadata. Paginate before account histories become large. Add import-job idempotency and stable broker execution IDs.

## Product backlog and release gates

### Milestone A — Foundational private preview

Acceptance: navigate all pages, inspect replay, import valid canonical rows, reject malformed data, deduplicate retries, save/read notes and profiles, preserve drafts on errors, export records, and enforce owner isolation. Validate mobile layout and keyboard paths.

### Milestone B — One real broker, one reliable replay

Choose the first broker based on users' actual exports. Build golden test fixtures for buys, sells, partial fills, corrections, short positions, and option adjustments. Obtain historical data rights and benchmark fill-to-chart alignment. Do not call a chart “options replay” when it only shows the underlying. Include explicit missing-data states.

### Milestone C — Conversational learning

Connect the selected model provider, enforce budgets, implement cursor-aware retrieval, add memory confirmation, and evaluate factual grounding. Test a suite of malicious import strings, cross-user retrieval attempts, ambiguous intent, insufficient samples, contradictory preferences, and model outages.

### Milestone D — Paid beta

Set up commercial identity, recoverable login, checkout, signed idempotent payment webhooks, entitlement enforcement, cancellation, receipts, and support. Keep prices and effective dates versioned. Finish legal/privacy and licensed data agreements. Measure inference + data + storage + support per active user before expanding usage limits.

### Milestone E — Compounding value

Weekly reviews, versioned goals, repeated-pattern cards, progress tracking on future trades, optional trade comparisons, and exportable reports. Consider counterfactual simulation only after actual execution reconstruction is trustworthy.

## Launch and operating plan

Recruit 10–20 target users who can provide supported exports. Success means a user imports history, completes a review, saves a useful reflection, returns the next week, and eventually renews. Track activation, time to first useful review, import failure rate, weekly review completion, returning reviewers, paid conversion, cancellation reasons, and variable cost per review. Define event payloads minimally; do not transmit raw journal text to analytics by default.

Release with one supported broker and explicit asset coverage, not an unverified “all brokers” claim. Run interviews around actual reviews rather than asking whether people like the idea. Show sample reports and observed results, not profit promises or invented testimonials.

For $20,000 gross receipts over three months at $19.99/month, 501 customers paying an average of two months would be required. This is arithmetic, not a forecast. A successful beta may generate less while establishing retention and unit economics.

## Decisions still needed

1. First broker/export format and initial stock versus options audience.
2. Historical data provider, redistribution rights, and data coverage.
3. LLM and voice provider, privacy terms, model limits, and cost ceiling.
4. Public authentication and billing provider for the commercial product.
5. Operating entity, support email, domain, and trademark clearance.
6. Founding plan limits, pilot cohort, and measured retention target.

Preserve this document as a living plan. Log what was actually built and learned separately from future intentions; do not rewrite earlier milestones as if they had already shipped.