AI-Native Series ยท The Visionboard
Life GPS, 2019 โ 2026: What the First Planner Got Right, What Killed It, and the Three Organs an AI-Native Rebuild Adds
1-minute takeaway โ what you'll walk away with
What this is. The origin episode. Life GPS was a planner I wrote in R in April 2019: you give it tasks with weights, floors and ceilings, it packs your week as a binary integer program, and when Tuesday goes sideways it freezes the past and re-solves the rest. I re-ran that exact code today on my 2026 goals, and then asked why something that worked was abandoned.
Why it matters. If you have ever built a plan that died by Wednesday, the diagnosis here is transferable: the planner was correct and the loop still died, because one person was the sensor, the executor and the judge. Franklin hit the same wall in 1726. For an engineer, the episode names the three feeds an AI-native rebuild has to supply and shows the one it must never automate.
What you can do. Run your own week through the 12-line example below (the code is public, MIT). Then check which of the three organs you are still hand-cranking. That is the one that will kill your loop.
The Visionboard โ the series spine
- The Visionboard: Life GPS rebuilt with the human above the loop episode 1
- Life GPS, 2019 โ 2026: what the first planner got right and what killed it this episode
- Life GPS for one person: the daily director's act, and where the agent may not go next
- Life GPS for a small team: roles not persons, load as a constraint episode 4
- The Visionboard scoreboard: what moved, what did not, and three futures with falsifiers episode 5
What Life GPS was, who this episode is for, and why the origin matters
Every design in this series descends from one small program. Before the Visionboard's agents, tripwires and signatures make sense, you need to see the thing they were bolted onto, and you need to see it fail for the right reason. That is this episode's job. It is the history and the autopsy, and it is for three readers: the student who wants to see a real optimizer applied to a real week, the engineer who wants the exact constraint set, and the founder who has watched a good system die of neglect and wants a name for the cause.
Life GPS was born in April 2019. Six years later I described the moment in the company-scale article: I was drowning, too many things to learn and too few hours, and every rigid weekly plan died by Wednesday. So I built a small app to fix me. The pitch was a car's satnav: it does not re-read the whole map when you miss a turn, it says "here is your next best move from where you actually are." The code was R and Shiny, and it sat on GitHub with a Medium write-up. In July 2026 I ported it to Python, unchanged in its brain, so that it could be a library and an API instead of a form.
Here is the claim the episode has to earn: the 2019 program was correct, and correctness was not enough. First the picture, then the proof, then the autopsy.
One picture: cooking for yourself, with a very good shopping list
The bottom rung of the cooking ladder is cooking for yourself. You decide what matters this week (protein, something green, one treat), how much of each you need (at least three dinners with vegetables, no more than one dessert), and you shop once. Then Tuesday happens: you get home late, the chicken goes uncooked, and the plan for Wednesday is now wrong. A good cook does not throw the week away. They look at what is still in the fridge and re-plan the remaining meals from there.
Life GPS is that cook's shopping list turned into a solver, and its one clever move is the re-plan. The map is one-to-one.
| Cooking for yourself | Life GPS handle (2019 R, 2026 Python) |
|---|---|
| What matters this week, and how much | a Task with weight, min_hours, max_hours, optional min_daily / max_daily / deadline_hour |
| The week's meal slots | hour-slots; decision variable x[slot, task] โ {0, 1} |
| Fill the fridge with the most of what matters | maximise ฮฃ (hours on task รท max hours) ร scaled weight โ a perfect week scores 100 |
| You cannot cook two dinners in one slot | constraint C3: at most one task per hour-slot |
| At least three vegetable dinners, at most one dessert | C1/C2 weekly floor and cap per task; C6/C7 daily floor and cap |
| Tuesday happened; re-plan from the fridge | replan(): freeze the hours lived, subtract them from every budget, shift deadlines, re-solve only the remaining days โ model predictive control |
| "How did the week go?" | the satisfaction score, 0 to 100, and a per-task fulfilment rate |
The proof: the 2019 brain, run today on the 2026 goals
life_GPS repository (PuLP + CBC, a faithful port of the 2019 lpSolve function) on 2026-09-06. One run, deterministic; not a study.[MEASURED]I took the three 2026 tracks and wrote them the way the 2019 program wanted them: a revenue task (price and sell one offer, at least 10 hours, at most 20, no more than 5 a day), a research task (the self-improving agentic-systems work and its quality-management application, 8 to 15 hours), a daily journal on walking with God, family and teammates (exactly one hour every day), a weekly one-to-one discipleship hour, a faith-and-work article, and preparation for a monthly fellowship talk. Weights from 10 down to 5, the way the R took them.
from life_gps import allocate, replan, PlanRequest, Task, CheckIn, RealizedTask
req = PlanRequest(days=5, hours_per_day=10, tasks=[
Task(name="Revenue: price + sell one offer", weight=10, min_hours=10, max_hours=20, max_daily=5),
Task(name="Research: RSI-os / QMS-os", weight=8, min_hours=8, max_hours=15, max_daily=4),
Task(name="Daily journal", weight=9, min_hours=5, max_hours=5, min_daily=1, max_daily=1),
Task(name="Weekly 1:1 discipleship", weight=7, min_hours=1, max_hours=2, max_daily=2),
Task(name="Faith & work article", weight=6, min_hours=2, max_hours=4, max_daily=2),
Task(name="Prep monthly fellowship talk", weight=5, min_hours=1, max_hours=2, max_daily=1),
])
plan = allocate(req) # score 100.0 โ every task at its cap
up = replan(CheckIn(request=req, days_elapsed=2, realized=[
RealizedTask(task="Revenue: price + sell one offer", hours_done=3),
RealizedTask(task="Research: RSI-os / QMS-os", hours_done=2),
RealizedTask(task="Daily journal", hours_done=2),
RealizedTask(task="Weekly 1:1 discipleship", hours_done=1)]))
# up.score == 88.8 โ "Re-solved the remaining 3 day(s). Frozen past: Revenue 3h, Research 2h, Journal 2h, 1:1 1h."The solver filled all fifty slots and hit every cap: revenue 20 of 20, research 15 of 15, journal 5 of 5, the rest at their maximums. Score 100. Then I told it what a realistic Wednesday looks like: two days gone, three hours of revenue work instead of ten, two of research, the journal kept. It froze those hours, subtracted them from every budget, and re-solved the remaining three days. Score 88.8, with a message naming exactly what it had frozen. The revenue task, the one furthest behind, took the most of the remaining slots. That is a satnav re-route, done by an integer program written seven years ago.
[DEF]Two things are worth naming precisely. The brain is a binary integer linear program: variables in {0, 1}, a linear objective, linear constraints, solved exactly by branch-and-bound in CBC. The trick is receding-horizon control: re-solve the remaining horizon from the current state on every check-in. Industrial process control has done this since the late 1970s (Richalet et al. 1978; Cutler and Ramaker 1980), which is why the company article calls the loop "the same MPC loop its robots use." Nothing in Life GPS was new. The application to a week was.
The autopsy: it died the way Franklin's chart died
[EVIDENCE]Three hundred years before my app, Benjamin Franklin built the same loop out of paper. In Part Two of his Autobiography he describes a book with a page per virtue: "I ruled each page with red ink so as to have seven columns, one for each day of the week, marking each column with a letter for the day." A black spot went in for every fault. He gave each virtue a week of strict attention, thirteen weeks per course, four courses a year. It worked, and then it did not: "I went through one course only in a year, and afterwards only one in several years, till at length I omitted them entirely, being employ'd in voyages at sea and divers engagements in business rendering my attendance to them very difficult."
Read the structure, not the sentiment. Franklin's loop had a designed grid, a sensor reading every evening, an executor all day, and a judge at night. Every one of those roles was Franklin. The loop's throughput was capped by one man's attention, and when his attention went to sea, the loop went with it.
[EVIDENCE]Life GPS died identically, and I can be specific because I wrote the autopsy in August. Three feeds had to be typed by hand. The weights: "Learning = 10, Play = 6," pure gut, never revisited. The tasks and rules: a table, retyped every week, always stale. The feedback: self-scored twice a day. The August article says it in five words: "A chore, so I stopped." The satnav worked. The driver stopped reporting the turns.
Locke and Latham's goal-setting theory, the load-bearing 30-year work here, is usually quoted for its headline: specific, difficult goals beat "do your best." The clause that matters for a planner is the condition attached to it: the effect holds given feedback on progress. Life GPS had no feedback unless I typed it. Franklin had none unless he sat down with the red-ink book. Both loops were open the moment the human got tired, and a specific, difficult goal with no feedback is just a difficult goal.
What an AI-native rebuild adds: not a smarter brain, three organs
[DESIGN]When people hear "AI-native," they expect the model to replace the solver. It must not. A language model asked for a plan twice gives two different, constraint-violating answers; that is the finding of the solver article and of the 2024 to 2025 research it cites. The brain stays a solver. What the model is good at is the three feeds the human hand-cranked.
Organ 1, the weights. In 2026 an agent reads the telemetry and proposes an importance for every node, in a signing tray. The human signs, or the weight counts as exactly 1. This is the one organ where the human is kept, and Episode 1 measured what happens when the human does not show up: zero signatures in 32 days.
Organ 2, the tasks and rules. The retyped table became a goal graph in a file under version control, with dependencies. You speak an edit, you see a diff, you confirm. A move whose node is blocked routes through the blocker instead. The 2026 Python port already has the seed of this: an intake() that turns "ship my MVP, meditate daily, five days of eight hours" into a validated request. The form became a sentence.
Organ 3, the feedback. Report cards filed by the agents that did the work; leading metrics read from data; and, because this organ is the one that killed both Franklin and me, tripwires that fire when a feed stays at zero. Episode 1 also recorded the honest limit: the tripwires fired correctly on day 32, and two of the three tracks had still received zero cards in a month, because a tripwire that nobody reads is a dot in Franklin's book that nobody looks at.
That last sentence is the whole transfer from 2019 to 2026. The sensors got a thousand times cheaper. The judge did not. The next episode is about the judge.
Build it in 30 minutes: the contract
INPUTS
tasks[] : {name, weight, min_hours, max_hours, min_daily?, max_daily?, deadline_hour?}
horizon : days ร hours_per_day (slots = days ยท hours_per_day)
check-in : {days_elapsed, realized[{task, hours_done}]}
OUTPUTS
plan : schedule[day][hour] โ task | "", score 0..100, fulfilment[{task, scheduled, demand, rate}]
replan : the same, for the remaining days only, plus a message naming the frozen past
INVARIANTS (tests first)
one task per slot; every task within [min_hours, max_hours]; daily floors/caps hold
infeasible โ feasible=false with a message naming what to loosen โ never a silent best-effort
replan never edits the past: scheduled(before check-in) is frozen, budgets are reduced by hours_done
STOP RULE
a task whose demand is already met leaves the remaining horizon
DELIBERATELY MISSING
any weight the human did not type; any feedback the human did not type โ the organs episode 3 suppliesUse PuLP with the bundled CBC solver, as the public repository does. Fifty binary variables solve in well under a second; a month of ten-hour days is still trivial. The hard part is not the solve. The hard part is the two lines marked deliberately missing.
Same story, five exits
| Reader | The decision this episode hands you | The one action |
|---|---|---|
| Student | A week is an allocation problem, and an exact solver handles it easily | Run the 12 lines on your own week; break one constraint and watch the message |
| Engineer | Do not let the model be the solver; let it feed the solver | Draw your system's three feeds; mark which are typed by a human today |
| Founder | A correct tool with a hand-cranked feedback feed will die of neglect | Instrument one feedback feed this week so it fires without you |
| Executive | "We have a plan" is not "we have a loop"; a loop needs a sensor that is not a person | Ask, for your top initiative, who types the progress number and how often they stop |
| Investor | The moat is rarely the brain; it is the cheap sensor nobody else has wired | Ask which feed the team automated first, and why that one |
Patterns, anti-patterns, and the mechanism
Patterns. Solve exactly; re-solve from the current state; freeze the past; name the frozen past in the message; report infeasibility with what to loosen.
Anti-patterns. Asking a language model to allocate. Weights typed once and never revisited. A feedback feed that is a person. Re-planning by throwing the week away.
The mechanism. Receding-horizon optimisation keeps a plan alive only as long as the state estimate is fresh; the state estimate is fresh only as long as the sensor is not a tired human.
The first principle, in one sentence. A plan is a function of the state, so whoever owns the sensor owns whether the plan is alive.
Exit test
- What does
replan()do to the two days already lived? (freezes them; subtracts their hours from every budget; shifts deadlines; solves only the remainder) - Name the three feeds Life GPS needed a human to type. Which one killed it?
- What is the one organ the 2026 rebuild deliberately leaves human, and what did Episode 1 measure about it?
Reality Mission
Mine: the daily journal task in the example above is the relationship track's sensor. It is exactly one hour a day in the solver and exactly the kind of feed that stops when the human is tired. Before episode 3 ships, that journal becomes a report card the board can read, so the relationship track gets its first non-null reading.
Yours: write your week as six Task lines. Do not run it yet. Look at the weights you typed and ask where each number came from. That answer is Organ 1, and it is the subject of the next episode.
Read next
Episode 2 of The Visionboard. Claims are tagged by class โ definition, design choice, evidence, measurement, open question. The 2019 code was re-run, not remembered; the numbers above come from that run, logged in the repository's research dossier under docs/plans/.
References
- Paul Wu, Life GPS, github.com/wjlgatech/life_GPS โ created 2019-04-25 (R/Shiny; the function
DaysOfFulfillment001inmakingHistory_functions.R); Python port pushed 2026-07-06 (life_gps/allocator.py,engine.py,intake.py). MIT. Run on 2026-09-06 for the numbers above. - Paul Wu, Life GPS โ a smart planner that adapts to your changes and prioritizes your days ahead, Medium, 2019. Served to browsers only (Cloudflare blocks fetchers); linked from the repository README.
- Benjamin Franklin, The Autobiography of Benjamin Franklin, Part Two, section "Plan for Attaining Moral Perfection." Public domain; Project Gutenberg #20203. Both quotations verified verbatim against the Gutenberg text on 2026-09-06.
- J. Richalet, A. Rault, J. L. Testud, J. Papon, "Model predictive heuristic control: Applications to industrial processes," Automatica 14(5), 1978; C. R. Cutler and B. L. Ramaker, "Dynamic matrix control โ a computer control algorithm," Joint Automatic Control Conference, 1980.
- Edwin A. Locke and Gary P. Latham, A Theory of Goal Setting and Task Performance, Prentice Hall, 1990 โ the feedback condition.
- Paul Wu, I Built My Company's Brain in 2019 and Mistook It for a To-Do List, 2026-08 โ the three starved feeds, quoted above.
- Paul Wu, Let the Model Write the Problem. Let the Solver Sign the Answer., 2026-08-04 โ LLM-Modulo, OptiMUS and the seam contract.
- Paul Wu, The Visionboard, episode 1, 2026-09-06 โ the day-32 measurement referenced throughout.