Published system analysis
The Lifecycle of Software Objects
Ted Chiang
Spoiler-free analysis is open
This original material examines the management system without reproducing the text or retelling the plot. Source-backed premise and editorial interpretation are labelled separately.
Source-backed premise
The publisher describes artificial entities that people train and develop for more than a decade while software environments change and become obsolete. The management lens treats AI as a long-lived dependency among systems, users, infrastructure and owners.
Editorial management thesis
Deployment creates a technical system; dependence creates a stewardship obligation. Long-lived AI needs continuity, portability and decommissioning governance from the start.
New method studies
The same fictional system can answer a different management question when examined with another tool.
Service Blueprint
The Lifecycle of Software Objects and Service Blueprinting: Who Maintains Care?
A visible AI experience depends on backstage work that can disappear when providers change.
Read the studySystem map
Authority
Rights to update, migrate, sell or stop the system need an accountable long-term owner.
Information
Training history, versions, behavioural change, permissions and evaluations form the continuity record.
Resources
Compute, compatible runtime, specialist knowledge, curated data and maintenance funding must survive the launch team.
Incentives
Growth, platform migration and user continuity create conflicts precisely when legacy becomes expensive.
Adaptation
Migration governance defines what must persist, what may change and how drift becomes observable.
Failure modes
- A critical AI dependency has no lifecycle owner.
- Runtime obsolescence outruns safe migration.
- Vendor exit becomes an operational crisis.
- A backup preserves an API but loses context, policy and evaluation history.
Ethical assessment
Even without making claims about AI moral status, organisations must consider user dependence, continuity promises and the harm of abrupt termination. Process dependency requires an exit strategy.
Practical transfer
Assign a lifecycle owner
Make one owner accountable for migration, continuity, retirement and the evidence record.
Design portability early
Define the data, policy, state and evaluations needed to change model or platform.
Rehearse provider exit
Test whether the critical function can be restored without the current provider.
Limits of the analogy
- The novella treats AI as developing digital beings; the transfer does not require that view of current models.
- Enterprise AI usually has more formal contracts and controls.
- Some systems should be retired rather than preserved indefinitely.
Questions for discussion
- 1.Who owns the lifecycle after the project ends?
- 2.What must move besides API access or model files?
- 3.Which provider exit would create a crisis today?
Explore the mechanism
From observation to diagnosis and decision
Rate this material
Evaluate the usefulness of the system analysis, not the literary quality of the book.
—
No ratings yet
Source and editorial record
The Lifecycle of Software Objects — Ted Chiang
Subterranean Press — publisher or authoritative premise recordLast reviewed: 2026-08-24
- Source ID
- source_the_lifecycle_of_software_objects_publisher
- Publisher / record
- Subterranean Press
- Accessed
- 2026-08-24
- Supports
- bibliography, premise
Title and author identify the work under review. No cover art, quotations or publisher description is reproduced.