AI-процеси · код, приклади й чесні межі

AI може помилитися.
Наступний крок має це бачити.

Виконувані приклади AI-процесів показують вхідні дані, підстави продовження або зупинки та рішення, які залишаються людині. Код і тести доступні для перевірки.

Відкрити код Профіль GitHub

7локальних прикладів

1команда для перевірки

0зовнішніх дій у публічному proof

1людське рішення на межі

Три корисні питання

Що станеться після відповіді AI?

Відповідь може виглядати переконливою, навіть коли потрібного документа немає або він застарів. Якщо за нею автоматично йде повідомлення чи зміна в системі, помилка вже має наслідок.

Куди вона піде?

У лист, таблицю, іншу програму чи на розгляд людині? Саме наступний крок визначає ризик.

Коли зупинитися?

У відкритих прикладах брак даних, застарілий запис або суперечність зупиняють передачу результату.

Хто вирішить далі?

Тест показує причину зупинки. Важливу дію після цього має розглядати людина.

Це можна побачити в тестових прикладах. Якщо схожа помилка трапляється у вашій роботі, опишіть один випадок — спочатку розберемося, що саме треба перевірити.

Поставити питання

Від прикладу до задачі

Почати можна з одного збою.

Достатньо знеособленого опису: що надходить до системи, куди має піти результат і яка помилка найбільше заважає. Ключі, приватні файли та доступ до робочої системи для першої розмови не потрібні.

Потім можна домовитися про маленьку перевірку: правильний приклад проходить, помилкові зупиняються з названою причиною. Обсяг реальної роботи визначається окремо.

Публічний код використовує тестові дані. Він не є впровадженням у чужій системі й не виконує зовнішніх дій.

Що є в коді

Одну передачу можна розкласти на три частини.

Джерело і наступний крок

Що саме отримує програма, куди передає результат і хто відповідає за рішення.

Чітка зупинка

Коли даних бракує, вони застаріли або суперечать одне одному, процес не вдає успіх.

Тести та межі

Правильні й помилкові приклади, причина кожного рішення та чесний опис того, чого тести не доводять.

Починаємо з конкретного

Спершу одна зрозуміла передача.

Малий приклад показує, де система помиляється і що можна перевірити. Лише після цього є сенс говорити про більшу архітектуру.

01 · перше питання
Одна передача
Чи проходить правильний приклад і чи зупиняються помилкові з названою причиною?
02 · якщо доказ цього потребує
Сусідні кроки
Після першої перевірки стане видно, чи є сенс посилювати інші переходи.
03 · якщо потрібне продовження
Наступні кроки
Після першої перевірки можна описати, що ще лишається незрозумілим. Сам опис не дає дозволу змінювати робочу систему.

Технічний рівеньКарта переходів від даних до людського рішення

Operating Core Map

Подивіться, де рішення переходить до людини.

Ця інтерактивна карта веде один приклад від входу до перевірки даних, обмеженої роботи й людського розгляду. Вона допомагає побачити ідею, але не є системою клієнта.

Зафіксована control-surface карта

Межа системи

Етап: system-boundary
Public reference: Typed source-to-target boundary
Для реального процесу: Названі source, target, owner та schema
Не claimed: Немає доступу до client system чи production.
Authority: none
External action authorized: false
Production: false
Provider observed: false

Browser-local інспекція зафіксованої карти, не runtime system, evidence, contract, deployment, provider observation чи permission. Вона не має network, storage, telemetry, clipboard, navigation, prefill або submit APIs.

Відкриті приклади

Запустіть тести й подивіться самі.

У репозиторії є приклади перевірки даних, обмеженого очікування та передачі результату людині. Одна команда запускає тести; їх успіх не є гарантією безпеки іншої системи.

python3 run_proof.py

Спробуйте самі

Змініть дані — побачте рішення.

Оберіть тестовий сценарій. Приклад покаже рішення та причину, не виконуючи зовнішніх дій.

Зафіксований синтетичний результат

Валідний доказ

Результат triage: draft
Названа причина: EVIDENCE_COMPLETE
Рішення fixture: draft
Зовнішня дія дозволена: false

Повний синтетичний доказ може дати draft; будь-яку наступну дію все одно вирішує людина.

Це підготовлені тестові дані, не перевірка вашої системи. Приклад працює лише в цій вкладці.

Метод і технічні межі прикладу

Ілюстративне browser-local відтворення окремих зафіксованих evidence-gate fixtures. Поточний source explorer не має network, storage або telemetry APIs. Це не Python equivalence, EGOH parity, production safety, certification, client validity чи external authorization.

Необов'язковий інструментРозкласти власну задачу перед зверненням

Локальний acceptance packet

Складіть вузький review-only draft перед public inquiry.

Оберіть лише контрольовані значення. Builder створює browser-local planning draft, а не evidence, contract, award, payment чи дозвіл на зовнішню дію.

1 · Тип передачі

2 · Buyer-declared source category

3 · Вузький target

4 · Decision owner role

5 · Costly failure, який має fail closed

6 · Що покаже результат?

7 · Test environment

8 · Межа людської дії

9 · Public boundary declaration

Ваш browser-local output

Review-only planning draft

{
  "schema": "external-buyer-acceptance-packet-v1",
  "workflow": null,
  "source": null,
  "target": null,
  "decision_owner_role": null,
  "decision_owner_status": "must-be-named-during-human-review",
  "costly_failure": null,
  "measurable_five_day_evidence": null,
  "test_environment": null,
  "human_action_boundary": null,
  "boundary_declaration": null,
  "exclusions": "production-credentials-private-data-payment-account-changes-excluded",
  "output_status": "UNSENT · no buyer selections · local to this tab · not validated",
  "scope": "review-only",
  "draft_class": "unpopulated-planning-template",
  "completion_status": "incomplete",
  "authority": "none",
  "evidence": false,
  "contract": false,
  "award": false,
  "payment": false,
  "external_action": false,
  "external_action_authorized": false,
  "production": false,
  "production_activation": "excluded",
  "automatic_submit": false,
  "manual_route": "existing-github-issue-form"
}

Міст до canonical Issue Form

Спершу локальна перевірка, потім ручний public summary.

{
  "state": "held-incomplete-local-draft",
  "authority": "none",
  "external_action_authorized": false
}

Коли всі controlled values обрані, bridge покаже engineering scaffold і buyer-declared acquisition-source choice canonical Issue Form. Перечитайте кожен public summary вручну: він не вводиться, не копіюється й не подається цією сторінкою. Потім вручну відкрийте існуючу англомовну public GitHub Issue Form. Public form не може перевірити відсутність private data.

Вручну відкрити існуючу англомовну public GitHub Issue Form

Не вводьте тут і не додавайте до public issue secrets, credentials, private code, customer/personal data, private URLs або production access details. Поточний builder має контрольовані поля, не має network, storage, telemetry чи automatic-submit APIs.

Де це корисно

Коли відповідь AI стає чиєюсь дією.

Наприклад, програма передає результат у внутрішній інструмент, чекає на відповідь іншого сервісу або має вирішити, чи достатньо джерел для висновку.

Якщо перевірку не вдається зробити чесно, це теж результат: назвати, чого бракує, і не видавати невідоме за успіх.

Є питання чи схожа задача?

Опишіть один випадок. З нього й почнемо розмову.

Поставити питання Профіль GitHub

Публічне звернення бачать усі. Не надсилайте паролі, приватні дані, код клієнта чи доступ до робочих систем.

AI може помилитися.Наступний крок має це бачити.