App to Stack / portability test
The Replacement Drill
A stack is not portable because its files can be exported. It is portable when its working method can survive replacement.
Keep the methodChange the machinery
Move the method, not just the files.
A replacement drill asks what remains useful when the trusted interface is no longer there.
The export is not the exit.
The app-to-stack transition promises that a person can carry capability across changing tools. That promise becomes real only when replacement has been rehearsed.
Applications train App People to treat continuity as a login problem. The vendor keeps the history, the settings, the familiar controls, and often the path by which work got done. When an account closes or a product changes, the export button feels like a rescue hatch. It may preserve files. It rarely preserves a method.
Stack People have a more demanding obligation. A personal AI capability may involve source selection, a vocabulary for the work, standing boundaries, a review habit, examples of good judgment, and a way to notice exceptions. Some of that can live in documents; some exists in routines and decisions. If all of it depends on one model, workspace, or workflow, the stack has not escaped application dependence. It has merely made the application more intimate.
A replacement drill is a deliberate test in which a person moves one bounded capability to a different system and checks whether the method, limits, and accountability still hold.
This is not a demand for perfect interoperability. Different systems will produce different interfaces, strengths, risks, and results. The point is not to make every model interchangeable. The point is to know which parts of a capability belong to a vendor and which parts belong to the person who is responsible for the outcome.
The app-to-stack transition described in The First Stack Generation moves the productive center from a fixed application toward an evolving person-plus-method. A replacement drill gives that claim a practical test. Can the person name the method well enough to move it?
Run the drill before the emergency.
Replacement is easiest to evaluate while the original system still works and the person can compare, correct, and decide what belongs where.
Choose one live obligation.
Do not test an empty demo. Pick a bounded, lawful task that matters: a weekly client brief, a research intake, a household renewal, or a project handoff. The stakes reveal the missing parts.
Write the method outside the product.
Name the desired outcome, trusted materials, exclusions, decision points, and return interval. These are not a giant prompt. They are the human terms on which assistance is allowed.
Rebuild and compare.
Use a second system to prepare the same bounded outcome. Compare not only fluency, but source discipline, omissions, escalation, and the work needed to make the result answerable.
The drill will expose friction. That is its value. A missing source list, an unstated threshold, or a preference that only existed in a buried chat is not a failure of the new tool. It is evidence that a piece of the capability was never made available to its owner.
What the test protects
Against the quiet new lock-in.
It is tempting to call any heavily personalized system a stack. But personalization can make dependency feel like ownership. The more a system remembers, the more painful departure can become. A person may stay because it is truly the best tool, which is a valid choice. Or the person may stay because the method has become unreadable everywhere else. Those are different conditions.
For workers, this distinction changes bargaining power. A worker should not copy an employer’s private material into a personal capability. Boundaries still matter. Yet a worker can retain a lawful general method: how to frame a decision, inspect a source, organize a handoff, and decide when an answer needs a human return. A replacement drill clarifies that boundary. It separates portable craft from borrowed records.
For organizations, the test is not a threat to standardization. It is a way to stop confusing a purchased product with institutional competence. A team still needs common records, accountable owners, and a secure place for shared work. But it benefits when people can describe the method behind a good result rather than presenting a private system as a miracle no one can inspect.
For educators and public institutions, the drill suggests a better question than “Which AI tool should everyone learn?” Teach people to retain the parts that make a tool useful: a question worth asking, a source worth trusting, a rule for refusal, and an honest account of what has not been verified. Those parts can cross a product change. They are the beginning of durable capability.
Freedom needs a rehearsal.
The goal is not to leave every tool. It is to remain able to choose. A mature stack may keep a preferred model for years, just as a person may keep a trusted notebook or colleague. The difference is that the relationship is chosen with evidence, not enforced by a hidden dependency. Stack People will not be the people with the most integrations. They will be the people who can keep their method legible when the machinery changes.