LifeQuest replaced the generic completion checkbox because different quests produce different kinds of credible evidence. A workout photo, elapsed focus time, a qualifying GitHub push, and an honest self-report each answer a different question about what happened.
In April 1970, Apollo 13 astronauts Jim Lovell, Jack Swigert, and Fred Haise faced rising carbon dioxide inside the lunar module. The command module carried square lithium hydroxide canisters, while the lunar module used round ones. The crew had filters, but the available parts did not fit the system keeping them alive.
At Mission Control in Houston, engineer Ed Smylie and his team worked with materials already available aboard the spacecraft. They devised an adapter using items including plastic bags, cardboard, and duct tape, then relayed the assembly instructions to the crew. NASA documents the episode in its Apollo 13 history, and Lovell and Jeffrey Kluger recount it in Lost Moon.
The lesson was painfully physical: a useful component still fails when it does not fit the job in front of it.
One checkbox was trying to answer four different questions
A generic “Complete” button looks clean. It also collapses every real-world activity into the same unsupported claim.
Did someone finish a 25-minute study block? Did they push code after creating a programming quest? Does a camera image plausibly show the result of a craft session? Did they complete something meaningful that cannot reasonably be photographed or measured?
Those questions require different evidence. Treating them as interchangeable weakens the entire progression system. A checkbox can record intent, but it cannot distinguish between a quick tap and work that left a relevant trace.
LifeQuest therefore matches completion methods to the quest. Suitable quests can offer photo proof, a server-timed focus session, GitHub verification, or self-report. The available choices depend on what can genuinely support the claim.
That is the bridge from Apollo 13 to a real-life RPG. The problem was never a lack of parts. The parts had to connect correctly. In LifeQuest, evidence only becomes useful when the verification method fits the activity.
Full XP follows evidence that fits the work
Each full-XP method is built around a specific kind of signal.
Photo proof uses the in-app camera and sends the image for AI plausibility review. It can support quests where a visible result makes sense, such as a completed craft or a physical setup. Acceptance means the image was judged plausible for the quest. It does not mean the system is fraud-proof, and it does not turn an image into certainty.
Focus sessions use elapsed server time. The visible countdown is not trusted as the source of truth, so changing a device-side counter cannot manufacture the required duration. This makes the method appropriate for focused work where time spent is the relevant evidence. What can a server-timed focus session actually prove? examines that boundary in more detail.
GitHub verification fits coding quests in the Craft domain. LifeQuest checks for a qualifying public push made after the quest was created. A push from last week cannot prove today’s quest, and a username alone cannot prove that new work happened.
These methods are intentionally narrow. Photo review should not pretend to measure study time. A timer should not claim that a workout had good form. A GitHub push has no useful connection to a Social quest.
Honest self-report stays available
Some worthwhile goals leave no practical evidence. A difficult conversation, a private reflection, or a small act of courage may matter deeply while producing nothing suitable for a camera, timer, or public activity feed.
LifeQuest keeps self-report available for those cases. The user can complete any suitable quest by honestly reporting it and receive half XP.
That reduced award preserves two ideas at once. The work still counts, and stronger evidence earns a clearer distinction. Self-report is an escape from rigid verification without becoming identical to verified completion.
The product also keeps coaching separate from proof. A user can record up to 60 seconds of exercise or craft form and receive asynchronous AI feedback with a summary, cues, and concerns. That coaching clip cannot award XP because feedback about form does not establish quest completion. Squat Form Check: Why Eli’s Coaching Clip Could Not Award XP explains why that separation matters.
Design the evidence before awarding the points
The practical design test is simple: identify what a quest claims, then ask what signal could honestly support that claim.
If duration matters, measure duration from a trusted clock. If a new code contribution matters, look for an event created after the quest began. If the outcome is visible, request a current camera image and describe the review modestly. If none of those methods fit, let the user say they did it and label the reward accordingly.
Apollo 13’s carbon dioxide problem was solved when Smylie’s team connected incompatible parts with an adapter designed for the actual constraints aboard the spacecraft. LifeQuest applies the same discipline at much lower stakes: choose the connection that fits, state what it can establish, and never make one convenient input pretend to prove everything.
Comments
No comments yet.