Nobody can name all the models in production. A release waits for an approval nobody planned for. An auditor asks which data produced a forecast, and the answer depends on finding its original author. Begin with an inventory and a clear distinction between technical risk, organizational responsibility and acceptable use. Turn those concerns into requirements before designing the controls. The middle talks examine shared asset records, risk-based review and the evidence needed to investigate a disputed prediction. Then extend the record from an individual model to an entire language-model workflow, including its changing providers and human fallback. Finish with the identities and supervision needed when a system can act. These organizational accounts illustrate governance practices, not a statement of current legal requirements.
Why first: Radclyffe's financial-services account begins by discovering work that formal reporting missed. An inventory spanning experiments and production makes risk review possible at all. His distinction between compliance, engineering risk and ethics also prevents a documentation tool from being mistaken for the whole governance process.
Why second: Guinan asks who helped define the requirements and whose perspective was absent. Broad commitments need practical thresholds and a plan for failure if engineers are to apply them. This gives the inventory a purpose: record systems against agreed expectations rather than accumulating names for their own sake.
Why here: Oppenheimer explains why a model can be technically ready yet wait at an unexpected production gate. Early work with security and operations exposes those requirements, while reusable controls avoid repeating the same approval work for every project. The aim is a deliberate risk decision supported by the delivery process.
Why here: Multiple catalogs can fragment permissions, lineage and audit records even when each system works locally. Leon and Bukta's 2024 design proposes a common view across data and model assets. Use it to examine what your records must connect before deciding whether any particular catalog fits your organization.
Why here: The forecasting examples make those records useful to an actual review. Risk tiers change the scrutiny a model receives, and lineage helps reviewers reconstruct its training and release history. The panel also keeps human validation where a changed market and a broken data pipeline could produce similar symptoms.
Why here: Gade shows how explanations can turn a disputed prediction into a concrete investigation of features and training examples. He also limits the claim: an attribution describes what the model learned, not the cause of events in the world. That distinction matters when deciding what your review evidence can actually establish.
Why here: A general-purpose model can appear in workflows with very different consequences. Oppenheimer therefore extends the catalog to the steps, providers, versions and controls of the complete application. Documented error boundaries and human fallback preserve the accountability established earlier when the model is only one component.
Why last: Reagan adds the question of who an acting system represents. His account connects supervision and budgets with managed identities and permissions that can change after sensitive data is accessed. Governance must remain attached to the execution and its responsible people, rather than ending with approval of an initial model.