# Model answers — separate from personal practice

Every numerical result is synthetic practice, not DeepBrain performance. These are decision starting points, not uniquely correct answers.

## E01 · Choose the value unit

**Decision:** Should the North Star count accounts, people, minutes or exports?

**Readout:** Compare DB01 account reach with task volume and confirmation coverage.

**Actual query output (synthetic), first rows:**

|week_start|value_accounts|confirmed_tasks|
|---|---|---|
|2026-05-11|1|1|
|2026-05-18|3|3|
|2026-05-25|3|3|

**Model spoken answer:** I would track accounts receiving confirmed quality value, with coverage and cost beside the count.

**Caveat/counterargument:** Would one large account or repeated locale versions distort the story? Filters use date, unlike task cards. Only whole UTC weeks fully inside the selected date range and ended before cutoff are included. Missing confirmations limit interpretation.

**Next evidence:** Confirm account identity, repeated job frequency and use-confirmation method.

**Deliberately left out:** Minute totals, because they measure production load rather than which accounts received value.

## E02 · Find the important handoff

**Decision:** Which stage deserves the next investigation?

**Readout:** Use created tasks as the common denominator, then separate parallel review/export paths.

**Actual query output (synthetic), first rows:**

|workflow|created|eligible|rendered|previewed|exported|reviewed|accepted|distributed|used|
|---|---|---|---|---|---|---|---|---|---|
|api_template|390|361|329|289|222|187|149|96|79|
|document_avatar|373|351|307|257|201|172|132|86|62|
|dubbing|318|291|241|216|169|158|111|57|43|

**Model spoken answer:** I would investigate the largest verified loss of useful work, then test one recovery change.

**Caveat/counterargument:** Could an expected rights or plan block explain the gap? Review and export are parallel checkpoints; do not force them into a strictly ordered funnel.

**Next evidence:** Inspect real traces and task sessions; validate missing events before naming a defect.

**Deliberately left out:** An explanation of every possible stage and model; the decision needs one verified bottleneck.

## E03 · Defend activation

**Decision:** What qualifies as a first useful result?

**Readout:** Count users, retain mature zero-task signups and require review/use before day seven.

**Actual query output (synthetic), first rows:**

|persona|eligible_users|activated_users|activation_pct|
|---|---|---|---|
|developer|94|8|8.51063829787234|
|marketing|93|4|4.301075268817205|
|training|93|6|6.451612903225806|

**Model spoken answer:** I would use first-week confirmed value among all eligible signups and report the missing-review limit.

**Caveat/counterargument:** Does a late review leak future information into the first week? All mature signups, including zero-task users. Workflow filter means primary intended workflow.

**Next evidence:** Confirm whether users, accounts or invited seats are the right production denominator.

**Deliberately left out:** Generated-video counts, which use task grain rather than user activation.

## E04 · Mature repeat value

**Decision:** Which cohort merits customer-success investigation?

**Readout:** Use the complete days 28–41 window, counts and cohort mix.

**Actual query output (synthetic), first rows:**

|cohort_month|eligible_users|returning_users|return_pct|
|---|---|---|---|
|2026-05-01|52|5|9.615384615384617|
|2026-06-01|51|14|27.450980392156865|
|2026-07-01|56|7|12.5|

**Model spoken answer:** I would investigate mature cohorts with weak repeat value, after checking their job frequency and coverage.

**Caveat/counterargument:** Are later cohorts censored or jobs naturally infrequent? Unconditional signup return during days 28–41, not retention conditional on activation.

**Next evidence:** Interview returning and nonreturning users about need frequency and unobserved offline use.

**Deliberately left out:** A claim that return equals satisfaction or learning.

## E05 · Signal versus cause

**Decision:** Does activation cause later return?

**Readout:** Explain the association and a future account-randomized intervention.

**Actual query output (synthetic), first rows:**

|early_value|mature_users|later_return|return_pct|
|---|---|---|---|
|0|212|31|14.622641509433961|
|1|12|3|25.0|

**Model spoken answer:** Early value is associated with later return in this fictional panel; I would test a specific onboarding change before claiming causality.

**Caveat/counterargument:** Could initial intent or account mix cause both? Descriptive association; intent, account mix and confirmation coverage may explain it.

**Next evidence:** Assignment unit, sample/power, coverage and a disconfirming test.

**Deliberately left out:** Predicted-minus-observed residuals as a supposed causal estimate.

## E06 · Quality evidence first

**Decision:** Can reviewed acceptance justify expansion?

**Readout:** Read review coverage, acceptance and critical-error counts together.

**Actual query output (synthetic), first rows:**

|workflow|tasks|previews|reviewed|coverage_pct|acceptance_pct|critical_errors|
|---|---|---|---|---|---|---|
|api_template|390|289|187|64.70588235294117|79.67914438502673|9|
|document_avatar|373|257|172|66.92607003891051|76.74418604651163|11|
|dubbing|318|216|158|73.14814814814815|70.25316455696202|11|

**Model spoken answer:** I would not extrapolate reviewed acceptance until I understand missing reviews and critical failure slices.

**Caveat/counterargument:** Who did not review, and why? Reviewed acceptance is selected; missing review remains unknown.

**Next evidence:** Representative bilingual labels, sampling mechanism and hard-case evidence.

**Deliberately left out:** A platform-wide accuracy claim from selected reviews.

## E07 · Latency without arithmetic errors

**Decision:** Should the team reduce queue time or reviewer wait?

**Readout:** Compare root ready latency with completion and Q23 human wait.

**Actual query output (synthetic), first rows:**

|workflow|completed_tasks|p50_seconds|p95_seconds|
|---|---|---|---|
|api_template|329|388.0000278353691|1363.0000099539757|
|document_avatar|307|419.0000206232071|1320.9999963641167|
|dubbing|241|378.0000016093254|1310.0000157952309|

**Model spoken answer:** I would measure whole-task latency and completion first; component p95 values cannot simply be added.

**Caveat/counterargument:** Are incomplete slow tasks excluded? Creation to visible-ready includes wait/retry. Completer-only; inspect non-completion in Q02. Not sum of component p95.

**Next evidence:** Trace spans, timeouts and status UI observations across comparable workloads.

**Deliberately left out:** A promised service-level target without real baseline or load evidence.

## E08 · Recover value safely

**Decision:** Which recovery should be built first?

**Readout:** Compare tasks with failures, recovered renders and recovered useful tasks.

**Actual query output (synthetic), first rows:**

|workflow|tasks|tasks_with_failed_attempt|recovered_to_render|recovered_to_value|retried|unfinished_eligible|
|---|---|---|---|---|---|---|
|api_template|390|44|12|2|13|32|
|document_avatar|373|54|10|3|11|44|
|dubbing|318|57|7|1|10|50|

**Model spoken answer:** I would choose recovery by useful work restored, while checking duplicate charges and total retries.

**Caveat/counterargument:** Does render recovery actually restore use? All failures mature at cutoff except latest-day tasks excluded by generator; recovery-to-render differs from customer value.

**Next evidence:** Failure eligibility, customer intent, observation window and debit reconciliation.

**Deliberately left out:** A low retry rate presented as automatically good.

## E09 · Cost of useful work

**Decision:** What changes cost per useful result most?

**Readout:** Include failed/nonmonetized attempts and compare all service scopes.

**Actual query output (synthetic), first rows:**

|workflow|tasks|useful_tasks|direct_vendor_usd|usd_per_confirmed_use|
|---|---|---|---|---|
|api_template|390|79|1244.62214|15.754710632911392|
|document_avatar|373|62|1075.3534319999999|17.344410193548384|
|dubbing|318|43|973.881924|22.648416837209304|

**Model spoken answer:** I would reduce the verified cost driver per useful task, with quality and full period cost as guardrails.

**Caveat/counterargument:** Does low confirmation coverage inflate the denominator problem? Includes all selected task costs incl failures; excludes period allocations, shown separately Q18. Review is vendor fraction; customer time separate.

**Next evidence:** Real invoices, provider rates, vendor/customer labor split and stable use-confirmation sampling.

**Deliberately left out:** Calling the direct-cost ratio gross margin.

## E10 · Review burden

**Decision:** Does fast production save customer time?

**Readout:** State preparation, review and repair separately; net estimate is not causal savings.

**Actual query output (synthetic), first rows:**

|workflow|reviewed_tasks|prep_minutes|review_minutes|repair_minutes|estimated_net_minutes|
|---|---|---|---|---|---|
|api_template|187|7.591871657754011|12.856256684491978|10.337272727272726|88.73106951871657|
|document_avatar|172|7.785697674418605|12.92029069767442|11.522441860465115|124.84831395348837|
|dubbing|158|7.384050632911393|14.000316455696204|13.926645569620252|94.23981012658227|

**Model spoken answer:** Faster rendering helps only if total customer work falls; I would measure preparation, review and repair.

**Caveat/counterargument:** Is the manual baseline measured or estimated? Manual baseline is an invented estimate; net time is not causal savings.

**Next evidence:** Matched same-task baseline, quality parity and downstream workload.

**Deliberately left out:** A causal productivity percentage based on an invented baseline.

## E11 · Hidden cost driver

**Decision:** Which operational cost deserves attention?

**Readout:** Rank dollar components, not summed heterogeneous units.

**Actual query output (synthetic), first rows:**

|component|units|unit|cost_usd|
|---|---|---|---|
|support|3871.66|staff_minute|2129.413|
|vendor_review|1554.456|staff_minute|1010.3964|
|render_compute|343760.0|compute_second|110.0032|

**Model spoken answer:** I would investigate the largest avoidable cost component and protect the quality of support.

**Caveat/counterargument:** Would suppressing support tickets only hide work? Do not add heterogeneous units; quantity and rate remain component-specific.

**Next evidence:** Support resolution quality, invoice reconciliation and utilization assumptions.

**Deliberately left out:** Raw unit counts across seconds, GB and staff minutes.

## E12 · Explain three meters

**Decision:** How should a failed job settle usage?

**Readout:** Reconcile reserved=consumed+released+outstanding within each meter.

**Actual query output (synthetic), first rows:**

|meter|reserved|consumed|released|outstanding|tasks|
|---|---|---|---|---|---|
|avatar_video_count|582.0|522.0|60.0|0.0|624|
|dubbing_minute|1687.9|1426.4|261.5|0.0|318|
|generative_credit|130.0|114.0|16.0|0.0|139|

**Model spoken answer:** I would show customers the relevant meter and reconcile each failed task exactly once.

**Caveat/counterargument:** Could a retry create a duplicate debit? Illustrative entitlement model, not claimed production billing. Never sum minute/credit/count units.

**Next evidence:** Actual plan/contract rules, event dedup and failure-settlement tests.

**Deliberately left out:** Adding generative credits to dubbing minutes as if they were one unit.

## E13 · Reject a bad experiment readout

**Decision:** Can the apparent variant difference support rollout?

**Readout:** Q13 counts mature accounts with mixed seat assignments; inspect this interference before inference.

**Actual query output (synthetic), first rows:**

|mature_accounts|mixed_variant_accounts|interference_rate|eligible_seats|
|---|---|---|---|
|167|35|0.20958083832335328|280|

**Model spoken answer:** I would reject a causal conclusion here because seat assignment can mix variants inside a team account.

**Caveat/counterargument:** Are team members exposed to both variants? This lab assigns users, so team accounts can have mixed variants. This audit is not a causal comparison; fix assignment before inference.

**Next evidence:** Account-level assignment and actual exposure, preregistered success and harm criteria.

**Deliberately left out:** A ship recommendation based only on a favorable point estimate.

## E14 · Growth worth buying

**Decision:** Which channel deserves the next experiment?

**Readout:** Use mature, matched cost and activated-user cohorts; do not call this paying-account CAC.

**Actual query output (synthetic), first rows:**

|channel|eligible_users|activated_users|later_users|allocated_spend|usd_per_activated|
|---|---|---|---|---|---|
|partner|73|3|11|3755.97|1251.99|
|sales|72|4|14|3948.94|987.235|
|search|79|5|9|3990.01|798.0020000000001|

**Model spoken answer:** I would test a channel on useful activation and later value, not scale it on cheap signups alone.

**Caveat/counterargument:** Does channel intent or sales assistance explain activation? Allocated synthetic spend; all users have 42-day follow-up here. Not CAC per paying account or causal channel performance.

**Next evidence:** Paying-account linkage, channel attribution, incremental acquisition test and retention.

**Deliberately left out:** Unverified LTV/CAC benchmarks and a channel winner claim.

## E15 · Trace the evidence

**Decision:** Which records support your recommendation?

**Readout:** Inspect one task per row and follow its review/use/cost IDs.

**Actual query output (synthetic), first rows:**

|task_id|user_id|account_id|persona|workflow|created_at|render_success|reviewed_at|accepted|confirmed_use_at|confirmed_quality_use|direct_vendor_usd|
|---|---|---|---|---|---|---|---|---|---|---|---|
|1|1|1|training|document_avatar|2026-08-27 13:30:00|1||||0|0.08607999999999999|
|2|1|1|training|document_avatar|2026-08-31 06:13:00|1||||0|0.07039999999999999|
|3|1|1|training|document_avatar|2026-09-19 22:44:00|1|2026-09-20 09:56:24|1|2026-09-22 15:56:24|1|1.98572|

**Model spoken answer:** I would show the supporting task records and keep their grain explicit before defending the aggregate.

**Caveat/counterargument:** Do rows duplicate users, accounts or money? Fictional task IDs; no customer identity or private payload.

**Next evidence:** Real event provenance and task-version integrity.

**Deliberately left out:** A tour of every field instead of the evidence that changes the decision.

## E16 · Include never-starters

**Decision:** Whose absence is hidden by active-user charts?

**Readout:** Retain zero-task mature users and avoid assigning a cause from absence.

**Actual query output (synthetic), first rows:**

|persona|eligible_users|zero_task_users|
|---|---|---|
|developer|79|12|
|marketing|74|19|
|training|71|16|

**Model spoken answer:** I would include never-starters in the denominator and ask what job they expected to do.

**Caveat/counterargument:** Could an invitation be intended only for review? No task does not identify the cause; no session instrumentation in this lab.

**Next evidence:** Role/intent and consented nonstarter research; session events if necessary.

**Deliberately left out:** Assumed churn reasons and demographic profiling.

## E17 · Commercial retention

**Decision:** Is rising MRR healthy?

**Readout:** Reconcile opening+new+expansion-contraction-churn=closing; inspect GRR/NRR.

**Actual query output (synthetic), first rows:**

|month|opening_mrr|new_mrr|expansion|contraction|churn|closing_mrr|grr|nrr|
|---|---|---|---|---|---|---|---|---|
|2026-05|0.0|3840.0|0.0|0.0|0.0|3840.0|||
|2026-06|3840.0|3831.0|10.8|0.0|690.0|6991.8|0.8203125|0.823125|
|2026-07|6991.8|4701.0|148.8|312.0|252.0|11277.6|0.9193340770617009|0.94061615034755|

**Model spoken answer:** I would separate new sales from existing-account retention before calling recurring growth healthy.

**Caveat/counterargument:** Does new revenue hide losses among existing accounts? Full calendar months only; exclude October partial. Normalized fictional subscription MRR; not cash or actual price tiers.

**Next evidence:** Actual contracts, renewals, logo loss, refunds and accounting policy.

**Deliberately left out:** Treating MRR as cash or adding one-off usage purchases.

## E18 · Full economics

**Decision:** Can the service sustain this workload?

**Readout:** Preaggregate billing, task costs and period allocations separately before joining month.

**Actual query output (synthetic), first rows:**

|month|net_cash|payment_fee|direct_usd|service_allocated|rd|service_cash_contribution|after_rd_cash_proxy|
|---|---|---|---|---|---|---|---|
|2026-05|3835.95|111.36|205.595464|366.52|1164.58|3152.4745359999997|1987.8945359999998|
|2026-06|6986.94|202.7622|608.602736|279.27|1347.57|5896.305064|4548.735064|
|2026-07|11032.8|327.0505|754.062304|347.08000000000004|1399.86|9604.607195999999|8204.747195999998|

**Model spoken answer:** I would present the service cash-contribution proxy with its exclusions, not call it profit.

**Caveat/counterargument:** Which costs and cash timing remain excluded? Not recognized gross margin or profit; customer labor, acquisition and unmodeled overhead excluded. Task-cost month is task creation convention.

**Next evidence:** Acquisition, overhead, recognition policy and provider commitments.

**Deliberately left out:** A precise company margin estimate from practice numbers.

## E19 · Candidate release

**Decision:** Does a better average justify deployment?

**Readout:** Pair heldout source cases and inspect critical errors, latency and cost by slice.

**Actual query output (synthetic), first rows:**

|slice|candidate|cases|passes|pass_rate|critical_errors|mean_cost_usd|mean_latency_seconds|
|---|---|---|---|---|---|---|---|
|long_scene|baseline|27|21|0.7777777777777778|0|0.4110370370370371|429.3333333333333|
|long_scene|candidate|27|26|0.9629629629629629|1|0.42362962962962963|382.22222222222223|
|multi_speaker|baseline|27|26|0.9629629629629629|0|0.2922592592592593|320.8888888888889|

**Model spoken answer:** I would hold a candidate with unresolved critical failures even if its average score improves.

**Caveat/counterargument:** Does a critical slice get worse? Fictional paired cases, not actual model output; no real release evidence.

**Next evidence:** Rights-cleared real media, independent bilingual labels and source-isolated split.

**Deliberately left out:** Synthetic pass rates as proof of real model superiority.

## E20 · Trust an automated judge?

**Decision:** Should automated review replace bilingual checks?

**Readout:** Compute failure-detection recall and false alarms; inspect critical misses.

**Actual query output (synthetic), first rows:**

|candidate|cases|true_failure_detected|missed_failure|false_alarm|true_pass|
|---|---|---|---|---|---|
|baseline|108|18|4|7|79|
|candidate|108|13|3|5|87|

**Model spoken answer:** I would calibrate the judge against domain reviewers and retain human review where missed errors matter.

**Caveat/counterargument:** How many important failures did the judge miss? Synthetic labels; compute failure recall, inspect slices and critical misses before using a live blocking judge.

**Next evidence:** Real adjudicated labels, agreement slices and operational false-positive costs.

**Deliberately left out:** A single judge pass score as sufficient release evidence.

## E21 · Choose feasible scope

**Decision:** Which opportunity fits actual capacity?

**Readout:** Account for dependencies and separate engineering, design and review weeks.

**Actual query output (synthetic), first rows:**

|opportunity_id|name|eng_weeks|design_weeks|review_weeks|dependency|low_reach|high_reach|source_id|
|---|---|---|---|---|---|---|---|---|
|OP1|Explain entitlements before render|2.2|1.1|0.3||50|180|PLAN|
|OP3|Webhook recovery and reconciliation|3.3|0.4|0.6||15|85|PLAN|
|OP2|Version-bound locale review|4.1|1.5|1.4|OP1|30|120|PLAN|

**Model spoken answer:** I would fund one bounded workflow and name what is deferred, after checking all constrained roles.

**Caveat/counterargument:** What if reviewer capacity, not engineering, is binding? Proposed estimates, no effect size or confidence probability; high reach is not a forecast.

**Next evidence:** Actual capacity, range estimates, demand evidence and opportunity cost.

**Deliberately left out:** Treating person-weeks as a calendar completion promise.

## E22 · Release versus readiness

**Decision:** Which missing gate prevents pilot?

**Readout:** All gate states are unverified; name the evidence and accountable role.

**Actual query output (synthetic), first rows:**

|gate_id|requirement_id|owner_role|test|state|source_id|
|---|---|---|---|---|---|
|G1|FR1|Engineering|duplicate request returns one task and one debit|unverified|PLAN|
|G2|FR2|Domain reviewer|number and terminology critical cases pass|unverified|PLAN|
|G3|FR3|Engineering|edit invalidates prior approval|unverified|PLAN|

**Model spoken answer:** The specification is ready for review, but a pilot needs real acceptance evidence and owner approval.

**Caveat/counterargument:** Does a well-written test count as a passed test? All proposed gates unverified; no actual product release performed.

**Next evidence:** Actual test results, support readiness, approval and rollback drill.

**Deliberately left out:** A launch claim based on artifact completion.

## E23 · One elapsed-time story

**Decision:** Where is the customer's real wait?

**Readout:** Distinguish ready-to-review wait, active work and total time to use.

**Actual query output (synthetic), first rows:**

|workflow|reviewed_tasks|mean_ready_to_review_hours|useful_tasks|mean_created_to_use_hours|
|---|---|---|---|---|
|api_template|187|32.44099821773841|79|66.58607594980091|
|document_avatar|172|31.537596898738208|62|66.29142025053021|
|dubbing|158|30.0413502110522|43|69.23625323089749|

**Model spoken answer:** I would compare machine and human waiting before investing in faster inference.

**Caveat/counterargument:** Are unconfirmed long tasks censored? Different completed populations in each duration; missing review/use may censor long waits.

**Next evidence:** Incomplete durations, reviewer staffing and end-to-end observation.

**Deliberately left out:** Adding mean waits from different task populations.

## E24 · Explain recorded paths

**Decision:** Where does the last recorded step occur?

**Readout:** Use timestamp-ordered edges and conservation; review/export can swap order.

**Actual query output (synthetic), first rows:**

|source|target|tasks|
|---|---|---|
|created|last_recorded|204|
|created|ready|877|
|distributed|last_recorded|55|

**Model spoken answer:** The paths show the last recorded checkpoint, not why someone stopped; I would inspect the handoff before naming abandonment.

**Caveat/counterargument:** Are skipped events instrumentation gaps or true behavior? Ordered by actual timestamps; review/export can occur in either order. Last recorded is not proven abandonment.

**Next evidence:** Observed task traces and missing event tests.

**Deliberately left out:** A claim that every terminal node represents churn.