Research paper · September 2026

Useware

Software lifetime as a runtime variable. From persistent applications to ephemeral intent-generated computing.

Continuity no longer requires continuity of implementation.

Njål Gaute Solland · VALO Research · Proposed paradigm and research programme

Research thesis

The application no longer has a default right to survive.

Existing software paradigms generally treat applications, services, functions and workflows as persistent artifacts. Useware proposes a different unit of continuity: persistent identity, state, authority, provenance and evidence, combined with transient executable implementations whose lifetime is decided at runtime.

The central claim is not that AI can generate code. The stronger claim is that sufficiently cheap synthesis and verification make software lifetime itself an optimization variable.

IntentComposeAuthorizeExecuteVerifyRetain state / evidenceDecompose or cache

Lifetime model

Persistence becomes a runtime decision.

Traditional computing exposes runtime controls for memory, scheduling, priority, cache lifetime, retries and network timeouts. Useware adds executable lifetime to that set.

C_persist(T) = C_storage + C_maintenance + C_attack_surface + C_sync + C_staleness

C_regen(T) = E[N_reuse(T)] × (C_synthesis + C_verification + C_warmup)

Retain the artifact when expected persistence cost is lower than expected regeneration cost. Otherwise the optimal lifetime tends toward zero. Staleness matters because persisted generated code can drift away from current policy, schemas, dependencies, authority, context and user intent.

Architecture

State fabric versus execution ephemerality.

Identity & authorityPersistent. Defines who or what may act, on whose behalf and under which constraints.

Entity state & historyPersistent. Carries the user or organization across implementations.

Evidence & auditPersistent or immutable. Preserves request, authorization, execution and effect.

Generated interfaceSession or task lifetime. Exists only while useful for the current intent.

Synthesized executableTTL-controlled. Temporary mechanism for producing an authorized state transition.

Compute fabricDynamic placement across endpoint, personal device, local node, trusted edge and remote burst compute.

Compute

Compute follows the task, not the product.

A Useware system can place a bounded task wherever it best fits: phone or laptop, home or office server, trusted edge or mesh, or leased accelerator capacity. Placement can be optimized for latency, privacy, energy, bandwidth, accelerator availability, authority, reliability and monetary cost.

This does not mean a mesh of weak machines becomes a large accelerator. Communication overhead, memory topology, synchronization and model partitionability remain real limits. The thesis is narrower: fixed execution location stops being the default.

Governance boundary

Ephemeral code requires persistent consequence control.

If an implementation can disappear seconds after execution, assurance cannot rely only on a long-lived codebase. The durable record must preserve intent, current authority, constraints, inputs and provenance, artifact identity, runtime environment, decision, actual effect, resulting state and replayable evidence.

The implementation may disappear. The authority boundary, actual consequence and evidence may not.

Research programme

Testable claims.

H1For selected low- to medium-complexity tasks, on-demand generation has lower lifecycle cost than persistent software.

H2A heterogeneous personal compute fabric can handle a substantial share of everyday AI workloads without premium compute in every endpoint.

H3Dynamic placement can outperform fixed cloud-first execution on a joint cost-latency-privacy objective.

H4Task continuity can survive implementation destruction when identity, state, authority, provenance and history persist.

H5Ephemeral implementations can support auditable consequential action when runtime facts and actual effects are captured.

H6When generation latency is low enough, users will prefer intent-to-capability interaction for selected tasks.

Conclusion

Implementation persistence is no longer sacred.

The old model is build → deploy → operate → maintain → retire. The Useware model is intend → make → authorize → use → verify → forget.

The durable computational center moves away from the application and toward the person or organization: identity, data, relationships, authority, preferences, history and evidence.

Status: proposed paradigm and research programme. Related work supports the enabling mechanisms; the lifetime model and persistence boundary remain hypotheses requiring experimental validation.