{"resolved":true,"match_type":"uuid","source_type":"original_book","book_id":"24410bf1-91f1-4e6b-9613-e64f0132d341","title":"The Stack On Software and Sovereignty","author":null,"edition":null,"publisher":null,"year":null,"isbn":"9780262029575","requested_by":"printed_page","book":{"source_type":"original_book","book_id":"24410bf1-91f1-4e6b-9613-e64f0132d341","id":"24410bf1-91f1-4e6b-9613-e64f0132d341","uuid":"24410bf1-91f1-4e6b-9613-e64f0132d341","title":"The Stack On Software and Sovereignty","normalized_title":"thestackonsoftwareandsovereignty","author":null,"edition":null,"publisher":null,"year":null,"isbn":"9780262029575","isbns":["9780262029575"],"parsed":true,"ai_readable":true,"document_type":"book","page_count":517,"navigation_url":"https://workshop.closeclaw.top/ai/book/24410bf1-91f1-4e6b-9613-e64f0132d341","title_url":"https://workshop.closeclaw.top/ai/title/The%20Stack%20On%20Software%20and%20Sovereignty","fixed_page_url_template":"https://workshop.closeclaw.top/ai/book/24410bf1-91f1-4e6b-9613-e64f0132d341/page/{printed_page}","path_api_url_template":"https://workshop.closeclaw.top/api/ai/book/24410bf1-91f1-4e6b-9613-e64f0132d341/page/{printed_page}","read_url":"https://workshop.closeclaw.top/api/ai/read/24410bf1-91f1-4e6b-9613-e64f0132d341","page_url":"https://workshop.closeclaw.top/api/ai/books/24410bf1-91f1-4e6b-9613-e64f0132d341/page","search_url":"https://workshop.closeclaw.top/api/ai/books/24410bf1-91f1-4e6b-9613-e64f0132d341/search"},"page":{"printed_page":50,"pdf_page":68,"physical_index":68,"physical_index_base":0,"printed_page_status":"recognized","page_sha256":"807c2be1832a7ebcceb04db9c476447e5360d3ca1abb8ec07739142534068e91"},"chapter":"Fheck The Stack |On Software and Sovereignty Benjamin H. Bratton","content":"13. Ideal platforms not only act on new interactions according to programmed rules and in relation to archived structured information, but also serve as distributed sensing systems that incentivize the detection of errors (or mere anomalies), which are interpreted by the platform ’ s formal models. In principle, what are interpreted as errors will not only update the model ’ s description of the whole, but will also correct the rules by which future interactions are governed. Ideal platforms also treat anomalies not only as errors but as signals of emergent patterns or norms for which some new positive accommodation may be required.\n\n14. The competition between platforms may occur over new tabula rasa space or over the recomposition of one or more existing systems in accordance with a platform ’ s strategy. To date, many successful platforms are those that provide Users with new capabilities by making their existing systems more efficient. Platforms that organize existing systems and information tend to achieve generative entrenchment more quickly than those that seek to introduce new systems from scratch. Users will make tactical use of some platform interfaces to link some existing systems, and in doing so they are incentivized to incorporate more of their own interests within these systems. Subsequent Users are incentivized to link their systems to benefit from the network effects set in motion by earlier Users, who in turn enjoy increasing network benefits as more User systems are incorporated over time. The platform is able to realize platform surplus value from this generative entrenchment.\n\n15. Platforms link actors, information, and events across multiple spatial and temporal scales at once. Platform ubiquity makes it more robust in relation to some threats, both intrinsic and extrinsic, and more vulnerable in relation to others. A platform ’ s ability to defend one component or even replace it when it is no longer useful can make the whole more resilient, but it can also then leave individual components vulnerable. The integrated architecture of the platform may also allow internal component-to-component feedback loops to cycle out of control, amplifying the destabilization of the whole apparatus.\n\n16. A platform ’ s actual processes may be very different from how they are understood by their Users, who may form mental images of those processes based on their own individual interactions or on how the platform has represented itself to them. Platforms don ’ t look like how they work and don ’ t work like how they look. For example, a User may understand his or her own interactions with the platform according to the content hierarchies of a GUI that bears almost no relation to how the platform actually structures or sees that interaction. Architects of a typical Cloud-based platform may organize the system according to the provision (and strategic throttling) of data through application programming interfaces (APIs) that make many different kinds of platform effects possible, the sources of which may be opaque to the most common Users or even to other components of the system.\n\n50\n\nPlatform and Stack, Model and Machine","previous_page":49,"next_page":51}