Deployment & institutions
How internal model mechanisms interact with the infrastructure, institutions, and economies in which models are deployed, and when persistence is a fact about the model versus a fact about the world.
A deployed AI system is not just a model. It is a model plus an API, a workflow, a revenue line, a set of retrained staff, and an institution that no longer remembers how the pre-AI process worked. This programme studies that composite object, with one organising distinction: model entrenchment (persistence arising from a model's internal representations, objectives, awareness, or behaviour) versus AI-system entrenchment (persistence arising from infrastructure, capital, switching costs, and social dependence).
The distinction matters because the two are routinely conflated in both directions. 'We can't turn it off' usually describes economics but sounds like agency; genuinely evaluation-conditional behaviour could hide inside systems whose persistence is fully explained by dependence. The two require different evidence (mechanistic for the first, institutional for the second), different interventions, and different governance responses.
The programme's method is deliberately mixed: interpretability results as evidence inputs to institutional decisions; case coding of real removal difficulties; and an economics strand on the capital markets forming around compute, because dependence has a financial substrate.
Model entrenchment
Persistence caused by the model's own representations or behaviour; the interpretability-facing half of the programme.
AI-system entrenchment
Persistence caused by external dependence: integration depth, switching costs, lock-in, absent substitutes.
Infrastructure dependence
Compute, data pipelines, and the physical substrate a deployment accretes.
Institutional lock-in
Workflow redesign, deskilling, procurement, and regulatory approval of incumbents.
Economic dependence
Revenue attribution, compute finance, and the markets that make removal expensive.
Model replacement & shutdown
What removal actually requires, and what makes it costly in practice.
Deployment-to-training feedback
How deployment data and dependence shape the next training run.
Interpretability as evidence
What probe and steering results should institutions demand before granting a system load-bearing status?
- For systems documented as hard to remove, what share of the difficulty is attributable to model behaviour versus external dependence?
- What is the right formal object for 'persistence pressure', a decomposable quantity, or only a qualitative coding?
- What early-warning representational evidence would precede genuinely model-side persistence?
- What disclosure standard should precede load-bearing deployment?
Methods in use or proposed: Two-axis case coding with pre-registered rubrics · institutional analysis · compute-market modelling · proposed activation-level experiments (with Programme 03).
A short orientation list of primary sources, not a survey. The Interpretability Map holds the full dependency graph.
- David, P. A. (1985). Clio and the Economics of QWERTY. American Economic Review, 75(2).
- Arthur, W. B. (1989). Competing Technologies, Increasing Returns, and Lock-In by Historical Events. Economic Journal, 99(394).
- Omohundro, S. (2008). The Basic AI Drives. Proceedings of AGI 2008.
- Soares, N., Fallenstein, B., Yudkowsky, E., & Armstrong, S. (2015). Corrigibility. AAAI Workshop on AI and Ethics.
- Turner, A., et al. (2021). Optimal Policies Tend to Seek Power. NeurIPS 2021. arxiv.org/abs/1912.01683