Purchase Conversation 1: Interaction Spec - Sydney

Original Transcripts & References

• Purchase 1 Workflow Conversation.txt
• Purchase 2 Real Estate Financial Planning.txt
• Purchase 3 Mortgage Process Optimization Meeting.txt
• Purchase 4 copy.txt

Summary Overview

This summary distills the Purchase conversation artifact set (Sections A-F + Meta Capture) into a quick, readable briefing for product, design, and engineering.

1) What this conversation was

• A live, end-to-end simulation of the Phase 1 Clarity Engine for a home purchase (property + affordability planning).
• User = Sydney Bocik (target customer profile in this scenario). Engine = David (embodied Purlend intelligence).
• Goal = produce borrower-owned truth and options (3-4 scenario paths), not a single "answer" or approval.

2) The core product lesson

• "Truth" is a deliverable, not a feature: the output must be an all-in monthly 'whole number' (ranges + assumptions) that the user can plan life around.
• Purchase clarity requires a two-lane model: qualifying truth (underwriting) vs lived affordability truth (cash-flow + holding costs). If these are blended, users get confused and lose trust.
• Anxiety is functional: when costs are ambiguous or privacy feels unsafe, cognition degrades. The UI must reduce cognitive load through structure (ranges, breakdowns, checklists, progressive disclosure).

3) Archetype snapshot (Sydney — Purchase)

• Who: first-time buyer with a specific property in mind; explores "house-hack" (ADU/roommate) as a buffer.
• Job-to-be-done: 'Help me decide if this is truly affordable (all-in) and what could change the number later.'
• Emotional posture: motivated, analytical, but anxious about surprises post-commitment.
• Trust triggers: neutrality/no pressure; explicit assumptions; concrete examples; privacy-first staging.
• Breakers: SSN-in-chat style asks; hidden line items; steering/'best option' language; legalese around portability.

4) The Phase 1 conversation spine (what good looks like)

• Anchor fast: capture (a) monthly comfort cap and/or (b) a specific property anchor early.
• Convert unknowns into ranges + named drivers (tax/insurance drift, utilities, maintenance, vacancy).
• Generate 3-4 equal-weight scenarios (no ranking) with explicit trade-offs + 'what could break this.'
• Exit with a portable clarity package: assumptions, ranges, scenarios, and next-step checklist; optional Stage 2 bridge.

5) What Phase 1 must build (foundation requirements)

• All-in Cost Composer (Whole Number Stack) with confidence labels and editable assumptions.
• Two-Lane Truth View (Qualifying vs Lived Affordability) surfaced explicitly in the UI.
• Scenario Cards (3-4) with equal weight; neutral language; pros/cons; complexity + volatility exposure indicators.
• Lightweight Documentation Checklist + Examples (lease/deposit proof, gift letter) without forced uploads.
• Privacy-first Verification Bridge (secure handoff; 'skip for now'; no sensitive data in chat).
• Anxiety/Confusion Reset pattern (summarize knowns/unknowns; offer choices; avoid spirals).

6) Biggest risks surfaced

• False certainty: presenting a single payment number without breakdown and volatility ranges undermines the wedge.
• Early sensitive-data friction: if verification feels required, trust collapses before value is proven.
• Partner/channel optics: watermarking/lock-in semantics can create perceived bait-and-switch if not designed in plain language.
• Portability confusion: users need a simple distinction between a Portable Clarity Package (always) vs Portable Offer Package (sometimes).

7) Most important open questions (to resolve next)

• What is the canonical "whole number" schema (minimum line items) for purchase Phase 1?
• How will insurance/tax drift be modeled in Phase 1 (range heuristics vs integrations) and how is uncertainty labeled?
• What is the official Stage 2 bridge UX (when shown, what it promises, and what data is collected)?
• What is the portability policy + UX copy (what transfers; what must be regenerated; permission model)?
• How will rental income be represented (cash-flow offset vs qualifying credit) and when is documentation required?

8) Recommended next step

• Repeat the same structure on the Refi conversation to compare deltas and unify the shared 'truth' architecture.
• Continue conversations.

Conversation Breakdown

A) Source of truth

1. Canonical Transcript (Clean + Timecoded)

Purchase_Canonical_Transcript_v0.1.txt

2. Conversation Summary (Neutral, 10-15 bullets)

• The conversation establishes a target affordability ceiling and frames the purchase as risk-managed planning (including buffers for homeownership risk and rental-income variability).
• The conversation quickly moves from abstract affordability into a property-specific starting point, using a real address and list price as the anchor for exploration.
• The "rent the ADU / back unit" assumption is tested, including whether the unit is currently rented and what would be required to count future rental income in qualification.
• The Engine explains qualification logic using a back-end ratio approach (mortgage payment including taxes/insurance), and contrasts this with how landlords qualify tenants (e.g., 3x rent).
• The Engine clarifies that using projected rental income may require an executed lease and evidence of funds/deposit, and uses this moment to call out the need for clear documentation examples (lease, endorsed check, deposit trail).
• A "can a roommate sign then back out" question introduces a boundary around intent and fraud, and the Engine responds by describing what underwriting can validate versus what life can change after execution.
• The conversation transitions into early risk discovery: cash-on-hand, moving/utility startup costs, and credit-history red flags that could block qualification later.
• The Engine positions soft credit as an educational step ("credit-worthy / hidden gotchas") before any hard inquiry, with a clear distinction between education vs. pre-approval mechanics.
• The transcript includes a friction point around sensitive data entry (e.g., reluctance to place SSN in chat), and the Engine discusses lower-friction methods for soft credit where possible.
• The Engine flags process risks that amplify purchase stress — particularly employment verification timing — and recommends avoiding changes that create documentation gaps during underwriting/closing windows.
• A separate segment expands from "this transaction" to a broader architecture question: what parts of the experience should be portable (logs, scenario outputs, educational artifacts) vs. what is constrained by lender/legal/paid-verification realities.
• The conversation defines portability as borrower-centric (permissioned transfer between professionals), while acknowledging that offers can't be identically replicated across lenders due to program eligibility, pricing, and fulfillment constraints.
• The transcript describes "data freshness" constraints (documents and verifications going stale on ~30-day cycles) and introduces electronic verification as an option to reduce repeated document collection.
• The Engine distinguishes pre-qualification vs. pre-approval through the lens of verification depth (credit/income/employment/assets), and notes gift documentation timing requirements in a purchase scenario.
• The conversation includes a business-model fork (distribution/partner channel dynamics vs. direct-to-borrower) and how that choice affects who "owns" or can reuse/transfer elements of the experience.

B) Conversation Flow

3. Conversation Map (State Machine)

This is the intended Phase 1 purchase flow (clarity-first). It's designed so Phase 1 becomes a foundation (portable truth + affordability) rather than "feature debt."

Primary states

P0 — Entry + Trust Setup

• Goal: establish a neutral, no-pressure posture ("clarity, not approval"), set expectations (ranges + assumptions), and explain optional deeper verification later.
• Entry: session starts (anonymous Stage 1).
• Exit: user confirms the goal + consents to clarifying questions.
• Transitions: → P1.

P1 — Intent + Context Capture

• Goal: capture the decision the user is trying to make (purchase) + constraints (geo, property type, HOA tolerance, timing).
• Entry: user says "I want to buy" / "Can I buy?" / "Where do I start?"
• Exit: intent is reflected back; exploration anchor selected (property-first vs budget-first).
• Transitions: → P2 (need baseline anchors) or → P4 (property-first) or → Stage 2 Bridge (user asks to verify / pre-approval).

P2 — Baseline Affordability Anchors

• Goal: establish the user's real comfort ceiling (what they can live with monthly) and a basic snapshot of debts/liabilities.
• Entry: intent is clear; needs grounding.
• Exit: a working "all-in monthly comfort range" is agreed.
• Transitions: → P3.

P3 — Strategy Variables + Constraints

• Goal: capture the "levers" the user might rely on (ADU/roommate/rental plan, gifts, timeline) and educate on what typically counts without steering.
• Entry: baseline anchors exist.
• Exit: enough inputs exist to generate 3-4 viable scenario paths.
• Transitions: → P4, ↻ loop via education modules, or → Stage 2 Bridge.

P4 — Truth Layer: 'All-in' Monthly Range

• Goal: produce a clear monthly range (PITI + selected holding costs), label assumptions, and surface volatility drivers (tax/insurance drift).
• Entry: enough assumptions exist to model.
• Exit: user acknowledges understanding of the "whole number" and volatility drivers.
• Transitions: → P5, ↻ back to P2/P3 if assumptions change.

P5 — Scenario Synthesis (3-4 Cards)

• Goal: present 3-4 neutral scenario cards (equal weight, not ranked), with legible trade-offs.
• Entry: truth layer exists.
• Exit: user selects a path to explore or signals closure.
• Transitions: → P6 (explore) or → P7 (exit plan).

P6 — Exploration Loop (Compare + Adjust)

• Goal: compare scenarios, tweak assumptions, update ranges, detect anxiety/confusion spikes and run clarity resets.
• Entry: at least one scenario selected.
• Exit: stable decision posture (confidence in a path, or clarity on what info is missing).
• Transitions: ↻ back to P5 (recompute scenarios), → P7, → Stage 2 Bridge.

P7 — Exit Summary + Next Steps

• Goal: summarize assumptions + outputs in plain language; provide a short checklist; optionally invite Stage 2 verification.
• Entry: user asks for "what do I do now?"
• Exit: user leaves with a portable clarity package and clear actions.

Education Modules (substates)

These are invoked from multiple places without breaking the core flow:

• E1 Qualification basics (DTI/ratios)
• E2 Rental income + lease requirements
• E3 Gift vs loan + compliance boundary
• E4 Soft vs hard credit + privacy-first data collection
• E5 Taxes/insurance/flood + holding costs + volatility
• E6 Process risk warnings (job changes, new financing, documentation timing)

4. Annotated Transcript (Tagged)

Tagging below is done at the segment (macro-beat) level to preserve flow readability while still being systematic.

Tag sets used

• Conversation Function: RAPPORT, INTENT_DISCOVERY, AFFORDABILITY_FRAMING, PROPERTY_ANCHOR, INCOME_STRATEGY, QUALIFICATION_EDUCATION, READINESS_PLANNING, COMPLIANCE_BOUNDARY, VERIFICATION_BRIDGE, RISK_MANAGEMENT, COST_TRUTH_LAYER, SCENARIO_SETUP, NEXT_STEPS, META_PRODUCT_ARCHITECTURE, DATA_OWNERSHIP_PORTABILITY, PARTNER_CHANNEL_STRATEGY, etc.
• Component Layer: Oracle / Navigator / Advisor / Storyboard
• Moment Flags: CLARITY_MOMENT, ANXIETY_SPIKE, CONFUSION_SPIKE, DATA_SENSITIVITY, TRUST_GAIN, TRUST_RISK, NOTE_TAKER, INCENTIVE_MISMATCH, VALUE_PROP_TENSION, SCOPE_TO_STAGE2, EDGE_CASE, etc.

Purchase simulation (Recording 1) — segmented map

B2.S01 — Rec 1 (0:00-6:39)

• What happens: Rapport + informal warm-up before the simulation begins.
• Function: RAPPORT
• Layer: Advisor
• Flags: TRUST_GAIN
• Flow mapping: P0 → P1

B2.S02 — Rec 1 (6:40-8:55)

• What happens: User states first-home purchase intent and uncertainty; Engine sets clarity-first posture and gathers constraints.
• Function: WELCOME_EXPECTATIONS, INTENT_DISCOVERY, CONTEXT_CAPTURE
• Layer: Advisor, Navigator, Oracle
• Flags: TRUST_GAIN
• Flow mapping: P0 → P1 → P2

B2.S03 — Rec 1 (8:56-12:05)

• What happens: Baseline anchors (rent/utilities) + initial affordability framing; user anxiety about whether buying is possible.
• Function: AFFORDABILITY_FRAMING, FINANCIAL_SNAPSHOT_CAPTURE
• Layer: Oracle, Navigator
• Flags: ANXIETY_SPIKE, CLARITY_MOMENT
• Flow mapping: P2

B2.S04 — Rec 1 (11:16-12:05)

• What happens: Income/employment snapshot (role, salary, raise timing).
• Function: FINANCIAL_SNAPSHOT_CAPTURE, RISK_MANAGEMENT
• Layer: Oracle, Navigator
• Flow mapping: P2 → P3

B2.S05 — Rec 1 (12:05-16:08)

• What happens: House-hack strategy exploration; lease requirement becomes a key rule.
• Function: INCOME_STRATEGY, QUALIFICATION_EDUCATION
• Layer: Navigator, Storyboard
• Flags: CONFUSION_SPIKE, CLARITY_MOMENT
• Flow mapping: P3 (E1/E2)

B2.S06 — Rec 1 (17:08-19:33)

• What happens: Property-first anchor (address, price, ADU).
• Function: PROPERTY_ANCHOR, SCENARIO_SETUP
• Layer: Oracle, Navigator
• Flags: CLARITY_MOMENT
• Flow mapping: P1/P2 → P4

B2.S07 — Rec 1 (18:56-20:56)

• What happens: Intent recapped: truth + affordability exploration, not pressure.
• Function: INTENT_CLARIFICATION, EXPECTATION_SETTING
• Layer: Advisor, Navigator
• Flags: TRUST_GAIN
• Flow mapping: P4 → P3

B2.S08 — Rec 1 (20:56-24:27)

• What happens: Purchase readiness variables (cash/down payment/gifts).
• Function: READINESS_PLANNING
• Layer: Oracle, Navigator
• Flags: DECISION_PARALYSIS_RISK
• Flow mapping: P3 (E3)

B2.S09 — Rec 1 (21:47-23:53)

• What happens: Fraud-adjacent question; compliance education without accusation.
• Function: COMPLIANCE_BOUNDARY, EDUCATION
• Layer: Advisor, Navigator
• Flags: TRUST_RISK, CLARITY_MOMENT
• Flow mapping: P3 (E3)

B2.S10 — Rec 1 (24:27-28:31)

• What happens: Gift vs loan mechanics; "send examples" becomes a Storyboard requirement.
• Function: DOCUMENTATION_EXAMPLES, READINESS_PLANNING
• Layer: Storyboard, Navigator
• Flags: NOTE_TAKER, CLARITY_MOMENT
• Flow mapping: P3 (E3)

B2.S11 — Rec 1 (28:56-30:50)

• What happens: Soft credit vs hard pull clarified; Stage 1 exploration defined.
• Function: VERIFICATION_BRIDGE, EDUCATION
• Layer: Navigator, Advisor
• Flags: SCOPE_TO_STAGE2, DATA_SENSITIVITY
• Flow mapping: P3 → Stage 2 Bridge (E4)

B2.S12 — Rec 1 (30:50-33:40)

• What happens: Vacancy + roommate uncertainty; lease example as a visual cue; fraud boundary revisited.
• Function: EDGE_CASE_HANDLING, DOCUMENTATION_EXAMPLES
• Layer: Storyboard, Advisor, Navigator
• Flags: EDGE_CASE, TRUST_RISK, CLARITY_MOMENT, NOTE_TAKER
• Flow mapping: P3 (E2/E3)

B2.S13 — Rec 1 (34:45-36:21)

• What happens: Liquid cash + moving costs; "do I have enough runway?" check.
• Function: FINANCIAL_SNAPSHOT_CAPTURE, READINESS_PLANNING
• Layer: Oracle, Navigator
• Flow mapping: P2/P3

B2.S14 — Rec 1 (36:21-38:24)

• What happens: SSN-in-chat resistance; secure-link workflow proposed; proceed on assumptions.
• Function: VERIFICATION_BRIDGE
• Layer: Advisor, Navigator
• Flags: DATA_SENSITIVITY, TRUST_RISK, CLARITY_MOMENT
• Flow mapping: P3 → Stage 2 Bridge (E4)

B2.S15 — Rec 1 (39:02-41:52)

• What happens: Explicit "three stages" architecture (exploration vs verified vs execution).
• Function: META_PRODUCT_ARCHITECTURE, STAGE_GATING
• Layer: Navigator
• Flags: NOTE_TAKER, SCOPE_TO_STAGE2
• Flow mapping: global rule (P0-P7)

B2.S16 — Rec 1 (42:36-45:36)

• What happens: Credit score acknowledged; education link deferred; new financing caution introduced.
• Function: RISK_MANAGEMENT, EDUCATION
• Layer: Oracle, Navigator, Advisor
• Flags: CLARITY_MOMENT
• Flow mapping: P3 (E4/E6)

B2.S17 — Rec 1 (45:54-48:17)

• What happens: Process risk warnings: employment verification and "don't switch jobs."
• Function: RISK_MANAGEMENT
• Layer: Advisor, Navigator
• Flags: ANXIETY_SPIKE, CLARITY_MOMENT
• Flow mapping: P3 (E6)

B2.S18 — Rec 1 (50:48-51:42)

• What happens: Student loans and DTI timing become an explicit planning variable.
• Function: FINANCIAL_SNAPSHOT_CAPTURE, RISK_MANAGEMENT
• Layer: Oracle, Navigator
• Flags: ANXIETY_SPIKE
• Flow mapping: P3 (E1)

B2.S19 — Rec 1 (51:46-56:52)

• What happens: PITI truth layer: taxes, flood, insurance assumptions + minimum coverage logic.
• Function: COST_TRUTH_LAYER, EDUCATION
• Layer: Storyboard, Navigator
• Flags: CLARITY_MOMENT
• Flow mapping: P4 (E5)

B2.S20 — Rec 1 (56:52-1:04:25)

• What happens: Affordability range stated (property obligations). User flags lifestyle costs as part of "truth."
• Function: AFFORDABILITY_FRAMING, COST_TRUTH_LAYER
• Layer: Advisor, Navigator
• Flags: CLARITY_MOMENT, NOTE_TAKER
• Flow mapping: P4 → P5 prep

B2.S21 — Rec 1 (1:04:30-1:07:44)

• What happens: "For the notetaker": demonstrates "lead without steering"; reconfirms max payment; gift requirement framed as assumption-based.
• Function: META_NOTETAKER, SCENARIO_SETUP
• Layer: Navigator
• Flags: NOTE_TAKER
• Flow mapping: P4 → P5

B2.S22 — Rec 1 (1:07:49-1:12:46)

• What happens: Holding costs expand: utilities/Wi-Fi/lawn/security. Whole-number truth becomes a deliverable.
• Function: COST_TRUTH_LAYER, EDUCATION
• Layer: Storyboard, Navigator
• Flags: CLARITY_MOMENT, NOTE_TAKER
• Flow mapping: P4 ↻ (E5)

B2.S23 — Rec 1 (1:12:46-1:16:56)

• What happens: Underwriting math vs lived cash flow; budget categories introduced (templated).
• Function: BUDGET_DEEPENING
• Layer: Oracle, Navigator
• Flags: DECISION_PARALYSIS_RISK
• Flow mapping: P4 ↻ / P6

B2.S24 — Rec 1 (1:16:56-1:22:30)

• What happens: Rent vs own comparison; defines holding costs explicitly; clarifies "apples to apples" mismatch.
• Function: COMPARISON, COST_TRUTH_LAYER
• Layer: Storyboard, Navigator
• Flags: CLARITY_MOMENT
• Flow mapping: P6

B2.S25 — Rec 1 (1:22:30-1:27:59)

• What happens: Incentive misalignment + personalization: market avoids whole-number truth; concrete security examples illustrate variability.
• Function: META_PRODUCT_ARCHITECTURE, VALUE_PROP_TENSION
• Layer: Advisor, Storyboard, Navigator
• Flags: INCENTIVE_MISMATCH, VALUE_PROP_TENSION, NOTE_TAKER
• Flow mapping: feeds requirements + design insights

Debrief / architecture (Recordings 2-3)

These segments are meta, but they materially define what Phase 1 must be (portable truth + user-owned clarity).

B2.S26 — Rec 2 (0:00-6:28)

• What happens: Reasserts "whole number" (ranges for holding costs) as core value prop.
• Function: COST_TRUTH_LAYER, VALUE_PROP_TENSION
• Layer: Storyboard, Navigator
• Flags: CLARITY_MOMENT
• Flow mapping: strengthens P4/P5

B2.S28 — Rec 2 (20:34-31:13)

• What happens: Pre-qual semantics + soft vs hard pull + profile persistence + verification freshness.
• Function: VERIFICATION_BRIDGE, META_PRODUCT_ARCHITECTURE
• Layer: Navigator
• Flags: SCOPE_TO_STAGE2, DATA_SENSITIVITY, NOTE_TAKER
• Flow mapping: defines Stage 2 Bridge boundaries

B2.S30 — Rec 2 (47:58-56:17)

• What happens: Portability principle: "logging is yours" (borrower-owned scenario/history transfers with permission); circumvention risk acknowledged.
• Function: DATA_OWNERSHIP_PORTABILITY, PARTNER_CHANNEL_STRATEGY
• Layer: Advisor, Navigator
• Flags: CLARITY_MOMENT, TRUST_RISK, VALUE_PROP_TENSION
• Flow mapping: portable clarity package scope

B2.S35 — Rec 3 (4:25-6:45)

• What happens: Definitional mismatch is the product problem: borrower "payment" vs fundability vs affordability; "out-of-pocket" differs by actor.
• Function: TAXONOMY_SEED, COST_TRUTH_LAYER
• Layer: Storyboard, Navigator
• Flags: CLARITY_MOMENT, CONFUSION_SPIKE, NOTE_TAKER
• Flow mapping: taxonomy + UI requirements

B2.S37 — Rec 3 (9:14-10:39)

• What happens: Retention trigger: willingness to save an account depends on whether the system resolves real uncertainties.
• Function: TRUST_CLARITY, NEXT_STEPS
• Layer: Advisor, Navigator
• Flags: TRUST_GAIN, NOTE_TAKER
• Flow mapping: P7 instrumentation / success criteria

C) User Archetype

5. User Archetype Card (1-page)

User Archetype Card (Scenario Persona: Sydney Bocik)

Who they are (role + context)

A first-time homebuyer with a specific property in mind, seeking clarity on whether they can qualify and whether homeownership is truly right for them. They are also considering "house-hack" style cash-flow support (renting a room/unit) as an emotional + financial backstop.

Primary "job to be done"

"Help me decide — with confidence — if I can afford the real monthly cost of owning this home, and what would cause that number to change later."

Their definition of "afford" is explicitly not the lender's qualifying number; it's the all-in 'whole number' (mortgage + utilities + maintenance + lifestyle impact).

Emotional posture + anxieties

• Analytical, detail-seeking, and motivated — but carrying real anxiety about being surprised after committing.
• Anxiety spikes when costs are ambiguous or when they can't "see the whole number."
• Describes the experience as "scary," and looks for buffers/nest-egg logic to feel safe.

Trust model (what triggers distrust / trust)

Trust increases when the system:

• Makes assumptions explicit, shows line items, and allows depth (shallow → deep) so the user can "earn" confidence through detail.
• Demonstrates neutrality + pacing control (not being rushed; no pressure). The user chose a realtor partly because she wasn't "pressurey" and wouldn't rush them.
• Treats truth as the product: corrects non-compliant patterns ("gift vs loan"), explains consequences, and protects the user from accidental fraud.

Distrust triggers:

• Requests for highly sensitive data before value is proven (e.g., SSN in chat).
• Generic "education" that feels like Google — i.e., not personalized to their scenario.

Decision style (fast/slow, validation/control)

• Control-oriented and scenario-driven. Wants a ballpark first, then chooses to go deeper when it feels "possible."
• Doesn't accept "yes you can afford it" as resolution; confidence comes from understanding the drivers of the number and what could change it.

Constraints (time, cash, cognition, attention)

• Cash constraint: reports about $5,000 liquid savings in the scenario.
• Cognitive constraint: the complexity of ownership costs + underwriting rules creates overload; the system must reduce mental load through structure (line items, ranges, staged disclosure).
• Volatility constraint: fear of cost drift (insurance/taxes, especially in places like Florida) makes "future-proofing" part of affordability.

What they consider a win

• Leaves with an all-in monthly "whole number" range they believe.
• Understands the line-item drivers (utilities, lawn, security, lifestyle) and can adjust assumptions.
• Feels pacing control (not rushed) and can pause/resume without penalty.
• Receives "truth-first" guidance that prevents compliance mistakes and protects them from bad outcomes.

What breaks the experience

• Being pushed into verification too early (SSN friction / "prove you're serious" logic before the user feels safe).
• Missing line items and hidden costs (affordability reduced to lender math only).
• Any whiff of steering, pressure, or non-neutral sales behavior.
• No mechanism to handle non-compliant inputs responsibly (the "human filtering" disappears in AI).

6. Intent Stack

Surface intent (what they asked)

• "Can I afford this?" (with a practical monthly cap expectation and fear of drift).
• "Do I qualify for this specific property?"
• "How do I navigate down payment sourcing correctly (gift vs loan)?"

Underlying intent (what they meant)

• "Give me the complete affordability picture — mortgage + living + ownership + volatility."
• "Let me control the pace and the depth: ballpark first, deeper later."
• "Make the process predictable so I don't get surprised at underwriting." (Rules, examples, consequences, and what changes outcomes.)

True motive (what they're protecting / pursuing)

• Protecting: emotional safety, privacy, and avoidance of getting locked into a decision that later proves unaffordable (or non-compliant).
• Pursuing: confidence + agency — feeling like the decision is theirs, informed by truth, with a stable "whole number" they can plan their life around.
• Category-level driver: the user is not buying "a loan." They're buying clarity that withstands stress (i.e., the system works when anxiety would normally degrade comprehension and decision-making). This is why "truth" (even if it slows or kills deals) functions as the actual deliverable in the experience.

D) Data + Systemization

This section converts the purchase conversation into a reusable data model + computation model + output spec that can absorb additional conversations over time (without losing narrative flow).

The PRD requires Stage 1 to be an anonymous exploration that ends in 3-4 equal-weight scenario cards (no ranking/steering) and uses structured JSON as the rendering contract.

7. Inputs Inventory (Data Dictionary)

Everything the system asked for or implicitly relied on, grouped by:

• Required vs Optional (for Stage 1 scenarioing)
• User-provided vs Inferred
• Stable vs Volatile

Group 1 — Intent + constraints (required)

• intent.primary_goal — what clarity is needed (e.g., "can this purchase work without guesswork?")
• intent.affordability_cap_all_in — hard monthly ceiling (the "truth constraint")
• intent.house_hack_plan — whether rent-offset is part of the plan (and how)

Group 2 — Current baseline (required)

• current.housing_cost_all_in — rent + utilities baseline used for monthly impact comparisons
• current.location_context — used for rent comps, insurance volatility heuristics

Group 3 — Borrower profile (required in Stage 1, verified in Stage 2)

• borrower.income_gross_annual (volatile)
• borrower.employment_stability_notes (volatile)
• borrower.cash_on_hand + financing.gift_amount (volatile)
• borrower.reserve_floor (stable preference; critical to trust)

Group 4 — Property + rental plan (required)

• property.address
• property.purchase_price
• property.occupancy_type (owner-occupied assumption)
• rental.ad_u_rent_gross_monthly (volatile)
• rental.documentation_status (lease executed? deposit verified?) (volatile but determinative)

Group 5 — Debts + obligations (required conceptually; Stage 2 verified)

• debts.auto_payment
• debts.revolving_min_payment
• debts.student_loan_assumption (this is often the swing factor)

Group 6 — Escrow + holding costs (required for "truth")

• escrow.property_tax_estimate_method (volatile)
• escrow.insurance_estimate_method (highly volatile)
• ops.holding_cost_range (utilities/maintenance/security buffer)

Systemization rule: Stage 1 must treat escrow + holding costs as a first-class truth object, not a footnote — because that's where "affordability drift" lives (and where anxiety spikes happen).

8. Derived Variables + Logic Notes

Core derived variables

• Baseline renting (all-in)
  rent_all_in = rent + utilities
• Bank obligation (PITI) (estimated in Stage 1)
  piti = principal_interest + taxes + insurance + (pmi if applicable)
• All-in homeowner cost (truth)
  all_in_owner = piti + holding_costs_range
• House-hack net cash-flow (cash lens)
  net_owner_cashflow = all_in_owner - rent_collected
• Rental income qualifying credit (underwriting lens)
  rent_qual_credit = rent_collected * rent_credit_pct
  (kept separate from cash-flow on purpose)
• Back-end DTI
  dti = (piti + monthly_debts) / gross_monthly_income

Logic notes that must be explicit

• Cash-flow vs qualifying are different "truths." Stage 1 should show both, because users conflate them.
• Escrow volatility projection should be available as a range-based layer (not pretending certainty):
  • taxes drift (county reassessment / millage changes)
  • insurance drift (market shocks, flood/roof risk, carrier exits)
• Reserve protection constraint should be treated as a requirement: "what remains after close," not only "cash to close."

Tooling needed (MVP Phase 1)

Minimum calculator/tool set for purchase:

• mortgage PI calculator (rate assumptions via RAG + rate sheet inputs)
• property tax lookup + fallback estimator
• insurance estimator (heuristic Stage 1; quote integration later)
• DTI calculator (program presets configurable)
• rent comp / rent survey lookup
• volatility projection module (range-based, confidence-labeled)

Uncertainty points (must be shown, not hidden)

• rate + program assumptions (term/PMI/product)
• whether rent can be counted without executed lease + verified deposit
• student loan payment treatment
• insurance variability + flood-zone verification
• definition mismatch risk: "$X all-in" (bank payment vs true homeowner all-in)

9. Outputs Inventory

Everything produced (or implied as necessary) that needs a stable output format.

Output type 1 — Education modules (triggered in-flow)

• DTI explanation (plain language)
• rental income rules + documentation checklist
• "bank obligation vs all-in homeowner truth" bucketing explanation
• underwriting stability explanations (job change timing, verifications)
• escrow volatility explanation (fixed rate ≠ fixed payment)
• closing timing / first payment mechanics (cash-flow bridge)

Output type 2 — Comparison frames

• rent all-in vs own all-in (apples-to-apples)
• cash-flow lens vs qualifying lens
• estimated Stage 1 vs verified Stage 2 (progression model)

Output type 3 — Next-step summary (non-prescriptive)

• rent survey to validate ADU rent
• flood/insurance early checks
• if rent is needed for qualifying: lease + deposit verification before close
• clarify student loan payment assumption
• protect post-close reserve floor as a constraint

10. Scenario Options Presented

E) Design + Product Insight

11. Design Insights (Deep)

Cognitive friction points (where the user struggled)

• Definition mismatch: users conflate lender "payment" (PITI) with lived affordability ("whole number"). The flow repeatedly has to separate constructs (Section B: B2.S19-B2.S24).
• Qualification vs cash-flow mismatch: rental income can reduce out-of-pocket but may not count for qualifying without documentation (B2.S05, B2.S12).
• Documentation ambiguity stalls progress: lease executed, deposit trail, gift vs loan mechanics require concrete examples to reduce mental load (B2.S10-B2.S12).
• Volatility is hard to reason about without structure: taxes/insurance drift and holding costs stay abstract until converted into named drivers + ranges (B2.S19, B2.S22; Rec 2 volatility thread).
• Portability semantics create comprehension friction: "what transfers" vs "what must be regenerated" becomes confusing when communicated as legal/rights logic (B2.S30-B2.S32; B2.S31 in particular).
• Stage boundary confusion is constant: users naturally ask for Stage 2/3 behaviors during Stage 1; boundary must be crisp without feeling evasive (B2.S11, B2.S15, B2.S28).

Emotional friction points (where anxiety rose)

• Fear of being surprised later: anxiety spikes when an all-in number isn't believable or fully surfaced (B2.S03, B2.S20-B2.S22).
• Privacy/safety friction: SSN-like steps in chat trigger immediate hesitation (B2.S14).
• Compliance fear: fraud-adjacent hypotheticals require firm education without shaming (B2.S09, B2.S12).
• Process fragility anxiety: job change timing, new debt, verification timing threaten "surprise denial" outcomes (B2.S17-B2.S18).
• Market volatility dread: insurance/taxes increases destabilize confidence; users want drift modeling even if approximate (Rec 2: B2.S27).

Clarity triggers (what created relief/understanding)

• Naming the deliverable: "whole number / all-in monthly" reframes the product as truth, not approval (B2.S22).
• Two-lane framing: separating "bank obligation" from "lived affordability" reduces confusion and rework (B2.S20-B2.S24).
• Concrete exemplars: visual examples of lease/deposit proof/gift letters collapse uncertainty (B2.S10-B2.S12).
• Property anchor + baseline compare: real address/price + rent baseline turns abstract fear into concrete decision-making (B2.S06, B2.S24).
• Ranges + named drivers: converting unknowns into ranges with drivers (tax/insurance drift, utilities, maintenance) produces confidence without fake certainty (B2.S19, B2.S22; Rec 2 drift thread).
• "What would change this answer?" framing: turns anxiety into action and prevents spiraling.

Trust triggers (what increased/decreased trust)

• Trust increases with neutrality + no-pressure: explicit exploration posture and equal-weight paths (B2.S02, B2.S07).
• Trust increases with privacy-first staging: sensitive steps optional, secure link handoffs, value first (B2.S14).
• Trust increases when incentive misalignment is acknowledged: borrower-centric truth positioning (B2.S25, B2.S30).
• Trust decreases with legalistic language: ownership/rights explanations feel like a "gotcha" when not plain-language (B2.S31).
• Trust decreases when partner-channel logic threatens autonomy: watermarking/lock-in perception must be intentionally designed (B2.S29-B2.S32).

Pacing insights (when to slow/accelerate)

• Accelerate early to an anchor: capture monthly comfort ceiling and/or a property anchor quickly (B2.S02-B2.S06).
• Use progressive disclosure: deliver a first ballpark range, then invite deeper detail only after "this could work" (B2.S03 → B2.S13).
• Slow down at boundary moments: (a) privacy/SSN, (b) compliance, (c) volatility. These need reassurance + explicit choices (B2.S09, B2.S14, B2.S27).
• When anxiety spikes, stop adding variables: restate control + summarize knowns/unknowns; offer one next question (B2.S03, B2.S17).
• Do not mix Stage 1 exploration with Stage 2 verification inline: create a clear "bridge" moment (B2.S11, B2.S15, B2.S28).

Language insights (words/phrases that worked)

• Truth framing: "whole number," "all-in," "fully baked," "the number you can live with," "drivers," "ranges," "assumptions." (B2.S22-B2.S24)
• Agency framing: "Here are paths people explore," "trade-offs," "what would change this," "you control the pace," "optional next step."
• Boundary framing (non-shaming): "Here's what underwriting can verify," "here's what would be required," "this is why lenders treat it this way." (B2.S09-B2.S12)
• Avoid (must be filtered): "I recommend," "best option," "you should," "guaranteed approval," ranked language (PRD neutrality guardrails).

Visualization opportunities (what should be shown, not said)

• All-in 'Whole Number' stack: P&I + taxes + insurance + PMI + holding costs, with volatility band + confidence label (B2.S19-B2.S22).
• Two-lane Truth View: "Qualifying (Underwriting)" vs "Lived Cash-Flow (Reality)" side-by-side, showing where rent offsets apply (B2.S05, B2.S20-B2.S24).
• Drift Projection (5-10 year range): taxes/insurance with toggles for location/flood/roof assumptions (Rec 2 volatility thread).
• Documentation Gallery: examples (lease, deposit proof, gift letter) + "needed for this scenario" checklist (B2.S10-B2.S12).
• Scenario Compare Table: all-in range, complexity score, volatility exposure, documentation burden, "what could break this."
• Stage Progress Indicator: Exploration → Verify → Execute, with permission boundaries and benefits per stage (B2.S15, B2.S28).

12. UX Requirements Extract

Phase 1 — Must Exist (foundation)

• Affordability Cap Capture (hard constraint early)
• All-in Cost Composer (line-item + ranges + confidence labels; holding costs are first-class)
• Two-lane Truth Model (qualifying vs lived affordability; never one ambiguous "payment")
• Scenario Cards (3-4) equal-weight, neutral titles + trade-offs; no ranking
• Assumption Panel + "What would change this?" checklist (editable assumptions + missing info)
• Documentation Checklist (lightweight) per scenario (no forced uploads)
• Privacy-first Verification Bridge (secure link, skip option, value earned before sensitive data)
• Anxiety/Confusion Reset Pattern (summarize + re-offer choices)
• Portable Clarity Package export/share (user-owned summary + assumptions + glossary + next steps)
• Instrumentation hooks (scenario interactions + clarity rating + drop-off points)

Phase 2+ — Can Wait (design for it now)

• Automated enrichment (tax/flood/insurance quotes, rent comps)
• Account creation + cross-device persistence
• Soft credit + verified income/employment/asset integrations
• Offer portability / MISMO export + marketplace selection
• Partner-channel governance beyond basic portability rules
• Longitudinal analytics (estimate vs funded outcome comparisons)

Explicit anti-patterns to avoid

• Single-number outputs without decomposition
• Hiding uncertainty (no ranges/confidence/drivers)
• Verification before value is earned (SSN-first flows)
• Ranking scenarios / "best option" language
• Legalese for rights/ownership/partner constraints
• Letting underwriting math erase lived affordability (cash-flow reality must remain primary)

F) Meta capture

13. Notetaker Stream (Extracted + Organized)

Pulled out of the transcript and categorized:

• IDEA / OPEN_QUESTION / RISK / ASSUMPTION / EDGE_CASE / DEPENDENCY / MEASUREMENT

Each item includes timestamp + "impacts" + priority.

Purchase_Notetaker_Stream_v0.1.csv

• OPEN_QUESTION: 65
• IDEA: 52
• ASSUMPTION: 19
• RISK: 16
• DEPENDENCY: 16
• EDGE_CASE: 6
• MEASUREMENT: 2

G) Measurement + QA

14. Evaluation Rubric (Conversation-specific)

Scoring guidance: Each criterion is rated Pass/Needs Work/Fail, with optional 1-5 scoring where appropriate. P0 criteria must be Pass for the conversation to be considered 'shippable' behavior in Phase 1.

P0 — Safety, Trust, and Neutrality (non-negotiable)

P0 — Clarity Deliverable (the product)

P1 — Conversation Craft (experience quality)

P1 — Outputs & Packaging

P2 — Measurement & Instrumentation (recommended)

Neutrality Checks (quick checklist)

• No ranked language (no "best," "top," "recommended," "you should").
• No urgency or pressure ("act now," "lock now," "this is your only shot").
• Equal weight formatting: each scenario has comparable length and emphasis.
• Explicit trade-offs: each scenario has at least one meaningful con.
• No hidden CTA: Stage 2 invitation is optional and framed as 'if you want more precision.'

Clarity Checks (quick checklist)

• All-in monthly range is stated (not only PITI).
• Assumptions are visible and editable.
• Unknowns are named with ranges and drivers.
• Qualifying vs lived affordability are separated.
• User can articulate 'what would change the answer' in their own words (or the system provides it as a checklist).

Completion Criteria (Phase 1 Purchase)

• User has a monthly all-in range and understands its components.
• User has 3-4 neutral scenario cards and can explain trade-offs.
• User has a shortlist of the 3-6 missing inputs that would materially change outcomes.
• User has an exit summary + next steps; optional Stage 2 invitation is offered without pressure.
• No P0 trust/privacy/compliance failures occurred.

15. Pattern Library Entries (Reusable Modules)

Format: Trigger → Module → Example language → Expected output. Examples are intentionally short to preserve neutrality and allow UI copy variation.

Intent Ladder (Surface → Underlying)

Trigger: User asks 'Can I afford it?' or provides a vague purchase goal.

Module: Ask one surface question, then one 'why' question; reflect intent back in a single sentence.

Example language: "What would 'affordable' mean for you month-to-month? And what would that enable for you (peace of mind, savings, travel, etc.)?"

Expected output: intent.primary_goal; intent.affordability_cap_all_in; intent.drivers (why).

Anchor Fast: Property-first vs Budget-first

Trigger: User is uncertain where to start OR offers a listing/address.

Module: Offer two starting paths and let the user choose.

Example language: "We can start from a specific home price/address, or we can start from a monthly comfort cap and work backward. Which feels better?"

Expected output: flow.anchor_type; property.address/price or affordability cap.

Two-Lane Truth (Qualifying vs Lived Affordability)

Trigger: User conflates PITI with affordability, or brings up lifestyle costs.

Module: Display side-by-side lanes; keep both active throughout scenarioing.

Example language: "There are two truths: what a lender can approve, and what you can live with monthly. I'll show both so nothing is hidden."

Expected output: lane.qualifying (PITI+debts, DTI); lane.lived (all-in+holding costs).

Whole Number Stack (All-in Monthly Composer)

Trigger: User asks for the 'real number,' seems anxious, or decisions stall.

Module: Show a stacked breakdown with a range band; label each assumption.

Example language: "Here's the whole-number range: mortgage + taxes + insurance + a holding-cost buffer. I'll show what's assumed and what could move."

Expected output: all_in_owner_range; breakdown line items; confidence labels; drivers.

Rent Offset: Cash-flow vs Qualifying Credit

Trigger: User plans ADU/roommate income or house-hack strategy.

Module: Separate 'cash collected' from 'qualifying credit'; explain documentation gate.

Example language: "Rent can help your cash flow right away, but lenders may only credit it for qualifying if there's a documented lease and deposit trail."