Physical AI: От нейросетей к гуманоидным роботам

3. Аналитика teleop share как скрытого COGS.

Как применить: сформулируйте один проверяемый вопрос к вашей ячейке, который закрывается этой опорой; запишите ответ в research note релиза. Если вопроса нет — вычеркивайте пункт из рабочего списка.

4. Stage-gate наборы метрик для спонсора (one-pager).

Как применить: сформулируйте один проверяемый вопрос к вашей ячейке, который закрывается этой опорой; запишите ответ в research note релиза. Если вопроса нет — вычеркивайте пункт из рабочего списка.

5. Риски spare stockout и single-source sensors.

Как применить: сформулируйте один проверяемый вопрос к вашей ячейке, который закрывается этой опорой; запишите ответ в research note релиза. Если вопроса нет — вычеркивайте пункт из рабочего списка.

6. Ценообразование pilot vs series и искажение стимулов.

Как применить: сформулируйте один проверяемый вопрос к вашей ячейке, который закрывается этой опорой; запишите ответ в research note релиза. Если вопроса нет — вычеркивайте пункт из рабочего списка.

7. Second-site transfer costs (карта среды vs copy conf).

Как применить: сформулируйте один проверяемый вопрос к вашей ячейке, который закрывается этой опорой; запишите ответ в research note релиза. Если вопроса нет — вычеркивайте пункт из рабочего списка.

8. Support burden после GA как индикатор зрелости.

Как применить: сформулируйте один проверяемый вопрос к вашей ячейке, который закрывается этой опорой; запишите ответ в research note релиза. Если вопроса нет — вычеркивайте пункт из рабочего списка.

9. Дисквалификаторы тендера (safety/offline/rollback/teleop journal).

Как применить: сформулируйте один проверяемый вопрос к вашей ячейке, который закрывается этой опорой; запишите ответ в research note релиза. Если вопроса нет — вычеркивайте пункт из рабочего списка.

10. Чувствительность ROI к −success / +teleop.

Как применить: сформулируйте один проверяемый вопрос к вашей ячейке, который закрывается этой опорой; запишите ответ в research note релиза. Если вопроса нет — вычеркивайте пункт из рабочего списка.

Рабочий протокол для полки «экономика и рынок» (U0198)

1. Выберите один claim пилота.

2. Найдите две опоры из списка выше.

3. Приложите полевой артефакт (лог/hash/ticket).

4. Зафиксируйте estimate vs measured.

Если шаг 2–3 не закрываются — claim снимается до следующего релиза.

Источники: наборы данных и бенчмарки

Подборка источников и опорных рамок по теме «наборы данных и бенчмарки» для команды Physical AI. Это не библиография «для красоты»: каждый пункт должен помогать проверить факт на полу или сформулировать критерии приёмки. Vendor-neutral: без рейтингов поставщиков.

Список опор

1. Публичные manipulation datasets: что переносится на ваш SKU-класс (обычно мало).

Как применить: сформулируйте один проверяемый вопрос к вашей ячейке, который закрывается этой опорой; запишите ответ в research note релиза. Если вопроса нет — вычеркивайте пункт из рабочего списка.

2. Бенчмарки imitation/contact-rich: читайте protocol, не лидерборд.

Как применить: сформулируйте один проверяемый вопрос к вашей ячейке, который закрывается этой опорой; запишите ответ в research note релиза. Если вопроса нет — вычеркивайте пункт из рабочего списка.

3. Внутренний golden set полок сайта важнее внешнего рейтинга.

Как применить: сформулируйте один проверяемый вопрос к вашей ячейке, который закрывается этой опорой; запишите ответ в research note релиза. Если вопроса нет — вычеркивайте пункт из рабочего списка.

4. Метрики coverage known-hard и rare abort codes.

Как применить: сформулируйте один проверяемый вопрос к вашей ячейке, который закрывается этой опорой; запишите ответ в research note релиза. Если вопроса нет — вычеркивайте пункт из рабочего списка.

5. Schema episode и обязательные поля для сравнимости.

Как применить: сформулируйте один проверяемый вопрос к вашей ячейке, который закрывается этой опорой; запишите ответ в research note релиза. Если вопроса нет — вычеркивайте пункт из рабочего списка.

6. Holdout by site/shift как анти-leak.

Как применить: сформулируйте один проверяемый вопрос к вашей ячейке, который закрывается этой опорой; запишите ответ в research note релиза. Если вопроса нет — вычеркивайте пункт из рабочего списка.

7. Запрет demo-only роликов в eval.

Как применить: сформулируйте один проверяемый вопрос к вашей ячейке, который закрывается этой опорой; запишите ответ в research note релиза. Если вопроса нет — вычеркивайте пункт из рабочего списка.

8. Версионирование таксономии лейблов вместе с датасетом.

Как применить: сформулируйте один проверяемый вопрос к вашей ячейке, который закрывается этой опорой; запишите ответ в research note релиза. Если вопроса нет — вычеркивайте пункт из рабочего списка.

9. Лицензии данных и PII/video constraints.

Как применить: сформулируйте один проверяемый вопрос к вашей ячейке, который закрывается этой опорой; запишите ответ в research note релиза. Если вопроса нет — вычеркивайте пункт из рабочего списка.

10. Регресс-сьюты seeded scenes между релизами.

Как применить: сформулируйте один проверяемый вопрос к вашей ячейке, который закрывается этой опорой; запишите ответ в research note релиза. Если вопроса нет — вычеркивайте пункт из рабочего списка.

Рабочий протокол для полки «наборы данных и бенчмарки» (U0199)

1. Выберите один claim пилота.

2. Найдите две опоры из списка выше.

3. Приложите полевой артефакт (лог/hash/ticket).

4. Зафиксируйте estimate vs measured.

Если шаг 2–3 не закрываются — claim снимается до следующего релиза.

Источники: методика проверки фактов

Подборка источников и опорных рамок по теме «методика проверки фактов» для команды Physical AI. Это не библиография «для красоты»: каждый пункт должен помогать проверить факт на полу или сформулировать критерии приёмки. Vendor-neutral: без рейтингов поставщиков.

Список опор

1. Триангуляция: полевой лог ↔ конфиг hash ↔ CMDB запись.

Как применить: сформулируйте один проверяемый вопрос к вашей ячейке, который закрывается этой опорой; запишите ответ в research note релиза. Если вопроса нет — вычеркивайте пункт из рабочего списка.

2. Запрет цитировать demo-day как evidence серии.

Как применить: сформулируйте один проверяемый вопрос к вашей ячейке, который закрывается этой опорой; запишите ответ в research note релиза. Если вопроса нет — вычеркивайте пункт из рабочего списка.

3. Проверка age сенсоров и PTP offset перед выводом о «деградации модели».

Как применить: сформулируйте один проверяемый вопрос к вашей ячейке, который закрывается этой опорой; запишите ответ в research note релиза. Если вопроса нет — вычеркивайте пункт из рабочего списка.

4. Связка success×teleop×SKU-mix против reward hacking.

Как применить: сформулируйте один проверяемый вопрос к вашей ячейке, который закрывается этой опорой; запишите ответ в research note релиза. Если вопроса нет — вычеркивайте пункт из рабочего списка.

5. Primary sources: стандарты и договор, не блог вендора.

Как применить: сформулируйте один проверяемый вопрос к вашей ячейке, который закрывается этой опорой; запишите ответ в research note релиза. Если вопроса нет — вычеркивайте пункт из рабочего списка.

6. Порог воспроизводимости: N смен / N ячеек до claim.

Как применить: сформулируйте один проверяемый вопрос к вашей ячейке, который закрывается этой опорой; запишите ответ в research note релиза. Если вопроса нет — вычеркивайте пункт из рабочего списка.

7. Red-team приёмки: ночь, glare, soft pouch, network drop.

Как применить: сформулируйте один проверяемый вопрос к вашей ячейке, который закрывается этой опорой; запишите ответ в research note релиза. Если вопроса нет — вычеркивайте пункт из рабочего списка.

8. Журнал change control как источник истины по среде.

Как применить: сформулируйте один проверяемый вопрос к вашей ячейке, который закрывается этой опорой; запишите ответ в research note релиза. Если вопроса нет — вычеркивайте пункт из рабочего списка.

9. Отделение estimate от measured в one-pager спонсору.

Как применить: сформулируйте один проверяемый вопрос к вашей ячейке, который закрывается этой опорой; запишите ответ в research note релиза. Если вопроса нет — вычеркивайте пункт из рабочего списка.

10. Postmortem packet completeness score (время до правды).

Как применить: сформулируйте один проверяемый вопрос к вашей ячейке, который закрывается этой опорой; запишите ответ в research note релиза. Если вопроса нет — вычеркивайте пункт из рабочего списка.

Рабочий протокол для полки «методика проверки фактов» (U0200)

1. Выберите один claim пилота.

2. Найдите две опоры из списка выше.

3. Приложите полевой артефакт (лог/hash/ticket).

4. Зафиксируйте estimate vs measured.

Если шаг 2–3 не закрываются — claim снимается до следующего релиза.

A1. Кейс: ночная приёмка на складе SKU A–C

Вымышленный складской пилот: SKU A–C, две смены. Дневное демо зелёное; ночь падает на бликах и другом WMS-приоритете. Acceptance без ночи — ложь.

Setup

Карта ограничений v0: свет lux estimates, зоны людей, out-of-scope хвост. Журнал teleop обязателен. Safety supervisor отдельно от политики хвата.

Ход пилота

Недели 1–2 supervised. Canary на A–B. Расширение до C только после teleop≤порога. Change control на перестановку стеллажа mid-pilot.

Метрики (estimates)

Success дня ~выше ночи на заметную дельту; teleop ночи растёт; near miss на проходе фиксируют. Полнота эпизодов падает в пике — чинят пайплайн до масштаба.

Разбор

Не «модель тупая», а карта и приёмка. Добавить ночной протокол в FAT/SAT. Запрет приёмки по demo-SKU дня.

Фокус этой главы (U0201)

Разбор «A1. Кейс: ночная приёмка на складе SKU A–C» держится на фасете canary halt. Соседние кейсы могут звучать похоже по складу, но здесь другие abort-коды, другие пороги и другой пакет evidence. Не переносите чеклист один в один.

Симптом на полу

Смена видит деградацию, которую легко списать на «модель». В юните 0201 первичная гипотеза — canary halt. Проверка: сравнить calib_drift_px и p95_latency_ms до/после изменения среды при фиксированном config hash.

Abort-коды и RACI

— U0201_TELEOP_HIDDEN — owner OT, secondary ML

— U0201_HASH_MISSING — owner integration, secondary vendor field

— U0201_LATENCY_BUDGET — owner safety/compliance

Эскалация: код → runbook шаг → canary halt при пороге.

Метрики (только для этой главы)

— calib_drift_px — drift target board, px; порог-кандидатоперации: 31 (уточняется на FAT ячейки U0201).

— p95_latency_ms — p95 hot path; порог-кандидатоперации: 31 (уточняется на FAT ячейки U0201).

— success_night — доля успешных циклов ночью; порог-кандидатоперации: 30 (уточняется на FAT ячейки U0201).

— stockout_hours — часы простоя из-за spare; порог-кандидатоперации: 31 (уточняется на FAT ячейки U0201).

Протокол проверки (уникальный)

1. Зафиксировать config hash H0201 и версию карты ограничений.

2. Прогнать отказный сценарий по фасету «canary halt» на canary не менее двух смен.

3. Снять пакет: state, keyframes, calib_drift_px, success_night, teleop_flag.

4. Если p95_latency_ms хуже порога — rollback тем же пайплайном, что выкат.

5. Запись в CMDB cell note: U0201 result.

Чеклист (не общий шаблон)

— [ ] Карта ограничений содержит пункт про canary halt

— [ ] Коды U0201_TELEOP_HIDDEN, U0201_HASH_MISSING в таксономии релиза

— [ ] Дашборд смены показывает calib_drift_px и p95_latency_ms

— [ ] Тест отказа U0201 в FAT/SAT

— [ ] Запрет принимать демо без этого теста

Что не делать

— Копировать конфиг соседней главы без смены hash.

— Чистить teleop, чтобы поднять success в отчёте по «A1. Кейс: ночная приёмка на складе SKU A–C».

— Глушить мониторы age/latency «на время пилота».

— Подменять пакет U0201 роликом demo-day.

Короткий вывод

«A1. Кейс: ночная приёмка на складе SKU A–C» закрывается, когда фасет canary halt измерим, коды abort назначены и canary умеет остановиться. Юнит U0201 — самостоятельный evidence pack, не клон соседнего.

A2. Кейс: потеря калибровки после смены крепления камеры

Field «чуть подтянул кронштейн» без ticket. Residual вырос, политика уверена, damage упаковки растёт.

След

Config hash тот же, extrinsic нет. Batch камеры смешан. Нет числового отчёта калибровки в gate.

Лечение

Запрет ручного edit. Калибровка числами. Alternate firmware batch. Регресс known-hard. Change ticket на крепёж = регресс perception.

Фокус этой главы (U0202)

Разбор «A2. Кейс: потеря калибровки после смены крепления камеры» держится на фасете словарь метрик. Соседние кейсы могут звучать похоже по складу, но здесь другие abort-коды, другие пороги и другой пакет evidence. Не переносите чеклист один в один.

Симптом на полу

Смена видит деградацию, которую легко списать на «модель». В юните 0202 первичная гипотеза — словарь метрик. Проверка: сравнить teleop_share и p95_latency_ms до/после изменения среды при фиксированном config hash.

Abort-коды и RACI

— U0202_HASH_MISSING — owner OT, secondary ML

— U0202_LATENCY_BUDGET — owner integration, secondary vendor field

— U0202_SENSOR_AGE — owner safety/compliance

Эскалация: код → runbook шаг → canary halt при пороге.

Метрики (только для этой главы)

— teleop_share — доля циклов с teleop; порог-кандидатоперации: 42 (уточняется на FAT ячейки U0202).

— p95_latency_ms — p95 hot path; порог-кандидатоперации: 6 (уточняется на FAT ячейки U0202).

— age_p95_ms — p95 age сенсора в политике; порог-кандидатоперации: 38 (уточняется на FAT ячейки U0202).

— incomplete_ep — доля эпизодов без обязательных полей; порог-кандидатоперации: 44 (уточняется на FAT ячейки U0202).

Протокол проверки (уникальный)

1. Зафиксировать config hash H0202 и версию карты ограничений.

2. Прогнать отказный сценарий по фасету «словарь метрик» на canary не менее двух смен.

3. Снять пакет: state, keyframes, teleop_share, age_p95_ms, teleop_flag.

4. Если p95_latency_ms хуже порога — rollback тем же пайплайном, что выкат.

5. Запись в CMDB cell note: U0202 result.

Чеклист (не общий шаблон)

— [ ] Карта ограничений содержит пункт про словарь метрик

— [ ] Коды U0202_HASH_MISSING, U0202_LATENCY_BUDGET в таксономии релиза

— [ ] Дашборд смены показывает teleop_share и p95_latency_ms

— [ ] Тест отказа U0202 в FAT/SAT

— [ ] Запрет принимать демо без этого теста

Что не делать

— Копировать конфиг соседней главы без смены hash.

— Чистить teleop, чтобы поднять success в отчёте по «A2. Кейс: потеря калибровки после смены крепления камеры».

— Глушить мониторы age/latency «на время пилота».

— Подменять пакет U0202 роликом demo-day.

Короткий вывод

«A2. Кейс: потеря калибровки после смены крепления камеры» закрывается, когда фасет словарь метрик измерим, коды abort назначены и canary умеет остановиться. Юнит U0202 — самостоятельный evidence pack, не клон соседнего.

A3. Кейс: скрытый teleop и обвал после текучки операторов

KPI success зелёный за счёт незалогированных вмешательств. Уход двух операторов — обвал «автономии».

Диагностика

Сравнить teleop FTE с журналом. Сегменты смен. Стимулы: премия только за success без teleop.

Контрмеры

Обязательный журнал причин. Аудит смены. Запрет бонусов без teleop share. Обучение backfill до масштаба.

Фокус этой главы (U0203)

Разбор «A3. Кейс: скрытый teleop и обвал после текучки операторов» держится на фасете age/skew сенсоров. Соседние кейсы могут звучать похоже по складу, но здесь другие abort-коды, другие пороги и другой пакет evidence. Не переносите чеклист один в один.

Симптом на полу

Смена видит деградацию, которую легко списать на «модель». В юните 0203 первичная гипотеза — age/skew сенсоров. Проверка: сравнить teleop_share и mtt_truth_min до/после изменения среды при фиксированном config hash.

Abort-коды и RACI

— U0203_LATENCY_BUDGET — owner OT, secondary ML

— U0203_SENSOR_AGE — owner integration, secondary vendor field

— U0203_FORCE_MUTE — owner safety/compliance

Эскалация: код → runbook шаг → canary halt при пороге.

Метрики (только для этой главы)

— teleop_share — доля циклов с teleop; порог-кандидатоперации: 25 (уточняется на FAT ячейки U0203).

— mtt_truth_min — минуты до полного пакета логов; порог-кандидатоперации: 28 (уточняется на FAT ячейки U0203).

— success_night — доля успешных циклов ночью; порог-кандидатоперации: 28 (уточняется на FAT ячейки U0203).

— support_h_cell — часы поддержки / ячейка / неделя; порог-кандидатоперации: 31 (уточняется на FAT ячейки U0203).

Протокол проверки (уникальный)

1. Зафиксировать config hash H0203 и версию карты ограничений.

2. Прогнать отказный сценарий по фасету «age/skew сенсоров» на canary не менее двух смен.

3. Снять пакет: state, keyframes, teleop_share, success_night, teleop_flag.

4. Если mtt_truth_min хуже порога — rollback тем же пайплайном, что выкат.

5. Запись в CMDB cell note: U0203 result.

Чеклист (не общий шаблон)

— [ ] Карта ограничений содержит пункт про age/skew сенсоров

— [ ] Коды U0203_LATENCY_BUDGET, U0203_SENSOR_AGE в таксономии релиза

— [ ] Дашборд смены показывает teleop_share и mtt_truth_min

— [ ] Тест отказа U0203 в FAT/SAT

— [ ] Запрет принимать демо без этого теста

Что не делать

— Копировать конфиг соседней главы без смены hash.

— Чистить teleop, чтобы поднять success в отчёте по «A3. Кейс: скрытый teleop и обвал после текучки операторов».

— Глушить мониторы age/latency «на время пилота».

— Подменять пакет U0203 роликом demo-day.

Короткий вывод

«A3. Кейс: скрытый teleop и обвал после текучки операторов» закрывается, когда фасет age/skew сенсоров измерим, коды abort назначены и canary умеет остановиться. Юнит U0203 — самостоятельный evidence pack, не клон соседнего.

A4. Кейс: второй сайт без SAT-процедуры

Copy conf на сайт B. Другой свет/EMI/Wi-Fi. Success↓ teleop↑. BD давит OTA.

Правильный ход

Стоп копирования. Карта заново. Сузить SKU. Canary. Не общий OTA на A+B.

Фокус этой главы (U0204)

Разбор «A4. Кейс: второй сайт без SAT-процедуры» держится на фасете anti-pattern catalogue. Соседние кейсы могут звучать похоже по складу, но здесь другие abort-коды, другие пороги и другой пакет evidence. Не переносите чеклист один в один.

Симптом на полу

Смена видит деградацию, которую легко списать на «модель». В юните 0204 первичная гипотеза — anti-pattern catalogue. Проверка: сравнить age_p95_ms и stockout_hours до/после изменения среды при фиксированном config hash.

Abort-коды и RACI

— U0204_TELEOP_HIDDEN — owner OT, secondary ML

— U0204_HASH_MISSING — owner integration, secondary vendor field

— U0204_LATENCY_BUDGET — owner safety/compliance

Эскалация: код → runbook шаг → canary halt при пороге.

Метрики (только для этой главы)

— age_p95_ms — p95 age сенсора в политике; порог-кандидатоперации: 37 (уточняется на FAT ячейки U0204).

— stockout_hours — часы простоя из-за spare; порог-кандидатоперации: 13 (уточняется на FAT ячейки U0204).

— success_night — доля успешных циклов ночью; порог-кандидатоперации: 9 (уточняется на FAT ячейки U0204).

— near_miss — near miss / 1000 циклов; порог-кандидатоперации: 33 (уточняется на FAT ячейки U0204).

Протокол проверки (уникальный)

1. Зафиксировать config hash H0204 и версию карты ограничений.

2. Прогнать отказный сценарий по фасету «anti-pattern catalogue» на canary не менее двух смен.

3. Снять пакет: state, keyframes, age_p95_ms, success_night, teleop_flag.

4. Если stockout_hours хуже порога — rollback тем же пайплайном, что выкат.

5. Запись в CMDB cell note: U0204 result.

Чеклист (не общий шаблон)

— [ ] Карта ограничений содержит пункт про anti-pattern catalogue

— [ ] Коды U0204_TELEOP_HIDDEN, U0204_HASH_MISSING в таксономии релиза

— [ ] Дашборд смены показывает age_p95_ms и stockout_hours

— [ ] Тест отказа U0204 в FAT/SAT

— [ ] Запрет принимать демо без этого теста

Что не делать

— Копировать конфиг соседней главы без смены hash.

— Чистить teleop, чтобы поднять success в отчёте по «A4. Кейс: второй сайт без SAT-процедуры».

— Глушить мониторы age/latency «на время пилота».

— Подменять пакет U0204 роликом demo-day.

Короткий вывод

«A4. Кейс: второй сайт без SAT-процедуры» закрывается, когда фасет anti-pattern catalogue измерим, коды abort назначены и canary умеет остановиться. Юнит U0204 — самостоятельный evidence pack, не клон соседнего.

A5. Кейс: OTA в пятницу и ложный «тихий хотфикс»

Пятничный OTA без canary. «Тихий хотфикс» поверх инцидента стирает улики.

Процесс

Окно, дежурство, canary две ячейки, rollback артефакт, запрет фикса без заморозки логов 24ч.

Фокус этой главы (U0205)

Разбор «A5. Кейс: OTA в пятницу и ложный «тихий хотфикс»» держится на фасете fleet spare kit. Соседние кейсы могут звучать похоже по складу, но здесь другие abort-коды, другие пороги и другой пакет evidence. Не переносите чеклист один в один.

Симптом на полу

Смена видит деградацию, которую легко списать на «модель». В юните 0205 первичная гипотеза — fleet spare kit. Проверка: сравнить support_h_cell и p95_latency_ms до/после изменения среды при фиксированном config hash.

Abort-коды и RACI

— U0205_WMS_DUP_CMD — owner OT, secondary ML

— U0205_PRIVACY_RAW — owner integration, secondary vendor field

— U0205_SPARE_STOCKOUT — owner safety/compliance

Эскалация: код → runbook шаг → canary halt при пороге.

Метрики (только для этой главы)

— support_h_cell — часы поддержки / ячейка / неделя; порог-кандидатоперации: 32 (уточняется на FAT ячейки U0205).

— p95_latency_ms — p95 hot path; порог-кандидатоперации: 32 (уточняется на FAT ячейки U0205).

— age_p95_ms — p95 age сенсора в политике; порог-кандидатоперации: 12 (уточняется на FAT ячейки U0205).

— teleop_share — доля циклов с teleop; порог-кандидатоперации: 22 (уточняется на FAT ячейки U0205).

Протокол проверки (уникальный)

1. Зафиксировать config hash H0205 и версию карты ограничений.

2. Прогнать отказный сценарий по фасету «fleet spare kit» на canary не менее двух смен.

3. Снять пакет: state, keyframes, support_h_cell, age_p95_ms, teleop_flag.

4. Если p95_latency_ms хуже порога — rollback тем же пайплайном, что выкат.

5. Запись в CMDB cell note: U0205 result.

Чеклист (не общий шаблон)

— [ ] Карта ограничений содержит пункт про fleet spare kit

— [ ] Коды U0205_WMS_DUP_CMD, U0205_PRIVACY_RAW в таксономии релиза

— [ ] Дашборд смены показывает support_h_cell и p95_latency_ms

— [ ] Тест отказа U0205 в FAT/SAT

— [ ] Запрет принимать демо без этого теста

Что не делать

— Копировать конфиг соседней главы без смены hash.

— Чистить teleop, чтобы поднять success в отчёте по «A5. Кейс: OTA в пятницу и ложный «тихий хотфикс»».

— Глушить мониторы age/latency «на время пилота».

— Подменять пакет U0205 роликом demo-day.

Короткий вывод

«A5. Кейс: OTA в пятницу и ложный «тихий хотфикс»» закрывается, когда фасет fleet spare kit измерим, коды abort назначены и canary умеет остановиться. Юнит U0205 — самостоятельный evidence pack, не клон соседнего.