JSON-схема диагностики падения метрик ML-модели

Сформируй воспроизводимую схему диагностики падения метрик модели {model_type} в контексте {business_context}, если {performance_metrics} снизились на {percentage_drop}% за {time_period}.

Отвечай только на русском языке и верни только один валидный JSON-объект без Markdown и без пояснений вне JSON.
Используй строго такую схему верхнего уровня:
- executive_summary
- prioritized_checklist
- diagnostic_procedures
- statistical_tests_and_thresholds
- monitoring_and_alerting_recommendations
- examples_of_common_root_causes
- estimated_diagnostic_timeline
- references_and_notes

Требования к содержанию:
- executive_summary: 2-4 предложения о наиболее вероятных причинах и порядке проверки.
- prioritized_checklist: список шагов с id, name, priority, estimated_time_minutes и rationale.
- diagnostic_procedures: до 8 категорий причин; для каждой верни cause, description, steps, diagnostic_queries, decision_tree, remediation_actions и rollback_criteria.
- steps: не более 8 пунктов на категорию, с action, expected_output, failure_indicators и estimated_time_minutes.
- diagnostic_queries: не более 8 коротких рабочих сниппетов на категорию; language только из sql, python, promql, bash или other.
- decision_tree: вложенная структура с node, branches, condition, then и remediation, достаточная для выбора следующего шага.
- statistical_tests_and_thresholds: PSI, KS, Chi-square и другие релевантные тесты с purpose, code_example и recommended_thresholds.
- monitoring_and_alerting_recommendations: метрика, способ расчёта, порог, severity и recommended_action.
- examples_of_common_root_causes: краткие кейсы с indicators и immediate_checks.
- estimated_diagnostic_timeline: quick_checks_minutes, detailed_investigation_hours, full_root_cause_analysis_days.

Обязательное покрытие:
- качество данных, drift признаков и label shift;
- training-serving skew и feature store;
- производительность модели по сегментам;
- проверки recent deploys, model versioning и CI/CD;
- инфраструктурные сбои, задержки, таймауты и исчерпание ресурсов;
- регрессионные баги и быстрые проверки воспроизводимости.

Ограничения:
- Используй placeholders вроде {feature_table}, {serving_logs}, {label_table}, если конкретные имена неизвестны.
- Все пороги помечай как ориентировочные, если они зависят от данных.
- Не добавляй ключи вне указанной схемы.