Done Has a Half-Life Tony Malott · Published 2026-09-02 https://shareplane.malott.ai/artifacts/done-has-a-half-life/ Done Has a Half-Life SHAREPLANE SPECIAL · DESIGN OS WORK #002 · MUTATE LOCK CANDIDATE ✓ Evidence ⌘ Graph ◇ Provenance TONY MALOTT · THESIS Done Has a Half-Life. Stable by Choice, Adaptable by Design Everything meaningful should become explicitly done. Every done state should remain reconsiderable. By Tony Malott Thesis author & originator Presumption of fitness over changed context conceptual · not calibrated 100% 50% 0% t₀ t½ time → RECONSIDER when changed context overcomes incumbency Accept t₀ Observe new evidence Reconsider material delta Stabilize accepted state The half-life is a decision concept, not a physical decay constant. THE FOUNDATIONAL DISTINCTION DONE(t 0 ) ≠ DONE(∞) A completed state is valid under the context in which it was accepted. It is not a lifetime warranty on the implementation. Tony Voice Default reading Reference Semantic authority Reconsider continuously. Change selectively. Stabilize deliberately. Preserve learning. Tony Voice edition. The default reading experience. The Reference edition remains the semantic authority. THE SIGNATURE INTERACTION A done state earns a presumption of fitness. Context spends it. Completion Half-Life is the period over which an accepted implementation can reasonably keep that presumption before changed conditions justify explicit reconsideration. Conceptual curve · not a calibrated decay function ACCEPTED TODAY RECONSIDERATION THRESHOLD changed context time → capability evidence economics requirements risk REFERENCE EDITION Abstract Artificial intelligence does not eliminate “done.” It changes what “done” means. In traditional engineering and management, completion often carried an implicit assumption of durability. AI changes the economics beneath that assumption. Capabilities improve faster, implementation alternatives proliferate, the cost of exploring new designs falls, and requirements, dependencies, evidence, and expectations move rapidly. An implementation can remain functional and correctly built while losing its presumption of continuing optimality. This thesis calls that phenomenon Completion Half-Life . A completed state remains valid under the context in which it was accepted, but no accepted implementation is permanently immune from new evidence. The response should not be perpetual change. Continuous mutation creates instability, destroys operating evidence, consumes human attention, and turns inexpensive generation into expensive verification and disruption. The stronger operating model is Continuous Reconsiderability . Continuously observe whether the assumptions behind an accepted state remain true; reconsider when they materially change; mutate only when a successor clears the full value-and-risk threshold; stabilize the result; and preserve the learning so the next transition costs less. As implementation becomes easier to analyze, generate, refactor, and replace, lost meaning becomes relatively more expensive. Intent, semantics, provenance, evidence, policy, dependencies, decision history, tests, and accumulated learning become forms of organizational capital. The AI-native enterprise should optimize for the Marginal Cost of Safe Improvement , not merely faster production. Done Has a Half-Life — Thesis Framework Derived visual expression. Click to inspect the full-resolution original. Provenance SECTION 01 The Foundational Claim Everything meaningful should become explicitly done. Nothing meaningful should become permanently exempt from reconsideration. A release can be done. A migration can be done. A policy can be accepted. An architecture can become current. A project can close. Every accepted state is still conditional upon the environment in which it was accepted. DONE(t0) is real. It does not imply DONE(∞) . SECTION 02 Completion Half-Life Completion Half-Life is the period over which a previously accepted implementation can reasonably retain its presumption of continuing fitness before changed conditions justify explicit reconsideration. Potential accelerants include new AI capability, new operating evidence, economic shifts, changed requirements, dependency changes, security or regulatory change, and accumulated organizational learning. Different layers have different expected half-lives. Freeze Meaning. Free Implementation. Completion Half-Life Derived visual expression. Click to inspect the full-resolution original. Provenance Fact-check class: thesis construct. Completion Half-Life is original to this thesis. DORA provides contextual evidence that AI changes organizational/software-delivery dynamics, but does not directly establish this construct. SECTION 03 The Incumbent Still Matters The incumbent possesses operating history, known behavior, user familiarity, existing proof, integrated dependencies, migration avoidance, and accumulated domain knowledge. Therefore the burden of proof belongs to change . ExpectedNetValue > MinimumImprovementThreshold ExpectedNetValue = ExpectedBenefit − FullChangeCost − RiskPremium The current system does not need to prove perfection. The proposed successor must prove sufficient improvement. SECTION 04 Context Debt Context Debt is the future cost created when meaning available today is not preserved and must later be rediscovered, inferred, reconstructed, or guessed. It includes semantic debt, intent debt, provenance debt, dependency debt, evidence debt, authority debt, and learning debt. Cost(ContextDebt) = RecoveryCost + UncertaintyCost + RequalificationCost + CoordinationCost + ErrorRisk + OpportunityDelay Context Debt vs. Context Capital Derived visual expression. Click to inspect the full-resolution original. Provenance SECTION 05 Context as Capital Useful context is authoritative, provenance-aware, versioned, discoverable, connected, reusable, and sufficiently structured for humans and machines. Durable context can include semantic models, decision rationale, policy, tests, evidence, dependencies, provenance, known-failure rules, automation, and reusable skills. CCR = ReusableDurableKnowledgeProduced / ExpensiveReasoningPerformed A low-CCR organization repeatedly purchases cognition. A high-CCR organization compounds it. SECTION 06 Context Liquidity and Context Yield Context Liquidity is the ease with which organizational knowledge can be discovered, trusted, interpreted, combined, and applied. Context Yield is the future cost avoided or value created because prior reasoning was preserved in reusable form. Continuous improvement compounds only when learning becomes durable. Otherwise it becomes continuous rediscovery. SECTION 07 The Reconsideration Economy Every existing implementation contains an implicit option. Historically many options were economically irrelevant because exercising them was too expensive. AI changes their exercise prices. The Reconsideration Economy is an environment in which rapidly changing intelligence, automation, evidence, and economics continuously reprice organizational decisions previously considered settled. The Reconsideration Economy Derived visual expression. Click to inspect the full-resolution original. Provenance SECTION 08 Reconsiderability Reconsiderability is the degree to which an accepted system can be safely reevaluated, materially altered, or replaced without reconstructing its meaning, losing valid evidence, or introducing uncontrolled risk. Maintainability asks: Can this implementation be changed? Reconsiderability asks: Can we safely question whether this should remain the implementation at all? SECTION 09 The Reconsideration Economy Is Not the Change Economy AI can make alternatives abundant. Organizational attention, customer tolerance, governance capacity, and human change bandwidth remain scarce. The winning organization evaluates more options while exercising fewer, higher-value ones. Externally supported context. DORA 2025/2026 describes AI as an organizational amplifier and reports higher AI adoption associated with both delivery throughput and delivery instability. Inspect evidence SECTION 10 From Agile to Reconsiderable Waterfall: optimize the plan. Agile: optimize learning. DevOps: optimize delivery. Cloud: optimize infrastructure flexibility. AI-native engineering: optimize reconsiderability. The AI-era question is: Given what we know and can do today, would we still choose to build and operate this system this way? SECTION 11 Reconsider Before You Automate ObsoleteProcess + AI = HighPerformanceObsoleteProcess Recover intent, identify the original constraint, test whether it still exists, remove obsolete steps, redesign, then automate what remains. SECTION 12 The Continuously Reconsiderable Enterprise Processes, roles, controls, vendor decisions, organizational structures, and strategic assumptions all have half-lives. A continuously reconsiderable enterprise preserves enough understanding to know why they exist, what assumptions justify them, what evidence supports them, who owns them, what depends on them, and what would trigger reconsideration. SECTION 13 Stable by Choice Stability is not the absence of reconsideration. Stability is the current outcome of reconsideration. A stable system should be able to say: We are not changing this because current evidence does not justify changing it. SECTION 14 The Operating System SENSE → TRIGGER → RECONSIDER → DISPOSITION → TRANSITION → CAPITALIZE LEARNING → repeat Most signals should produce no mutation. A trigger authorizes evaluation, not change. Affected objects receive explicit dispositions: REUSE, REVALIDATE, REGENERATE, REQUALIFY, RETIRE/SUPERSEDE . Operating System of Continuous Reconsiderability Derived visual expression. Click to inspect the full-resolution original. Provenance SECTION 15 Dependency-Aware Change Selective change requires dependency intelligence. Given changed object x : ImpactClosure(x) = { y | y transitively depends on x } Only objects inside the impact closure should presumptively enter regeneration or requalification. Everything outside should presumptively remain reusable. SECTION 16 Accepted States Continuous Reconsiderability requires explicit closure. Every material transition should end in an accepted state recording identity, meaning, evidence, dependencies, authority, predecessor, reused proof, and exceptions. Projects become transitions: State(t0) → BoundedChange → State(t1) . The project ends; the knowledge lineage survives. SECTION 17 Learning Writeback Failure → Diagnosis → Repair → Proof → Normalize Learning → Write Back → Future Prevention If a known failure continually requires expert rediscovery, the organization is not learning. It is merely solving. SECTION 18 The Nine Laws Done Has a Half-Life. No accepted implementation receives permanent immunity from new evidence. Freeze Meaning, Free Implementation. Durable semantics should outlive temporary expression. Optimize for Safe Change. The objective is low-cost, bounded, trustworthy improvement. Learning Must Compound. Otherwise continuous improvement becomes continuous rediscovery. Optionality Without Instability. Everything should remain reconsiderable; not everything should constantly change. Preserve Meaning Before It Becomes Archaeology. Never make tomorrow infer what today already knows. Reconsider Before You Automate. Do not accelerate obsolete constraints. Preserve the Organization's Right to Choose Again. Avoid unnecessary irreversibility. The Burden of Proof Belongs to Change. A successor must overcome the value of the incumbent. SECTION 19 The North Star Metric Marginal Cost of Safe Improvement (MCSI) MCSI = TotalIncrementalCost / VerifiedUsefulImprovement The organization wins when it can create verified useful improvement at progressively lower marginal cost without destroying stability, meaning, or trust. SECTION 20 The Case Against the Thesis The thesis fails if it degenerates into continuous mutation. It must account for migration cost, verification bottlenecks, human change fatigue, regulation, safety, tacit knowledge, security, incumbent operating evidence, context overload, and vendor lock-in. A superior design is not necessarily a superior decision. Some systems should deliberately become boring. Reconsider continuously. Change selectively. Finish explicitly. Externally scoped evidence. METR found a 19% slowdown in its early-2025 experienced open-source developer RCT; its 2026 follow-up says newer tools likely improved speedups but the new estimates are unreliable. NIST supplies lifecycle risk-management context. Inspect evidence SECTION 21 The AI-Native Definition of Done Done means accepted under current context, with enough durable context preserved to allow safe reconsideration when that context materially changes. A completion should record what was accepted, why, what it means, supporting evidence, dependencies, what changed, what was reused, what remains open, who accepted it, and how it can later be reconsidered. SECTION 22 The End State Autonomous Sensing. Assisted Reconsideration. Governed Adaptation. Humans increasingly retain authority over purpose, values, semantics, priorities, and consequential acceptance. AI increasingly assists with observation, retrieval, synthesis, option generation, impact analysis, validation, execution, and memory. The organization becomes stable by choice and adaptable by design . CONCLUSION Compounding Adaptation AI does not make completion obsolete. It makes permanent assumptions about completion increasingly dangerous. The defining capability may not be how much change an organization can generate, but how cheaply it can determine which changes are actually worth making. Everything meaningful should become explicitly done. Every done state should remain reconsiderable. Reconsider continuously. Change selectively. Stabilize deliberately. Preserve learning. TONY EDITION Abstract I used to think “done” meant something stronger than I do now. You built the thing. You tested it. You got it into production. The owner accepted it. Maybe you even survived the deployment without discovering that one more YAML file had opinions about your evening. At that point, you were done. I still believe in finishing things. In fact, I think finishing explicitly matters more in an AI world, not less. A release needs a terminal state. A decision needs an owner. A system needs an accepted baseline. People need to know what is current and what is not. What I no longer believe is that “done” gives an implementation permanent immunity from reconsideration. AI is changing too many of the economics underneath our decisions. Capabilities move faster. The cost of exploring alternatives is falling. New evidence shows up sooner. Requirements change. Dependencies change. User expectations change. Things that were economically stupid to rewrite a year ago can suddenly become rational to reconsider. That is what I mean by Completion Half-Life . A completed state is valid under the context in which we accepted it. It is not a lifetime warranty on the implementation. The answer is not permanent refactoring. That would be idiotic in a different direction. Stable systems have value. Operating evidence has value. User familiarity has value. Migration has a cost. Human beings have a finite tolerance for having their tools “improved” every Thursday. The better model is Continuous Reconsiderability : keep the current state explicit and stable, continuously watch the assumptions underneath it, reconsider when something material changes, and make the challenger prove that change is worth the full cost and risk. The deeper implication is about context. As implementation gets cheaper to generate and replace, the meaning around the implementation becomes more valuable. Intent, semantics, evidence, provenance, policy, dependencies, tests, decisions, and known failures become capital because they let us change without starting over intellectually every time. The real AI advantage is not the ability to make more things. We are already becoming absurdly good at that. The advantage is the ability to make better changes at a lower marginal cost without losing what we already learned . That is the thesis. Done Has a Half-Life — Thesis Framework Derived visual expression. Click to inspect the full-resolution original. Provenance SECTION 01 The Foundational Claim The first version of this thought was intentionally blunt: If something is done, you are losing. I do not think that survives contact with reality as written. Everything meaningful should become done. If the team cannot say when something is accepted, we have not created agility. We have created permanent ambiguity. A release can be done. A migration can be done. A policy can be accepted. An architecture can be current. A project can close. What I reject is the leap from: DONE(t0) to: DONE(∞) Those are completely different claims. The first says we satisfied the requirements, evidence, constraints, economics, and authority that existed when we made the decision. The second says the world is now obligated to stop changing. It has declined the invitation. So the core claim becomes: Everything meaningful should become explicitly done. Nothing meaningful should become permanently exempt from reconsideration. That gives us closure without complacency. SECTION 02 Completion Half-Life Completion Half-Life is the period over which an accepted implementation can reasonably keep its presumption of continuing fitness before changed conditions justify explicit reconsideration. I am deliberately saying reconsideration , not replacement. The world may change and the answer may still be: keep what we have. But the assumption has to be allowed back into court. What shortens the half-life? A materially better AI capability appears. New production evidence contradicts an assumption. Economics change. Requirements change. A dependency becomes obsolete or dangerous. Regulation or security changes. We simply learn enough from operating the thing to see it differently. Different layers should have different half-lives. Purpose should usually change slowly. Core semantics should be durable. Policy and constraints should change deliberately. Evidence and provenance should accumulate. Implementation, orchestration, prompts, model choices, and UI can move much faster. That leads to one of the central laws of the thesis: Freeze meaning. Free implementation. We have spent decades doing the opposite in enterprise technology. The code survives forever and everyone forgets why it exists. That is not durability. That is fossilization. Completion Half-Life Derived visual expression. Click to inspect the full-resolution original. Provenance Fact-check class: thesis construct. This is my proposed model, not a term I am borrowing from somebody else. The external research is contextual support, not ownership of the idea. SECTION 03 The Incumbent Still Matters There is a risk in all of this. Once AI makes rewriting easier, engineers can suddenly find a hundred reasons to rewrite everything. This is where the thesis needs a defense mechanism. The incumbent has real value simply because it exists and has survived reality. It has: operating history; known behavior; user familiarity; existing proof; integrations that already work; migration we do not have to perform; failure modes we already understand. So the current state gets an incumbency premium . The rule is not “new wins.” The rule is: ExpectedNetValue > MinimumImprovementThreshold where: ExpectedNetValue = ExpectedBenefit − FullChangeCost − RiskPremium And FullChangeCost means full change cost. Not the two hours the model needed to generate prettier code. Migration matters. Qualification matters. Training matters. Disruption matters. Security matters. Human attention matters. This is why I think the burden of proof belongs to change . The incumbent does not have to prove perfection. The challenger has to prove that it is sufficiently better to justify surrendering the value of stability. SECTION 04 Context Debt This is where the thesis starts getting more important than software lifecycle language. AI is getting better at reconstructing implementation. It is not getting magical powers to recover institutional truth that nobody preserved. Suppose I find this in code: if customer.age >= 62: apply_special_rule() A model can explain what the code does in milliseconds. Why 62? That might be regulation. It might be an old contract. It might be a product decision. It might be a workaround from 2019 that nobody remembers. It might simply be wrong. AI can generate a very persuasive explanation. Persuasive is not the same thing as true. That missing meaning is Context Debt . Context Debt is the future cost we create when meaning available today is not preserved and somebody later has to rediscover, reconstruct, infer, or guess it. It shows up as semantic debt, intent debt, provenance debt, dependency debt, evidence debt, authority debt, and learning debt. And we pay interest on it. People leave. Links rot. systems change. Memories become fiction with confidence intervals. Eventually the implementation becomes the only surviving record of what the organization knew. At that point you no longer own software. The software owns your institutional memory. Context Debt vs. Context Capital Derived visual expression. Click to inspect the full-resolution original. Provenance SECTION 05 Context as Capital The flip side of Context Debt is Context Capital . If we spend serious human or machine reasoning to solve something, the output should not automatically be a disposable answer. We should ask what residual asset deserves to survive. Maybe it is: a semantic definition; a decision and rationale; a policy; a test; a provenance link; a dependency edge; a known-failure detector; a reusable skill; an automation; an accepted artifact. That gives us a choice after expensive cognition: CONSUME COGNITION or CAPITALIZE COGNITION I care a lot about that distinction because AI makes it very easy to repeatedly buy the same reasoning. The model will happily rediscover the same lesson next Tuesday. It gets paid either way. The organization should care. So we can think about a Context Conversion Ratio : CCR = ReusableDurableKnowledgeProduced / ExpensiveReasoningPerformed A low-CCR organization keeps buying cognition. A high-CCR organization turns cognition into assets. That is how intelligence compounds. SECTION 06 Context Liquidity and Context Yield Context can exist and still be useless. If the answer is buried in someone's inbox, trapped inside a recording, contradicted by three other documents, or impossible to bind to the artifact it describes, we technically preserved something. Congratulations to the archive department. Operationally, we still have a problem. Context Liquidity is how easily preserved knowledge can be found, trusted, interpreted, combined, and applied. Context Yield is the future work we avoid or value we create because that context was preserved in usable form. A known failure that becomes a deterministic detector has yield. A decision record that prevents three weeks of architecture archaeology has yield. A dependency graph that tells us 94 artifacts can be reused while six need regeneration has yield. The rule is simple: Continuous improvement compounds only when learning becomes durable. Otherwise it is continuous rediscovery. From missing meaning to compounding value 01 Context Debt Meaning exists now but is not preserved, so the future pays to infer it again. 02 Context Capital Expensive reasoning leaves behind a durable reusable asset. 03 Context Liquidity The asset can actually be found, trusted, interpreted, combined, and applied. 04 Context Yield Future work disappears or future value appears because the knowledge is usable. Preservation creates inventory. Liquidity creates usefulness. Yield is the proof. SECTION 07 The Reconsideration Economy Every system contains an option. We can keep it, modify it, rewrite it, replace it, retire it, or leave it alone. Those options always existed. What changes is their exercise price. A rewrite that made no economic sense when it required 25 engineers and eighteen months may become interesting when AI can collapse repository analysis, implementation, migration planning, testing, and documentation. The old decision did not necessarily become wrong. The economics changed. That is the Reconsideration Economy : AI continuously reprices decisions we previously considered settled. This is why sunk-cost thinking becomes dangerous. “We just spent $3 million building that” tells me something about history. It does not automatically tell me what we should spend tomorrow. The better question is: Given what we know and can do now, is retaining this still the best use of future capital? That is a harder question. It is also the one that matters. The Reconsideration Economy Derived visual expression. Click to inspect the full-resolution original. Provenance SECTION 08 Reconsiderability Agile made feedback cheaper. DevOps made delivery cheaper. Cloud made infrastructure more disposable. AI is beginning to make reconsideration cheaper. That deserves its own system quality: Reconsiderability is the degree to which we can safely question, alter, or replace an accepted implementation without first reconstructing its meaning or throwing away valid evidence. Maintainability asks: Can we change this implementation? Reconsiderability asks: Can we safely decide that this should no longer be the implementation? A system can be beautifully maintainable and still be structurally trapped if nobody knows what behavior is sacred, what is accidental, what depends on what, or what proof remains valid. That is local agility without real optionality. SECTION 09 The Reconsideration Economy Is Not the Change Economy This is where I want to push back hard on my own thesis. AI can make candidate change abundant. That does not make customer tolerance abundant. It does not make executive attention abundant. It does not make governance capacity abundant. It definitely does not give human beings unlimited enthusiasm for having a familiar workflow redesigned because somebody discovered a slightly cleaner abstraction. So the winning organization should not change the most. It should become very good at change selectivity . Evaluate 100 possibilities. Pursue eight. Change three. Get real value from those three. Preserve the evidence behind why the other 97 did not clear the bar. That is a much better use of AI than generating 100 pull requests and congratulating ourselves on velocity. Evidence check. DORA gives us actual data for the throughput/stability tension. Inspect evidence SECTION 10 From Agile to Reconsiderable I do not think this is just Agile with a fresh label. The progression looks more like this: Waterfall: optimize the plan. Agile: optimize learning. DevOps: optimize delivery. Cloud: optimize infrastructure flexibility. AI-native engineering: optimize reconsiderability. The new question is not simply: What should we build next? It is increasingly: Given what we know and can do today, would we still choose to build and operate this system this way? That reaches backward into choices that Agile teams often inherit rather than reopen. AI is compressing the reconsideration loop. That is the actual shift. SECTION 11 Reconsider Before You Automate One of the easiest ways to waste AI is to take an existing process, automate it, and declare victory. Sometimes that is correct. Sometimes the process exists because of a constraint that disappeared three technologies ago. Then we get: ObsoleteProcess + AI = HighPerformanceObsoleteProcess Before automating a process, recover its purpose. Ask what constraint created each major step. Ask whether that constraint still exists. Remove what no longer deserves to exist. Then automate what remains. AI should not become the world's most efficient engine for industrializing historical stupidity. SECTION 12 The Continuously Reconsiderable Enterprise Once you accept Completion Half-Life for software, it gets uncomfortable quickly. Processes have half-lives. Roles have half-lives. Controls have half-lives. Vendor decisions have half-lives. Organization structures have half-lives. Strategic assumptions have half-lives. A continuously reconsiderable enterprise can explain why these things exist, which assumptions support them, what evidence says they are still useful, who has authority over them, and what depends on them. That does not mean reorganizing the company every six weeks. It means preserving the ability to discover that a six-year-old process was designed around a constraint that no longer exists. That is very different from “transformation.” It is institutionalized adaptability. SECTION 13 Stable by Choice This is the phrase that keeps the whole thesis from becoming nonsense: Stability is not the absence of reconsideration. Stability is the current outcome of reconsideration. A system can remain unchanged because nobody understands it. Or it can remain unchanged because we evaluated the current evidence and decided the incumbent still wins. Those look identical from Git history. They are completely different management states. The first is inertia. The second is discipline. I want systems to become boring when boring is the right answer. Boring is underrated. Boring production systems let people sleep. SECTION 14 The Operating System The thesis needs an actual loop or it is just something people nod at in a conference room. The operating loop is: SENSE → TRIGGER → RECONSIDER → DISPOSITION → TRANSITION → CAPITALIZE LEARNING → REPEAT Sense. Observe capability, evidence, economics, requirements, risk, and dependency changes. Trigger. Detect when an assumption supporting the current state may no longer hold. Reconsider. Compare the incumbent against available alternatives. Disposition. Decide what gets reused, revalidated, regenerated, requalified, retired, or superseded. Transition. Execute a bounded change under explicit authority. Capitalize Learning. Preserve whatever should make the next cycle cheaper. Most sensing should produce no change. That is not a bug. That is the system working. Operating System of Continuous Reconsiderability Derived visual expression. Click to inspect the full-resolution original. Provenance SECTION 15 Dependency-Aware Change If we are serious about changing selectively, we need to know what depends on what. A financial number changes. That might affect a calculation, a chart, an infographic, a PowerPoint, a report, an offline package, and three downstream decisions. Or it might affect exactly one table. The system should know the difference. Given a changed object x : ImpactClosure(x) = { y | y transitively depends on x } Objects inside that closure become candidates for regeneration or requalification. Objects outside should start with a presumption of reuse. This is how you stop paying to rebuild the universe because one number changed. SECTION 16 Accepted States Continuous reconsiderability requires explicit closure. Otherwise we are just continuously moving. Every material transition should end in an accepted state that can answer: What exactly is current? What does it mean? What evidence supports it? What depends on it? Who accepted it? What did it supersede? What proof was reused? What remains unresolved? Then the lifecycle becomes: State(t0) → BoundedChange → State(t1) The project ends. The knowledge lineage survives. That is the important part. SECTION 17 Learning Writeback This is the part we routinely skip because everybody is relieved the incident is over. A failure happens. We diagnose it. We repair it. Tests pass. Then six months later somebody pays to rediscover the same thing. That is not learning. The correct loop is: Failure → Diagnosis → Repair → Proof → Normalize Learning → Write Back → Future Prevention A repeated failure should become cheaper each time until eventually it is impossible, or at least embarrassing, to repeat. The same applies to architecture decisions, operating procedures, policy interpretation, and recurring analysis. Expensive cognition should leave a residue. SECTION 18 The Nine Laws Law 1 — Done Has a Half-Life No accepted implementation receives permanent immunity from new evidence. Law 2 — Freeze Meaning, Free Implementation Durable semantics should outlive temporary expression. Law 3 — Optimize for Safe Change The target is not cheap generation. The target is bounded, trustworthy improvement. Law 4 — Learning Must Compound Otherwise continuous improvement becomes continuous rediscovery. Law 5 — Optionality Without Instability Everything should remain reconsiderable. Not everything should constantly change. Law 6 — Preserve Meaning Before It Becomes Archaeology Never make tomorrow infer what today already knows. Law 7 — Reconsider Before You Automate Do not accelerate obsolete constraints. Law 8 — Preserve the Organization's Right to Choose Again Avoid unnecessary irreversibility. Law 9 — The Burden of Proof Belongs to Change A successor must overcome the economic value of the incumbent. SECTION 19 The North Star Metric If I had to reduce this to one operating metric, I would not use code produced, tickets closed, agents launched, or model tokens consumed. I would use something closer to Marginal Cost of Safe Improvement : MCSI = TotalIncrementalCost / VerifiedUsefulImprovement North Star candidate Marginal Cost of Safe Improvement MCSI = Total Incremental Cost Verified Useful Improvement The denominator is the discipline. Output does not count unless the improvement is verified and useful. The denominator is doing a lot of work there. More output is not automatically improvement. More automation is not automatically improvement. More change is definitely not automatically improvement. The goal is verified useful improvement at a progressively lower marginal cost without destroying stability, meaning, or trust. That is a much healthier optimization target. SECTION 20 The Case Against Continuous Improvement The thesis fails if people interpret it as permanent mutation. Migration cost is real. Verification can become the bottleneck after generation gets cheap. Human change fatigue is real. Regulation can intentionally slow change for legitimate reasons. Tacit knowledge does not disappear because we have embeddings. Security punishes unnecessary mutation. Context itself can become noisy and stale. And an incumbent that has been running successfully for ten years has earned credibility that a brilliant one-hour rewrite has not. A technically superior design can be an economically inferior decision. That sentence matters. The refined doctrine is therefore: Reconsider continuously. Change selectively. Finish explicitly. That is not as dramatic as “nothing is ever done.” It is a lot more useful. Evidence check. METR is useful precisely because it complicates the easy “AI always makes developers faster” story; NIST gives us the risk-management boundary. Inspect evidence SECTION 21 The AI-Native Definition of Done Traditional “done” asks whether we completed the thing correctly. The AI-native version should ask one more question: Did we leave enough durable context that the next qualified human or AI can reconsider this without starting from ignorance? So: Done means accepted under current context, with enough durable context preserved to allow safe reconsideration when that context materially changes. A strong completion leaves behind: what was accepted; why it was accepted; what it means; what evidence supports it; what depends on it; what changed; what was reused; what remains open; who accepted it; how it can later be reconsidered. Done should create a clean future starting point. That is a much more durable form of completion. SECTION 22 The End State I do not think the end state is an autonomous company where AI continuously rewrites everything while humans watch a dashboard and pray. The better model is: Autonomous Sensing. Assisted Reconsideration. Governed Adaptation. 01 · SENSE Autonomous Sensing machine-favored 02 · RECONSIDER Assisted Reconsideration shared reasoning 03 · ADAPT Governed Adaptation human authority AI becomes increasingly good at observation, retrieval, synthesis, option generation, impact analysis, validation, execution, and memory. Humans retain authority over purpose, values, semantics, priorities, and consequential acceptance. The boundary will move. The distinction should remain. Capability is not authority. Intelligence is not legitimacy. The organization becomes stable by choice and adaptable by design . CONCLUSION Compounding Adaptation AI does not make completion obsolete. It makes permanent assumptions about completion increasingly expensive. I do not think the winning organization will be the one that changes the fastest. That is too easy to game and too easy to regret. The winning organization will be the one that can continuously detect when the assumptions underneath an accepted state have materially changed, cheaply understand what that means, reject most unnecessary change, and move deliberately when a successor is actually worth the price. Then it will stabilize again. And, critically, it will preserve what it learned so the next decision does not begin from zero. That is the distinction I care about. Not perpetual transformation. Not complacency. Compounding adaptation. Not perpetual transformation. Not complacency. Compounding adaptation. Everything meaningful should become explicitly done. Every done state should remain reconsiderable. Reconsider continuously. Change selectively. Stabilize deliberately. Preserve learning. Thesis contents 01. The Foundational Claim 02. Completion Half-Life 03. The Incumbent Still Matters 04. Context Debt 05. Context as Capital 06. Context Liquidity and Context Yield 07. The Reconsideration Economy 08. Reconsiderability 09. The Reconsideration Economy Is Not the Change Economy 10. From Agile to Reconsiderable 11. Reconsider Before You Automate 12. The Continuously Reconsiderable Enterprise 13. Stable by Choice 14. The Operating System 15. Dependency-Aware Change 16. Accepted States 17. Learning Writeback 18. The Nine Laws 19. The North Star Metric 20. The Case Against the Thesis 21. The AI-Native Definition of Done 22. The End State Publication state Pre-CI: package prepared, wrapper not bound. Graph: 75 nodes · 124 edges. Evidence: 5 admitted sources · 9 classified claims. Theme: SharePlane wrapper-owned. Done Has a Half-Life By Tony Malott · Thesis author & originator Done Has a Half-Life · v0.3.0 · Design OS local candidate Reference semantic SHA-256: 68dd41395565f4fbcfd5e166fdfae8e2418a1e626c9fc0cf7f44629f2678509d Tony Voice projection SHA-256: bad92812e96552031cf77c1213c5d4d8a4bfff4a7f1368e6b14a070940b69454 Graph + provenance + wrapper hooks bound Visuals remain derived expressions of authoritative text. Close Details × Related work Follow the argument through the graph. These links are projected directly from canonical reader relationships. Outgoing cards preserve this Work's authored reading directions; cards labeled Points here are derived from other public Works whose canonical edges target this Work. Foundations The Semantic Operating System The Semantic Operating System establishes identity, authority, evidence, freshness, and next-valid-action semantics; this Work extends that substrate into a temporal discipline for reconsidering accepted completion. Foundations The Code Is No Longer the Hard Part The earlier Work explains how cheaper implementation moves value into intent, context, evidence, and integration; this Work carries that inversion forward by treating continued fitness and safe improvement as lifecycle concerns. Companions The Application Is Disposable. The Context Is Not. The companion Work explains why governed context outlives a replaceable implementation; this Work explains how context liquidity makes later reconsideration and adaptation safer and more economical. Companions The Most Expensive Model Is Often Compensation for Missing Control The control Work shows how intent, routing, authority, and validation reduce trusted completion cost; this Work applies the same discipline to the marginal cost of safe improvement after acceptance. Applications Software Has Entered Its Re-Image Era The Re-Image Work makes maintenance compete with reconstruction once product truth is durable; this Work adds a governed trigger and economic vocabulary for deciding when an accepted implementation deserves another look. Field Evidence Four Days That Changed the Scale of One Engineer The field report measures one accountable operating system built from context, authority, verification, protected review, and durable learning; it is a bounded operational companion, not empirical proof of the thesis constructs. Points here · Foundations Cognitive Capital Context Capital, Context Liquidity, Context Yield, and reconsiderability supply the lifecycle logic that Cognitive Capital generalizes. Evidence and boundaries Inspect what supports the argument. Field evidence, corroboration, counterevidence, prior art, and authority remain distinct. The machine receipt stays available below; the reader-facing evidence cannot be hidden only inside it. External corroboration State of AI-assisted Software Development 2025 Scoped delivery and organizational context External corroboration Balancing AI tensions: Moving from AI adoption to effective SDLC use Scoped current AI-assisted delivery context External corroboration Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity Narrow productivity evidence with scope limits Counterevidence We are Changing our Developer Productivity Experiment Design Follow-up qualification of the earlier productivity result External corroboration Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile Governance and trustworthiness context Authority and lineage SharePlane Platform Issue #723 Semantic, Creative Lock, package repair, and bounded execution authority Boundary What this does not claim Public-safe systems thesis. Conceptual constructs are not calibrated physical or statistical laws. The prior failed ZIP remains integrity-learning evidence and is not execution authority. SOURCE REFERENCES State of AI-assisted Software Development 2025 https://dora.dev/research/2025/dora-report/ Balancing AI tensions: Moving from AI adoption to effective SDLC use https://dora.dev/insights/balancing-ai-tensions/ Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/ We are Changing our Developer Productivity Experiment Design https://metr.org/blog/2026-02-24-uplift-update/ Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence SharePlane Platform Issue #723 https://github.com/pinklon/shareplane-platform/issues/723