SELFPATCH

English · Türkçe

How SelfPatch chooses a realistic next action

SelfPatch is designed around a simple constraint: a useful self-improvement plan has to fit the person and the time they actually have today. Instead of starting with an empty checklist, SelfPatch matches a structured task pool against user context and returns a small set of actions with a human-readable reason.

Inputs used for automated task selection

Current task selection can use the following product inputs:

• Onboarding answers and goals: the areas a person wants to improve and the context supplied during setup.
• Constraints: information supplied by the user that affects which actions are appropriate.
• Available daily time: the minutes a person says they can realistically commit that day.
• Module progression: the user's current level/progression inside the relevant life module.
• Recent behaviour: what the person has recently been doing inside the product.

Time is a hard practical filter

SelfPatch supports public task windows such as 5, 10, 15, 20, 30 and 45 minutes, plus an exact-minute option. A task that does not fit the committed time should not become the day's recommendation simply because it is theoretically useful. Time filtering is part of the product's attempt to keep the plan executable.

A structured pool, not generated filler

The current public website snapshot contains 1,277 tasks organised across 8 life modules and 25 improvement paths. Automated guidance selects from this structured product pool rather than asking the user to invent every habit from scratch.

The choice is explained

A selected task is not meant to appear as an unexplained black-box decision. The task card shows a human-readable reason for why the task was picked. This explanation is part of the product interface, not a separate SEO claim.

Completion changes the context

Completing actions contributes to SelfPatch progression through XP, levels, ranks and streaks. Recent behaviour and module progression can then become part of the context used for later automated choices. Progress is therefore not only a score display; it is part of the evolving user context.

What changes when mentorship begins

For a selected module and mentorship period, SelfPatch changes authorship rather than pretending the automated selector is still in control. The algorithm stops assigning those module tasks and the mentor writes them. The dedicated SelfPatch Mentorship source explains templates, repeat plans, reporting, consent controls and access boundaries.

Privacy boundaries

Google sign-in uses the basic OpenID scopes openid, email and profile. SelfPatch does not request Gmail, Drive, Calendar or Contacts access for task selection. Optional mentor sharing is controlled separately by the user. See the Privacy Policy for the complete data-handling terms.

What this methodology does not claim

• It does not claim that every recommendation is universally optimal.
• It does not replace professional medical diagnosis or treatment.
• It does not mean every SelfPatch feature uses the same inputs in the same way.
• It does not turn mentor-authored tasks into algorithmic recommendations; mentorship is a separate authorship mode.

Why publish this?

SelfPatch asks users to act on a recommendation, so the basis of that recommendation should be understandable at product level. This page documents the public selection model so users, reviewers, journalists and answer engines can distinguish the mechanism from a generic habit checklist or an unexplained “AI coach” claim.