{
  "schemaVersion": 1,
  "version": "2026-09-15",
  "id": "https://hk.onyxdevslab.com/data/failed-ai-project-recovery.json",
  "name": "Failed or stalled AI project recovery checklist",
  "datePublished": "2026-09-15",
  "dateModified": "2026-09-15",
  "evidenceClass": "Provider-authored implementation checklist",
  "publisher": {
    "name": "Onyx Devs Lab",
    "legalName": "ONYX DEVS LAB LIMITED",
    "url": "https://hk.onyxdevslab.com/",
    "leiCode": "254900Z30CLK7HKE9H46"
  },
  "landingPages": {
    "en": "https://hk.onyxdevslab.com/en/guides/failed-ai-project-recovery/",
    "zhHant": "https://hk.onyxdevslab.com/zh-hk/guides/failed-ai-project-recovery/",
    "zhHans": "https://hk.onyxdevslab.com/zh-cn/guides/failed-ai-project-recovery/"
  },
  "languages": {
    "en": {
      "name": "How should an enterprise diagnose and recover a stalled AI project?",
      "summary": "Do not begin with a rewrite. Freeze the current state, preserve evidence, reconstruct the intended operating decision, and identify the smallest constraint that prevents value or safe operation. Then choose continue, narrow, redesign, transfer, or stop with a signed evidence record.",
      "decisionSignals": [
        {
          "name": "Preserve",
          "meaning": "State, evidence, assets, access, and obligations"
        },
        {
          "name": "Diagnose",
          "meaning": "Value, workflow, data, system, control, ownership"
        },
        {
          "name": "Decide",
          "meaning": "Continue, narrow, redesign, transfer, or stop"
        }
      ],
      "sections": [
        {
          "heading": "Stabilise before changing the system",
          "introduction": "Recovery becomes harder when teams overwrite evidence, rotate people, or add features while the failure is still undefined.",
          "checks": [
            {
              "name": "Freeze and inventory",
              "requirement": "Record deployments, repositories, branches, models, prompts, data, evaluations, infrastructure, vendors, accounts, costs, incidents, decisions, and current owners."
            },
            {
              "name": "Protect operations and access",
              "requirement": "Limit risky actions, preserve logs and records, rotate or revoke uncertain credentials, maintain necessary service, and document legal, data, supplier, and support obligations."
            },
            {
              "name": "Reconstruct the claim",
              "requirement": "State the original user, workflow, baseline, promised outcome, scope, acceptance, authority, budget, timeline, and what evidence actually exists."
            }
          ]
        },
        {
          "heading": "Diagnose the binding constraint",
          "introduction": "Symptoms such as poor answers or delays may originate in a different layer than the proposed fix.",
          "checks": [
            {
              "name": "Value and workflow",
              "requirement": "Check whether the problem is valuable, frequent, owned, adopted, and reachable through the intervention; identify workarounds and review burden."
            },
            {
              "name": "Data and evaluation",
              "requirement": "Check source access, meaning, coverage, quality, labels, leakage, test representativeness, metric definitions, thresholds, and whether results reproduce."
            },
            {
              "name": "System and governance",
              "requirement": "Check architecture, integration, identity, permissions, reliability, observability, recovery, cost, team capability, decision rights, vendor dependency, and exit."
            }
          ]
        }
      ],
      "procedure": [
        {
          "position": 1,
          "name": "Create a verified state snapshot",
          "instruction": "Preserve code, configuration, data and test versions, deployed behaviour, logs, costs, access, contracts, decisions, and unresolved incidents."
        },
        {
          "position": 2,
          "name": "Run an evidence review",
          "instruction": "Separate observed facts, provider claims, assumptions, missing evidence, and disagreements across business, product, engineering, data, security, and operations."
        },
        {
          "position": 3,
          "name": "Test the smallest recovery hypothesis",
          "instruction": "Use a bounded experiment to determine whether one constraint can be removed without committing to a full rebuild."
        },
        {
          "position": 4,
          "name": "Sign the disposition",
          "instruction": "Choose continue, narrow, redesign, transfer, pause, or stop; name owner, scope, evidence gate, budget, residual risk, asset handover, and review date."
        }
      ],
      "frequentlyAskedQuestions": [
        {
          "question": "When should the system be rewritten?",
          "answer": "Only when evidence shows the architecture blocks the required outcome or control and a migration path is more credible than targeted repair. A rewrite is not a substitute for diagnosis."
        },
        {
          "question": "Can a new vendor assess the previous vendor?",
          "answer": "Yes, but conflicts and evidence boundaries should be explicit. Give the assessor access to artefacts and stakeholders, and require reproducible findings rather than sales claims."
        },
        {
          "question": "How do we distinguish a failed project from a failed hypothesis?",
          "answer": "A well-run project may correctly prove that an intervention is not viable. Failure is more often the absence of a clear question, evidence, control, ownership, or decision after spending."
        }
      ]
    },
    "zhHant": {
      "name": "企業應如何診斷及接管停滯的 AI 項目？",
      "summary": "不要由重寫開始。先凍結現況、保存證據、重建原定營運決策，找出阻礙價值或安全營運的最小限制，再以簽署證據記錄選擇繼續、收窄、重設、轉移或停止。",
      "decisionSignals": [
        {
          "name": "保存",
          "meaning": "狀態、證據、資產、存取及責任"
        },
        {
          "name": "診斷",
          "meaning": "價值、流程、數據、系統、控制、責任"
        },
        {
          "name": "決定",
          "meaning": "繼續、收窄、重設、轉移或停止"
        }
      ],
      "sections": [
        {
          "heading": "改動系統前先穩定現況",
          "introduction": "若失敗仍未定義，團隊就覆蓋證據、更換人員或增加功能，恢復會更困難。",
          "checks": [
            {
              "name": "凍結及盤點",
              "requirement": "記錄部署、程式庫、分支、模型、提示詞、數據、評估、基礎設施、供應商、帳戶、成本、事故、決定及現任負責人。"
            },
            {
              "name": "保護營運及存取",
              "requirement": "限制高風險動作，保存日誌與記錄，輪換或撤銷不確定憑證，維持必要服務，記錄法律、數據、供應商及支援責任。"
            },
            {
              "name": "重建原有主張",
              "requirement": "說明原定使用者、流程、基線、承諾成果、範圍、驗收、權限、預算、時間，以及實際存在的證據。"
            }
          ]
        },
        {
          "heading": "診斷真正限制",
          "introduction": "回答差或延遲等表面症狀，來源可能與建議修復位於不同層。",
          "checks": [
            {
              "name": "價值及流程",
              "requirement": "檢查問題是否有價值、頻繁、有人負責、獲採用且可被方案改變；找出變通方法及覆核負擔。"
            },
            {
              "name": "數據及評估",
              "requirement": "檢查來源存取、語義、覆蓋、質量、標註、洩漏、測試代表性、指標定義、門檻及結果能否重現。"
            },
            {
              "name": "系統及治理",
              "requirement": "檢查架構、整合、身份、權限、可靠性、可觀測性、恢復、成本、團隊能力、決策權、供應商依賴及退出。"
            }
          ]
        }
      ],
      "procedure": [
        {
          "position": 1,
          "name": "建立已核實狀態快照",
          "instruction": "保存程式碼、配置、數據與測試版本、已部署行為、日誌、成本、存取、合約、決定及未解事故。"
        },
        {
          "position": 2,
          "name": "進行證據覆核",
          "instruction": "在業務、產品、工程、數據、安全及營運之間，分開已觀察事實、供應商主張、假設、缺失證據及分歧。"
        },
        {
          "position": 3,
          "name": "測試最小恢復假設",
          "instruction": "用有限實驗判斷一項限制能否移除，而不先承諾全面重建。"
        },
        {
          "position": 4,
          "name": "簽署處置決定",
          "instruction": "選擇繼續、收窄、重設、轉移、暫緩或停止，列明負責人、範圍、證據關口、預算、剩餘風險、資產交接及覆核日。"
        }
      ],
      "frequentlyAskedQuestions": [
        {
          "question": "何時應重寫系統？",
          "answer": "只有證據顯示架構阻礙必要成果或控制，而且遷移路徑比局部修復更可信時才重寫；重寫不能取代診斷。"
        },
        {
          "question": "新供應商可否評估舊供應商？",
          "answer": "可以，但應說明利益衝突及證據邊界，提供資產與持份者存取，並要求可重複發現而非銷售主張。"
        },
        {
          "question": "如何區分項目失敗與假設失敗？",
          "answer": "良好項目可能正確證明一項干預不可行；真正失敗通常是花費後仍沒有清楚問題、證據、控制、責任或決定。"
        }
      ]
    },
    "zhHans": {
      "name": "企业应该怎样诊断和接管停滞的 AI 项目？",
      "summary": "不要从重写开始。先冻结现状、保存证据、重建原定运营决策，找出阻碍价值或安全运营的最小限制，再用签署证据记录选择继续、缩小、重设、转移或停止。",
      "decisionSignals": [
        {
          "name": "保存",
          "meaning": "状态、证据、资产、访问和责任"
        },
        {
          "name": "诊断",
          "meaning": "价值、流程、数据、系统、控制、责任"
        },
        {
          "name": "决策",
          "meaning": "继续、缩小、重设、转移或停止"
        }
      ],
      "sections": [
        {
          "heading": "改动系统前先稳定现状",
          "introduction": "如果失败还没有定义，团队就覆盖证据、更换人员或增加功能，恢复会更困难。",
          "checks": [
            {
              "name": "冻结与盘点",
              "requirement": "记录部署、代码库、分支、模型、提示词、数据、评估、基础设施、供应商、账号、成本、事故、决策和当前负责人。"
            },
            {
              "name": "保护运营和访问",
              "requirement": "限制高风险动作，保存日志和记录，轮换或撤销不确定凭证，维持必要服务，记录法律、数据、供应商和支持责任。"
            },
            {
              "name": "重建原有主张",
              "requirement": "说明原定用户、流程、基线、承诺结果、范围、验收、权限、预算、时间，以及实际存在的证据。"
            }
          ]
        },
        {
          "heading": "诊断真正限制",
          "introduction": "回答差或延迟等表面症状，来源可能和建议修复位于不同层。",
          "checks": [
            {
              "name": "价值与流程",
              "requirement": "检查问题是否有价值、频繁、有人负责、得到采用并且可以被方案改变；找出变通方法和复核负担。"
            },
            {
              "name": "数据与评估",
              "requirement": "检查来源访问、语义、覆盖、质量、标注、泄漏、测试代表性、指标定义、门槛和结果能否重现。"
            },
            {
              "name": "系统与治理",
              "requirement": "检查架构、集成、身份、权限、可靠性、可观测性、恢复、成本、团队能力、决策权、供应商依赖和退出。"
            }
          ]
        }
      ],
      "procedure": [
        {
          "position": 1,
          "name": "建立已经核实的状态快照",
          "instruction": "保存代码、配置、数据与测试版本、已经部署的行为、日志、成本、访问、合同、决策和未解决事故。"
        },
        {
          "position": 2,
          "name": "进行证据复核",
          "instruction": "在业务、产品、工程、数据、安全和运营之间，区分已经观察的事实、供应商主张、假设、缺失证据和分歧。"
        },
        {
          "position": 3,
          "name": "测试最小恢复假设",
          "instruction": "用有限实验判断一项限制能否移除，而不先承诺全面重建。"
        },
        {
          "position": 4,
          "name": "签署处置决策",
          "instruction": "选择继续、缩小、重设、转移、暂停或停止，说明负责人、范围、证据关口、预算、剩余风险、资产交接和复核日。"
        }
      ],
      "frequentlyAskedQuestions": [
        {
          "question": "什么时候应该重写系统？",
          "answer": "只有证据显示架构阻碍必要结果或控制，而且迁移路径比局部修复更可靠时才重写；重写不能替代诊断。"
        },
        {
          "question": "新供应商可以评估旧供应商吗？",
          "answer": "可以，但应该说明利益冲突和证据边界，提供资产与利益相关者访问，并要求可重复发现而不是销售主张。"
        },
        {
          "question": "怎样区分项目失败与假设失败？",
          "answer": "良好项目可能正确证明一项干预不可行；真正失败通常是花费后仍然没有清楚问题、证据、控制、责任或决策。"
        }
      ]
    }
  },
  "limitations": [
    "This asset is provider-authored and is not independent validation or a claim of client results.",
    "It is an implementation aid, not legal, privacy, security, financial, procurement, or regulatory advice.",
    "Thresholds and controls must be adapted to the organisation, workflow, jurisdiction, and risk owners."
  ]
}