Anti-Drift Review

Проверка AI-отчётов и задач на неподтверждённые выводы, слабые доказательства и расхождения моделей.

Проверка отчёта

Присылаете документ на art@looi.ru с темой «Anti-Drift» или в Telegram — t.me/artloooi. В ответ — разбор: какие утверждения не подкреплены источниками, где выводы сильнее данных, где модели расходятся.

Метод: несколько независимых рецензий → сводка расхождений → нормализация формулировок. Это не «доказательство истины», а карта мест, где документ требует человеческой проверки. Как устроена проверка внутри.

Это вспомогательная проверка рисков, а не юридическая, финансовая, медицинская или инвестиционная консультация.

Не присылайте секреты, ключи, клиентские данные, приватные документы, договоры, медицинские/финансовые детали или регулируемую информацию.

Проверить задачу перед делегированием агенту

Быстрый чек по правилам: достаточно ли у задачи структуры, примеров, отката и точек approval, чтобы начинать пилот под наблюдением. Это не разрешение на автономию.

Это планировочная самопроверка, а не юридическая, security, privacy, медицинская, финансовая или compliance-консультация. Не вставляйте секреты, ключи, клиентские данные, приватные документы, договоры, медицинские/финансовые детали или регулируемую информацию.

Процесс / задача

Структура задачи

Hard overrides

Если пункт применим, он сильнее баллов. Red — не делегировать; Yellow — только подготовка и approval.

Guardrails

Первый безопасный эксперимент

Метрика / kill criteria

Как считается: каждый отмеченный пункт структуры — 2 балла, максимум 14. Десять и больше — green, шесть–девять — yellow, пять и меньше — red. Любой yellow-override опускает green до yellow; любой red-override даёт red независимо от баллов.

Tool-call schema contract

Отдельный быстрый preflight для agent workflows, где ошибка случается не в финальном ответе, а на слое tool call: модель присылает payload не той формы, runtime молча чинит/дропает поле, а команда видит только итоговый diff.

Agent Tool-Call Schema Contract Preflight

Синтетический пример: tool ждёт edits: [{old,new}], агент присылает invented nested shape вроде edits: {replace:[...]}. Проверка нужна до write/edit/deploy action.

1. Which tools can mutate state: file edit, PR, deploy, ticket, CRM, billing, database, email? 2. Is every mutating tool schema explicit, versioned, and enforced at runtime? 3. What happens to unknown fields: reject, ignore, coerce, repair, or retry? 4. Does the log preserve raw tool-call payload, validation result, and repair path? 5. Which malformed calls must fail closed even if final answer looks plausible? 6. Is schema validation tested separately from prompt/output evaluation? 7. What fixtures cover invented nested fields, wrong arrays/objects, missing required fields, wrong enum values, and over-broad action scope? 8. Who owns final accept gate: tool runtime, agent orchestrator, reviewer, or deploy pipeline? 9. How are model upgrades tested against historical tool-call fixtures before rollout? 10. How will the team notice schema contract drift before it becomes silent corruption?

Запросить tool-call review Написать в Telegram

Без code upload, repo access, форм, backend, внешней аналитики и хранения tool schema/payload. Счётчики живут только в браузере и экспортируются вручную.

Spend copilot source trace

Preflight для AI-copilot поверх расходов, поездок и reimbursement: перед тем как ответ становится approval, management report или спором с политикой, нужно увидеть источник, владельца правила и границу уверенности.

Spend Copilot Source/Audit Trail Preflight

Синтетический пример: spend copilot уверенно пишет «можно approve», но смешивает travel category, policy exception и неподтверждённые expense-policy rows. Проверка нужна до approval/rejection/action recommendation.

1. Which spend question is being answered: policy lookup, reimbursement decision, travel category, budget variance, vendor spend, or management summary? 2. Which source rows support the answer: receipt line, trip record, policy clause, approval history, budget owner note, or exception log? 3. Which claims are unsupported by source rows and must be removed or marked uncertain? 4. Does the answer separate factual trace from approval/rejection recommendation? 5. Which policy owner can confirm ambiguous categories, limits, exceptions, and regional rules? 6. What audit log will survive: prompt/query, source row ids, policy version, AI answer, human reviewer, final decision? 7. Which answers must fail closed: payment approval, reimbursement denial, compliance flag, tax/VAT claim, employee discipline, or contract/vendor action? 8. What synthetic fixture tests category mixups, stale policy, missing receipt, duplicate trip, exception override, and wrong currency? 9. How will the team notice when model/provider changes alter source citation or spend-policy interpretation? 10. What is the smallest non-confidential sample that can prove the copilot is reviewable before rollout?

Запросить spend-copilot review Написать в Telegram

Без загрузки expense rows, форм, backend, внешней аналитики, financial advice, approval automation и хранения spend/reporting данных. Счётчики живут только в браузере и экспортируются вручную.

Code prototype handoff truth

Preflight для команд, где рабочий код-прототип становится источником правды вместо отдельной Figma-спеки: перед handoff нужно проверить, что в коде не потерялись состояния, решения, токены, accessibility и acceptance criteria.

Code Prototype Handoff Truth Check

Синтетический пример: Claude/Cursor/v0 prototype выглядит готовым, но не говорит, какие состояния покрыты, какие copy decisions приняты, где component/token mapping, какие analytics events нужны и кто принимает handoff as source of truth.

1. What is the source of truth for this feature now: code prototype, Figma, PRD, ticket, or production behavior? 2. Which user states are covered: empty, loading, error, permission, success, edge-case, mobile, localization, and rollback? 3. Which design tokens/components are used, invented, renamed, or bypassed by the prototype? 4. Which copy decisions are intentional, which are placeholders, and who owns final wording? 5. Which accessibility checks are required before the prototype becomes implementation input? 6. Which analytics/events, experiment flags, and success metrics must be present before handoff? 7. Which engineering acceptance criteria are explicit enough to test without reading the designer's mind? 8. What screenshots, browser states, or fixtures prove the prototype behavior across key paths? 9. What must not be treated as truth: generated placeholder data, fake API behavior, mocked permissions, or visual-only interactions? 10. Who signs off that the coded prototype can replace or update the design/spec source of truth?

Запросить prototype handoff review Написать в Telegram

Без code upload, Figma/file upload, форм, backend, внешней аналитики и хранения design/code/prototype данных. Счётчики живут только в браузере и экспортируются вручную.

Onboarding state coverage

Preflight для onboarding kit / design system, где команда добавляет ещё экраны, но не проверяет повторяемые состояния: invite, empty, error, role, permission, upgrade, migration, mobile, localization, analytics и fallback.

Onboarding Kit State Coverage Gate

Синтетический пример: Figma/onboarding kit выглядит полным, потому что в нём много экранов, но в реальном signup flow нет состояний invite expired, permission denied, role mismatch, empty workspace, billing upgrade и mobile error recovery.

1. Which onboarding object is being covered: signup, invite, workspace setup, role onboarding, migration, upgrade, or activation checklist? 2. Which repeated states exist: empty, loading, error, success, permission, invite expired, role mismatch, mobile, localization, and fallback? 3. Which states are intentionally out of scope, and who accepts that product/conversion risk? 4. Which copy variants are real decisions versus placeholder text from a template or AI generation? 5. Which analytics events prove the user moved through activation rather than only viewed screens? 6. Which accessibility and keyboard paths are required before the kit is reused? 7. Which component variants/tokens are shared with the product system and which were invented for the kit? 8. What fixture or prototype state proves each critical path without using customer data? 9. Which failure states must block launch: broken invite, impossible role selection, no recovery, or hidden billing/permission rule? 10. Who owns the final acceptance gate before this kit becomes reusable production infrastructure?

Запросить onboarding review Написать в Telegram

Без Figma/file upload, форм, backend, внешней аналитики и хранения user-flow, product, customer или onboarding data. Счётчики живут только в браузере и экспортируются вручную.

Эксперимент из серии про проверяемость — Артур Арсёнов · t.me/artloooi · art@looi.ru · looi.ru