Failure and Learning Solvency

Failure Is Inevitable - Debt Is Optional

Developing mycelium technologies in real-world, commercial contexts means working in motion. By design, processes advance to the next stage of maturity while meaningful uncertainty remains unresolved. Progressing with scaled demonstrations before process stationarity is proven can provide a valid learning opportunity that balances rigor and speed. In most scenarios this is a structural reality of applied development. Waiting for complete resolution at each stage may actually slow progress and throttle learning. Instead, development proceeds through successive step-ups in scale and commitment, using minimum viable performance thresholds as permission to move forward.

Considering this, failure is the natural consequence of deliberately challenging the operational space of a system that is still becoming what it will be. Each increase in scale, duration, or integration exposes the technology to conditions it has not yet fully encountered. Interactions that were negligible at one stage begin to dominate at the next. When failure appears at these transitions, it reflects latent uncertainty becoming operationally exposed under new constraints, not simply a breakdown of execution.

In this sense, failure can be understood as actualized uncertainty. Latent uncertainty is always present in complex systems: untested assumptions, unexplored regions of the response surface, sensitivities yet to be provoked. Scaling, then, can become an opportunity; a forcing function that pulls that uncertainty into the open, revealing structure that was previously invisible or irrelevant. These moments are unavoidable in technologies that advance by staged exposure rather than full prior resolution.

Lets borrow the language of technical debt and solvency as a useful metaphor for how uncertainty is incurred, carried, repaid, or allowed to compound in applied R&D. For our purposes here, technical debt begins where uncertainty stops being usable. At its core, technical debt is uncertainty (latent or actualized) that has not been operationalized into a form that can guide future decisions. When a failure does not reduce uncertainty, bound behavior, or refine the working model of the system, it leaves residue. That residue accumulates as hidden assumptions, partial explanations mistaken for understanding, and fragile alignments carried forward into subsequent development stages.

This distinction is especially sharp in mycelium R&D because mycelium systems amplify uncertainty as scale and time increase. The fundamentals of phenotypic plasticity ensure that behaviors expressed at one scale may not persist analogously at the next. Under these conditions, the relevant question is whether uncertainty, once exposed by a step-up in maturity or scale, is transformed into something functional. Uncertainty that can be named, bounded, and used to constrain future choices has learning value. Uncertainty that cannot becomes technical debt.

At scale, the danger is that practical interpretation of process variance and failure becomes inaccessible. As unresolved uncertainty accumulates across development stages, systems grow harder to reason about. Decisions lean more heavily on momentum, precedent, or urgency than on understanding. In extreme cases, the remaining uncertainty exceeds the system’s capacity to interpret its own behavior. This is catastrophic technical debt: not an immediate collapse, but a gradual erosion of epistemic solvency as the technology advances faster than its capacity to learn.

In development paths defined by successive increases in scale and maturity, failure is inevitable. Learning is not. Failure merely exposes uncertainty; learning requires that uncertainty revealed at each step be deliberately converted into constraints that guide the next one. What separates productive failure from accumulated debt is not effort or speed, but design: the discipline of using each step-up in scale to transform exposed uncertainty into operational knowledge rather than deferred cost.

Failure as Pedagogy

What follows may be obvious from an experimental perspective, from the vantage point of structured design-of-experiment or initial process development. But it is worth stating explicitly because as scale, cost, and stakes increase, these principles erode faster than almost anything else in the system. Pressure to move, recover, and demonstrate progress can aggressively override the discipline that makes failure useful. When that happens, failure stops teaching.

If failure is the moment latent uncertainty becomes visible, then pedagogy determines whether that visibility produces learning. Failure on its own doesn’t teach; it only actualizes uncertainty. Whether that uncertainty becomes usable, and able to guide the next decision, depends on how failure is situated within the learning system. A productive failure is one where actualized uncertainty gets operationalized. The failure reduces the amount of latent uncertainty remaining in the system by bounding behavior, invalidating assumptions, or refining the working model used to reason about what comes next. Even when outcomes are undesirable, productive failures perform useful work. They reveal structure; the system becomes easier to reason about than it was before.

An unproductive failure also actualizes uncertainty, but doesn’t transform it. Causality remains ambiguous and assumptions remain intact. The failure is experienced, sometimes forcefully, but it doesn’t reduce the uncertainty that generated it. In these cases, uncertainty persists in a non-operational form, present but unusable, setting the conditions for technical debt.

Consider a fermentation system being developed, stabilized, or interrogated across multiple runs. A coherent set of input parameters is deliberately controlled and a consistent set of measurements is collected over time. Growth rate, gas exchange, temperature, moisture, and a handful of derived features are measured the same way across runs. Individual runs may fail (stalling early, overshooting targets, or collapsing), but these failures are productive. Because the same response characteristics are tracked coherently, each failure actualizes uncertainty in a form that can be compared, modeled, and carried forward. Over time, previously latent sensitivities become explicit. Even when variables are aliased, they exist within a shared representational space, allowing uncertainty to be progressively reduced rather than merely exposed.

Now consider the same system under different conditions. Measurements are collected inconsistently, or not at all. Input parameters drift informally. Operators adapt in real time without recording how or why. Failures still occur, but they don’t teach; uncertainty is actualized, but the absence of coherent measurement prevents it from being operationalized. Variables remain aliased without resolution. Outcomes can’t be meaningfully compared across runs. The uncertainty revealed by failure can’t be used to refine the working model of the system, and therefore doesn’t reduce the latent uncertainty that remains.

A particularly common contributor to this pattern in rapid development environments is the belief that failed runs aren’t worth measuring. Once a run is deemed “failed” data collection becomes qualitative or incomplete, and attention shifts toward recovery or replacement rather than characterization. This attitude is rarely stated explicitly, but it is widespread. It rests on the assumption that failed outcomes are epistemically inferior to successful ones. In practice, this reverses the learning logic. By withholding measurement precisely when uncertainty is most concentrated, and most acutely surfaced, failure is prevented from doing its pedagogical work.

In the first case, failure converts latent uncertainty into operational knowledge. In the second, it merely reveals uncertainty without transforming it. Pedagogical failures interrogate structure rather than performance, revealing where assumptions break, where sensitivities dominate, and where boundaries lie. Failures treated as unworthy of measurement may feel expedient in the moment, but they preserve uncertainty rather than resolving it. When failures are structured to operationalize uncertainty, they contribute to learning even when outcomes are poor. When they’re not, failure accumulates. Uncertainty that remains non-operational is carried forward into subsequent development stages, where it reappears as technical debt.

Technical Debt as Accumulated Uncertainty

Technical debt is often described in the context of software engineering: shortcuts taken under time pressure, incomplete consolidation, messy code, missing documentation, or things to be cleaned up later (Cunningham, 1992; Besker, 2020). Even in software engineering, however, technical debt is increasingly understood not simply as poor implementation, but as deferred cost that compounds over time and remains invisible until systems become difficult to change or interpret. In experimental systems, and especially biological ones, this metaphor breaks down further; technical debt is a problem of unresolved assumptions embedded in the system itself by design decisions.

In experimental terms, technical debt accumulates when uncertainty is actualized but not resolved operationally. It appears as deferred validation, where assumptions persist because the system appears to be working; as partial explanations mistaken for understanding; and as fragile alignments mistaken for robustness. Empirical studies of technical debt show that unresolved liabilities can persist for long periods, increasing complexity, reducing maintainability, and degrading the system’s capacity to support future change even while the system continues to function acceptably on the surface (Besker, 2020; Chowdhury et al., 2025).

One pathway to this kind of debt is poor experimental structure. Experiments are run sequentially without a coherent design linking them. Conditions shift opportunistically and measurements vary run to run. Outcomes are judged primarily on pass/fail criteria rather than on how they update understanding. Individual runs may succeed often enough to justify continuation, but they do little to resolve how or why the system behaves as it does. Research on technical debt consistently shows that carrying unresolved issues forward increases complexity and degrades a system’s ability to support future change or reasoning (Besker, 2020; Chowdhury et al., 2025).

Another pathway is the systematic under-measurement of negative results. Failed runs are absorbed into narrative explanations rather than data. A batch stalls and is attributed to contamination, operator error, or bad luck, without collecting the same measurements that would have been gathered had it succeeded. Educational and cognitive research on learning from error emphasizes that errors and failures support learning when they are processed, interpreted, and situated within conditions that make learning from them possible; dismissed or unexamined errors are far less likely to improve understanding (Narciss & Alemdag, 2025). In experimental systems, this practice actualizes uncertainty without operationalizing it, preserving the very assumptions that produced the failure.

A third, especially insidious pathway is guess-and-check experimentation. Here, experimental choices are driven by intuition or urgency. A condition is selected, tested, and evaluated against a binary outcome: did it work or not? If it fails, a different guess is tried. If it succeeds, it is repeated or scaled. Studies of startups and rapid development environments show that intentionally taking on technical debt to move quickly can be rational in the short term, but becomes costly if not paired with deliberate resolution (Besker, 2020). Because individual runs are not structured to reduce uncertainty beyond their immediate outcome, learning remains local and fragile. Confidence increases without comprehension, and technical debt accumulates beneath apparent progress.

What makes technical debt dangerous, in many cases, is precisely because the process continues to perform. The danger is that interpretability erodes before performance does. Empirical work on technical debt shows that unresolved liabilities can be associated with increased complexity, lower readability, higher bug/change tendency, wasted developer time, and reduced maintainability, often before they appear as catastrophic failure (Besker, 2020; Chowdhury et al., 2025). Decisions shift from constraint-based reasoning to habit, precedent, or momentum.

At this point, technical debt becomes a learning crisis. Systems heavy with accumulated uncertainty lose the ability to reason about themselves. They struggle to distinguish structural limits from incidental variation, or minor perturbations from regime shifts. Even experienced operators find meaningful intervention difficult, because the system no longer provides interpretable feedback. Across engineering and learning sciences, the conclusion is consistent: unresolved uncertainty does not remain static. It compounds, narrowing the system's capacity to adapt, and ultimately, to survive.

Humans, Speed, and Zero-Sum Development

When uncertainty accumulates without being operationalized, it redistributes as cognitive load. The humans operating the system absorb what the system should have resolved: stress, vigilance, improvised workarounds, and institutional memory holding fragile systems together. Decisions organize around urgency as the norm: what must happen now, what keeps things running, what avoids immediate risk. And from here, temporary workarounds ossify into procedure.

Under these conditions, the risk is that activity accelerates while understanding stagnates or regresses. This is zero-sum development: effort that merely preserves the current state rather than advancing it, but under the belief that advancement is occurring. Feedback loops shorten without deepening, while time consumed exceeds insight returned. The organization becomes proficient at recovery and incompetent at resolution. From outside, pace appears rapid, but internally the system is running in place. Zero-sum development persists because it fills time convincingly while leaving learning capacity and pace unchanged. There is always something breaking, always something demanding response. Failures trigger correction, but not necessarily interrogation. This reinforces the conditions that accumulate debt: deferred validation, incomplete understanding, incomplete or wrong resolutions carried forward under pressure.

As this pattern entrenches, it can degenerate into a particularly dangerous headspace: the expectation that a single process change or experiment 'just has to work.' Under mounting pressure, with runway or resources finite, organizations begin placing disproportionate weight on individual interventions. A parameter is adjusted, a new substrate formulation is tested, a different inoculation strategy is deployed; the implicit assumption is that this one change will resolve the accumulated uncertainty that has been building for months. 

But it doesn't have to work. The system is under no obligation to resolve just because the intervention was attempted. Serial attempts at ‘magic bullet’ improvements, each one absorbing runway and resources that could have been deployed more deliberately, can squander the very capacity needed to learn systematically. The debt accumulated through these big swings, each one failing to operationalize the uncertainty it was meant to resolve, can become overwhelming.

As debt compounds further, learning bandwidth collapses. Fewer experiments target uncertainty reduction; more simply maintain operability. The system's capacity to learn diminishes as the need for learning intensifies. At the extreme, all remaining work becomes debt service. Every effort preserves operability rather than expands capability. Progress halts not because the technology has reached its limits, but because the organization has lost the ability to reason forward.

Technical Debt as Leverage

It is a bit unfair to frame technical debt strictly as accumulated burden eroding interpretability, increasing human load, and threatening progress. That captures its risks, but it misses its role as powerful and valuable leverage for accelerating development within the complexities of applied work. In applied development technical debt is, more often than not, incurred intentionally. In many cases, it's what allows development to proceed at all.

Borrowing against future understanding is structural to real-world experimentation. Early-stage systems are poorly bounded, high-dimensional, and plastic. Full resolution at these stages is rarely practical and often unnecessary. Development advances by moving forward while uncertainty remains, using partial resolution to test feasibility, expose dominant constraints, and determine whether further investment is justified. Technical debt functions as leverage, as uncertainty carried forward deliberately to accelerate learning in other high impact areas; as a means of continuously optimizing experimental effort to maximum impact. 

Whether this leverage remains productive depends on whether uncertainty stays bounded and visible. Like financial leverage it is profoundly dangerous, but with healthy respect for that danger, and skilled management of risk, it is a powerful tool for accelerated returns. Deferred resolution must be acknowledged as deferred. Unresolved assumptions must be flagged for repayment, with some clarity on when and how. When uncertainty is deferred without these conditions, its cost risks accumulating silently as declining interpretability, increasing process brittleness, and stunted progress.

Technical debt can be treated as an experimental variable rather than an incidental byproduct. It can be chosen, tracked, and bounded in time and scale. Decisions not to disambiguate a mechanism, not to stabilize a parameter, not to resolve a dependency are reasonable when explicit and revisitable. What matters is that uncertainty remains legible rather than dissolving into implicit assumption. This conflicts with ideals of experimental completeness. 

No one working in industry should be using full factorial designs—unless, of course, you can use a full factorial design. The dichotomy is intentional. Realistically, applied contexts won't grant practical opportunity to fully resolve experimental space through exhaustive factorial coverage, but full factorials remain the ideal precisely because they leave no white space for uncertainty to hide. In practice sparse designs, staged interrogation, and minimum viable knowledge-building, are adaptations to this reality. They accept uncertainty temporarily to make progress possible while preserving the option to resolve it later.

Maturity, then, is the ability to manage uncertainty as debt; to manage the repayment schedule respective to maximizing impact. Mature development recognizes when uncertainty can be carried forward safely and when it must be reduced before further progress is feasible. It watches for signals that debt is becoming costly: growing reliance on heroics, diminishing learning returns, flat KPI trends. It creates space for repayment; experiments that can resolve uncertainty that is weighing on operations and learning. In this way, experimental learning centers on maintaining tangible learning solvency. Progress depends on the ability to incur uncertainty deliberately, track it explicitly, and resolve it before it undermines the system's capacity to learn.

Technical Debt Management as Practice

Beyond taking on debt or paying it down in some absolute sense, the broader goal is to understand whether the system is moving toward solvency or away from it. Debt is a dynamic quantity managed over time through deliberate observation of how the system is changing, and learning solvency is the continuous output from that management process over the length of development.

For the sake of tracking learning solvency we can consider a small number of systemic qualities that can signal the trajectory of debt, stress, and learning, and guide decisions about when to borrow and when to repay. They reveal whether uncertainty is being operationalized or deferred, whether learning is compounding or collapsing, and whether the organization retains capacity to effectively reason about the system under development.

Performance Trajectories

We care about the absolute KPI performance at a given point over the length of development, but what matters perhaps more is trajectory: rate, direction, and deflection in the evolution of performance over time or per unit human and capital effort. A system advancing rapidly but with flattening gains sends a different signal than one advancing slowly with accelerating returns. The former may be running on momentum; the latter may be building leverage.

Tracking trajectory requires active statistical and visualization tools that surface changes in rate, not just absolute achievement. Is performance compounding, plateauing, or eroding? Are gains requiring progressively more effort? Simple trend analysis, rolling derivatives, or cumulative performance plots make deflection visible before it becomes a crisis. When performance trajectories flatten or reverse without clear external cause, unresolved uncertainty is often beginning to dominate. This triggers a shift toward debt repayment rather than new borrowing.

Regime Awareness

Mycelium systems, during development and maturation are, by definition, nonstationary. Rules governing behavior at one stage of scale or propagation may not apply at the next. A regime shift is a fundamental change in the drivers or structure organizing system behavior. Recognizing when a shift has occurred determines whether existing knowledge remains valid or whether new uncertainty has been introduced.

Regime awareness asks: Is the system stationary or non-stationary? Are relationships between inputs and outputs holding, or have they changed? Is variance increasing or stabilizing? Is the fraction of the system we understand growing or contracting? 

Practical signals include sudden sensitivity to parameters that were previously negligible, coherence loss in models that previously held, or behaviors with no precedent in prior runs. When regimes shift, borrowing becomes riskier. Assumptions made under previous conditions may no longer rationalize behavior, and debt taken on in one regime may not be repayable in the next. Regime stability creates opportunity to carry uncertainty forward safely, knowing learning from one run will transfer to the next.

Uncertainty Evolution

Uncertainty is definable and trackable. The critical signal: is it expanding or contracting over time? Is the system becoming easier or harder to reason about? Are areas of uncertainty being resolved, or is new uncertainty appearing faster than old uncertainty is eliminated?

In model-centric iteration, this becomes actionable: if a model is retrained as the system evolves, is the coefficient of determination, meaning how much of the observed variation the model can explain, improving, stable, or degrading? Is model structure becoming simpler or more complex? Are previously significant terms dropping out, or are new interaction terms required to maintain fit? Drift in model structure or performance indicates expanding uncertainty. The system is revealing sensitivities or dependencies that were not present, or not visible, before. Models that stabilize, simplify, or improve predictive performance signal that uncertainty is being operationalized. The system is becoming more interpretable.

Outside formal modeling, uncertainty evolution can be tracked through aliasing reduction, narrowing of plausible explanations, or progressive elimination of alternative hypotheses. The discipline is to ask regularly: Are we learning our way out of uncertainty, or discovering we understood less than we thought?

Heroics as Diagnostic

The human system is part of the experimental system. When individuals compensate for fragile processes through improvisation, vigilance, or institutional memory, the system is offloading interpretive work onto people rather than resolving it structurally. Heroics are a lagging indicator of accumulated debt, and perhaps one of the most reliable.

This matters because the interaction between the technical system under development and the human system trying to develop it is mediated by real stresses. Economic pressures, career pressures, political pressures; the full range of fears and anxieties that intensify under conditions of high capital commitment, meaningful uncertainty, and visible personal consequence. In scale-intensive development with real risk of failure, the psychological load is structural, representing a real and profound interaction layer between the human system and the mycelium system being developed. Through this layer people absorb the system's fragility as their own, and that absorption has costs that compound alongside technical debt.

Much of the hero narrative around technology development (innovation, risk-taking, moving fast and breaking things) is willfully dense to this reality. It treats stress as motivational fuel rather than interpretive distortion. It valorizes individual heroics while ignoring that heroics are often a symptom of systems that have lost the capacity to support the people operating them. The person pulling all-nighters to keep a fragile process running is not demonstrating grit, they are servicing debt the system should have resolved structurally. When this becomes normalized, when heroics are celebrated rather than interrogated, the organization risks losing its ability to distinguish between productive strain and learning collapse.

The diagnostic is effort allocation. Where are the bulk of human hours going? Toward sound behavior directed to real learning informed by real trajectories (structured experiments, coherent measurement, model refinement, assumption testing) or toward reactive triage? Do failures trigger interrogation or correction? When performance drops, are responses deliberate and experimental, or guess-and-check adjustments disconnected from a working model?

Heroics increase when uncertainty is high and legibility is low, signalling a reversion to individual problem-solving because the system no longer provides interpretable feedback. If the majority of effort is consumed reacting to instantaneous variance rather than interrogating structure, the system is insolvent. When effort shifts back toward proactive experimentation, when failures are measured rather than dismissed, and when operators reason from constraints rather than urgency, solvency is improving.

Signals and Solvency

These four qualities - performance trajectories, regime awareness, uncertainty, and heroics - compose. Flattening performance trajectories often coincide with expanding uncertainty and increasing heroics. Regime shifts introduce new uncertainty, which manifests as performance instability before heroic actions rise to compensate. The discipline is to track all four continuously and treat their collective trajectory as a guide for debt management decisions. When trajectories are positive (performance compounding, regimes stable, uncertainty contracting, heroics declining) the system may have capacity to take on debt. New uncertainty can be taken on deliberately because the organization retains bandwidth to operationalize it later. When trajectories are negative, borrowing becomes dangerous. Every new source of uncertainty adds to a system already struggling to interpret itself. Under these conditions, the rational move is repayment: experiments designed to reduce uncertainty, stabilize regimes, and restore interpretability.

It is a practice of continuous observation. The goal is not to eliminate debt, but to remain solvent: to ensure the rate at which uncertainty is being operationalized exceeds the rate at which it is being incurred. Solvency is dynamic and requires tracking, adjustment, and the discipline to shift resources toward repayment before the system loses capacity to learn its way forward.

In mycelium R&D, where the principles of phenotypic plasticity ensure that behaviors expressed at one scale may not persist at the next, and where real human consequences compound alongside technical uncertainty, this practice becomes essential. Failure remains inevitable. Learning does not. What separates productive development from epistemic collapse is the deliberate conversion of exposed uncertainty into operational knowledge. The system that maintains this discipline, that tracks its own capacity to learn, respects the human cost of fragility, and treats debt as leverage rather than burden, retains the ability to reason its way forward. The system that does not eventually finds that all remaining work is debt service, and progress halts not because the technology has reached its limits, but because the organization has lost the ability to learn.

References

Besker, T. (2020). Technical debt: An empirical investigation of its harmfulness and on management strategies in industry [Doctoral thesis, Chalmers University of Technology]. Chalmers Research. https://research.chalmers.se/en/publication/518318

Chowdhury, S., Kidwai, H., & Asaduzzaman, M. (2025). Evidence is all we need: Do self-admitted technical debts impact method-level maintenance? arXiv. https://doi.org/10.48550/arXiv.2411.13777

Cunningham, W. (1992, March 26). The WyCash portfolio management system [Experience report]. OOPSLA ’92. https://c2.com/doc/oopsla92.html

Narciss, S., & Alemdag, E. (2025). Learning from errors and failure in educational contexts: New insights and future directions for research and practice. British Journal of Educational Psychology, 95(1), 197–218. https://doi.org/10.1111/bjep.12716