# X08-TELCO-NETOPS — заметки работника (iteration3-v10)

## Карта процессов (2–3), охваченных пакетом

1. **Мониторинг RAN и автономные корректирующие действия во время событий высокой нагрузки** (RAN fault/event management). Примеры: Deutsche Telekom — RAN Guardian Agent (P01, продакшен в Германии); Verizon — агентный слой поверх vRAN/RIC для плановых изменений, service assurance и оптимизации (P04, ранний этап/pilot). Разница: у DT — конкретный работающий агент с измеренными (по собственным данным) числами; у Verizon — пересказ выступления представителя с качественными, не количественными результатами по агентному слою.
2. **NOC end-to-end: обработка неисправностей и жалоб клиентов агентами-копилотами до TM Forum Autonomous Networks Level 4 ('dark NOC')**. Пример: China Mobile (Guangdong Mobile + Zhejiang Mobile, с Huawei) — P02, коммерческое развёртывание. Единственный из пакета случай с явным governance_change (устранение необходимости человеческого надзора за критическими функциями) и подробными метриками по провинциям/сценариям — но все данные самоотчётные (China Mobile + со-разработчик Huawei через TM Forum).
3. **Самовосстановление сетевой облачной инфраструктуры при мультивендорных сбоях** (network cloud self-healing). Пример: Telstra с Red Hat/Dell/Cisco — P03, но это proof of concept, а не внедрённая практика: источник сам называет это PoC/trial, не production.

Связь между процессами 1 и 2: оба относятся к сетевой эксплуатации (NOC/RAN), различаются охватом (один домен RAN vs. сквозной NOC по нескольким доменам) и стадией зрелости (production у DT/CM vs. ранний этап у Verizon). Процесс 3 — инфраструктурный слой (telco cloud), логически предшествующий/параллельный NOC-автоматизации, но ещё на стадии демонстрации.

## Соотнесение с исключёнными дублями (обязательное указание координатора)

- **One NZ (`W/packets/O01-OPM-CISR-RIGHTS/cards.jsonl`)**: досье о распределении прав решений (AI Decision Matrix, MIT CISR) упоминает «fifteen task-based agents to analyze network data» в контексте устойчивости сети при отключениях электричества — это другая организация (New Zealand) и другой фокус (матрица прав решений в целом, не сетевая эксплуатация как отдельный процесс). Не дублируется: ни один из кейсов P01–P04 не относится к One NZ.
- **China Mobile I2-PR-0073 (цифровые сотрудники, Zhejiang)**: не дублируется напрямую. P02 описывает **другой, более узкий и детально задокументированный процесс** — программу TM Forum AN Level 4 'dark NOC' в Guangdong+Zhejiang (первоисточник — TM Forum case study и пресс-релиз Huawei, а не sohu/people.com.cn как в I2-PR-0073). Связь зафиксирована в `links_prior` карточки P02 как `related_process` (та же организация — Zhejiang Mobile, пересекающийся домен RAN fault management, но другой конкретный процесс/охват/источник/период). Возможность двойного учёта числа «цифровых сотрудников» в Zhejiang между I2-PR-0073 и P02 отмечена явно, чтобы координатор мог свести при агрегации.

## Дедупликация — проверено

- `grep -F` по `W/known-url-map.jsonl`: URL Deutsche Telekom и Telstra уже присутствуют как `E2-EU-OPS-CASE-005` и `E2-APAC-CASE-015` (v0.2-case) → оформлено как `novelty: updated` с `links_prior`. URL TM Forum, Huawei, Light Reading (Verizon), Capgemini, Telco Magazine, Communications Today — в базе не найдены (новые источники).
- `grep -i` по `W/known-records.jsonl`, `W/known-e4-cases.json`, `W/known-sources-v0.2.json` — совпадений по China Mobile Guangdong/Zhejiang dark NOC, Verizon vRAN agentic не найдено.
- `grep -il` по `W/packets/*/cards.jsonl` (другие пакеты этой итерации) на "deutsche telekom", "verizon", "telstra", "china mobile" — совпадений в чужих пакетах не найдено (кроме O01, разобрано выше).

## Запросы и очередь (в порядке выполнения)

1. WebSearch: `China Mobile 自智网络 L4 autonomous network 2025 TM Forum` → нашёл TM Forum case study и Huawei award page (использованы для P02).
2. WebSearch: `China Unicom TM Forum Autonomous Networks Level 4 award self-healing network` → только общие упоминания (награда за вклад сотруднику China Unicom, не именованный клиентский кейс с процессом) — карточка не создана, недобор зафиксирован.
3. WebSearch: `Vodafone AI agent network operations autonomous 2025 fault management` → нашёл Capgemini client story (оценка зрелости автоматизации, уровень 3.4, roadmap — не внедрённая практика) и Telco Magazine (агрегированная цифра Google без разбивки по операторам). Оба прочитаны (F05, F06), карточка **не создана**: по калибровке I3 «рамка предписывает» / «декларация» ≠ внедрённая практика; у Vodafone на данный момент описан только roadmap, а не действующий автономный процесс с измеренным эффектом.
4. WebSearch: `МТС Билайн ИИ автоматизация эксплуатации сети базовые станции 2025` → результаты только про строительство базовых станций (BTS-отели, домашнее оборудование Irteia/Yadro), без названной ИИ-функции — недобор по России зафиксирован после 1 запроса (второй адресный запрос не делался ввиду явного отсутствия релевантных материалов и ограниченного остатка бюджета; см. «Недобор» ниже).
5. WebSearch: `AT&T Verizon AI agent network operations autonomous RAN 2025 2026` → нашёл Light Reading о Verizon (использован для P04); по AT&T релевантных материалов не найдено в этом запросе.
6. WebSearch: `SK Telecom KT LG Uplus layoffs AI transformation network jobs analysts demographic not AI` → нашёл Communications Today (трудовые споры/переговоры по зарплате) — прочитан (F08), карточка **не создана**: это не практика сетевой эксплуатации (нет описанного ИИ-процесса в NOC/RAN), а трудовой конфликт и общая заявленная 'AICT-трансформация'; по калибровке «Практика требует процесса» — недостаточно для карточки в потоке TELCO_NET. Аналитики независимо указывают, что сокращения на ~16% штата «большой тройки» с 2022 по 2025 г. связаны также с демографией и практикой найма, а не только с ИИ — зафиксировано как контекст для координатора (это релевантно скорее для OPMODEL/кадровой линии, не для сетевой эксплуатации).

Всего WebSearch: **6** из бюджета 10. Открытия (curl): **8** из бюджета 20 (все успешные, HTTP 200).

## Недобор (адресные ячейки)

- **China Unicom (именованный клиентский кейс сетевой эксплуатации)**: после 1 адресного поиска не нашёл конкретного, детально описанного клиентского кейса (только общие упоминания вклада сотрудников в стандарты TM Forum) — второй адресный запрос не делался из экономии бюджета при уже достигнутой цели пакета (3+ практики); недобор, не доказанное отсутствие.
- **МТС/Билайн/МегаФон — сетевая эксплуатация с названной ИИ-функцией (Россия)**: 1 поиск не дал релевантных материалов (только инфраструктурные новости без ИИ). Недобор зафиксирован; второй адресный запрос не выполнялся ввиду явно нерелевантного корпуса результатов первого (строительство БС, не ИИ).
- **AT&T — именованный кейс сетевой эксплуатации**: не найден в рамках объединённого запроса с Verizon; отдельный адресный поиск не делался (бюджет и цель пакета уже достигнуты).
- **BT, Orange, SK Telecom (сетевая эксплуатация, не B2C-ассистент)**: не искал отдельно — вне 2 обязательных адресных попыток на пустые ячейки, при уже достигнутом целевом числе практик (3–5) и процессов (2–3) для разведки уровня M2.

## Отклонённые/не оформленные материалы (с причиной)

- **Vodafone × Capgemini** (client story, uses.capgemini.com): оценка зрелости автоматизации (TM Forum ANL, уровень 3.4 в Fault & Incident Management cross-domain) и roadmap к Level 4. Не карточка: это консалтинговый проект оценки/планирования, а не внедрённый автономный процесс — «Vodafone is now well positioned to continue its journey toward Level 4» и «planned introduction of AI-driven capabilities» — будущее время, декларация roadmap, не факт действующего изменения процесса.
- **Google Autonomous Network Operations framework** (Telco Magazine, июнь 2025): агрегированная цифра «reduced repair times by approximately 25%» приписана Google (вендор) без разбивки по операторам ни для Vodafone, ни для DT; для DT уже есть отдельный, гораздо более детальный первичный источник (пресс-релиз самой DT) — не дублировал.
- **SK Telecom / KT / LG Uplus — трудовые переговоры и сокращения** (Communications Today, 01.09.2026): не про сетевую эксплуатацию; см. «Недобор»/п.6 выше. Возможно релевантно для отдельного OPMODEL/кадрового пакета этой или будущей итерации — координатору на заметку, карточка не создана в этом пакете (не расширяю предмет пакета самостоятельно).

## Прочее

- Все даты публикаций сверены по метаданным (`datePublished`/`article:published_time` в разметке), не «на глаз»: DT — 2026-02-25; TM Forum (China Mobile) — 2025-09-03; Huawei — 2025-06-18 (по тексту пресс-релиза, DTW Copenhagen); Telstra — 2026-03-02 (по тексту); Light Reading (Verizon) — 2026-06-11; Capgemini (Vodafone) — 2026-03-05; Communications Today — 2026-09-01.
- Китайские числа в P02 (万/亿) не встречались — все цифры TM Forum/Huawei даны в арабских числах и процентах, пересчёт ×10 не требовался; тем не менее каждое число сверено дважды при переносе в `effects`.
- Модальность проверена отдельно для Telstra (много будущего времени — 'trialled to support future', 'laying the groundwork') и Verizon ('early days', без утверждений о завершённом внедрении) — стадии не завышены.