App to Stack / governed continuity
The Expiration Clause
A capability that keeps running after its reason has changed is not dependable. It is overdue for a decision.
A small clause with a large consequence
An expiration clause is a clear condition that tells a personal AI capability when to be reviewed, changed, paused, or retired.
The promise of the app-to-stack transition is continuity. A useful stack can retain a person’s standards, sources, routines, and corrections long enough for a method to become more capable than a one-off answer. That is the promise described by The First Stack Generation: people can arrive with evolving capability, rather than repeatedly adapting themselves to somebody else’s fixed application.
Continuity, however, is not permanence. A weekly brief may depend on a source that changes its method. A household routine may no longer fit the person who set it up. A hiring workflow can keep reproducing an old definition of readiness. A quiet assistant may go on applying yesterday’s priorities because nobody gave it a reason to stop.
App People learned to live inside software whose renewal was someone else’s business. Stack People inherit a different responsibility: they must notice when a capability’s original terms no longer hold. The question is not whether an AI system can keep going. It is whether its owner can still explain what it is for.
The label is not bureaucracy
Three terms that keep a stack answerable
Select a term above. It receives a high-visibility marker—the same kind of attention an automated routine needs at the moments when “still running” could be mistaken for “still right.”
01 / PURPOSE
Name the job, not the tool.
“Summarize updates” is an activity. “Prepare a current, source-linked brief for this decision every Monday” is a job. The second statement gives a person something to inspect when the context changes. It also keeps a stack from becoming a pile of impressive functions with no accountable use.
Ask at setupWhat decision, relationship, or ordinary task becomes better if this capability exists?
02 / REVIEW
Put revision on the calendar.
Some capabilities should be revisited after a month; others after a project, a changed role, a new source, or a visible mistake. A review point is not a punishment for automation. It is the handoff from the conditions that created a method to the conditions that now test it.
Ask at reviewAre the source, owner, purpose, and permission boundary still the ones this capability was built to serve?
03 / RETIREMENT
Make stopping a valid outcome.
A capability does not have to fail dramatically to deserve retirement. Sometimes the decision disappears. Sometimes the method becomes too costly to supervise. Sometimes a source, a relationship, or a person’s own priority changes. A clean exit prevents stale convenience from quietly becoming authority.
Ask at retirementWhat should be archived for learning, handed over with consent, or deleted because it no longer has a legitimate purpose?
The temptation to call it friction
The easiest stack to use is often the hardest one to question.
That is not an argument for treating every personal workflow like a compliance department. People need lightness. They need useful defaults. They need the relief of not rebuilding ordinary support from scratch.
But the alternative is not freedom. It is drift. A system that makes its own longevity invisible can turn a temporary judgment into a background rule. The risk grows as stacks become less like single-purpose apps and more like ongoing arrangements among memory, data, preferences, people, and work.
Organizations have long used retention schedules, renewals, audits, and sunsets to acknowledge that policies outlive the moments that made them sensible. Stack People need a personal version of that discipline—not because their methods are institutional, but because their methods can now compound.