Digital and Software Environments › Limitations and Impact

Real software is much messier than the small state machine this chapter has examined. A few limitations deserve careful spelling out.

Heterogeneity. A spreadsheet, desktop editor, and issue tracker have different observations, transition conventions, and task goals. Transfer must be tested rather than inferred from a common "software" label. Modular observation tools and workflow rules are one possible design; this chapter provides no evidence that such scaffolding generally dominates learned-model performance.

Learned dynamics and explicit contracts. Use a schema to constrain structure, a test to verify a covered assertion, and a dynamics model to predict effects. Only a complete executable specification justifies writing a specified transition kernel

$$T_{\mathrm{spec}}(s'\mid s,a).$$

That notation is not a claim that an OpenAPI document, type, or test suite already supplies the kernel. A hybrid can use formal constraints wherever their coverage is established and learned predictions where uncertainty remains. Its comparative performance needs evaluation.

Verification is neither free nor universal. A read can be unauthorized, stale, expensive, or rate-limited. Deletion does not always make evidence impossible: a tombstone or audit log may remain, if the agent may read it. Conversely, a visible record need not be attributable to the action under evaluation. Treat verification as an information-gathering action with explicit costs, as in the earlier Part VII discussion.

Task success conflates capabilities. The experiment made this numerically explicit: two policies can achieve different task-success scores for entirely different reasons. We can write task success as a composition, though the decomposition below is schematic rather than an exact identity:

$$\text{success} = f(\text{model}, \text{policy}, \text{observation}, \text{recovery})$$

where:

• $\text{success}$: the overall task-success rate
• $f$: a composite function bundling four capability factors into one scalar
• $\text{model}$: the quality of the transition model
• $\text{policy}$: the quality of the planning or control policy
• $\text{observation}$: the coverage and reliability of state observations
• $\text{recovery}$: the ability to detect and correct failures

A single scalar does not identify which capability caused a success or failure. Report predictive fidelity and calibration, observation coverage, policy performance, recovery outcomes, and costs separately. Part XI develops this evaluation perspective further.

Reset has a controlled boundary. Replays are useful when the fixture restores every relevant state component and external effects are isolated. Production may instead require compensation, audit-preserving corrections, or manual approval. A policy trained with low-cost reversibility should be reevaluated when those assumptions no longer hold.

Software fixtures let us examine prediction and feedback with explicit states and executable checks. The benefit comes from the chosen observation and control boundary, not a guarantee that software exposes truth cheaply. The next chapter turns to scientific, medical, and social environments, where the evidence available after an intervention can be delayed, incomplete, or confounded.