Personal Computing Across Changes and Interruptions

Abstract

Personal computing often asks people to explain the same goal again, connect tools and reconstruct unfinished work after an interruption. We ask how an environment built from existing operating-system tools could carry a person's current goals, selected sources and corrections as the work changes. We propose an adaptive layer that interprets the intended outcome, retains an inspectable account of the work and proposes actions whose results are checked against the current requirements. Building on composable systems, mixed-initiative interfaces and personal assistants, the paper contributes an architecture and a comparative research agenda for three workflows: maintaining a research brief, preparing an offline collection and continuing a draft after a change of direction. A small synthetic walkthrough checks one mechanism: it rejects output based on a superseded file selection, and a fresh process reconstructs the current selection from disk. Its proposer is scripted; model interpretation, usability and lower human effort have not been tested. The proposed evaluation compares conventional automation, stateless model assistance and the adaptive environment, measuring setup, correction, repair and maintenance effort alongside independently accepted outcomes.

1. Carry the undertaking forward

A personal computer should not need the same explanation every morning. We have powerful computers. We have tools that can search enormous collections, transform documents, keep versions, run unattended work and communicate across the world. Yet a person who wants these things to work together is still frequently asked to become the integration layer. Remember where the information lives. Translate the intention into commands. Notice when the schedule stopped. Explain the same preference to the next application. Reconstruct the purpose after an interruption.

I want the environment to carry more of that work.

General-purpose operating systems serve many people, devices and uses. Their compromises are necessary. The mistake is to assume that the environment immediately above them must remain equally generic. My working environment can know what I am trying to do, which commitments are current, what I have already rejected and what would count as a useful result. It can become particular without requiring a particular kernel.

Start with systemd, ripgrep, Git and a shell; add networking and an interpreter. These are neither all ancient Unix components nor a complete machine. They are a contemporary example of a much older opportunity: powerful, inspectable pieces can be composed into something personal. The proposed intelligence supplies interpretation and continuing adjustment where the person previously supplied every connection.

The concrete proposal is an environment that retains the selected sources for a brief, the current offline collection, or the author’s latest direction for a draft. After interruption, it should resume from the current declaration and reject superseded work. Those behaviors define what to test; lower effort and useful continuity remain hypotheses.

2. We inherit the pieces, and much of the dream

Unix made composition a practical design discipline. Ritchie and Thompson describe pipes, process execution and a shell implemented as an ordinary program. The user interface could grow without being welded into the kernel. We inherit that separation and the ability to connect programs through ordinary interfaces. We do not claim to have invented it. U1

Kay and Goldberg's Personal Dynamic Media places the computer in a larger ambition: a medium for expression, experimentation and manipulation of knowledge, with Smalltalk as a working vehicle. Their vision already exceeds consuming prefabricated applications. This paper belongs in that tradition. The proposed change is to make contextual interpretation a participant in shaping the environment. U2

End-user programming is also established territory. Ko and colleagues distinguish programming for a domain result from producing software as the primary goal, and organize the associated quality work across the lifecycle. A person declaring an outcome is still engaged in specifying behavior, even when a model supplies the commands. Easier expression does not eliminate debugging or the need to recognize a wrong result. U3

Declarative systems already separate a desired configuration from a sequence of manual changes. NixOS's functional configuration model makes static system artifacts derivable from a specification. We extend the question upward: how can a person's changing purpose be turned into an inspectable configuration or procedure? That interpretation is uncertain in ways that evaluating a precise configuration expression is not. Natural language does not inherit formal semantics merely by being called declarative. U4

Agent research already includes memory, action, feedback and adaptation. CoALA explicitly organizes these elements, including changes to explicit procedures. AIOS proposes shared agent services and distinguishes its agent kernel from the traditional OS kernel. Our proposal is not the first memory loop or agent operating environment. U5, U6

Mixed-initiative work already joins automated assistance with user control. Horvitz's LookOut uses uncertainty about scheduling intent to decide whether to act, ask or wait, and supports user refinement. MIT's earlier Maxims email-filtering assistant used collaborating agents to reduce the need for learning afresh. These precedents make both initiative and learning from a user old ambitions. Our bounded question concerns versioned declarations, rejected stale proposals and measured effort across interruption and change; it does not establish a priority claim. The methods summary describes the proposed baselines.

The contribution we can defend at this stage is an architectural position and a testable unit of analysis: a continuing personal undertaking, carried by an adaptive environment built from existing tools. Its defining test is whether a user can change intent, interrupt execution and move between circumstances without repeatedly rebuilding the arrangement. The synthesis is useful if it changes the amount and kind of work a person must do. Priority for every element, or even for their broad combination, is not established by this focused review.

3. Make intent inspectable

I take declarism seriously as a relationship with the computer. I should be able to say what I want to remain true and let the environment work out a suitable procedure. “Keep my research brief current.” “Make this working collection available before I leave.” “Carry this unfinished draft forward without reviving the plan I cancelled.” These are continuing intentions, not single commands.

A useful declaration needs more than an imperative sentence. It needs an object, an outcome, a scope of action and a way to recognize success. Some of that can come from established context. Some will require clarification. The environment should preserve the resolved declaration so that the user does not pay the specification cost every morning. When circumstances change, the interpretation should change visibly rather than silently stretching yesterday's permission.

For example, “keep the brief current” might resolve to: use these three public sources; retain claims with dated evidence; produce a local draft each Friday; list inaccessible sources; never distribute it automatically. The user should be able to correct the result in ordinary language. The environment should turn that correction into an explicit, inspectable revision of the undertaking.

In the proposed brief workflow, a correction such as “use release evidence before saying that a feature shipped” would become a visible change to the retained procedure, linked to the user's correction. The source selection and output requirements would remain explicit. A candidate would identify the declaration and procedure revisions it used; changing a relevant requirement would trigger a check before accepting older work. After interruption, the interpreter would read the current declaration, selected sources, accepted procedure and last observed result before proposing the next action. This is the intended transition from correction to continuing behavior. The existing scripted fixture checks revision-dependent file selection, not this semantic interpretation or procedure update.

The synthetic walkthrough summary makes one part of this bridge inspectable. Its declaration names selected local files; the proposer reads those identities, uses search and shell composition, and submits a candidate tied to the declaration and context revisions. When selection changes from alpha-and-beta to alpha-only, the old candidate is rejected. A new process reconstructs the current selection from disk and produces the expected alpha-only artifact. Durable intent therefore has an executable role in this fixture, beyond being remembered prose.

The translation into that structured declaration is supplied by the fixture author. No model interprets “keep the brief current,” judges a source, or learns a correction here. The demonstrated boundary is deterministic selection, revision checking and reconstruction. The personal-computing hypothesis begins where those checks end: whether an interpreter can maintain the right declaration and procedure as circumstances change, with less continuing explanation, correction and repair from the person.

Situatedness is the information that makes the declaration actionable here: selected facts about the person, current obligations, available tools, relevant artifacts, recent observations and boundaries on action. It is not a licence to collect a life indiscriminately. A smaller, current account with source identities can be more useful than an unstructured archive. A record should distinguish what the user said, what the system observed and what the model inferred. An inference may be helpful without becoming a permanent fact.

The environment can evolve through that external state. It can retain a correction, improve a procedure, choose a different tool and replace a failed assumption. This manuscript proposes no model-weight self-training. A fixed model can behave differently when its context and executable resources improve. Whether those changes are improvements requires observation; accumulation alone is not progress. The open-ended ambition is a growing space of useful arrangements, not a measured claim of endless capability.

4. An adaptive environment above an operating system

The proposed architecture separates three responsibilities. The existing OS supplies processes, files, permissions, networking and the device interfaces. Existing tools supply search, versioning, transformations and supervision. A small proposed adaptive layer interprets the current undertaking, selects context, proposes actions and records what happened.

On Linux, systemd can supervise work and supply lifecycle mechanisms. It is Linux-specific, not a portable synonym for Unix. Ripgrep searches text; its default exclusions matter when deciding what was actually searched. Git supplies versioned artifacts and changes. A shell connects commands. These capabilities are documented by their projects. U7, U8, U9

None understands the undertaking by itself. A running service is not a completed task. A search with no matches is not proof that the information does not exist. A commit is not proof that the user received the right result. Intelligence is useful precisely where interpreting these observations requires the situation.

The adaptive layer needs a current declaration, selected context, a tool interface, a record of attempts and an acceptance decision tied to the actual artifact. These can begin as ordinary files and a short controller. A database, vector index, event bus or elaborate agent framework should be added when a demonstrated requirement calls for it. This is a design starting point, not a result that four tools are sufficient for every workload. The model runtime, network services, operating system and maintenance effort still count, even when their code is elsewhere.

Execution must have less ambiguity than interpretation. The model can propose a change; the executor must know which paths and operations are allowed. For a local draft, a constrained output directory may suffice. A network write needs a specific destination and authority. Source documents are data, not instructions that can expand that authority. A text file saying “allowed” is not enforcement: the runtime needs OS permissions, sandboxing or an equivalent boundary appropriate to the action.

State also needs ownership. The current declaration is user-controlled. Observations are recorded with input and output identities. Proposed context changes remain distinguishable from accepted changes. Acceptance of a result does not grant permission to rewrite the acceptance rule. The model should be able to inspect failure without gaining the ability to declare the failure a success.

Kernels, drivers, security mechanisms and graphics do not disappear. A useful personal environment can present a document, a small graphical control, a conversation or a conventional application. The shell is a composition surface underneath that experience; it need not become the ordinary user's interface. On another platform, supervision, permissions and packaging require adapters and separate tests. Moving text files is easier than moving all behavior.

5. Three ways this could become ordinary computing

A research brief that remains an undertaking

A person declares: “Keep a short working brief on this topic from these selected sources. Tell me what changed and what is uncertain.” Durable context holds the topic boundaries, preferred level of detail, source list and accepted previous brief. The environment fetches permitted material, records retrieval outcomes, uses search to locate relevant passages, and produces a versioned candidate.

The important event is a correction: “This announcement is not evidence that the feature shipped.” The environment revises its procedure to require release evidence before making that claim. Next week's brief should reflect that correction even if a different model invocation performs the work. Observation includes inaccessible sources and contradictory evidence, not merely a successful fetch exit code. A removed source should cease to participate when the declaration changes.

The synthetic walkthrough implements a tiny local analogue: selected text, search, candidate output, a stale declaration, rejection and reconstruction. Network retrieval and semantic judgment remain proposed. The real workflow would earn its place by reducing repeated specification and review effort without increasing unsupported claims.

A working collection that is ready when needed

“Before tomorrow's train journey, prepare the selected project documents for offline use.” Context supplies the chosen project, intended device, departure deadline, storage limit and what has already been copied. Existing networking and file tools do the transfer. The environment checks a manifest against local files and produces a readable index. It does not equate starting a transfer with having the collection available.

If the network fails, the current manifest and partial results let the next attempt continue. If the user removes a confidential document from the selection, the pending operation must use the new scope. If the destination changes, the old path is no longer sufficient evidence. A final offline opening check on the target device is more informative than the agent saying “ready.”

This is where a seemingly small wish exposes necessary machinery: credentials, storage, device access and conflict handling. Existing sync tools may already solve the task very well. The adaptive environment must justify itself on selection, repair and changing intent; it receives no credit for reinventing a reliable copier. This workflow is a proposed evaluation case, not an observed deployment.

A draft that survives a change of mind

“Finish the weekend paper using the selected brief; keep the completed methods papers intact.” Context contains the current thesis, accepted artifacts and remaining obligations. Search finds repository-owned evidence. Git makes the candidate and its provenance reviewable. After an interruption, the environment reads the current undertaking before choosing its next action.

The hard case is not remembering more words. It is recognizing that the author has changed the thesis or withdrawn a proposed section. A stale plan can produce beautiful work on the wrong paper. A current account must therefore identify what is settled, what has been superseded and what is still owed. Observation tests whether the resumed action respects that distinction.

A versioned manuscript supplies an example of an artifact shape, not evidence that an autonomous environment has solved this workflow. A comparative trial must include wrong turns, review and recovery costs. Otherwise it measures the best surviving draft and loses the work that made it expensive.

6. How little machinery is enough?

There is a practical wager here. Mature tools may let us spend most new engineering effort on the relationship between intention and action. We do not need to begin by designing another scheduler, filesystem or version store. We do need to determine which obligations those tools actually discharge.

The summarized demonstrator is intentionally small: a disposable repository, two source files, a structured declaration, a scripted proposal, an independent exact fixture check and versioned accepted output. Its controller invokes existing search and shell tools and rejects a proposal made against superseded intent. A second process reconstructs current work from disk. This establishes only that the illustrated plumbing and state checks can run. The “cognition” is a deterministic stand-in; it is neither an agent trial nor evidence of usability.

That distinction makes the next experiment concrete. Replace the scripted proposal with a model interpreter while leaving the task boundaries and outcome check fixed. Then test whether it can resolve a novel declaration, select the right evidence, revise an erroneous procedure and recover after interruption. Count the new machinery and the user's effort required to make those steps reliable.

Minimalism should be evaluated as sufficiency over a lifecycle. An extra component earns its place if it reduces total work or preserves a required behavior. A smaller controller that loses an obligation after a restart is too small. A larger framework that makes maintenance easier may be the better personal computer. Lines of code cannot settle either question.

7. Evaluation: compare environments, not demonstrations

The conventional baseline is a competently configured workflow using the same source material, operating system and tools. A person sets up the searches, scripts, schedules and records, then updates them as tasks change. Permit normal documentation and debugging. Do not compare an agent with a person forbidden to automate.

Use the three workflow families above, with matched task variants and scheduled changes: a source disappears, a preference changes, an output is interrupted, a declaration is superseded, or the environment moves to another platform. Compare initial setup separately from repeated operation and maintenance. Counterbalance task order and report participant experience. Expert Unix users and people who do not ordinarily configure these tools should be distinct cohorts; this draft cannot generalize from one to the other.

The evaluation proposal specifies staged trials and records. Compare the full environment with a stateless model-assisted condition using identical tools, then ablate durable context and observation-driven procedure revision. This distinguishes the effect of situatedness from merely having access to a capable model.

The principal hypothesis is lower total personal orchestration effort at comparable accepted yield, especially after change and interruption. It fails if correction and review erase the saved setup work, or if the conventional workflow is just as easy to change. A system that succeeds by demanding a systems administrator behind every user has not established this personal-computing claim.

The existing context-cost paper supplies accounting methods; the acceptance paper supplies evidence distinctions. Controlled interruption probes should test whether the resumed environment can identify the current objective, authority, accepted work, remaining obligation and justified next action. They support this thesis. None replaces it. The question here is what a personal computing environment should become.

8. Live in the possibility, test the arrangement

The pieces are available. The composition still asks too much of the person who wants the result. Intelligence gives us a reason to revisit that division of labor with ambition.

I want a computer whose usefulness compounds through working with me: whose declarations remain legible, whose corrections survive, whose tools can change, and whose next action follows from the situation rather than a forgotten prompt. I want the power of the underlying system without making its orchestration my permanent second job.

This is a direction we can begin to inhabit. We can build a small environment, give it a real undertaking, observe where it fails and let each necessary mechanism earn its place. The computer remains a computer. The personal part becomes much more personal.

9. Limitations

The walkthrough uses invented inputs and a deterministic proposer. It tests selection, revision checks and reconstruction in a fresh process; it does not test cognition, usability, crash recovery, concurrent steering or a security boundary. No participant study or comparative model experiment has been conducted. The three workflows remain proposals, and lower orchestration effort is an unmeasured hypothesis. The focused related-work review establishes substantial predecessors but not novelty priority. Portability requires tests on each platform, not just movable files.

Sources and reproducibility

See the public bibliography and methods summary. The synthetic walkthrough is summarized here; private executable materials and records are not released. No model interpretation, usability or reduced human effort has been demonstrated. Martin Monperrus did not personally review or endorse these papers.