{
  "version": 1,
  "date": "2026-10-23",
  "evidence": "Synthetic practice and proposed planning, never company performance.",
  "cards": {
    "Q01": {
      "decision": "Is confirmed customer value growing across accounts?",
      "finding": "The final complete operational week shown, 21 September, has 11 quality-value accounts and 11 confirmed tasks. These are weekly account counts, not paying customers.",
      "action": "Inspect review coverage and the corresponding task rows before attributing movement to a launch.",
      "caveat": "Weeks with no qualifying events are absent from this sparse query; absence is not a plotted zero. Do not sum weekly distinct accounts into unique customers.",
      "spoken": "I would lead with weekly accounts receiving confirmed quality value, then check coverage before explaining a change."
    },
    "Q02": {
      "decision": "Which customer handoff deserves investigation?",
      "finding": "Across the default task-created cohort, 877 of 1,081 tasks rendered and 184 met confirmed quality use. Review and export are separate checkpoints.",
      "action": "Use Q24 or J01 to inspect actual recorded paths, then Q15 for examples.",
      "caveat": "Checkpoint columns are overlapping counts, not a compulsory sequential funnel. An eligibility block is not automatically a technical defect.",
      "spoken": "Rendering is one milestone. I would inspect the handoff to approved audience use before adding more creation features."
    },
    "Q03": {
      "decision": "Which signup segment needs a closer activation study?",
      "finding": "Developer activation is 8 of 94 eligible signups, marketing 4 of 93 and training 6 of 93 in the first seven days.",
      "action": "Inspect zero-task signups and early task records within a comparable persona/workflow.",
      "caveat": "Use seven-day mature signups, including zero activity. Counts are small; persona differences do not establish a design effect.",
      "spoken": "I would keep all eligible signups in the denominator and investigate one segment before proposing an onboarding change."
    },
    "Q04": {
      "decision": "Are comparable signup cohorts returning to quality work?",
      "finding": "June has 14 of 51 eligible users returning in days 28\u201341; May has 5 of 52. The table also supplies later cohorts.",
      "action": "Check maturity, cohort size, acquisition mix and natural video-production frequency.",
      "caveat": "This is unconditional signup return, not retention among activated users, account renewal or learner retention. September is only the eligible portion of that signup month.",
      "spoken": "I would compare mature cohorts and their counts before deciding that retention improved."
    },
    "Q05": {
      "decision": "Is first-week value a useful signal to investigate?",
      "finding": "Three of 12 early-value users later returned, versus 31 of 212 without early value: 25% versus 14.6%.",
      "action": "Check G02/G03 within months, then test prediction on a later held-out cohort.",
      "caveat": "This is a descriptive association. Initial intent, persona and shared accounts can explain differences.",
      "spoken": "Early value is associated with later return here, but I would not call it causal or rely on it before a held-out test."
    },
    "Q06": {
      "decision": "How much quality evidence supports the value count?",
      "finding": "Preview review coverage ranges from 64.7% to 73.1% across workflows. The retained reviews contain 31 critical-error flags.",
      "action": "Inspect error themes and who is missing from the reviewed sample before choosing a quality intervention.",
      "caveat": "Acceptance applies to reviewed tasks. Missing reviews are unknown, and critical failures must not disappear inside an average acceptance score.",
      "spoken": "I would show review coverage next to acceptance so that missing evidence does not look like either success or rejection."
    },
    "Q07": {
      "decision": "Should engineering prioritize render latency?",
      "finding": "Median ready latency is about 6\u20137 minutes; workflow p95 values are about 22 minutes in the completed-task sample.",
      "action": "Compare Q23 before deciding which part of the end-to-end journey to speed up.",
      "caveat": "Creation-to-ready includes the render journey, but excludes later human review. Never add component p95s or average workflow p95s to get an overall p95.",
      "spoken": "The render tail matters, but I would compare it with the much longer review-to-use journey before allocating engineering time."
    },
    "Q08": {
      "decision": "Does recovery restore useful work, or only technical completion?",
      "finding": "Of 155 tasks with a failed attempt, 29 later rendered and six reached confirmed quality use by cutoff.",
      "action": "Inspect recoverable failure classes, recent-task observation time and entitlement reconciliation.",
      "caveat": "Right censoring and missing confirmation limit recovery-to-value counts. A helpful retry is not a defect just because retry rate rises.",
      "spoken": "I would judge recovery by restored customer value, while checking whether recent tasks had enough time to recover."
    },
    "Q09": {
      "decision": "Which workflow consumes more direct cost per confirmed outcome?",
      "finding": "Direct vendor cost per confirmed-use task is about $15.75 for API templates, $17.34 for document avatars and $22.65 for dubbing.",
      "action": "Use Q11 to inspect the numerator and Q06 to understand confirmation coverage before changing price.",
      "caveat": "All task costs, including unsuccessful work, are included. These are illustrative vendor allocations, not total company cost or actual AI Studios margins.",
      "spoken": "Dubbing looks more expensive per confirmed outcome in this sample, so I would inspect workload and coverage before recommending pricing."
    },
    "Q10": {
      "decision": "Is automation reducing customer effort?",
      "finding": "Reviewed tasks still average roughly 31\u201335 active minutes across preparation, review and repair, depending on workflow.",
      "action": "Observe the review workflow and test changes against measured active effort and critical errors.",
      "caveat": "The manual alternative is an estimate; estimated net minutes are not measured causal time savings. Customer labor is separate from vendor expense.",
      "spoken": "I would measure the work customers still do after generation, rather than assume faster rendering means equivalent time saved."
    },
    "Q11": {
      "decision": "What is driving the cost numerator?",
      "finding": "Support contributes about $2,129 and vendor review $1,010, compared with $110 of render compute in the default task cohort.",
      "action": "Investigate repeated support/review causes before treating compute optimization as the largest savings opportunity.",
      "caveat": "Rates are fictional. Units differ by row; compare USD costs, not a sum of staff minutes, compute seconds and GB.",
      "spoken": "In this practice model, human operations dominate direct cost. I would investigate those causes before optimizing the smallest compute line."
    },
    "Q12": {
      "decision": "Are resource reservations reconciled correctly?",
      "finding": "Each of the three meters has zero outstanding balance: reserved minus consumed minus released equals zero.",
      "action": "Trace failed-task examples and duplicate requests before concluding that billing is trustworthy.",
      "caveat": "A balanced simplified ledger does not validate payment, refunds or a real production billing system. Video counts, minutes and credits are incompatible units.",
      "spoken": "I would reconcile each meter separately and test failure recovery; a zero balance is useful evidence, not proof of complete billing correctness."
    },
    "Q13": {
      "decision": "Can this assignment support an account-level experiment claim?",
      "finding": "Thirty-five of 167 mature accounts have users in more than one variant, about 21%.",
      "action": "Randomize at the account/team level if users collaborate, and predefine the outcome and maturity window.",
      "caveat": "This is an interference audit, not a treatment-effect estimate. User-level assignment does not make team accounts independent.",
      "spoken": "I would fix the unit of assignment before interpreting a team-workflow experiment, because mixed treatment within accounts can contaminate results."
    },
    "Q14": {
      "decision": "Which acquisition channel deserves a controlled next test?",
      "finding": "Allocated spend per activated mature user ranges from about $798 for search to $1,252 for partners; the activated counts are only 3\u20135 per channel.",
      "action": "Examine quality return, account value and confidence before a small incremental channel test.",
      "caveat": "This is allocated fictional spend per activated user, not paid-customer CAC or lifetime-value payback. Activation and later-return populations must stay eligible.",
      "spoken": "I would not move the budget on three to five activations per channel. I would validate downstream value with another mature cohort."
    },
    "Q15": {
      "decision": "What happened in an individual task behind the chart?",
      "finding": "Task 1 rendered but has no recorded review or use. Task 3 has acceptance, confirmed use and confirmed_quality_use equal to one.",
      "action": "Use contrasting task examples to diagnose the missing handoff, then validate the pattern in the eligible population.",
      "caveat": "A task row is evidence about one fictional record, not prevalence. Costs are already preaggregated before the task join.",
      "spoken": "I would inspect one successful and one unresolved task to explain the mechanism, then return to the full denominator."
    },
    "Q16": {
      "decision": "Are inactive signups hidden by an event-only denominator?",
      "finding": "Forty-seven of 224 mature users have no recorded task: 12 developers, 19 marketers and 16 training users.",
      "action": "Separate missing intent, access/setup obstacles and expected low-frequency use through customer research.",
      "caveat": "No task is not automatically churn or dissatisfaction. Query from eligible users with a left join, rather than only observed task events.",
      "spoken": "I would keep zero-activity users visible and learn why they did not start before deciding that an onboarding prompt is the answer."
    },
    "Q17": {
      "decision": "Is subscription growth being sustained by existing customers?",
      "finding": "September closing MRR is $21,453.96 while NRR is about 95.9%; new MRR of $7,455 outweighs losses from the opening base.",
      "action": "Separate new acquisition from contraction/churn and investigate existing-account value.",
      "caveat": "MRR is a monthly stock, not cash. Do not sum closing MRR across months; NRR above 100% is a ratio, not a percentage-point gain.",
      "spoken": "I would separate new sales from existing-customer retention: growing total MRR can conceal a shrinking opening customer base."
    },
    "Q18": {
      "decision": "Does revenue cover the modeled full service burden?",
      "finding": "September service cash contribution is about $19,329; after the modeled R&D allocation the cash proxy is about $18,004.",
      "action": "Reconcile net cash, fees, task costs and shared costs before assessing a proposed investment.",
      "caveat": "This modeled cash contribution is not accounting profit, audited margin or all company overhead. It has a different grain from per-task costs.",
      "spoken": "I would evaluate economics with a period bridge, keeping cash, recurring revenue and allocated costs separate."
    },
    "Q19": {
      "decision": "Can the proposed model/version be released safely?",
      "finding": "In the paired multi-speaker slice, passes fall from 26/27 to 22/27 and critical errors rise from zero to one, despite gains in other slices.",
      "action": "Investigate the regressing slice and critical cases; define an explicit safety gate before any limited rollout.",
      "caveat": "Cases are held out and paired, but synthetic. Slice averages alone are not paired significance tests or representative production guarantees.",
      "spoken": "I would hold broad rollout: aggregate gains do not outweigh an unresolved multi-speaker regression and critical-error evidence."
    },
    "Q20": {
      "decision": "Can an automated judge safely replace independent review?",
      "finding": "The candidate judge misses three of 16 expert-labeled failures; the baseline judge misses four of 22.",
      "action": "Inspect false passes and keep independent review of high-risk cases before changing review coverage.",
      "caveat": "Failure recall is detected failures divided by all actual failures, not accuracy over all cases. Averages can hide severe false passes.",
      "spoken": "I would evaluate the failures the judge misses, not just its overall accuracy, before reducing human review."
    },
    "Q21": {
      "decision": "Which bounded opportunity is worth the next evidence step?",
      "finding": "Proposed engineering estimates range from 2.2 to 5.5 weeks. Version-bound locale review depends on entitlement clarity.",
      "action": "Validate the customer problem and dependency, then fund a bounded test with a named owner.",
      "caveat": "Effort and reach ranges are planning assumptions, not delivery commitments or measured demand. Do not add incompatible role-weeks into a single staffing promise.",
      "spoken": "I would choose the smallest justified bet with its dependency and evidence gate, rather than rank ideas by the largest optimistic reach."
    },
    "Q22": {
      "decision": "What evidence is required before release?",
      "finding": "All four proposed gates are unverified: duplicate-request behavior, critical terminology cases, stale approval invalidation and reconciled recovery.",
      "action": "Assign the engineering/domain/support owners and gather test evidence for each gate.",
      "caveat": "These are proposed readiness requirements, not failures observed inside DeepBrain. Unknown is not verified.",
      "spoken": "I would make the release decision conditional on the named tests, not treat a completed feature ticket as evidence that it is safe to ship."
    },
    "Q23": {
      "decision": "Is the main time bottleneck technical or organizational?",
      "finding": "Mean ready-to-review waits are about 30\u201332 hours and creation-to-confirmed-use means about 66\u201369 hours, far longer than median render minutes.",
      "action": "Study review queues, ownership and version handoffs while protecting quality; test against actual use time.",
      "caveat": "The review and use means use different selected subsets. They cannot be added into a stage-by-stage latency decomposition.",
      "spoken": "I would investigate the review handoff before assuming faster rendering is the highest-value latency improvement."
    },
    "Q24": {
      "decision": "Where does the recorded task journey actually stop?",
      "finding": "The default cohort has 877 recorded created-to-ready transitions and 204 created-to-last-recorded endpoints.",
      "action": "Inspect skipped checkpoints, endpoint records and review coverage before proposing a recovery change.",
      "caveat": "Last recorded is not proof of abandonment. Export and review may be parallel; these are task transitions, not unique users.",
      "spoken": "I would use the recorded path to choose an investigation, then check whether missing telemetry explains the apparent drop-off."
    },
    "N01": {
      "decision": "What changes when we choose a weaker value definition?",
      "finding": "In the complete week of 12 October, 28 accounts exported while 14 accounts had confirmed quality use.",
      "action": "Keep exports as a diagnostic and inspect quality-confirmation coverage before judging the gap.",
      "caveat": "This explorer uses the full frozen snapshot, unlike the operational May\u2013September default. Each definition anchors on its own event time.",
      "spoken": "I would distinguish distribution volume from confirmed audience value; a larger export count does not make it the better North Star."
    },
    "N02": {
      "decision": "Which measured handoff could explain the value gap?",
      "finding": "In the full snapshot, 80.2% of tasks rendered and 17% reached confirmed quality use; 68.3% of previews have reviews.",
      "action": "Inspect completion, review coverage and post-render workflow together.",
      "caveat": "These fractions have different denominators. They are candidate drivers, not multipliers that reproduce distinct-account value.",
      "spoken": "The task-level gap tells me where to investigate; it does not by itself tell me which intervention will cause account value to rise."
    },
    "N03": {
      "decision": "Which links are mathematical, observed or still hypothetical?",
      "finding": "The relationship table labels a fixed-population identity, a synthetic association and proposed causal links separately.",
      "action": "State the type of link before defending a metric tree.",
      "caveat": "No arrow has an estimated causal weight. Account-week arithmetic only works for exactly the same eligible account-week population.",
      "spoken": "I would make the metric relationships explicit and distinguish arithmetic from evidence about what causes customer behavior."
    },
    "J01": {
      "decision": "What paths do tasks take when checkpoints are optional or parallel?",
      "finding": "The flow uses actual timestamp order and retains direct links when intermediate events are absent.",
      "action": "Choose one endpoint and inspect J02 plus its Q15 records.",
      "caveat": "The flow excludes before-creation timestamps; it does not fabricate intermediate events or infer abandonment.",
      "spoken": "I would follow the observed path and ask what is unrecorded before turning a diagram into a product diagnosis."
    },
    "J02": {
      "decision": "Is the task flow trustworthy enough to act on?",
      "finding": "The full snapshot has zero before-creation chronology exclusions, 425 ready outputs without review, 193 tasks with a failed attempt and six recovered quality-use tasks.",
      "action": "Check review coverage and failure classes before comparing technical recovery with customer value.",
      "caveat": "Zero chronology exclusions does not establish complete instrumentation. The snapshot has more tasks than the operational default.",
      "spoken": "The audit tells me the bigger uncertainty is missing quality evidence and recovery-to-value, not a proven timestamp defect."
    },
    "G01": {
      "decision": "How does early exposure connect to later value?",
      "finding": "Of 224 mature signups, 12 have early selected value, 78 have an early task without it and 134 have no early filtered task.",
      "action": "Compare later return without removing the no-task group.",
      "caveat": "Workflow filters first-week exposure only. Later quality return includes any workflow and all mature persona signups remain eligible.",
      "spoken": "I would keep the entire mature signup cohort visible so that an attractive early-user result does not hide everyone who never started."
    },
    "G02": {
      "decision": "Does the early-value pattern persist within signup months?",
      "finding": "The August early-value group has one eligible user and no later return; the other August group has 44 users and six returns.",
      "action": "Read G03 denominators alongside the lines and compare another mature cohort.",
      "caveat": "Monthly grouping reduces one source of mix differences; it does not remove confounding or fix tiny cells.",
      "spoken": "I would not tell a retention success story from a line chart whose key segment contains one person."
    },
    "G03": {
      "decision": "How much confidence can we place in the cohort percentages?",
      "finding": "A one-user group with zero returns has a stored approximate standard error of zero.",
      "action": "Use a suitable small-sample interval, such as Wilson, and collect more eligible users before deciding.",
      "caveat": "A zero plug-in standard error at 0/1 is a mathematical artifact, not certainty. Account clustering further weakens simple independence assumptions.",
      "spoken": "I would lead with the count and flag that the zero error bar is misleading for a one-user segment."
    },
    "G04": {
      "decision": "Is more first-week activity associated with later return?",
      "finding": "The zero-task band has 134 users, while the four-plus-task band has only two and no later return.",
      "action": "Inspect individual rows and job frequency before prescribing more activity.",
      "caveat": "Each point is an aggregate band. More tasks may reflect difficulty or repeated repair, and correlation may be confounded.",
      "spoken": "I would not optimize task count simply because it is easy to increase; the outcome is repeated quality work."
    },
    "G05": {
      "decision": "Do early and later signals move together across comparable cohorts?",
      "finding": "Both weekly lines use the same mature signup-week users and expose eligible counts.",
      "action": "Look for repeatable patterns, then check acquisition/persona mix and the held-out result.",
      "caveat": "Shared time trends and partial edge weeks can produce a pattern without a causal relationship.",
      "spoken": "I would use this trend to generate a hypothesis, then test it on a later cohort before using it to steer the roadmap."
    },
    "G06": {
      "decision": "Are predicted return rates calibrated on unseen users?",
      "finding": "The early-value group predicts 30% return but has one held-out user and zero returns. The other group has 44 held-out users.",
      "action": "Keep the sparse group visible and inspect G07's baseline comparison.",
      "caveat": "Training uses earlier complete mature signup months; the latest complete mature month is held out. Tiny segments are unstable.",
      "spoken": "I would not operationalize a forecast whose most interesting held-out segment contains one person."
    },
    "G07": {
      "decision": "Does the signal actually improve prediction over a simple baseline?",
      "finding": "On the same 45 held-out users, signal Brier error is 0.117468 versus baseline 0.116467; the difference favors the baseline.",
      "action": "Retain the simpler forecast and investigate a better-defined signal on new held-out evidence.",
      "caveat": "Brier error is the average squared gap between a predicted probability and the actual 0-or-1 outcome; lower is better. Predictive accuracy is distinct from intervention impact. These fictional results are not company performance.",
      "spoken": "This signal does not beat the base-rate forecast in the practice data, so I would not claim predictive lift or causal improvement."
    },
    "G08": {
      "decision": "Can we explain the cohort denominator record by record?",
      "finding": "The analysis table has one row for each of the 224 mature signups, including no early filtered task.",
      "action": "Inspect one zero-exposure and one early-value row, then return to the population view.",
      "caveat": "No task in the selected early workflow differs from no activity anywhere. Account and user identifiers represent different units.",
      "spoken": "I would use a user row to explain eligibility and exposure, then make the decision at the appropriate account or cohort level."
    }
  },
  "steps": [
    {
      "id": "value",
      "title": "Choose the customer outcome",
      "question": "Are we counting useful work or just generated output?",
      "cards": [
        "Q01",
        "N01",
        "N02",
        "N03"
      ],
      "dashboards": [
        12,
        7,
        11
      ],
      "point": "Use weekly accounts with accepted, no-critical-error work and confirmed audience use as a proposed North Star. Keep review coverage beside it.",
      "say": "I would measure weekly accounts completing quality work that is actually used. Exports help diagnose delivery, but they do not establish audience value. I would validate confirmation coverage before interpreting a change.",
      "next": "Once the outcome is clear, find where the delivery-to-use journey needs investigation.",
      "links": [
        [
          "Customer jobs",
          "/product/"
        ],
        [
          "Canonical definitions",
          "/metrics/"
        ],
        [
          "Strategy choices",
          "/strategy/"
        ]
      ]
    },
    {
      "id": "journey",
      "title": "Find the limiting handoff",
      "question": "What should we improve first in the customer journey?",
      "cards": [
        "Q02",
        "Q07",
        "Q08",
        "Q23",
        "Q24",
        "J01",
        "J02"
      ],
      "dashboards": [
        8,
        13,
        10
      ],
      "point": "Ready latency is measured in minutes, while review and actual use take much longer in this fictional sample. Investigate workflow ownership and recovery before assuming compute is the main constraint.",
      "say": "I would investigate the post-render handoff first. Ready latency is minutes, while the selected review-to-use records show waits of hours or days. Those populations differ, so I would inspect the records and test review ownership before committing to a redesign.",
      "next": "A faster handoff is only valuable if the approved content is accurate and the customer has less repair work.",
      "links": [
        [
          "Workflow and operator roles",
          "/product/"
        ],
        [
          "Failure/recovery PRD",
          "/prd/"
        ],
        [
          "Task data grain",
          "/data/"
        ]
      ]
    },
    {
      "id": "quality",
      "title": "Protect quality and customer effort",
      "question": "Can we ship this improvement and reduce review safely?",
      "cards": [
        "Q06",
        "Q10",
        "Q19",
        "Q20"
      ],
      "dashboards": [
        10
      ],
      "point": "Do not let average pass rates or estimated time savings hide critical errors, a regressing slice or reviewer workload.",
      "say": "I would hold broad rollout until the multi-speaker regression and critical errors are understood. Other evaluation slices improve, but that does not resolve the failing customer case. I would work with engineering and domain reviewers on a bounded retest before reducing review coverage.",
      "next": "After protecting quality, ask whether more eligible customers reach and repeat the outcome.",
      "links": [
        [
          "Evaluation and release gates",
          "/prd/"
        ],
        [
          "Research limits",
          "/research/"
        ],
        [
          "Engineering-partnership SBI",
          "/answers/"
        ]
      ]
    },
    {
      "id": "return",
      "title": "Connect activation to repeat value",
      "question": "Does early value translate into later customer use?",
      "cards": [
        "Q03",
        "Q04",
        "Q05",
        "Q16",
        "G01",
        "G02",
        "G03",
        "G04",
        "G05",
        "G08"
      ],
      "dashboards": [
        9,
        14,
        8
      ],
      "point": "Keep mature signup users, including zero activity, in the denominator. Early-value association is a hypothesis to test, not an intervention result.",
      "say": "Early value is associated with later return in the practice data, but only 12 users are in the early-value group. I would keep inactive signups visible, check counts within cohorts and validate the pattern prospectively before saying onboarding caused better retention.",
      "next": "A promising association must survive a held-out prediction test, and any product intervention needs a valid unit of assignment.",
      "links": [
        [
          "Activation and return definitions",
          "/metrics/"
        ],
        [
          "Prioritization drills",
          "/practice/"
        ],
        [
          "Acquisition and zero-activity exercises",
          "/exercises/"
        ]
      ]
    },
    {
      "id": "evidence",
      "title": "Challenge the apparent success story",
      "question": "How do we know the signal or experiment is trustworthy?",
      "cards": [
        "Q13",
        "G06",
        "G07"
      ],
      "dashboards": [
        14,
        8
      ],
      "point": "The early signal slightly underperforms a simple held-out base-rate forecast. Mixed variants within team accounts also limit an account-level experiment claim.",
      "say": "I would not claim predictive lift here. On the same 45 held-out users, the signal has slightly higher Brier error than the base-rate prediction. I would keep the simpler forecast and improve the evidence. An intervention would need account-level assignment to avoid team contamination.",
      "next": "Even a valid customer improvement must make economic sense without shifting hidden work or risk to someone else.",
      "links": [
        [
          "Observed versus proposed evidence",
          "/research/"
        ],
        [
          "Data and assignment contracts",
          "/data/"
        ],
        [
          "Rollout design",
          "/prd/"
        ]
      ]
    },
    {
      "id": "economics",
      "title": "Connect value to sustainable economics",
      "question": "Should we change price, cost structure or acquisition spend?",
      "cards": [
        "Q09",
        "Q11",
        "Q12",
        "Q14",
        "Q17",
        "Q18"
      ],
      "dashboards": [
        10,
        9
      ],
      "point": "Separate customer labor, vendor costs, resource meters, recurring revenue and cash. Growing MRR can coexist with erosion of the opening customer base.",
      "say": "I would separate new sales from existing-customer value. September MRR grows in the fictional data while NRR is below 100 percent. Before scaling acquisition, I would inspect renewal causes and full service costs, including the support and review work that dominates this model.",
      "next": "Turn the diagnosis into one bounded opportunity with explicit dependencies and release evidence.",
      "links": [
        [
          "Economics and units",
          "/economics/"
        ],
        [
          "Buyer and pricing research",
          "/product/"
        ],
        [
          "Commercial metric definitions",
          "/metrics/"
        ]
      ]
    },
    {
      "id": "decision",
      "title": "Make one bounded product decision",
      "question": "What would you actually do next, and what would change your mind?",
      "cards": [
        "Q21",
        "Q22",
        "Q15"
      ],
      "dashboards": [
        7
      ],
      "point": "Use task evidence and customer research to choose a limited review/recovery test. Proposed effort ranges and unverified gates are planning records, not accomplished outcomes.",
      "say": "My proposed next step is a bounded test of review ownership and version-safe approval. I would validate the missing handoff with customers, work with engineering and domain reviewers on the dependency and critical cases, and expand only if confirmed use improves without more errors, workload or cost.",
      "next": "Stop after the recommendation and success test. Let the interviewer choose the next level of detail.",
      "links": [
        [
          "Bounded localization PRD",
          "/prd/"
        ],
        [
          "Strategy stack",
          "/strategy/"
        ],
        [
          "Personal evidence map",
          "/evidence/"
        ]
      ]
    },
    {
      "id": "speak",
      "title": "Explain it clearly, then stop",
      "question": "Can you extract the main point without narrating every dashboard?",
      "cards": [],
      "dashboards": [
        11
      ],
      "point": "One takeaway, one caveat, one action. Use historical SBI only for your real experience; these tables support hypothetical decision practice.",
      "say": "I would prioritize the handoff from generated video to reviewed audience use. The practice data suggest that human review and recovery deserve investigation, but they do not prove the cause. I would test one bounded change with customer-use, quality, workload and cost measures.",
      "next": "STOP. If asked for your experience, choose one sourced Rakuten, Edugo or KidsLoop example from the answer bank.",
      "links": [
        [
          "20\u201330-second and 60\u201390-second SBI answers",
          "/answers/"
        ],
        [
          "Sourced ownership and limits",
          "/evidence/"
        ],
        [
          "Practice rubric and stopping rule",
          "/practice/"
        ]
      ]
    }
  ]
}