З Do4U API ти можеш користуватися з власного програмного забезпечення тими самими інструментами, що й на сайті: узагальнювати, порівнювати, відповідати клієнтам, створювати альтернативні тексти, переписувати та перекладати. Кожен запит обробляється на наших власних серверах у Польщі, в ЄС.
Базовий URL: https://do4u.eu/api/v1
Опис OpenAPI 3.1 (JSON) – Машиночитний опис цього API для генераторів коду та інструментів, як-от Postman чи Insomnia. Ключ не потрібен.
Автентифікація
Створи ключ в акаунті в розділі API-ключі. Надсилай його з кожним запитом у заголовку Authorization: Bearer <key> (або X-API-Key: <key>). Тримай ключ у таємниці й ніколи не вставляй його на вебсторінку. Ключ можна відкликати будь-коли.
Як це працює
Завдання виконуються асинхронно. Ти створюєш завдання й одразу отримуєш його id (HTTP 202). Потім запитуй завдання, доки його статус не стане done або failed. Опитуй кожні 2–5 секунд; більшість завдань триває кілька секунд.
Кінцеві точки
GET
/tools
Інструменти, опції та твої ліміти вхідних даних
GET
/balance
Твій баланс кредитів
POST
/jobs
Створення завдання (JSON або multipart/form-data з файлом зображення)
GET
/jobs/{id}
Статус і результат завдання
DELETE
/key
Відкликає ключ, який ти надсилаєш із цим запитом, наприклад, коли інтеграцію відключено. Уже створені завдання завершаться.
POST
/key/revoke
Те саме, що DELETE /key, для клієнтів, які вміють надсилати лише GET і POST.
Назва інструмента, дивись таблицю нижче. Обов'язково.
text
Вхідний текст. Для compare: текст A. Для alt_text: необов'язковий контекст сторінки.
text_b
Текст B (лише для compare).
url
Публічна вебсторінка, яку читають замість тексту (summarize, accessibility_check).
html
HTML сторінки для перевірки (accessibility_check), до 300 000 символів.
focus_keyword
Необов'язкове ключове слово для seo_meta. Без target seo_meta пише мовою з поля language.
faq
Необов'язкові фрагменти FAQ (лише для support_reply).
questions
Необов'язково для seo_meta, content_brief і faq_schema: поширені запитання відвідувачів як список текстів або {"text": ..., "count": n} (до 50, використовується щонайбільше 20). faq_schema відповідає на них насамперед, якщо джерело на них відповідає; visitor_questions у результаті показує, що сталося з кожним.
image
Зображення для alt_text: поле файлу в multipart/form-data або base64 / data URI у JSON. JPG, PNG, WebP або GIF, до 5 MB.
image_url
Необов'язково для alt_text замість image: публічна адреса зображення (http або https; JPEG, PNG, WebP або GIF; щонайбільше 5 MB). Do4U завантажує його один раз у фоновому режимі. Якщо це не вдається, завдання завершується помилкою image_unavailable і нічого не коштує.
options
Об'єкт з опціями інструмента, наприклад {"length": "short"}.
language
Мова результату й приміток: en, de або pl. За замовчуванням en. Для translate цільова мова задається опцією target.
no_store
true: вхідні дані видаляються одразу після обробки, а результат після першого отримання.
brand_voice
Необов'язково: false вимикає для цього завдання голос твого бренду (за замовчуванням голос бренду застосовується, якщо його налаштовано).
ai_label
Необов’язково: true показує видиму примітку «Позначено як створене ШІ» біля результату у вебінтерфейсі, false приховує її. За замовчуванням: налаштування у твоєму обліковому записі. Машиночитна позначка ШІ завжди є в результаті, і її не можна вимкнути: поля ai_generated і generator, коментар HTML у результатах HTML, ai_notice для описів зображень. ai_generated має значення false, якщо результат отримано лише з автоматичних перевірок.
callback_url
Необов'язково: публічна https-адреса, на яку надходить підписаний POST, коли завдання завершено (див. Webhooks).
render_js
Необов'язково: true спочатку завантажує сторінку з JavaScript (сторінки, які будують вміст у браузері; інструменти, що читають url). Доплата за рендеринг стягується лише якщо сторінку справді завантажено так; поле результату render показує, що сталося.
no_cache
Необов'язково: true завжди запускає нове завдання ШІ. Без цього використовується виконаний і досі збережений результат твого облікового запису (або робочого простору) з тим самим інструментом, параметрами та вхідними даними: завдання виконується одразу, from_history має значення true, і воно коштує 0 % кредитів оригіналу. Ніколи з no_store, ніколи для url.
allow_same_language
Необов'язково для translate, translate_html і translate_file: true перекладає, навіть якщо текст уже мовою перекладу. Без цього таке завдання відхиляється з same_language (400) — лише коли перевірка впевнена.
Безпечне повторення запитів (Idempotency-Key)
Надсилай заголовок Idempotency-Key з POST /jobs, наприклад випадковий UUID для кожного завдання (від 1 до 255 друкованих символів ASCII). Якщо з'єднання перервалося, а ти надсилаєш той самий запит повторно з тим самим Idempotency-Key і тим самим ключем API протягом 24 год, ти отримаєш ту саму відповідь: те саме завдання, без другого завдання і без другого списання. У такій відповіді є заголовок Idempotent-Replayed: true. Для кожного нового завдання використовуй новий ключ. Якщо ти надішлеш той самий ключ з іншим запитом, отримаєш 422 idempotency_conflict. Помилки не зберігаються: після помилки можна надіслати запит ще раз із тим самим ключем.
action: review | exportexport_format: csv | xlsxocr_language: en | de | pl | fr | es | it | nl | cs | sk | bg | da | el | fi | hr | hu | lt | pt | ro | sl | sv | uk | nb
action: review | exportexport_format: zipocr_language: en | de | pl | fr | es | it | nl | cs | sk | bg | da | el | fi | hr | hu | lt | pt | ro | sl | sv | uk | nb
mode: check | translateformat: auto | srt | vtttarget: en | de | pl | cs | sk | bg | hr | sl | uk | el | fr | es | it | pt | nl | da | sv | fi | lt | hu | ro
tone: neutral | friendly | persuasive | formallength: medium | short | longchannel: shop | marketplacetarget: auto | en | de | pl | fr | es | it | nl | cs | sk | uk | bg | da | el | fi | hr | hu | lt | pt | ro | sl | svmeta_description: no | yes
products, language, detected_language, channel, format, limits, counts, check, note
зазвичай 1–3 кредитів
headlinesЗаголовки та теми листів
text
kind: page | newsletter | adtone: neutral | friendly | persuasive | formalcount: 5 | 3 | 8target: auto | en | de | pl | fr | es | it | nl | cs | sk | uk | bg | da | el | fi | hr | hu | lt | pt | ro | sl | sv
level: simple | general | expertexamples: no | yestarget: auto | en | de | pl | fr | es | it | nl | cs | sk | uk | bg | da | el | fi | hr | hu | lt | pt | ro | sl | sv
level: B1 | A1 | A2 | B2 | C1target: auto | en | de | pl | fr | es | it | nl | cs | sk | uk | bg | da | el | fi | hr | hu | lt | pt | ro | sl | svkeep_terms: no | yes
chatbot: auto | yes | nomedia: unknown | no | realistic | artistic | illustrativearticles: unknown | no | unreviewed | reviewedtarget: auto | en | de | pl | fr | es | it | nl | cs | sk | uk | bg | da | el | fi | hr | hu | lt | pt | ro | sl | sv
target: auto | en | de | pl | fr | es | it | nl | cs | sk | uk | bg | da | el | fi | hr | hu | lt | pt | ro | sl | svtone: friendly | neutral | persuasive | formal | casuallength: medium | short | long
target: en | de | pl | fr | es | it | nl | cs | sk | uk | bg | da | el | fi | hr | hu | lt | pt | ro | sl | sv
translation, notes, review_status, alignment
зазвичай 1–4 кредитів
proofreadКоректура
text
text_language: auto | en | de | pl | fr | es | it | pt | nl | cs | sk | uk | ru | bg | ro | hu | sv | da | fi | tr | el | ar | fa | he | hi | zh | ja | ko | th
target: en | de | pl | fr | es | it | nl | cs | sk | uk | bg | da | el | fi | hr | hu | lt | pt | ro | sl | svscope: auto | all | missingline_endings: lf | crlf | lf_no_final_newline | crlf_no_final_newline
queued і running: ще виконується (position і wait_seconds допоможуть тобі чекати). done: result містить поля інструмента. failed: нічого не списано (credits дорівнює 0); error.code вказує причину: address_blocked (Do4U не відкриває цю адресу, наприклад приватну або внутрішню; надішли замість неї текст або HTML), input_too_large (скороти вхідні дані), image_unavailable або job_failed. expired: результат більше не зберігається.
Вебхуки
Додай "callback_url" до POST /api/v1/jobs, і Do4U надішле підписаний POST (подія job.finished зі статусом, кредитами та посиланням на результат - не сам результат), щойно завдання буде виконано. Лише публічні адреси на порту 80 або 443; ми повторюємо спробу до 6 разів зі зростаючими паузами.
Приклад: створи завдання з callback_url – і запит, який Do4U надсилає на цю адресу, коли завдання виконано:
POST /do4u-hook
Content-Type: application/json
X-Do4U-Event: job.finished
X-Do4U-Signature: t=1793180000,v1=6b1f...
{"event":"job.finished","id":"8f1c0b6a...","tool":"summarize","status":"done","credits":1,
"created":"2026-10-28T10:00:00+01:00","finished":"2026-10-28T10:00:04+01:00","result_url":"https://do4u.eu/api/v1/jobs/8f1c0b6a..."}
Перевір заголовок X-Do4U-Signature: t=<time>,v1=<hex>, де v1 = HMAC-SHA256(secret, "<time>.<raw body>"). Відхиляй застарілий час (наприклад, старіший за 5 хвилин). Твій секрет починається з whsec_ і показаний на сторінці «Ключі API».
// Node.js: rawBody = the request body exactly as received (string)
const crypto = require('crypto');
function do4uSignatureOk(rawBody, header, secret) {
const t = (header.match(/t=(\d+)/) || [])[1];
const v1 = (header.match(/v1=([0-9a-f]{64})/) || [])[1];
if (!t || !v1 || Math.abs(Date.now() / 1000 - Number(t)) > 300) return false;
const expected = crypto.createHmac('sha256', secret).update(t + '.' + rawBody).digest('hex');
return crypto.timingSafeEqual(Buffer.from(expected), Buffer.from(v1));
}
Коли баланс кредитів облікового запису падає нижче порогу, Do4U надсилає один підписаний POST на адресу вебхука цього облікового запису. Подія не містить персональних даних, лише баланс, поріг і час (UTC). Наступна подія надійде лише після того, як кредити будуть додані знову (покупка, щомісячні безкоштовні кредити або ваучер). Підпис і секрет такі самі, як для job.finished.
POST /do4u-hook
Content-Type: application/json
X-Do4U-Event: credits.low
X-Do4U-Signature: t=1793180000,v1=6b1f...
{"event":"credits.low","balance":18,"threshold":20,"ts":"2026-10-29T10:00:04Z"}
Шаблон, ще не протестований у справжньому екземплярі n8n чи Make – перевір підпис, перш ніж ним користуватися.
В n8n: Workflows → Import from file. Потім введи свій секрет у вузол "Check signature" і свій ключ API у "Do4U: get result", активуй робочий процес і використай робочу URL-адресу вебхука як callback_url. Для n8n на власному сервері для перевірки підпису потрібна змінна середовища NODE_FUNCTION_ALLOW_BUILTIN=crypto.
Make
Додай модуль Webhooks → Custom webhook як тригер і ввімкни "JSON pass-through" та "Get request headers" у його розширених налаштуваннях.
Використай адресу цього вебхука як callback_url.
Перевір підпис: порівняй v1 із заголовка X-Do4U-Signature з sha256(t + "." + raw body; hex; твій секрет).
Додай HTTP → Make a request: GET на result_url із заголовком Authorization: Bearer <your API key>.
Використай поле result у своїх наступних модулях.
Шаблон, ще не протестований у справжньому екземплярі n8n чи Make – перевір підпис, перш ніж ним користуватися.
Рецепти: ланцюжок інструментів
Рецепт виконує від 2 до 4 інструментів один за одним як єдине завдання. Надсилай «recipe» замість «tool»: або назву готового рецепта, або список кроків. Текст потрапляє на перший крок; результат кожного кроку – це текст для наступного. GET /api/v1/recipes перелічує готові рецепти, інструменти, які можна використовувати, і поле, яке передає кожен інструмент.
Ти отримуєш одну оцінку для всіх кроків (credits_estimate). Ця сума резервується на початку. Після кожного кроку реальне використання списується, а решта залишається зарезервованою до кінця, після чого вивільняється. Невдалий крок нічого не коштує, решту кроків пропущено, а кроки, які вже завершилися, оплачуються.
GET /api/v1/jobs/{id} показує кожен крок зі статусом (pending, queued, running, done, failed, skipped), його кредитами, повідомленням input_shortened, якщо текст довелося скоротити для наступного інструмента, і результатом кожного кроку після завершення рецепта. З no_store результати показуються один раз. callback_url спрацьовує один раз, наприкінці рецепта.
Idempotency-Key порожній, задовгий або містить символи, що не є друкованими символами ASCII.
idempotency_conflict
422
Цей Idempotency-Key уже використано з іншим запитом.
idempotency_in_progress
409
Запит із цим Idempotency-Key ще виконується. Зачекай трохи (Retry-After).
idempotency_unavailable
503
Idempotency-Key зараз неможливо використати. Спробуй пізніше.
same_language
400
Текст уже мовою перекладу (інструменти перекладу). Надішли allow_same_language: true, щоб усе одно перекласти.
Ліміти
60 запитів за хвилину на ключ і 120 на акаунт.
Одночасно відкритих завдань на акаунт: Free 3, Starter 3, Standard 5, Pro 10, для сайту й API разом.
Вхідні дані: Free 8 000 символів, платні пакети 30 000. Нижчі ліміти для окремих інструментів: compare 20 000, alt_text 1 000, translate 12 000 (compare: обидва тексти разом).
API-ключі: Free 1, Starter 1, Standard 5, Pro 10.
Кредити
Нове завдання показує оцінку (credits_estimate); списується фактичне використання (credits). Невдалі завдання нічого не коштують. Безкоштовні кредити використовуються першими.
Офісні інструменти: вхідні дані, перевірка та експорт
Усі дев’ять інструментів використовують POST /api/v1/jobs і наявну кінцеву точку стану завдань. Вхідні документи та створені чернетки є даними, а не інструкціями для виконання дій. Результати потребують перевірки перед практичним використанням. Жоден інструмент не надсилає повідомлень, не публікує статей і не змінює вихідних файлів.
Протокол зустрічі
meeting_minutes
Вхідні дані та обмеження
Лише звичайний текст UTF-8, до 12 000 символів; кожен непорожній вихідний рядок обмежено 1 200 символами. options.items приймає рядки "5", "10" або "20" (типово "10"). Мова джерела зберігається. Завантажені PDF, віддалені URL та зображення не приймаються.
Результат та експорт
Результат містить перевірені варіанти чернеток, точні цитати з джерела, номери рядків і зміщення в байтах. Відсутні відповідальні, строки чи відповіді залишаються незаповненими. result.exports.text і result.exports.csv містять filename, mime та content у UTF-8. Комірки CSV отримують захист від формул. Навчальні тести також надають result.exports.moodle_xml для імпорту запитань із короткою відповіддю в Moodle. Запитання та відповіді все одно потребують фахової перевірки.
JSON-запит
{
"tool": "meeting_minutes",
"text": "Decision: use the blue design.\nAnna will send the draft by 7 November 2026.\nBudget remains open.",
"options": {
"items": "10"
}
}
Тендерні вимоги
tender_requirements
Вхідні дані та обмеження
Лише звичайний текст UTF-8, до 12 000 символів; кожен непорожній вихідний рядок обмежено 1 200 символами. options.items приймає рядки "5", "10" або "20" (типово "10"). Мова джерела зберігається. Завантажені PDF, віддалені URL та зображення не приймаються.
Результат та експорт
Результат містить перевірені варіанти чернеток, точні цитати з джерела, номери рядків і зміщення в байтах. Відсутні відповідальні, строки чи відповіді залишаються незаповненими. result.exports.text і result.exports.csv містять filename, mime та content у UTF-8. Комірки CSV отримують захист від формул. Навчальні тести також надають result.exports.moodle_xml для імпорту запитань із короткою відповіддю в Moodle. Запитання та відповіді все одно потребують фахової перевірки.
JSON-запит
{
"tool": "tender_requirements",
"text": "A signed declaration is mandatory.\nThe proposal must include two references.\nThe submission deadline is 9 November 2026.",
"options": {
"items": "10"
}
}
Робочі інструкції
work_instructions
Вхідні дані та обмеження
Лише звичайний текст UTF-8, до 12 000 символів; кожен непорожній вихідний рядок обмежено 1 200 символами. options.items приймає рядки "5", "10" або "20" (типово "10"). Мова джерела зберігається. Завантажені PDF, віддалені URL та зображення не приймаються.
Результат та експорт
Результат містить перевірені варіанти чернеток, точні цитати з джерела, номери рядків і зміщення в байтах. Відсутні відповідальні, строки чи відповіді залишаються незаповненими. result.exports.text і result.exports.csv містять filename, mime та content у UTF-8. Комірки CSV отримують захист від формул. Навчальні тести також надають result.exports.moodle_xml для імпорту запитань із короткою відповіддю в Moodle. Запитання та відповіді все одно потребують фахової перевірки.
JSON-запит
{
"tool": "work_instructions",
"text": "Prerequisite: a clean surface.\nOperator: technician.\nSwitch off the device before cleaning.\nCheck that the surface is dry.",
"options": {
"items": "10"
}
}
Навчальна вікторина
learning_quiz
Вхідні дані та обмеження
Лише звичайний текст UTF-8, до 12 000 символів; кожен непорожній вихідний рядок обмежено 1 200 символами. options.items приймає рядки "5", "10" або "20" (типово "10"). Мова джерела зберігається. Завантажені PDF, віддалені URL та зображення не приймаються.
Результат та експорт
Результат містить перевірені варіанти чернеток, точні цитати з джерела, номери рядків і зміщення в байтах. Відсутні відповідальні, строки чи відповіді залишаються незаповненими. result.exports.text і result.exports.csv містять filename, mime та content у UTF-8. Комірки CSV отримують захист від формул. Навчальні тести також надають result.exports.moodle_xml для імпорту запитань із короткою відповіддю в Moodle. Запитання та відповіді все одно потребують фахової перевірки.
JSON-запит
{
"tool": "learning_quiz",
"text": "Water freezes at zero degrees Celsius.\nA triangle has three sides.\nPhotosynthesis uses light energy.",
"options": {
"items": "10"
}
}
Очищення CSV та XLSX
clean_table
Вхідні дані та обмеження
CSV передається в text (до 24 000 байтів), або text починається з D4XLSX1: з подальшим строгим кодуванням base64 файлу XLSX (до 1 000 000 декодованих байтів). Обмеження: один аркуш, 201 рядок включно із заголовком, 32 стовпці, 3 000 комірок і 20 000 байтів тексту комірок. Формули, макроси та зовнішні посилання відхиляються. Стилі та функції електронних таблиць не зберігаються. options.delimiter: auto, comma, semicolon або tab. options.decimal: keep або comma.
Результат та експорт
Перевірка виявляє повністю однакові дублікати рядків і обережні виправлення значень. Для експорту повторно передаються той самий початковий text і параметри з options.office_action="export", options.export_format="csv" або "xlsx", а selected — як список перевірених ідентифікаторів, закодований у JSON-рядку. Застосовуються лише вибрані зміни. Порожній вибір не виконує очищення. Захист CSV від формул залишається активним; XLSX зберігає буквальні рядки. Робочий процес повторно обчислює ідентифікатори, а не довіряє звіту клієнта.
selected — це рядок зі списком JSON, наприклад "[\"C1\"]"; потрібно використовувати фактичні ідентифікатори з перевірки. Максимум 5 000 байтів і 3 000 різних ідентифікаторів. Завдання експорту повертають result.type="office_export" і result.export з filename, mime та content_base64. Base64 декодується як байти файлу. Звіти, надані клієнтом, не приймаються.
Звичайний текст UTF-8 до 12 000 байтів. options.scope приймає all, email, phone, iban або ip. Необов’язкове поле terms — це рядок із максимум 30 точними, чутливими до регістру термінами в окремих рядках, загалом до 2 000 байтів. Для виявлення імен та адрес потрібні ці власні терміни. Розпізнавання IP охоплює IPv4; можливі номери телефонів потребують перевірки, а можливі IBAN — правильної контрольної суми.
Результат та експорт
Кожне входження та запропонований заповнювач потребують перевірки. Повторювані однакові значення мають стабільні заповнювачі в межах цього тексту. Для експорту повторно передаються початковий text і параметри з options.office_action="export", options.export_format="txt", а selected — як список ідентифікаторів входжень, закодований у JSON-рядку. Невибрані входження залишаються без змін. Це допомагає приховувати дані, але не засвідчує незворотну анонімізацію.
selected — це рядок зі списком JSON, наприклад "[\"C1\"]"; потрібно використовувати фактичні ідентифікатори з перевірки. Максимум 5 000 байтів і 3 000 різних ідентифікаторів. Завдання експорту повертають result.type="office_export" і result.export з filename, mime та content_base64. Base64 декодується як байти файлу. Звіти, надані клієнтом, не приймаються.
Звичайний SRT або WebVTT передається в text, до 65 536 байтів, 200 блоків і 16 000 символів тексту субтитрів. Стилі, вбудована розмітка та непідтримувані метадані відхиляються. options.mode — check (типово) або translate; options.format — auto, srt або vtt. options.target вибирає підтримувану мову перекладу. Цілочислові поля max_line_chars (10–100, типово 42), max_lines (1–6, типово 2) і max_cps (5–40, типово 20) розташовані на верхньому рівні.
Результат та експорт
Результат повідомляє про помилки часу, накладання, довжину рядків і швидкість читання. Перевірка зберігає мову оригіналу. Переклад змінює текст блоків, зберігаючи початкові часові позначки та відповідність блоків; часові позначки не змінюються, а блоки не розділяються. Текст для завантаження міститься в result.file разом із result.filename та result.mime. Неправильні часові позначки можуть залишити file зі значенням null. Успішна перевірка не гарантує доступності або мовної якості.
XML рахунка у UTF-8 передається в text, до 262 144 байтів. Приймаються UBL Invoice, UBL CreditNote та UN/CEFACT CII з профілем EN 16931 або XRechnung 3. options.profile — auto, en16931 або xrechnung. ZIP, PDF, видобування вбудованого PDF ZUGFeRD, DTD та зовнішні сутності не підтримуються. Видобутий XML можна передати окремо, якщо він відповідає прийнятому профілю.
Результат та експорт
Валідація використовує офіційні артефакти XSD і Schematron із зафіксованими версіями: KoSIT 1.6.3, конфігурацію XRechnung 3.0.2 від 2026-08-31, правила EN 16931 1.3.16 і правила XRechnung 2.6.0. Результат записує версії, хеш документа, виявлені проблеми, серйозність, ідентифікатори правил і статус прийняття. not_checked означає, що рішення про відповідність не отримано. Успішна технічна перевірка не гарантує прийняття одержувачем, правильності бухгалтерського обліку чи дотримання законодавства.
JSON-запит
Наведений нижче стислий приклад XML навмисно неповний і має повертати помилки валідації. Повний комерційний рахунок повинен містити всі обов’язкові поля; приклад демонструє формат запиту, а не відповідний вимогам рахунок.
Етап брифінгу потребує topic (300 байтів), audience (500 байтів) і goal (500 байтів). Необов’язкове поле text надає до 12 000 байтів вихідного матеріалу, не більше ніж у 12 абзацах по 1 800 байтів кожен. Необов’язковий source_url має бути публічною HTTP(S)-адресою до 2 000 символів; для дозволу аналізу analyse_url має бути логічним значенням JSON true. Приватні адреси та недозволені сторінки залишаються заблокованими.
Результат та експорт
Спочатку передається phase="briefing". Перевіряються отримані план, запитання та джерела. Прив’язаний до власника результат надає approval_token і briefing_hash. Лише після явної перевірки передаються phase="article", approved=true, sources_approved=true та обидва незмінені значення. Схвалення спливає через 30 хвилин і належить автентифікованому обліковому запису. Запити статті не можуть замінювати topic, audience, goal, text або джерела. Стаття залишається чернеткою з абзацами, пов’язаними з джерелами; нічого не публікується автоматично.
JSON-запит
{
"tool": "blog_assistant",
"phase": "briefing",
"topic": "Bicycle inspections",
"audience": "Local commuters",
"goal": "Explain the appointment process",
"text": "An inspection requires an appointment.\n\nThe workshop checks brakes, tyres and lights."
}
Звіти рахунків містять result.exports.json; перевірені чернетки статей містять result.exports.text. Кожен експорт містить filename, mime та content у UTF-8. Текст статті зберігає посилання на джерела й залишається неопублікованою чернеткою.
Експорт зберігається як вкладення з повернутим MIME-типом. Увесь текст слід вважати недовіреним вмістом та екранувати перед відображенням у HTML. Вміст документів не можна виконувати, а виявлені проблеми — перетворювати на автоматичні зовнішні дії.
Інструменти для роботи з документами, електронними таблицями та медіафайлами
Ці вісім інструментів використовують той самий автентифікований API завдань. Надсилається JSON-запит, поле text якого містить об’єкт, закодований у JSON. Завантажені файли представлені в цьому об’єкті назвою файлу та вмістом у стандартному кодуванні base64. Файли за віддаленими URL-адресами не завантажуються.
Попередній перегляд та експорт є окремими запитами. Експорт потребує явного підтвердження та відбитка джерела або токена підтвердження, прив'язаного до власника, який повертається під час попереднього перегляду. Файл або відповідь моделі не можуть бути підтвердженням.
Оцифрування чеків
receipt_extract
Ввід та обмеження
Об’єкт містить files: один об’єкт із name та content_base64. PDF, PNG, JPEG або TXT; максимум 1 MB, PDF — до трьох сторінок. options.action має значення review або export; options.export_format — csv або xlsx. Для експорту повторно надсилаються оригінальні файли разом з approved=true, source_sha256 і reviewed з виправленими полями та позиціями.
Результат та перегляд
Перегляд повертає витягнуті поля, рядкові елементи, точні докази джерела та арифметичні попередження. Експортовані значення є чернетками, перевіреними клієнтом, а не верифікованими бухгалтерськими записами. OCR може вносити помилки.
Об’єкт містить task, columns, application, formula_language та separator. Кожен стовпець має name, cell і sample. До 20 стовпців і 3 000 символів в описі завдання. application має значення excel або sheets; назви функцій використовують en, de або pl; separator — кома або крапка з комою. Англійські назви функцій доступні за сумісних налаштувань електронної таблиці.
Результат та перегляд
Повертає формулу, пояснення, припущення та приклади перевірок. tests_executed — false: сервер ніколи не запускає формулу. Підтримуваний піднабір дозволяє використовувати загальні функції та локальні посилання на клітинки; зовнішні посилання, макроси та мережеві функції відхиляються.
Приклад запиту
{
"tool": "spreadsheet_formula",
"text": "{\"task\":\"Calculate quantity times unit price.\",\"columns\":[{\"name\":\"Quantity\",\"cell\":\"A2\",\"sample\":\"3\"},{\"name\":\"Unit price\",\"cell\":\"B2\",\"sample\":\"12\"}],\"application\":\"excel\",\"formula_language\":\"en\",\"separator\":\",\"}"
}
Об’єкт містить source, translation, source_language і target_language, а також необов’язкові terms із парами source та target. До 10 000 символів на текст і 30 пар термінів.
Результат та перегляд
Повертає можливі розбіжності з точними цитатами та зміщенням байтів в обох текстах. Окремі перевірки порівнюють буквальні чисельні входження та обов'язкові терміни. Знайдення може бути пояснене локалізованим форматуванням або флексією; порожній звіт не є підтвердженням точності.
Об’єкт містить filename, content_base64 і language. Підтримувані формати: WAV, MP3, M4A, MP4, WebM, OGG та FLAC. Максимум 3 MiB і 30 секунд. language має значення auto або підтримуваний код мови. Файли обробляються локально; завантаження за URL не здійснюється.
Результат та перегляд
Повертаються сегменти з часовими мітками та експорти TXT, SRT і VTT для перевірки. Розпізнавання може бути помилковим. Статус not_completed містить код із визначеного набору помилок і не означає успішного транскрибування.
Потрібен справжній файл. Схема нижче описує декодований об’єкт у полі text; content_base64 має містити фактичні байти файлу у стандартному кодуванні base64. Рядки-заповнювачі не є робочими прикладами.
Об’єкт містить template з name і content_base64, а також data у вигляді тексту CSV або D4XLSX1: з наступними байтами XLSX у стандартному кодуванні base64. Шаблон DOCX приймає до 32 заповнювачів, а дані — до 20 рядків. options.action має значення review або export; options.export_format — docx або pdf. Експорт потребує оригінальних вхідних даних, approved=true та source_sha256.
Результат та перегляд
Попередній перегляд показує заповнювачі, стовпці даних і відсутні значення. Відсутність значень, які використовуються в шаблоні, блокує експорт. ZIP містить готові документи. DOCX зберігає макет шаблону; PDF використовує простий текстовий макет без стилів Word і зображень.
Потрібен справжній файл. Схема нижче описує декодований об’єкт у полі text; content_base64 має містити фактичні байти файлу у стандартному кодуванні base64. Рядки-заповнювачі не є робочими прикладами.
Об’єкт містить таблиці source і target у вигляді тексту CSV або D4XLSX1: з наступними байтами XLSX у стандартному кодуванні base64. Цільовий заголовок задає назви потрібних стовпців; необов’язковий другий рядок указує text, number, date або email, за потреби з префіксом required:. mapping містить індекси стовпців джерела від нуля або null. До 200 рядків даних і 32 стовпців.
Результат та перегляд
Повертаються запропоновані зіставлення, профіль для повторного використання, рядки попереднього перегляду й проблеми валідації. Експорт з options.action=export потребує approved=true та явно заданого mapping; невирішені проблеми валідації блокують експорт. Зовнішні системи не змінюються.
Для phase=outline поле text містить title, audience, purpose і material. Матеріал складається з одного–восьми абзаців джерела, до 1 200 символів кожен. Для phase=pptx на верхньому рівні передаються approved=true та approval_token; text має бути відсутнім або порожнім. Токени прив’язані до автентифікованого облікового запису та мають строк дії.
Результат та перегляд
План містить заголовки слайдів і цитати, прив’язані до джерела. Після перевірки другий запит експортує редагований PPTX із геометричними елементами оформлення й нотатками доповідача. Текст джерела не може змінювати підтвердження, прив’язку облікового запису або права експорту.
Приклад запиту
{
"tool": "presentation",
"phase": "outline",
"text": "{\"title\":\"Workshop services\",\"audience\":\"Local businesses\",\"purpose\":\"Explain available services\",\"material\":\"The workshop repairs bicycles.\\nAppointments are required for inspections.\"}"
}
Об’єкт містить files і необов’язкову назву проєкту. До десяти файлів TXT, PDF, DOCX, PNG або JPEG, 1 MB на файл і 2 MB загалом. options.action має значення review або export; options.export_format — zip. Експорт потребує оригінальних вхідних даних, approved=true, source_sha256 та об’єкта names, що зіставляє ID файлів із перевіреними місцями призначення.
Результат та перегляд
Повернення запропонованих категорій, дат та імен файлів. Пропозиції базуються на тексті документа та потребують перевірки. Експорт створює ZIP-архів з копій; оригінали залишаються без змін. Небезпечні шляхи, зміна розширень та дублювання цільових папок відхиляються.
Текстові експорти містять content. Двійкові експорти позначають base64 через content_base64 або encoding=base64. Декодується лише вказане кодування. Назви файлів є пропозиціями; результати доступні лише через автентифікований результат завдання з перевіркою належності власнику.
Інструменти закупівель, планування й операційної роботи
Ці вісім інструментів використовують наявний автентифікований API завдань. Поле text містить об’єкт, закодований як JSON, із переліченими нижче вхідними полями. Приклади містять реальні зразкові дані в межах обмежень.
Кожен початковий результат потребує етапу моделі ШІ через наявну службу виконавців. Детермінований код перевіряє посилання на джерела, обмеження й обчислення після того, як модель запропонує відповідності, призначення або структуру. Резервного варіанта лише на програмному коді немає.
Надсилається application/json. Завантаження multipart, URL віддалених файлів, невідомі поля й непорожні options, специфічні для інструмента, відхиляються. options потрібно пропустити або надіслати як порожній об’єкт. Спільні прапорці API зберігають своє спільне значення в API.
Порівняння пропозицій постачальників
supplier_compare
Порівняння позицій пропозицій постачальників із потрібними позиціями, перевірка відповідностей, запропонованих ШІ, та аналіз різниць у кількості, валюті, доставці й загальній ціні.
Декодовані вхідні поля
requirements — Потрібні позиції
Стовпці CSV: description,quantity,unit. Позначення одиниць мають бути такими самими, як у пропозиціях. До 30 рядків; 40 рядків у всіх таблицях разом.
offers — Позиції пропозицій постачальників
Стовпці CSV: supplier,description,quantity,unit,unit_price,shipping,currency,lead_days. shipping — вартість доставки лише цієї позиції; за її відсутності вводиться 0. Строк поставки може бути порожнім. Ціни потрібно порівнювати на однаковій податковій основі.
csv_separator — Роздільник CSV
Вибрати крапку з комою, кому або табуляцію лише для експортованого CSV. Завантажені вихідні CSV й надалі потребують задокументованих заголовків, розділених комами.
csv_bom — Маркер UTF-8 у CSV
Додати маркер порядку байтів UTF-8 для сумісності з електронними таблицями або пропустити його для систем, що потребують звичайного UTF-8.
csv_line_ending — Закінчення рядків CSV
Використовувати LF або CRLF для експортованих записів CSV. Це не змінює вихідного тексту чи переносів рядків усередині комірок у лапках.
include_json — Додати експорт JSON
Запропонувати додатковий структурований звіт JSON із повними перевіреними рядками, висновками й підсумком. Експорт не виконує жодної дії.
max_lead_days — Межа перевірки строку постачання
0 вимикає цю додаткову перевірку. Інакше позначати строки постачання пропозицій, довші за вибрану кількість днів, і пропозиції без зазначеного строку постачання. Ціни й порівняння не змінюються. Максимум 999 днів.
row_order — Порядок рядків перевірки
Перевпорядкувати повні рядки таблиці без видалення висновків, зміни розрахунків чи призначень. Порожні значення сортування йдуть останніми; однакові значення зберігають початковий відносний порядок.
Максимальна кількість байтів UTF-8 в оболонці text: 60000
Перевірка результату й джерел
Тип результату — ops_review. columns містить key і label_key; rows містить відповідні скалярні значення комірок. findings містить локалізовні значення code й посилання на джерела refs; summary містить label_key і value. review_required та ai_required мають значення true. ai_model визначає прийняту модель, якщо її надає виконавець. Деякі інструменти також повертають source_sha256 або note_key. Рядки джерел залишаються недовіреними даними й мають відображатися як текст, ніколи як виконуваний HTML або інструкції.
Зіставлення позицій замовлення, поставки й рахунку за допомогою ШІ та обчислення відсутніх кількостей, надмірного виставлення рахунків і різниць у ціні за одиницю з вихідних даних.
Декодовані вхідні поля
orders — Позиції замовлення
Стовпці CSV: reference,description,quantity,unit,unit_price,currency. reference означає спільне посилання на замовлення, а не номер документа постачальника. Усюди мають використовуватися однакові позначення одиниць і податкова основа.
deliveries — Поставлені позиції
Стовпці CSV: reference,description,quantity,unit. reference означає спільне посилання на замовлення. Часткові поставки можуть бути окремими рядками.
invoices — Позиції рахунку
Стовпці CSV: reference,description,quantity,unit,unit_price,currency. reference означає спільне посилання на замовлення. Податки, знижки й кредит-ноти не можна вводити як товарні позиції.
csv_separator — Роздільник CSV
Вибрати крапку з комою, кому або табуляцію лише для експортованого CSV. Завантажені вихідні CSV й надалі потребують задокументованих заголовків, розділених комами.
csv_bom — Маркер UTF-8 у CSV
Додати маркер порядку байтів UTF-8 для сумісності з електронними таблицями або пропустити його для систем, що потребують звичайного UTF-8.
csv_line_ending — Закінчення рядків CSV
Використовувати LF або CRLF для експортованих записів CSV. Це не змінює вихідного тексту чи переносів рядків усередині комірок у лапках.
include_json — Додати експорт JSON
Запропонувати додатковий структурований звіт JSON із повними перевіреними рядками, висновками й підсумком. Експорт не виконує жодної дії.
review_blank_references — Позначати відсутні реквізити документів
Додати висновок перевірки для кожного рядка замовлення, постачання або рахунку з порожнім реквізитом. Наявні рішення зіставлення й попередження не змінюються.
row_order — Порядок рядків перевірки
Перевпорядкувати повні рядки таблиці без видалення висновків, зміни розрахунків чи призначень. Порожні значення сортування йдуть останніми; однакові значення зберігають початковий відносний порядок.
Максимальна кількість байтів UTF-8 в оболонці text: 60000
Перевірка результату й джерел
Тип результату — ops_review. columns містить key і label_key; rows містить відповідні скалярні значення комірок. findings містить локалізовні значення code й посилання на джерела refs; summary містить label_key і value. review_required та ai_required мають значення true. ai_model визначає прийняту модель, якщо її надає виконавець. Деякі інструменти також повертають source_sha256 або note_key. Рядки джерел залишаються недовіреними даними й мають відображатися як текст, ніколи як виконуваний HTML або інструкції.
Пропонування відповідностей між вхідними платежами й неоплаченими рахунками, виявлення неоднозначності та обчислення часткових платежів, залишків і переплат.
Декодовані вхідні поля
payments — Вхідні платежі
Стовпці CSV: reference,counterparty,date,amount,currency. Використовуються відомі посилання на рахунки, додатні суми й дати YYYY-MM-DD. Один платіж можна запропонувати лише для одного рахунку.
invoices — Неоплачені рахунки
Стовпці CSV: reference,counterparty,date,amount,currency. amount — непогашений залишок до завантажених платежів. Посилання можуть бути порожніми, але неоднозначність може завадити розподілу.
csv_separator — Роздільник CSV
Вибрати крапку з комою, кому або табуляцію лише для експортованого CSV. Завантажені вихідні CSV й надалі потребують задокументованих заголовків, розділених комами.
csv_bom — Маркер UTF-8 у CSV
Додати маркер порядку байтів UTF-8 для сумісності з електронними таблицями або пропустити його для систем, що потребують звичайного UTF-8.
csv_line_ending — Закінчення рядків CSV
Використовувати LF або CRLF для експортованих записів CSV. Це не змінює вихідного тексту чи переносів рядків усередині комірок у лапках.
include_json — Додати експорт JSON
Запропонувати додатковий структурований звіт JSON із повними перевіреними рядками, висновками й підсумком. Експорт не виконує жодної дії.
review_date — Опорна дата віку рахунків
Необов’язкова явна дата YYYY-MM-DD від 1900 до 2200 року. Відкриті залишки рахунків перевіряються за віком від дати рахунку в джерелі. Порожнє значення вимикає цю перевірку. Вік рахунку не є строком оплати чи юридичним висновком про прострочення.
aging_days — Поріг перевірки віку рахунків
Позначати додатні відкриті залишки, дата рахунку яких передує вибраній опорній даті щонайменше на цю кількість днів. Діапазон 0–3 650 днів. Потрібна опорна дата; строк оплати рахунку не виводиться.
row_order — Порядок рядків перевірки
Перевпорядкувати повні рядки таблиці без видалення висновків, зміни розрахунків чи призначень. Порожні значення сортування йдуть останніми; однакові значення зберігають початковий відносний порядок.
Максимальна кількість байтів UTF-8 в оболонці text: 60000
Перевірка результату й джерел
Тип результату — ops_review. columns містить key і label_key; rows містить відповідні скалярні значення комірок. findings містить локалізовні значення code й посилання на джерела refs; summary містить label_key і value. review_required та ai_required мають значення true. ai_model визначає прийняту модель, якщо її надає виконавець. Деякі інструменти також повертають source_sha256 або note_key. Рядки джерел залишаються недовіреними даними й мають відображатися як текст, ніколи як виконуваний HTML або інструкції.
Визначення пріоритетів складських позицій за допомогою ШІ, розрахунок поповнення за наданим попитом і строками поставки та перевірка впливу мінімального замовлення й розміру упаковки.
Декодовані вхідні поля
items — Складські позиції
Стовпці CSV: id,name,on_hand,daily_demand,lead_days,safety_stock,min_order,pack_size. ID мають бути унікальними. Кількості використовують десяткові крапки; lead_days і min_order — невід’ємні цілі числа, а pack_size — додатне ціле число.
horizon_days — Додаткові дні забезпечення запасом
Цільовий період забезпечення дорівнює строку поставки плюс ці додаткові дні. Попит вважається сталим; результат є оцінкою для планування.
notes — Примітки й побажання щодо планування
Необов’язковий контекст для пропозиції ШІ. Доступність, кваліфікації, залежності й числові обмеження також потрібно ввести в структуровані таблиці; примітки ніколи не скасовують ці перевірки.
csv_separator — Роздільник CSV
Вибрати крапку з комою, кому або табуляцію лише для експортованого CSV. Завантажені вихідні CSV й надалі потребують задокументованих заголовків, розділених комами.
csv_bom — Маркер UTF-8 у CSV
Додати маркер порядку байтів UTF-8 для сумісності з електронними таблицями або пропустити його для систем, що потребують звичайного UTF-8.
csv_line_ending — Закінчення рядків CSV
Використовувати LF або CRLF для експортованих записів CSV. Це не змінює вихідного тексту чи переносів рядків усередині комірок у лапках.
include_json — Додати експорт JSON
Запропонувати додатковий структурований звіт JSON із повними перевіреними рядками, висновками й підсумком. Експорт не виконує жодної дії.
large_order_threshold — Поріг перевірки великих замовлень
0 вимикає цю додаткову перевірку. Інакше позначати запропоновані кількості замовлень, строго більші за поріг, до 10 000 000 одиниць. Вихідні запаси, попит, цільове покриття, округлення за пакуванням і кількості замовлень не змінюються.
row_order — Порядок рядків перевірки
Перевпорядкувати повні рядки таблиці без видалення висновків, зміни розрахунків чи призначень. Порожні значення сортування йдуть останніми; однакові значення зберігають початковий відносний порядок.
Максимальна кількість байтів UTF-8 в оболонці text: 120000
Перевірка результату й джерел
Тип результату — ops_review. columns містить key і label_key; rows містить відповідні скалярні значення комірок. findings містить локалізовні значення code й посилання на джерела refs; summary містить label_key і value. review_required та ai_required мають значення true. ai_model визначає прийняту модель, якщо її надає виконавець. Деякі інструменти також повертають source_sha256 або note_key. Рядки джерел залишаються недовіреними даними й мають відображатися як текст, ніколи як виконуваний HTML або інструкції.
Приклад запиту
{
"tool": "reorder_plan",
"text": "{\"items\":\"id,name,on_hand,daily_demand,lead_days,safety_stock,min_order,pack_size\\nI1,Brake pads,12,3,5,4,10,5\\nI2,Chain oil,30,1,3,2,6,6\",\"horizon_days\":7,\"notes\":\"Brake pads support scheduled repairs and should be reviewed first. Chain oil is less urgent.\",\"csv_separator\":\"semicolon\",\"csv_bom\":true,\"csv_line_ending\":\"lf\",\"include_json\":false,\"large_order_threshold\":0,\"row_order\":\"source\"}"
}
Пропонування призначень працівників за допомогою ШІ та перевірка доступності, потрібних навичок, перекриття змін, наданих обмежень годин і незаповнених місць.
Декодовані вхідні поля
workers — Працівники
Стовпці CSV: id,name,skills,max_hours. Кілька навичок розділяються |. max_hours — максимальний загальний обсяг запланованої роботи в цій пропозиції, а не законодавче обмеження робочого часу.
availability — Доступність
Стовпці CSV: id,worker_id,start,end. Час явно задається в UTC у форматі YYYY-MM-DDTHH:MM. Один інтервал доступності має покривати всю зміну.
shifts — Зміни
Стовпці CSV: id,start,end,skill,needed. Увесь час указується в UTC. Працівник має володіти саме потрібною навичкою. needed — необхідна кількість працівників.
notes — Примітки й побажання щодо планування
Необов’язковий контекст для пропозиції ШІ. Доступність, кваліфікації, залежності й числові обмеження також потрібно ввести в структуровані таблиці; примітки ніколи не скасовують ці перевірки.
csv_separator — Роздільник CSV
Вибрати крапку з комою, кому або табуляцію лише для експортованого CSV. Завантажені вихідні CSV й надалі потребують задокументованих заголовків, розділених комами.
csv_bom — Маркер UTF-8 у CSV
Додати маркер порядку байтів UTF-8 для сумісності з електронними таблицями або пропустити його для систем, що потребують звичайного UTF-8.
csv_line_ending — Закінчення рядків CSV
Використовувати LF або CRLF для експортованих записів CSV. Це не змінює вихідного тексту чи переносів рядків усередині комірок у лапках.
include_json — Додати експорт JSON
Запропонувати додатковий структурований звіт JSON із повними перевіреними рядками, висновками й підсумком. Експорт не виконує жодної дії.
max_shift_hours — Поріг перевірки тривалості змін
0 вимикає цю додаткову перевірку. Інакше позначати вихідні зміни, довші за вибрану тривалість, до 168 годин. Призначення й попередження покриття зберігаються. Це налаштування планування, а не юридична оцінка робочого часу.
row_order — Порядок рядків перевірки
Перевпорядкувати повні рядки таблиці без видалення висновків, зміни розрахунків чи призначень. Порожні значення сортування йдуть останніми; однакові значення зберігають початковий відносний порядок.
Максимальна кількість байтів UTF-8 в оболонці text: 120000
Перевірка результату й джерел
Тип результату — ops_review. columns містить key і label_key; rows містить відповідні скалярні значення комірок. findings містить локалізовні значення code й посилання на джерела refs; summary містить label_key і value. review_required та ai_required мають значення true. ai_model визначає прийняту модель, якщо її надає виконавець. Деякі інструменти також повертають source_sha256 або note_key. Рядки джерел залишаються недовіреними даними й мають відображатися як текст, ніколи як виконуваний HTML або інструкції.
Приклад запиту
{
"tool": "shift_plan",
"text": "{\"workers\":\"id,name,skills,max_hours\\nW1,Alex,service|repair,8\\nW2,Sam,service,8\",\"availability\":\"id,worker_id,start,end\\nA1,W1,2026-11-09T08:00,2026-11-09T16:00\\nA2,W2,2026-11-09T08:00,2026-11-09T16:00\",\"shifts\":\"id,start,end,skill,needed\\nS1,2026-11-09T08:00,2026-11-09T12:00,service,1\\nS2,2026-11-09T12:00,2026-11-09T16:00,repair,1\",\"notes\":\"Where practical, retain Alex for repair work and use Sam for the service desk.\",\"csv_separator\":\"semicolon\",\"csv_bom\":true,\"csv_line_ending\":\"lf\",\"include_json\":false,\"max_shift_hours\":0,\"row_order\":\"source\"}"
}
Пропонування пріоритетів завдань і призначень ресурсів за допомогою ШІ, потім розрахунок графіка з урахуванням залежностей і денної спроможності та позначення непризначеної роботи.
Декодовані вхідні поля
tasks — Завдання проєкту
Стовпці CSV: id,name,hours,depends,skill. Залежності — ID завдань, розділені |. Порожнє depends означає відсутність попередника. Трудомісткість завдання призначається одному кваліфікованому ресурсу.
resources — Ресурси проєкту
Стовпці CSV: id,name,skills,hours_per_day. Навички розділяються |. Денна спроможність — доступний для планування час, до 12 годин. Календарі використовують понеділок–п’ятницю; свята й відпустки не моделюються.
start_date — Дата початку проєкту
Перший робочий день — ця дата або наступний понеділок, якщо вона припадає на вихідні. Інтервали робочих днів починаються о 00:00 UTC й описують розподіл спроможності, а не фактичний робочий час.
notes — Примітки й побажання щодо планування
Необов’язковий контекст для пропозиції ШІ. Доступність, кваліфікації, залежності й числові обмеження також потрібно ввести в структуровані таблиці; примітки ніколи не скасовують ці перевірки.
csv_separator — Роздільник CSV
Вибрати крапку з комою, кому або табуляцію лише для експортованого CSV. Завантажені вихідні CSV й надалі потребують задокументованих заголовків, розділених комами.
csv_bom — Маркер UTF-8 у CSV
Додати маркер порядку байтів UTF-8 для сумісності з електронними таблицями або пропустити його для систем, що потребують звичайного UTF-8.
csv_line_ending — Закінчення рядків CSV
Використовувати LF або CRLF для експортованих записів CSV. Це не змінює вихідного тексту чи переносів рядків усередині комірок у лапках.
include_json — Додати експорт JSON
Запропонувати додатковий структурований звіт JSON із повними перевіреними рядками, висновками й підсумком. Експорт не виконує жодної дії.
max_task_hours — Поріг перевірки трудомісткості завдань
0 вимикає цю додаткову перевірку. Інакше позначати завдання з трудомісткістю понад вибраний поріг, до 10 000 годин. Залежності, місткість ресурсів і розрахований графік не змінюються.
row_order — Порядок рядків перевірки
Перевпорядкувати повні рядки таблиці без видалення висновків, зміни розрахунків чи призначень. Порожні значення сортування йдуть останніми; однакові значення зберігають початковий відносний порядок.
Максимальна кількість байтів UTF-8 в оболонці text: 120000
Перевірка результату й джерел
Тип результату — ops_review. columns містить key і label_key; rows містить відповідні скалярні значення комірок. findings містить локалізовні значення code й посилання на джерела refs; summary містить label_key і value. review_required та ai_required мають значення true. ai_model визначає прийняту модель, якщо її надає виконавець. Деякі інструменти також повертають source_sha256 або note_key. Рядки джерел залишаються недовіреними даними й мають відображатися як текст, ніколи як виконуваний HTML або інструкції.
Приклад запиту
{
"tool": "project_plan",
"text": "{\"tasks\":\"id,name,hours,depends,skill\\nT1,Briefing,4,,planning\\nT2,Design,10,T1,design\\nT3,Review,3,T2,planning\",\"resources\":\"id,name,skills,hours_per_day\\nR1,Alex,planning,4\\nR2,Sam,design,5\",\"start_date\":\"2026-11-09\",\"notes\":\"The design depends on the completed briefing. Preserve time for the final review.\",\"csv_separator\":\"semicolon\",\"csv_bom\":true,\"csv_line_ending\":\"lf\",\"include_json\":false,\"max_task_hours\":0,\"row_order\":\"source\"}"
}
Перетворення рядків товарів на придатні до друку етикетки з перевіреними штрихкодами й QR-кодами.
Декодовані вхідні поля
csv — Рядки товарів (CSV)
Обов’язкові стовпці: id, name, code, qr. До 24 рядків. Вміст QR надходить лише з наданого стовпця qr.
format — Формат штрихкоду
EAN-13 потребує 13 цифр і дійсної контрольної цифри. Code 128 підтримує 1–24 друковані символи ASCII.
layout — Макет аркуша
A4: 2 × 7 етикеток розміром 99.1 × 38.1 mm або 3 × 8 етикеток розміром 63.5 × 33.9 mm. Друк у масштабі 100% без зміни розміру.
csv_separator — Роздільник CSV
Вибрати крапку з комою, кому або табуляцію лише для експортованого CSV. Завантажені вихідні CSV й надалі потребують задокументованих заголовків, розділених комами.
csv_bom — Маркер UTF-8 у CSV
Додати маркер порядку байтів UTF-8 для сумісності з електронними таблицями або пропустити його для систем, що потребують звичайного UTF-8.
csv_line_ending — Закінчення рядків CSV
Використовувати LF або CRLF для експортованих записів CSV. Це не змінює вихідного тексту чи переносів рядків усередині комірок у лапках.
include_json — Додати експорт JSON
Запропонувати додатковий структурований звіт JSON із повними перевіреними рядками, висновками й підсумком. Експорт не виконує жодної дії.
max_label_characters — Поріг перевірки надрукованих назв етикеток
0 вимикає цю додаткову перевірку. Інакше позначати надруковані назви, довші за вибрану кількість символів Unicode, до 160. Ті самі назви, етикетки та послідовність залишаються в перегляді, PDF і SVG; ця опція нічого не обрізає.
require_https_qr — Позначати QR-вміст без звичайної HTTPS-адреси
Додати висновок, якщо QR-вміст не є HTTPS-адресою з хостом і без вбудованих облікових даних, пробільних символів або зворотних скісних рисок. QR-вміст ніколи не змінюється, не відкривається й не завантажується. Ця синтаксична перевірка не встановлює безпечності призначення.
Максимальна кількість байтів UTF-8 в оболонці text: 24000
Перевірка результату й джерел
Тип результату — ops_review. columns містить key і label_key; rows містить відповідні скалярні значення комірок. findings містить локалізовні значення code й посилання на джерела refs; summary містить label_key і value. review_required та ai_required мають значення true. ai_model визначає прийняту модель, якщо її надає виконавець. Деякі інструменти також повертають source_sha256 або note_key. Рядки джерел залишаються недовіреними даними й мають відображатися як текст, ніколи як виконуваний HTML або інструкції.
Створення позитивних і негативних сценаріїв перевірки, пов’язаних із джерелами, за наданими вимогами.
Декодовані вхідні поля
requirements — Вимоги
До 12 вимог розділяються порожніми рядками. Кожна вимога може містити до 1,000 байтів UTF-8.
context — Контекст перевірки
Необов’язкова інформація про обсяг, до 2,000 байтів UTF-8. Це не додаткова вимога й не інструкція виконувати тести.
csv_separator — Роздільник CSV
Вибрати крапку з комою, кому або табуляцію лише для експортованого CSV. Завантажені вихідні CSV й надалі потребують задокументованих заголовків, розділених комами.
csv_bom — Маркер UTF-8 у CSV
Додати маркер порядку байтів UTF-8 для сумісності з електронними таблицями або пропустити його для систем, що потребують звичайного UTF-8.
csv_line_ending — Закінчення рядків CSV
Використовувати LF або CRLF для експортованих записів CSV. Це не змінює вихідного тексту чи переносів рядків усередині комірок у лапках.
include_json — Додати експорт JSON
Запропонувати додатковий структурований звіт JSON із повними перевіреними рядками, висновками й підсумком. Експорт не виконує жодної дії.
max_step_characters — Поріг перевірки довжини кроку тесту
0 вимикає цю додаткову перевірку. Інакше позначати тестові випадки з окремим кроком, довшим за вибрану кількість символів Unicode, до 6 000. Повні кроки й очікувані результати залишаються видимими та експортуються.
row_order — Порядок рядків перевірки
Перевпорядкувати повні рядки таблиці без видалення висновків, зміни розрахунків чи призначень. Порожні значення сортування йдуть останніми; однакові значення зберігають початковий відносний порядок.
Максимальна кількість байтів UTF-8 в оболонці text: 24000
Перевірка результату й джерел
Тип результату — ops_review. columns містить key і label_key; rows містить відповідні скалярні значення комірок. findings містить локалізовні значення code й посилання на джерела refs; summary містить label_key і value. review_required та ai_required мають значення true. ai_model визначає прийняту модель, якщо її надає виконавець. Деякі інструменти також повертають source_sha256 або note_key. Рядки джерел залишаються недовіреними даними й мають відображатися як текст, ніколи як виконуваний HTML або інструкції.
Приклад запиту
{
"tool": "test_cases",
"text": "{\"requirements\":\"Контактна форма вимагає адресу електронної пошти.\\n\\nКількість у замовленні має бути від 1 до 10.\",\"context\":\"Review of the customer ordering form.\",\"csv_separator\":\"semicolon\",\"csv_bom\":true,\"csv_line_ending\":\"lf\",\"include_json\":false,\"max_step_characters\":0,\"row_order\":\"source\"}"
}
Колекція exports може містити CSV-файли та, для підтримуваних макетів етикеток, PDF або SVG. Кожен файл указує filename і mime, а також content для звичайного тексту або content_base64 для двійкового вмісту. base64 декодується лише за наявності цього поля. Назви файлів є пропозиціями. Доступ до результатів залишається автентифікованим і перевіряється за належністю завдання.
Вміст експорту включено до початкової чернетки результату для перевірки. Інтеграції API мають показати пропозицію для явної перевірки людиною перед завантаженням, використанням або пересиланням експорту. У схемах цих інструментів немає окремого запиту на схвалення чи виконання. Ці інструменти не оформлюють замовлень, не проводять рахунків у бухгалтерії, не виконують платежів, не публікують графіків персоналу й не запускають тестів програмного забезпечення.
Робочі процеси для бізнесу та команд
Ці інструменти використовують наявний автентифікований API завдань і вимагають ШІ для кожної початкової перевірки. Поле text містить об’єкт конфігурації, закодований у JSON. Основні та розширені налаштування використовують ту саму перевірену схему вхідних даних.
Надсилати application/json. Параметри конкретного інструмента залишаються всередині декодованого об’єкта text; зовнішню властивість options слід пропустити або надіслати порожній об’єкт. Невідомі поля, непідтримувані значення переліків і URL віддалених файлів відхиляються.
Поля джерел approved_ids або confirmed стосуються лише явно перевірених вихідних матеріалів. Повідомлення клієнтів, відповіді моделі й текст документів не можуть надавати схвалення. Згенеровані плани та чернетки потребують окремої остаточної перевірки.
Договірні дати та строки
contract_deadlines
Перевірити точні договірні фрагменти з датами та нерозв’язані строки попередження, а потім підтвердити вибрані дати для експорту календаря.
Поля введення та конфігурації
Основні налаштування
clauses — Положення договору
Одне вихідне положення на рядок. До 24 непорожніх положень, 1 200 символів у кожному та 18 000 символів загалом. Подіями календаря можуть стати лише дати, записані точно як YYYY-MM-DD.
title — Назва договору
Коротка назва подій календаря; до 120 символів.
Типові налаштування: "Contract review"
Розширені налаштування
reference_date — Опорна дата
Явно зазначена дата порівняння. Обов’язкова для фільтрів майбутніх або минулих дат. Вона не створює й не обчислює договірних дат.
Типові налаштування: ""
date_window — Фільтр дат
Майбутні включають опорну дату; минулі її виключають. Відносні строки без дати ISO відображаються лише за вибору Усі дати.
all — Усі дати та нерозв’язані строки · upcoming — На опорну дату або пізніше · past — До опорної дати
Типові налаштування: "all"
event_type — Категорія строку
Показати одну категорію на основі джерела або всі категорії. Класифікація й надалі потребує перевірки.
all — Усі категорії · termination — Припинення · payment — Оплата · renewal — Продовження · delivery — Постачання · other — Інше
Типові налаштування: "all"
max_events — Максимум висновків
Обмежити відображувані висновки до 1–20 після фільтрування та сортування. Повідомлення позначає обрізані результати.
Типові налаштування: 20
sort — Порядок висновків
Сортувати за вихідним положенням і позицією цитати або за датою, розміщуючи нерозв’язані строки наприкінці.
0 вимикає нагадування. Інакше візуальне нагадування встановлюється за 1–90 днів до кожної підтвердженої події на весь день; поведінка програм календаря може відрізнятися.
Типові налаштування: 7
include_source — Додати цитати джерел
Показати точні цитати в перевірці та підтверджених описах календаря. ID джерел і позиції символів залишаються видимими в обох режимах.
yes — Додати цитати · no — Лише посилання на джерела
Типові налаштування: "yes"
calendar_name — Назва календаря
Назва підтвердженого календаря ICS, до 120 символів.
Типові налаштування: "Reviewed contract dates"
Максимальна кількість вхідних байтів UTF-8: 24000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "contract_deadlines",
"text": "{\"clauses\":\"Рахунок підлягає оплаті 2027-03-15.\\nПовідомлення має надійти щонайменше за 30 днів до продовження.\\nДата постачання — 2027-04-02.\",\"title\":\"Договір про послуги\",\"reference_date\":\"2027-01-01\",\"date_window\":\"upcoming\",\"event_type\":\"all\",\"max_events\":20,\"sort\":\"date\",\"reminder_days\":7,\"include_source\":\"yes\",\"calendar_name\":\"Перевірені дати договору\"}"
}
Упорядкувати надані позиції праці, послуг і матеріалів у чернетку з детермінованими розрахунками націнки, маржі, знижки та податку.
Поля введення та конфігурації
Основні налаштування
items — Позиції комерційної пропозиції
Заголовки CSV: label,kind,quantity,unit,cost. kind — labor, material або service. quantity використовує десяткову крапку та до трьох десяткових знаків; cost — чиста собівартість одиниці з максимум двома десятковими знаками. До 30 рядків. Кількість праці може означати години.
currency — Валюта
Одна валюта для всіх позицій; без валютної конвертації. Усі суми мають два десяткові знаки.
Націнка додає відсоток до собівартості. Цільова маржа ділить собівартість на одиницю мінус частку відсотка; це маржа до знижки, а не націнка.
markup — Націнка на собівартість · margin — Цільова маржа до знижки
Типові налаштування: "markup"
pricing_percent — Відсоток ціноутворення
0–500 для націнки або 0–95 для цільової маржі; максимум два десяткові знаки.
Типові налаштування: 20
discount_percent — Відсоток знижки
Явна знижка 0–100%, що застосовується до кожної обчисленої ціни продажу до податку. Максимум два десяткові знаки.
Типові налаштування: 0
tax_percent — Відсоток податку
Явний податок 0–100%, що застосовується після знижки. Нуль означає відсутність доданого податку. Цей інструмент не визначає застосовну ставку податку чи податковий режим.
Типові налаштування: 0
rounding — Округлення на кожному етапі розрахунку
Округлити собівартість позиції, ціну продажу, чисту суму після знижки та податок до двох валютних десяткових знаків за вибраним правилом. Підсумки додають округлені позиції.
nearest — До найближчої сотої; половини вгору · up — Завжди округлювати вгору · down — Завжди округлювати вниз
Типові налаштування: "nearest"
item_scope — Включені типи позицій
Включити всі вихідні позиції або лише працю, матеріали чи послуги. Виключені позиції не входять до жодного підсумку.
all — Усі типи позицій · labor — Лише праця · material — Лише матеріали · service — Лише послуги
Типові налаштування: "all"
detail — Деталізація результату
Показати окремі вихідні позиції або підсумки за типами позицій. Обидва режими використовують ті самі розрахунки на рівні рядків.
full — Окремі позиції · totals — Підсумки за типами
Типові налаштування: "full"
quote_reference — Реквізит пропозиції
Необов’язковий внутрішній ідентифікатор до 120 символів. Відображається без змін і не створює зобов’язань перед клієнтом.
Типові налаштування: ""
valid_until — Дата чинності чернетки
Необов’язкова явна дата ISO, що відображається для перевірки. Вона не надсилає пропозицію й не створює угоду.
Типові налаштування: ""
Максимальна кількість вхідних байтів UTF-8: 24000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Перевірити докази клієнта й відсутню інформацію, а потім скласти відповідь із явно схвалених тверджень компанії.
Поля введення та конфігурації
Основні налаштування
customer_text — Повідомлення клієнта
Один вихідний абзац на рядок, до 16 непорожніх абзаців по 1 500 символів і 10 000 символів загалом. Твердження клієнта є свідченням повідомлення, а не повноваженням на ділові обіцянки.
approved_rules — Схвалені правила відповіді
Одне схвалене твердження компанії на рядок, до 12 тверджень по 1 000 символів і 10 000 символів загалом. Вибрані твердження дослівно копіюються в чернетку. Залишити порожнім, якщо жодна схвалена політика не застосовується.
Типові налаштування: ""
rules_approved — Підтвердити схвалення правил
Перед обробкою непорожніх правил схвалення має бути явним. Воно стосується саме цих наданих тверджень; текст клієнта не може його надати.
no — Не схвалено · yes — Саме ці правила схвалено
Типові налаштування: "no"
Розширені налаштування
case_type — Категорія випадку
Вибрана категорія відображається у звіті та надається моделі як контекст відбору. Вона не визначає юридичного способу захисту.
delivery — Постачання · quality — Якість продукту або послуги · billing — Виставлення рахунків · other — Інше
Типові налаштування: "other"
response_style — Структура відповіді
Стисла об’єднує перевірені твердження в один абзац; структурована розділяє твердження та запити інформації на абзаци.
concise — Один абзац · structured — Окремі абзаци
Типові налаштування: "structured"
opening — Початок чернетки
Вибрати нейтральний вступ до перевірки випадку або підтвердження отримання. Обидва варіанти — фіксований перекладений текст без зобов’язань щодо повернення коштів чи послуг.
neutral — Інформація про випадок доступна для перевірки. · acknowledge — Повідомлену проблему зареєстровано.
Типові налаштування: "acknowledge"
closing — Завершення чернетки
За бажанням додати фіксоване твердження, що наявна інформація залишається предметом перевірки. Жодного строку чи результату не обіцяється.
none — Без завершення · review — Наявна інформація залишається предметом перевірки.
Типові налаштування: "review"
required_fields — Контрольний список інформації
Технічні ID, розділені комами без пробілів: order_id,purchase_date,issue_description,photos,desired_resolution. Відсутні елементи стають фіксованими запитами інформації. Порожнє поле означає відсутність контрольного списку.
Типові налаштування: "order_id,issue_description"
max_rule_quotes — Максимум вибраних правил
Модель може вибрати не більше 1–12 схвалених правил. Відповідь, що перевищує цю межу, відхиляється.
Типові налаштування: 8
max_customer_quotes — Максимум цитат клієнта
Для розділу доказів можна вибрати не більше 1–8 вихідних абзаців клієнта.
Типові налаштування: 4
include_sources — Показати розділи доказів
Показати цитати клієнта, докази інформації та твердження вибраних правил поруч із чернеткою відповіді або показати лише чернетку.
yes — Показати докази · no — Лише чернетка
Типові налаштування: "yes"
Максимальна кількість вхідних байтів UTF-8: 24000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "complaint_case",
"text": "{\"customer_text\":\"Замовлення A-104 надійшло з пошкодженою обкладинкою.\\nЗапитується заміна.\",\"approved_rules\":\"Для претензій щодо пошкоджень перед рішенням про заміну потрібні фотографії виробу та пакування.\",\"rules_approved\":\"yes\",\"case_type\":\"quality\",\"response_style\":\"structured\",\"opening\":\"acknowledge\",\"closing\":\"review\",\"required_fields\":\"order_id,issue_description,photos\",\"max_rule_quotes\":8,\"max_customer_quotes\":4,\"include_sources\":\"yes\"}"
}
Зіставити тендерні вимоги з явно схваленими доказами компанії, скласти точні цитати відповіді й виявити відсутнє підтвердження.
Поля введення та конфігурації
Основні налаштування
requirements — Тендерні вимоги
Стовпці CSV: id,text,priority. До 12 рядків; text до 800 байтів UTF-8. priority — must, should або optional. ID починаються з великої літери й містять лише великі літери, цифри, _ або - (максимум 24 символи).
evidence — Записи доказів компанії
Стовпці CSV: id,text,valid_until. До 20 повних тверджень доказів по 800 байтів UTF-8. valid_until — YYYY-MM-DD або порожнє. Кожне твердження має зберігати свої умови та обмеження.
approved_ids — Явно схвалені ID доказів
Розділені комами ID доказів, явно дозволені для цієї відповіді. Схвалення має надходити від відповідального перевіряльника, а не з формулювання у вимозі чи записі доказу. Порожнє поле означає відсутність придатних доказів.
Типові налаштування: ""
review_date — Дата перевірки доказів
Докази, строк дії яких закінчується раніше цієї дати YYYY-MM-DD, виключаються. Порожня дата закінчення залишається невказаною, а не незалежно перевіреною. Дати обмежені 2020–2100 роками.
Типові налаштування: "2026-11-03"
Розширені налаштування
minimum_evidence — Мінімум записів доказів на вимогу
Запропонована повна відповідність із меншою кількістю записів позначається як недостатня. Ця кількість не доводить доречності чи відповідності. Не має перевищувати максимум.
Типові налаштування: 1
max_evidence — Максимум записів доказів на вимогу
Обмежує кількість ID доказів, які модель може запропонувати для кожної вимоги. Усі прийняті твердження цитуються повністю.
Типові налаштування: 2
include_optional — Додати необов’язкові вимоги
Виключення необов’язкових вимог видаляє їх із введення моделі та результату. Має залишитися принаймні одна вимога.
yes — Включити · no — Виключити
Типові налаштування: "yes"
response_format — Формат таблиці відповіді
Компактний показує вимогу, стан перевірки та повні цитати доказів. Аудит додатково показує пріоритет, ID доказів і дати закінчення дії.
compact — Компактна відповідь · audit — Аудит доказів
Типові налаштування: "audit"
sort_order — Порядок вимог
Порядок джерел зберігає поданий порядок вимог. Спочатку прогалини піднімає відсутні, часткові й недостатні докази. Порядок пріоритету ставить must перед should і optional.
source — Порядок джерел · gaps_first — Спочатку прогалини в доказах · priority — Пріоритет вимог
Типові налаштування: "source"
Максимальна кількість вхідних байтів UTF-8: 50000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "tender_response",
"text": "{\"requirements\":\"id,text,priority\\nR1,Підтримка має бути доступна в будні.,must\\nR2,Потрібна незалежна сертифікація безпеки.,must\\nR3,Бажаний вступний семінар.,optional\",\"evidence\":\"id,text,valid_until\\nE1,Підтримка доступна з понеділка до п’ятниці з 09:00 до 17:00 UTC.,2027-12-31\\nE2,Вступний семінар включено до стандартної послуги.,2027-12-31\\nE3,Попередній план послуг включав підтримку у вихідні.,2025-12-31\",\"approved_ids\":\"E1,E2,E3\",\"review_date\":\"2026-11-03\",\"minimum_evidence\":1,\"max_evidence\":2,\"include_optional\":\"yes\",\"response_format\":\"audit\",\"sort_order\":\"gaps_first\"}"
}
Порівняти пов’язані з джерелами значення продукту в технічних описах, посібниках, пакуванні й тексті продукту з явними правилами одиниць і допусками.
Поля введення та конфігурації
Основні налаштування
documents — Документи продукту
Стовпці CSV: id,kind,text. Надати 2–4 документи, кожен до 2 400 байтів UTF-8. kind — datasheet, manual, packaging або product. ID відповідають правилам ID джерел із великими літерами. Для ком і переносів рядків усередині тексту необхідне взяття в лапки CSV.
features — Характеристики для порівняння
Стовпці CSV: id,label,type,unit. До 6 характеристик. label (до 80 байтів UTF-8) має буквально траплятися в кожній витягнутій цитаті без урахування регістру. type — number або text. Текстові характеристики потребують порожнього unit; числова одиниця є одиницею порівняння. Підтримувані докази використовують явні твердження атрибутів, як-от Weight: 2 kg або Colour=Blue; довільні твердження без цієї структури залишаються відсутніми. Текстові уточнення необхідно зберігати; числові твердження з уточненнями не трактуються як прості числа.
reference_id — ID опорного документа
ID наявного документа, який використовується як основа кожного порівняння. Відсутні або неоднозначні опорні значення залишають відповідне порівняння нерозв’язаним.
Типові налаштування: "D1"
Розширені налаштування
unit_policy — Порівняння одиниць
Точне вимагає незмінної одиниці характеристики. Метричне дозволяє лише перетворення mg/g/kg, mm/cm/m, ml/L, W/kW та mV/V в межах однієї групи. Одиниці чутливі до регістру; усі інші невідповідності залишаються конфліктами.
exact — Лише точні одиниці · metric — Дозволити перелічені метричні перетворення
Типові налаштування: "exact"
absolute_tolerance — Абсолютний числовий допуск
Максимальна абсолютна різниця в одиниці порівняння характеристики. Застосовується лише до сумісних числових значень; 0 вимагає рівності, якщо відносний допуск не дозволяє різницю.
Типові налаштування: 0
relative_tolerance_pct — Відносний допуск (%)
Дозволена різниця — більше з абсолютного допуску та abs(опорне значення) × відсоток / 100. Нульова опорна величина дає нульовий відносний допуск.
Типові налаштування: 0
case_sensitive — Порівняння регістру тексту
Керує чутливістю до регістру лише текстових значень. Ніколи не змінює регістр одиниць або цитати джерел.
no — Ігнорувати регістр · yes — З урахуванням регістру
Типові налаштування: "no"
whitespace_policy — Порівняння пробільних символів
Точне порівнює текстові значення без змін після витягування. Нормалізувати видаляє крайні пробіли й трактує послідовні пробільні символи як один пробіл. Цитати джерел залишаються незмінними.
exact — Зберегти пробіли · collapse — Нормалізувати пробіли
Типові налаштування: "collapse"
missing_policy — Обробка відсутніх значень
Відсутні або неоднозначні значення залишаються видимими як відкрита прогалина в доказах або блокувальний конфлікт. Значення заміни ніколи не вигадується.
warn — Позначити прогалину в доказах · conflict — Вважати конфліктом
Типові налаштування: "warn"
result_filter — Відображувані рядки
Усі показує кожне порівняння з опорою. Проблеми показує лише різниці, конфлікти одиниць і відсутні значення; підсумки й далі рахують усі порівняння.
all — Усі порівняння · issues — Лише проблеми
Типові налаштування: "all"
sort_order — Порядок результатів
Порядок характеристик відповідає таблиці характеристик. Порядок документів групує за ID документа. Спочатку проблеми підіймає невідповідні порівняння нагору.
feature — Порядок характеристик · document — Порядок документів · issues_first — Спочатку проблеми
Типові налаштування: "feature"
decimal_separator — Десятковий роздільник джерела
Числові значення мають послідовно використовувати вибраний роздільник, до шести десяткових знаків і без роздільників тисяч. Модуль обмежено 100 000 000. Модель має копіювати числа точно.
dot — Десяткова крапка · comma — Десяткова кома
Типові налаштування: "dot"
Максимальна кількість вхідних байтів UTF-8: 50000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "product_consistency",
"text": "{\"documents\":\"id,kind,text\\nD1,datasheet,Вага: 2 kg. Колір: Синій.\\nD2,packaging,Вага: 2000 g. Колір: синій.\\nD3,manual,Вага: 2.2 kg. Колір: Червоний.\",\"features\":\"id,label,type,unit\\nF1,Вага,number,kg\\nF2,Колір,text,\",\"reference_id\":\"D1\",\"unit_policy\":\"metric\",\"absolute_tolerance\":0.05,\"relative_tolerance_pct\":1,\"case_sensitive\":\"no\",\"whitespace_policy\":\"collapse\",\"missing_policy\":\"warn\",\"result_filter\":\"all\",\"sort_order\":\"issues_first\",\"decimal_separator\":\"dot\"}"
}
Перетворити підтверджені внутрішні матеріали на придатний до перевірки графік адаптації з датами, обов’язками, навчальними цілями та обмеженим денним навантаженням.
Поля введення та конфігурації
Основні налаштування
role — Роль
Професійна роль для плану адаптації; максимум 200 байтів UTF-8.
Типові налаштування: ""
start_date — Дата початку
Перший календарний день горизонту планування. Дати обчислюються в UTC; державні свята й відсутності не виводяться.
Типові налаштування: "2026-11-09"
documents — Підтверджені внутрішні вихідні документи
CSV з точними заголовками id,text; 1–12 унікальних ID джерел і вихідні тексти обсягом до 1 000 байтів UTF-8 кожен. Надати наявні завдання та описи процесів, а не інструкції для ШІ. Без URL або розмітки.
Типові налаштування: ""
confirmed — Джерела підтверджено для планування
Явне підтвердження придатності наданих внутрішніх матеріалів для цієї чернетки плану. Воно не надає доступу й не схвалює жодної реальної дії.
Типові налаштування: false
Розширені налаштування
horizon — Горизонт планування
Календарний горизонт від дати початку. Для розкладу доступні лише вибрані робочі дні.
7_days — 7 днів · 14_days — 14 днів · 30_days — 30 днів · 4_weeks — 4 тижні · 8_weeks — 8 тижнів
Типові налаштування: "14_days"
workdays — Робочі дні
Обмежити доступні дати вибраним набором днів тижня. Місцеві свята й відпустки не виключаються автоматично.
mon_fri — Понеділок–п’ятниця · mon_sat — Понеділок–субота · all_days — Усі дні
Типові налаштування: "mon_fri"
work_mode — Режим роботи
Спрямувати відбір завдань на основі джерел і показати вибраний режим для кожного завдання. Жодна зустріч, обліковий запис або право доступу не створюються.
onsite — На місці · remote — Дистанційно · hybrid — Гібридно
Типові налаштування: "hybrid"
owners — Відповідальні ролі
Одна роль на абзац, розділений порожнім рядком; 1–8 ролей, до 160 байтів UTF-8 кожна. ШІ може призначати лише ці ролі.
Типові налаштування: ""
learning_goals — Навчальні цілі
Одна ціль на абзац, розділений порожнім рядком; 1–8 цілей, до 600 байтів UTF-8 кожна. Кожне запропоноване завдання зіставляється з однією наданою ціллю.
Типові налаштування: ""
task_count — Кількість завдань
Запитується саме така кількість різних завдань, підтверджених джерелами. Документи мають містити достатньо придатних фрагментів завдань.
Типові налаштування: 4
minutes_per_day — Денний бюджет часу на адаптацію
Максимальна сума запланованих хвилин завдань на кожен робочий день. Кожне завдання потребує щонайменше 5 хвилин.
Типові налаштування: 120
follow_up — Режим подальшої перевірки
Не додавати контрольної точки, вибрати наступний доступний робочий день або останній робочий день горизонту. Контрольна точка на межі горизонту залишається на останній доступній даті.
none — Немає · next_workday — Наступний робочий день · final_day — Останній робочий день
Типові налаштування: "next_workday"
Максимальна кількість вхідних байтів UTF-8: 24000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "onboarding_plan",
"text": "{\"role\":\"Спеціаліст підтримки клієнтів\",\"start_date\":\"2026-11-09\",\"documents\":\"id,text\\nS1,Прочитати посібник підтримки й переглянути процес ескалації.\\nS2,Попрактикуватися в написанні відповідей у навчальному середовищі та розглянути приклади випадків.\",\"confirmed\":true,\"horizon\":\"14_days\",\"workdays\":\"mon_fri\",\"work_mode\":\"hybrid\",\"owners\":\"Керівник команди\\n\\nКоординатор навчання\",\"learning_goals\":\"Зрозуміти процес ескалації.\\n\\nПідготувати зрозумілі відповіді підтримки.\",\"task_count\":4,\"minutes_per_day\":120,\"follow_up\":\"next_workday\"}"
}
Створити узгоджені професійні запитання, розподіл часу й орієнтири доказів з опису ролі та професійних вимог без оцінювання кандидатів у балах.
Поля введення та конфігурації
Основні налаштування
role_description — Опис ролі
Лише професійна роль і обов’язки, до 3 000 байтів UTF-8. Не включати профілі кандидатів, персональні дані або захищені характеристики.
Типові налаштування: ""
requirements — Професійні вимоги
Одна пов’язана з роботою вимога на абзац, розділений порожнім рядком; 1–12 вимог, до 1 000 байтів UTF-8 кожна. Без URL, розмітки або приватної інформації кандидатів.
Типові налаштування: ""
duration — Тривалість співбесіди у хвилинах
Загальна тривалість сесії, включно з резервним часом. Після резерву має залишатися щонайменше 2 хвилини на запитання.
Типові налаштування: 45
Розширені налаштування
level — Рівень досвіду
Налаштувати глибину стандартизованих запитань: основи, практична наскрізна робота або складні компроміси. Це опис ролі, а не оцінка людини.
entry — Початковий рівень · experienced — Досвідчений · senior — Старший спеціаліст
Типові налаштування: "experienced"
interview_type — Формат співбесіди
Додати до кожного запитання узгоджений структурований, технічний або запропонований ситуаційний контекст.
structured — Структурована співбесіда · technical — Технічна співбесіда · case_study — Дослідження випадку
Типові налаштування: "structured"
focus — Професійний фокус
Зосередитися на спостережуваних компетенціях, розв’язанні проблем або комунікації про роботу.
competencies — Професійні компетенції · problem_solving — Розв’язання проблем · communication — Професійна комунікація
Типові налаштування: "competencies"
question_types — Стратегії запитань
Використати одну стратегію або поєднання щонайменше двох. Запитання будуються з точних фрагментів професійних вимог.
mixed — Змішані стратегії · knowledge — Знання · scenario — Запропонований сценарій · experience — Професійний досвід
Типові налаштування: "mixed"
question_count — Кількість запитань
Запитується саме така кількість різних поєднань вимоги й стратегії. Має залишатися щонайменше 2 хвилини на запитання.
Типові налаштування: 6
rubric — Орієнтири оцінювання
Не включати шкали, включити три або п’ять рівнів доказів. Інструмент надає лише орієнтири й ніколи не призначає балів кандидату.
none — Немає · three_level — Три рівні доказів · five_level — П’ять рівнів доказів
Типові налаштування: "three_level"
followups — Уточнювальне запитання
За бажанням включити одне стандартизоване запитання про докази, альтернативи й перевірку. Час його обговорення входить до часу кожного запитання.
none — Немає · one — Одне уточнювальне запитання
Типові налаштування: "one"
time_buffer — Резервний час сесії
Хвилини для вступу, переходів і завершення; віднімаються перед рівномірним розподілом часу запитань.
Типові налаштування: 5
Максимальна кількість вхідних байтів UTF-8: 24000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "interview_guide",
"text": "{\"role_description\":\"Інженер підтримки програмного забезпечення відповідальний за діагностику проблем продукту й документування відтворюваних випадків.\",\"requirements\":\"Пояснити відтворюваний процес налагодження.\\n\\nЧітко повідомляти технічні висновки команді реалізації.\",\"duration\":45,\"level\":\"experienced\",\"interview_type\":\"structured\",\"focus\":\"problem_solving\",\"question_types\":\"mixed\",\"question_count\":4,\"rubric\":\"three_level\",\"followups\":\"one\",\"time_buffer\":5}"
}
Підготувати стислий документ передавання з ідентифікованих джерел проєкту з явними статусами, відповідальними, фільтрами й видимими невідомими фактами.
Поля введення та конфігурації
Основні налаштування
project — Назва проєкту
Назва проєкту або робочого напряму, до 200 байтів UTF-8.
Типові налаштування: ""
sources — Знімок джерел проєкту
CSV з точними заголовками id,category,status,role,text. Використати 1–12 рядків, унікальні ID та вихідні тексти до 1 000 байтів UTF-8. Категорії: risk, decision, open, deliverable. Статуси: open, in_progress, done, unknown. Використовувати назву ролі замість приватних персональних даних. Без URL або розмітки.
Типові налаштування: ""
cutoff_date — Опорна дата знімка
Дата, призначена наданому знімку. Це опорна дата, задана користувачем, а не незалежно перевірена часова позначка джерела.
Типові налаштування: "2026-11-09"
Розширені налаштування
audience — Аудиторія передавання
Спрямувати відбір підтверджених джерелами пунктів, коли відповідних джерел більше, ніж дозволяє ліміт елементів.
successor — Наступник · team — Команда реалізації · management — Керівництво
Типові налаштування: "successor"
category_filter — Фільтр категорії
Включити всі категорії або лише вибрану категорію джерела.
all — Усі · risk — Ризик · decision — Рішення · open — Відкрито · deliverable — Результат до здавання
Типові налаштування: "all"
status_filter — Фільтр статусу
Фільтрувати явно наданий статус. Статус ніколи не виводиться з перефразування моделі.
all — Усі · open — Відкрито · in_progress — У процесі · done — Завершено в джерелі · unknown — Невідомо
Типові налаштування: "all"
role_filter — Фільтр відповідальної ролі
Необов’язкова точна назва ролі з CSV; порожнє значення включає всі ролі. Фільтр чутливий до регістру.
Типові налаштування: ""
detail — Деталізація фрагментів
Максимальна довжина вихідного фрагмента на елемент: стислий 180, стандартний 400, докладний 800 байтів UTF-8. Початкове формулювання й мова зберігаються.
Вибрати не більше такої кількості відповідних джерел, по одному фрагменту на джерело. Менша кількість відповідних джерел дає менше елементів.
Типові налаштування: 8
include_unknowns — Включити невідомий статус
Зберегти або виключити джерела, явно позначені як unknown. Відсутні факти ніколи не заповнюються вигаданими відповідями.
yes — Включити · no — Виключити
Типові налаштування: "yes"
sort_order — Порядок відображення
Сортувати вибрані пункти передавання за початковим порядком джерел, перекладеною категорією або перекладеним статусом.
source — Порядок джерел · category — Категорія · status — Статус
Типові налаштування: "source"
Максимальна кількість вхідних байтів UTF-8: 24000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "project_handover",
"text": "{\"project\":\"Випуск клієнтського порталу\",\"sources\":\"id,category,status,role,text\\nS1,decision,done,Керівник реалізації,Обсяг випуску включає сторінку облікового запису та налаштування сповіщень.\\nS2,risk,open,Керівник якості,Перевірка регресії на мобільних пристроях ще очікує виконання.\\nS3,open,unknown,Операції,Вікно розгортання не підтверджено.\",\"cutoff_date\":\"2026-11-09\",\"audience\":\"successor\",\"category_filter\":\"all\",\"status_filter\":\"all\",\"role_filter\":\"\",\"detail\":\"standard\",\"max_items\":8,\"include_unknowns\":\"yes\",\"sort_order\":\"source\"}"
}
Порівняння базового прогнозу руху коштів, обґрунтованого джерелами, з явними сценаріями строків і сум, денними залишками та попередженнями щодо резервного буфера.
Поля введення та конфігурації
Основні налаштування
transactions — Рух коштів
Заголовки CSV: id,date,direction,amount,description,certainty. До 40 унікальних ідентифікаторів джерела. direction — in або out; certainty — confirmed або expected. Дати мають формат YYYY-MM-DD; додатні суми використовують десяткову крапку та щонайбільше два десяткові знаки, до 10000000.00. Описи обмежено 600 байтами UTF-8. Жодна URL-адреса не завантажується.
start_date — Дата початку прогнозу
Початковий залишок — це залишок безпосередньо перед цим днем. Попередні рухи коштів із джерела залишаються видимими, але не входять до базового прогнозу. Використовуються календарні дати UTC без коригування на вихідні чи свята.
opening_balance — Початковий залишок
Десяткова сума зі знаком від -10000000.00 до 10000000.00, щонайбільше з двома десятковими знаками. Потрібен явно зазначений відомий залишок; інструмент не підключається до банку.
Типові налаштування: "0.00"
currency — Валюта
Одна валюта для всіх вихідних рядків, залишків, резервів і лімітів. Усі суми мають два десяткові знаки; конвертація валют не виконується.
Охоплює 1–90 календарних днів від дати початку. Рухи за межами будь-якого з горизонтів залишаються видимими й отримують зауваження; вони не входять до залишку відповідного прогнозу.
Типові налаштування: 30
reserve_buffer — Резервний буфер
Невід’ємний десятковий поріг залишку до 10000000.00. Зауваження позначає залишки сценарію нижче цього рівня; це параметр планування, а не доступний овердрафт.
Типові налаштування: "0.00"
inflow_delay_days — Затримка надходжень у сценарії
Переносить надходження з датою початку прогнозу або пізнішою на 0–90 календарних днів уперед лише у сценарії. Попередні рухи коштів із джерела залишаються виключеними з обох прогнозів, оскільки початковий залишок уже визначає вихідну позицію. Відкладена позиція може вийти за горизонт; її базова дата залишається видимою.
Типові налаштування: 0
outflow_delay_days — Затримка виплат у сценарії
Переносить виплати з датою початку прогнозу або пізнішою на 0–90 календарних днів уперед лише у сценарії. Попередні рухи коштів із джерела залишаються виключеними з обох прогнозів. Це припущення, а не дозвіл відкласти платіж. Дати джерела залишаються видимими.
Типові налаштування: 0
inflow_percent — Відсоток надходжень у сценарії
Застосовує цілий відсоток від 0 до 200 до кожного надходження у сценарії. Суми округлюються до найближчої сотої грошової одиниці, половини — вгору; базові суми не змінюються.
Типові налаштування: 100
outflow_percent — Відсоток виплат у сценарії
Застосовує цілий відсоток від 0 до 200 до кожної виплати у сценарії. Суми округлюються до найближчої сотої грошової одиниці, половини — вгору; базові суми не змінюються.
Для надходжень із джерела з позначкою expected застосовує цей цілий відсоток 0–100 після загального відсотка надходжень, повторно округлюючи до сотих. Підтверджені надходження та всі виплати не залежать від цього другого коефіцієнта.
Типові налаштування: 100
chart_interval — Інтервал графіка
Щоденний вигляд показує кожен залишок на кінець дня. Щотижневий — кожен сьомий день і останній день. Мінімальні залишки та зауваження щодо буфера й далі обчислюються для кожного дня, зокрема пропущених на графіку.
daily — Щодня · weekly — Щотижня
Типові налаштування: "daily"
sort_order — Порядок рядків перевірки
Змінює лише порядок повних вихідних рядків. Грошові перевірки, дані джерела, прогнози та всі зауваження залишаються незмінними.
source — Порядок джерела · date — Порядок за датою · category — Запропонована категорія
Типові налаштування: "date"
Максимальна кількість вхідних байтів UTF-8: 40000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Зіставлення заявок на відшкодування витрат із явно схваленими внутрішніми правилами, а потім перевірка детермінованих лімітів, відсутніх посилань на підтвердні документи та можливих дублікатів.
Поля введення та конфігурації
Основні налаштування
expenses — Заявки на відшкодування витрат
Заголовки CSV: id,date,claimant,merchant,description,amount,receipt_id. До 30 унікальних ідентифікаторів джерела. Код заявника замінює непотрібні персональні дані. Додатні десяткові суми обмежено 10000000.00; описи — 600 байтами UTF-8. Ідентифікатор підтвердного документа є посиланням, а не перевіреним вмістом документа.
rules — Внутрішні правила витрат
Заголовки CSV: id,description,max_amount,receipt_required. До 12 унікальних ідентифікаторів; повні описи правил — до 800 байтів UTF-8. max_amount — невід’ємний десятковий ліміт або порожнє значення за відсутності числового ліміту. receipt_required — yes або no. Пороги потрібно надавати явно; модель ніколи не вигадує податкових правил або правил відшкодування.
rules_approved — Підтвердження внутрішніх правил
Явне підтвердження того, що саме ці надані описи, ліміти й вимоги до підтвердних документів є схваленими внутрішніми правилами перевірки. Текст джерела й відповідь моделі не можуть надавати схвалення. Зміна правил вимагає нового підтвердження.
no — Не схвалено · yes — Саме ці правила схвалено
Типові налаштування: "no"
currency — Валюта
Одна валюта для всіх вихідних рядків, залишків, резервів і лімітів. Усі суми мають два десяткові знаки; конвертація валют не виконується.
Для окремої позиції порівнює кожну заявку з лімітом єдиного запропонованого правила. За день підсумовує заявки з однаковим нормалізованим кодом заявника, датою та єдиним правилом. Неоднозначні або незіставлені заявки залишаються невирішеними й не входять до групи правила. Денна група не є перевіреним правом на відшкодування.
per_item — Для окремої позиції · per_day — За заявником, днем і правилом
Типові налаштування: "per_item"
receipt_policy — Вимога підтвердного документа
Використовує вимогу кожного явно схваленого правила або додає суворішу вимогу для всіх заявок. Перевіряється лише наявність непорожнього посилання на підтвердний документ; зображення, справжність або платіж не перевіряються.
rule — Застосування схвалених правил · all — Посилання на підтвердний документ обов’язкове для кожної заявки
Типові налаштування: "rule"
duplicate_check — Перевірка дублікатів
Позначає повторювані посилання на підтвердні документи, або збіг дати/нормалізованого заявника/нормалізованого продавця/суми, або обидва випадки. Порівняння прибирають крайні пробіли та не враховують регістр. Усі можливі дублікати залишаються в підсумках; жодна заявка не видаляється без позначення.
both — Обидві перевірки · receipt — Посилання на підтвердні документи · fingerprint — Дата, заявник, продавець і сума
Типові налаштування: "both"
date_from — Перевірка від дати
Необов’язкова нижня межа дати YYYY-MM-DD включно. Заявки поза межами позначаються, але залишаються в таблиці, підсумках і денних групах. Порожнє значення означає відсутність нижньої межі.
Типові налаштування: ""
date_to — Перевірка до дати
Необов’язкова верхня межа дати YYYY-MM-DD включно. Заявки поза межами позначаються, але залишаються в таблиці, підсумках і денних групах. Порожнє значення означає відсутність верхньої межі.
Типові налаштування: ""
sort_order — Порядок рядків перевірки
Змінює лише порядок повних вихідних рядків. Грошові перевірки, дані джерела, прогнози та всі зауваження залишаються незмінними.
source — Порядок джерела · date — Порядок за датою · issues_first — Спочатку зауваження
Типові налаштування: "source"
include_evidence — Показ стовпців доказів
Включає точну вибрану цитату витрати та повні тексти запропонованих правил або приховує ці два стовпці відображення. Ідентифікатори джерел і правил, зауваження та грошові перевірки залишаються видимими.
yes — Включення цитат · no — Лише посилання на джерела
Типові налаштування: "yes"
Максимальна кількість вхідних байтів UTF-8: 40000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "expense_policy_check",
"text": "{\"expenses\":\"id,date,claimant,merchant,description,amount,receipt_id\\nE1,2027-03-02,TEAM-A,Міський готель,Ночівля в готелі для візиту до клієнта,140.00,REC-101\\nE2,2027-03-02,TEAM-A,Залізнична компанія,Поїздка потягом для візиту до клієнта,35.00,\\nE3,2027-03-02,TEAM-A,Міський готель,Ночівля в готелі для візиту до клієнта,140.00,REC-101\",\"rules\":\"id,description,max_amount,receipt_required\\nR1,Готельне проживання у відрядженнях перевіряється за наданим лімітом.,120.00,yes\\nR2,Залізничні поїздки у відрядженнях вимагають посилання на підтвердний документ.,80.00,yes\",\"rules_approved\":\"yes\",\"currency\":\"EUR\",\"limit_scope\":\"per_item\",\"receipt_policy\":\"rule\",\"duplicate_check\":\"both\",\"date_from\":\"2027-03-01\",\"date_to\":\"2027-03-31\",\"sort_order\":\"issues_first\",\"include_evidence\":\"yes\"}"
}
Порівняння вихідних і цільових вибірок з явним зіставленням, нормалізацією та допусками, а потім перевірка пов’язаних із джерелами класифікацій ШІ для репрезентативних зауважень.
Поля введення та конфігурації
Основні налаштування
source_csv — Вихідний CSV
До 1000 рядків і 12 стовпців. CSV UTF-8 із роздільником-комою та назвами стовпців ASCII; кожна клітинка — щонайбільше 600 байтів.
target_csv — Цільовий CSV
Цільова вибірка з тими самими правилами CSV. Порожні набори даних можуть містити лише заголовок.
mapping_csv — Зіставлення стовпців
Заголовки CSV source,target,type. До десяти зіставлень; type — text, number або reference. Значення посилань мають визначати рядок у відповідній вибірці. Зіставлення ключів завжди використовує точні значення.
Розширені налаштування
source_key — Стовпець ключа джерела
Стовпець, наявний у вихідному CSV. Порожні або дубльовані ключі залишаються видимими як прогалини даних.
Типові налаштування: "id"
target_key — Стовпець цільового ключа
Стовпець, наявний у цільовому CSV. Ключі зіставляються точно, незалежно від нормалізації тексту.
Типові налаштування: "id"
whitespace — Порівняння пробільних символів
«Точно» зберігає пробільні символи; «Обрізати» видаляє крайні пробільні символи; «Стиснути» також замінює внутрішні послідовності пробільних символів одним пробілом.
exact — Точно · trim — Обрізати · collapse — Стиснути
Типові налаштування: "trim"
case_sensitive — Порівняння тексту з урахуванням регістру
«Ні» порівнює зіставлений текст після перетворення Unicode на нижній регістр. Ключі та пошук посилань залишаються точними.
yes — Так · no — Ні
Типові налаштування: "yes"
null_tokens — Маркери порожніх значень
Один маркер на рядок, щонайбільше вісім маркерів і 120 байтів. Маркери зіставляються після обробки пробільних символів і до нормалізації регістру.
Типові налаштування: "NULL"
empty_policy — Правило порожніх значень
«Рівнозначно» трактує налаштовані маркери відсутності значення як порожні рядки. «Точно» зберігає маркери як звичайні значення.
exact — Точно · equivalent — Рівнозначно
Типові налаштування: "equivalent"
absolute_tolerance — Абсолютний числовий допуск
Максимальна абсолютна різниця в наданій числовій одиниці. Лише значення з десятковою крапкою; без перетворення одиниць.
Допуск відносно абсолютного вихідного значення. Застосовується більший із абсолютного та відносного допусків; нульове вихідне значення використовує абсолютний допуск.
Типові налаштування: 0
extra_rows — Додаткові цільові записи
«Повідомити» повідомляє про додаткові цільові записи як зауваження. «Дозволити» вважає їхню наявність допустимою в налаштованій області.
issue — Повідомити · allow — Дозволити
Типові налаштування: "issue"
detail_filter — Вибір деталей
«Лише зауваження» приховує узгоджені рядки деталей. «Усі» включає узгоджені рядки. Підсумки та вибір кандидатів ШІ залишаються незалежними від цього фільтра відображення.
issues — Лише зауваження · all — Усі
Типові налаштування: "issues"
Максимальна кількість вхідних байтів UTF-8: 200000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
{
"type": "object",
"additionalProperties": false,
"required": [
"source_csv",
"target_csv",
"mapping_csv"
],
"properties": {
"source_csv": {
"type": "string",
"description": "Up to 1,000 rows and 12 columns. Comma-separated UTF-8 CSV with ASCII column names; each cell at most 600 bytes.",
"maxLength": 190000
},
"target_csv": {
"type": "string",
"description": "Target extract using the same CSV conventions. Empty datasets may contain the header only.",
"maxLength": 190000
},
"mapping_csv": {
"type": "string",
"description": "CSV headers source,target,type. Up to ten mappings; type is text, number or reference. Reference values must identify a row in the corresponding extract. Key matching always uses exact values.",
"maxLength": 190000
},
"source_key": {
"type": "string",
"description": "A column present in the source CSV. Empty or duplicate keys remain visible as data gaps.",
"default": "id",
"maxLength": 600
},
"target_key": {
"type": "string",
"description": "A column present in the target CSV. Keys are matched exactly, independently of text normalization.",
"default": "id",
"maxLength": 600
},
"whitespace": {
"type": "string",
"description": "Exact preserves whitespace; trim removes surrounding whitespace; collapse also replaces internal whitespace runs with one space.",
"default": "trim",
"enum": [
"exact",
"trim",
"collapse"
],
"maxLength": 600
},
"case_sensitive": {
"type": "string",
"description": "No compares mapped text after Unicode lowercasing. Keys and reference lookups remain exact.",
"default": "yes",
"enum": [
"yes",
"no"
],
"maxLength": 600
},
"null_tokens": {
"type": "string",
"description": "One value per line, at most eight values and 120 bytes. Values match after whitespace processing and before case normalization.",
"default": "NULL",
"maxLength": 600
},
"empty_policy": {
"type": "string",
"description": "Equivalent treats the configured empty values as empty strings. Exact retains them as ordinary values.",
"default": "equivalent",
"enum": [
"exact",
"equivalent"
],
"maxLength": 600
},
"absolute_tolerance": {
"type": "number",
"description": "Maximum absolute difference in the supplied numeric unit. Decimal-dot values only; no unit conversion.",
"default": 0,
"minimum": 0,
"maximum": 1000000
},
"relative_tolerance_pct": {
"type": "number",
"description": "Tolerance relative to the absolute source value. The larger of absolute and relative tolerance applies; a zero source uses absolute tolerance.",
"default": 0,
"minimum": 0,
"maximum": 100
},
"extra_rows": {
"type": "string",
"description": "Issue reports additional target records as findings. Allow treats their presence as acceptable within the configured scope.",
"default": "issue",
"enum": [
"issue",
"allow"
],
"maxLength": 600
},
"detail_filter": {
"type": "string",
"description": "Issues hides matching detail rows. All includes matching rows. Totals and AI candidate selection remain independent of this display filter.",
"default": "issues",
"enum": [
"issues",
"all"
],
"maxLength": 600
}
}
}
Перевірка простежуваності партій і серійних номерів
batch_traceability
Простежування наданих зв’язків партій і реєстрів рухів, обчислення залишків із прив’язкою до одиниць та визначення одержувачів і відсутніх доказів у явній області.
Поля введення та конфігурації
Основні налаштування
batches_csv — CSV реєстру партій
Заголовки id,product,serial,unit,opening,notes. До 100 унікальних ідентифікаторів партій. opening — початковий обліковий залишок, а не незалежно перевірений запас.
links_csv — CSV зв’язків партій
Заголовки parent,child; до 200 зв’язків. Зв’язки описують простежуваність і ніколи не зменшують запас. Файл лише із заголовком є коректним.
movements_csv — CSV реєстру рухів
Заголовки id,batch,kind,quantity,unit,party,reference,date. До 300 унікальних рухів. Типи: receive,consume,ship,adjust_in,adjust_out. Кількості є невід’ємними значеннями з десятковою крапкою; дати використовують YYYY-MM-DD.
start_batch — Початкова партія
Потрібна рівно одна початкова партія або серійний номер. Ідентифікатори партій використовують літери, цифри, підкреслення або дефіси.
Типові налаштування: ""
Розширені налаштування
start_serial — Початковий серійний номер
Альтернатива початковій партії. Серійний номер має визначати рівно одну надану партію.
Типові налаштування: ""
direction — Напрям простежування
«Уперед» проходить від батьківської партії до дочірньої; «Назад» — від дочірньої до батьківської; «Обидва» досліджує обидва напрями. Цикли відвідуються один раз.
forward — Уперед · backward — Назад · both — Обидва
Типові налаштування: "both"
max_depth — Максимальна глибина зв’язків
Від 1 до 20. Зв’язки за межею явно підраховуються; їхні партії не включаються.
Типові налаштування: 10
as_of — Гранична дата рухів
Необов’язкова гранична дата YYYY-MM-DD включно. Фільтруються лише дати рухів; недатовані зв’язки партій не є історичними знімками.
Типові налаштування: ""
include_zero — Показ нульового запасу
«Ні» приховує рядки деталей запасу з нульовим залишком. Охоплення простежування, рухи та перевірка приміток ШІ не змінюються.
yes — Так · no — Ні
Типові налаштування: "yes"
movement_view — Деталі рухів
«Усі» показує кожен вибраний рух. «Відправлення» показує лише відвантаження; «Запаси» — інші рухи. Кожен вибраний рух і далі впливає на залишок запасу.
all — Усі · shipments — Відправлення · stock — Запаси
Типові налаштування: "all"
minimum_stock — Поріг попередження про запас
Залишки нижче цього порога виділяються. Одиниці мають точно відповідати кожній партії. Несумісні рухи виключаються з обчислень і повідомляються як прогалини.
Типові налаштування: 0
detail_order — Порядок деталей
«Партія» сортує за ідентифікатором партії. «Спершу зауваження» ставить детерміновані зауваження перед звичайними деталями.
batch — Партія · issues_first — Спершу зауваження
Типові налаштування: "batch"
Максимальна кількість вхідних байтів UTF-8: 200000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
{
"type": "object",
"additionalProperties": false,
"required": [
"batches_csv",
"links_csv",
"movements_csv"
],
"properties": {
"batches_csv": {
"type": "string",
"description": "Headers id,product,serial,unit,opening,notes. Up to 100 unique batch IDs. Opening is the starting ledger balance, not an independently verified inventory.",
"maxLength": 190000
},
"links_csv": {
"type": "string",
"description": "Headers parent,child; up to 200 relationships. Relationships describe trace links and never deduct stock. A header-only file is valid.",
"maxLength": 190000
},
"movements_csv": {
"type": "string",
"description": "Headers id,batch,kind,quantity,unit,party,reference,date. Up to 300 unique movements. Kinds: receive,consume,ship,adjust_in,adjust_out. Quantities are non-negative decimal-dot values; dates use YYYY-MM-DD.",
"maxLength": 190000
},
"start_batch": {
"type": "string",
"description": "Exactly one starting batch or serial number is required. Batch IDs use letters, digits, underscores or hyphens.",
"default": "",
"maxLength": 600
},
"start_serial": {
"type": "string",
"description": "Alternative to the starting batch. The serial must identify exactly one supplied batch.",
"default": "",
"maxLength": 600
},
"direction": {
"type": "string",
"description": "Forward follows parent to child; backward follows child to parent; both explores both directions. Cycles are visited once.",
"default": "both",
"enum": [
"forward",
"backward",
"both"
],
"maxLength": 600
},
"max_depth": {
"type": "integer",
"description": "Between 1 and 20. Relationships beyond the boundary are counted explicitly; their batches are not included.",
"default": 10,
"minimum": 1,
"maximum": 20
},
"as_of": {
"type": "string",
"description": "Optional inclusive cutoff in YYYY-MM-DD. Only movement dates are filtered; undated batch relationships are not historical snapshots.",
"default": "",
"maxLength": 600
},
"include_zero": {
"type": "string",
"description": "No hides zero-balance stock detail rows. Trace reach, movements and AI note review are unaffected.",
"default": "yes",
"enum": [
"yes",
"no"
],
"maxLength": 600
},
"movement_view": {
"type": "string",
"description": "All displays every selected movement. Shipments displays shipping movements only; stock displays other movements. Every selected movement still contributes to the stock balance.",
"default": "all",
"enum": [
"all",
"shipments",
"stock"
],
"maxLength": 600
},
"minimum_stock": {
"type": "number",
"description": "Balances below this threshold are highlighted. Units must match each batch exactly. Incompatible movements are excluded from arithmetic and reported as gaps.",
"default": 0,
"minimum": -1000000,
"maximum": 1000000
},
"detail_order": {
"type": "string",
"description": "Batch sorts by batch identifier. Issues first places deterministic findings before ordinary details.",
"default": "batch",
"enum": [
"batch",
"issues_first"
],
"maxLength": 600
}
}
}
Планування технічного обслуговування на основі джерел
maintenance_planner
Планування обслуговування за датами й годинами роботи на основі явних інтервалів джерела, з перевіркою прострочення, відповідальними ролями та окремо підтвердженим експортом календаря.
Поля введення та конфігурації
Основні налаштування
assets — Вихідні записи технічного обслуговування
Заголовки CSV: id,asset,instruction,interval_days,interval_hours,last_date,last_hours,current_hours,priority,owner. Текст CSV обмежено 40 000 байтами UTF-8. До 20 унікальних ідентифікаторів великими літерами; asset і owner — до 160 байтів UTF-8, інструкція виробника — до 1200 байтів. Потрібен принаймні один явний додатний інтервал: дні 1–3650 або години 1–100000. Денні інтервали вимагають last_date у форматі YYYY-MM-DD, не пізніше дати відліку. Годинні інтервали вимагають цілих last_hours і current_hours від 0 до 10000000, причому current_hours не менше last_hours. Невикористані клітинки інтервалів і лічильників залишаються порожніми. priority — high, medium або low. owner може бути порожнім. Інтервали мають бути переписані з фактичних даних виробника або схваленого джерела обслуговування; інструмент не перевіряє їхню авторитетність.
Типові налаштування: ""
reference_date — Дата відліку
Явна дата YYYY-MM-DD для порівняння строків виконання та граничних строків дій; підтримувані роки — 2000–2100. Поточна дата не вгадується.
Типові налаштування: "2026-11-03"
Розширені налаштування
horizon_days — Горизонт планування в днях
Календарні строки не пізніше дати відліку плюс ця кількість днів входять до горизонту планування. Наступна дата — last_date плюс наданий інтервал; прострочена робота не переноситься вперед без позначення.
Типові налаштування: 30
priority_filter — Фільтр пріоритету
Фільтрує явно наданий пріоритет перед вибором моделі. Пріоритет не виводиться з назви обладнання й не генерується моделлю.
all — Усі · high — Високий · high_medium — Високий і середній
Типові налаштування: "all"
due_filter — Фільтр стану строку
Усі включає пізніші роботи. До виконання включає прострочені завдання, дати в межах горизонту та годинні пороги в межах налаштованого попередження. Прострочені вимагає дати строго перед датою відліку або від’ємної кількості годин, що залишилися. Рівність означає настання строку, а не прострочення.
all — Усі · due — До виконання у вибраних межах · overdue — Прострочені
Типові налаштування: "due"
hours_warning — Поріг попередження про години роботи
Включає годинні завдання, коли кількість годин роботи, що залишилися, дорівнює цьому порогу або нижча. Це не оцінка темпу використання й ніколи не створює календарну дату з годин.
Типові налаштування: 20
max_items — Максимальна кількість вибраних записів
ШІ вибирає цю кількість придатних записів або всі придатні записи, якщо їх залишилося менше. Вибір є пропозицією для перевірки; виключені чи невибрані записи підраховуються, а не подаються як завершені.
Типові налаштування: 12
detail — Детальність фрагментів
Короткі фрагменти містять щонайбільше 180 байтів UTF-8; докладні — 600. Фрагменти зберігають точне формулювання джерела мовою оригіналу.
brief — Короткі фрагменти · detailed — Докладні фрагменти
Типові налаштування: "detailed"
sort_order — Порядок відображення
Сортує повні вибрані рядки за наданим пріоритетом, обчисленою датою виконання з виключно годинними завданнями наприкінці або початковим порядком джерела.
priority — Наданий пріоритет · date — Дата джерела · source — Порядок джерела
Типові налаштування: "priority"
calendar_name — Назва календаря
Назва окремо підтвердженого експорту календаря, щонайбільше 120 байтів UTF-8. Лише перевірені строки на основі дат можуть стати подіями. Жоден сервіс календаря не залучається.
Типові налаштування: "Maintenance review"
reminder_days — Випередження нагадування
0 вимикає нагадування. Інакше підтверджений календар використовує екранне нагадування за 1–90 днів до кожної вибраної події на весь день. Окреме підтвердження людиною є обов’язковим.
Типові налаштування: 7
Максимальна кількість вхідних байтів UTF-8: 50000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "maintenance_planner",
"text": "{\"assets\":\"id,asset,instruction,interval_days,interval_hours,last_date,last_hours,current_hours,priority,owner\\nA1,Повітряний фільтр,Оглянути фільтр і зафіксувати видиме забруднення.,30,,2026-10-10,,,high,Команда технічного обслуговування\\nA2,Компресор майстерні,Перевірити стан ременя та зафіксувати результат.,,200,,1000,1190,medium,Керівник майстерні\",\"reference_date\":\"2026-11-03\",\"horizon_days\":30,\"priority_filter\":\"all\",\"due_filter\":\"due\",\"hours_warning\":20,\"max_items\":12,\"detail\":\"detailed\",\"sort_order\":\"priority\",\"calendar_name\":\"Перевірені дати обслуговування\",\"reminder_days\":7}"
}
Упорядкування хронології інциденту, впливу, підтверджених джерелом причин, гіпотез і подальших дій із точними доказами та видимими запитаннями без відповіді.
Поля введення та конфігурації
Основні налаштування
incident — Назва інциденту
Коротка назва інциденту, до 200 байтів UTF-8. Без секретів, персональних ідентифікаторів або облікових даних.
Типові налаштування: ""
evidence — Записи доказів інциденту
Заголовки CSV: id,date,kind,status,impact,owner,deadline,text,criterion. Текст CSV обмежено 40 000 байтами UTF-8. До 24 унікальних ідентифікаторів великими літерами; text — до 1200 байтів UTF-8, criterion — до 500, owner — до 160. date і deadline мають формат YYYY-MM-DD або порожні. kind — event, impact, cause, hypothesis або action. status — recorded, confirmed, open, in_progress, done, verified або unknown. cause вимагає confirmed; hypothesis — open або unknown; action — open, in_progress, done, verified або unknown. impact — high, medium, low або unknown. Підтвердження й перевірка є твердженнями наданого запису, а не незалежними висновками. Відсутні відповідальна особа, строк і критерій ефективності залишаються порожніми.
Типові налаштування: ""
reference_date — Дата відліку
Явна дата YYYY-MM-DD для порівняння строків виконання та граничних строків дій; підтримувані роки — 2000–2100. Поточна дата не вгадується.
Типові налаштування: "2026-11-03"
Розширені налаштування
focus — Напрям перевірки
Вибирає всі докази, хронологію подій і наслідків, причини й гіпотези або дії перед вибором моделі. На пов’язані докази подій і наслідків можна й далі посилатися з повного наданого знімка.
all — Усі · chronology — Хронологія · causes — Причини й гіпотези · actions — Дії
Типові налаштування: "all"
cause_filter — Фільтр класифікації причин
Зберігає обидві класифікації джерела, лише підтверджені джерелом причини або лише гіпотези. Модель не може перетворити гіпотезу на підтверджену причину. Підтвердження копіюється з вхідних даних і має бути незалежно перевірене.
all — Усі · confirmed — Підтверджено в наданому джерелі · hypotheses — Лише гіпотези
Типові налаштування: "all"
action_filter — Фільтр стану дії
Усі зберігає кожен наданий стан дії. Відкриті включає open, in_progress і unknown; перевірені — лише дії з позначкою verified у джерелі. Завершена дія не є автоматично ефективною чи перевіреною.
all — Усі · open — Відкриті · verified — Перевірено в наданому джерелі
Типові налаштування: "all"
impact_filter — Фільтр впливу
Фільтрує явний рівень впливу для всіх типів записів. Невідомий вплив включається лише з Усі. Модель ніколи не вигадує серйозності.
all — Усі · high — Високий · high_medium — Високий і середній
Типові налаштування: "all"
max_items — Максимальна кількість вибраних записів
ШІ вибирає цю кількість придатних записів або всі придатні записи, якщо їх залишилося менше. Вибір є пропозицією для перевірки; виключені чи невибрані записи підраховуються, а не подаються як завершені.
Типові налаштування: 16
detail — Детальність фрагментів
Короткі фрагменти містять щонайбільше 180 байтів UTF-8; докладні — 600. Фрагменти зберігають точне формулювання джерела мовою оригіналу.
brief — Короткі фрагменти · detailed — Докладні фрагменти
Типові налаштування: "detailed"
sort_order — Порядок відображення
Сортує повні вибрані рядки за датою джерела з недатованими елементами наприкінці, перекладеним типом запису або початковим порядком джерела. Відсутні дати ніколи не виводяться.
chronology — Хронологія · type — Тип запису · source — Порядок джерела
Типові налаштування: "chronology"
include_questions — Включення запитань про прогалини доказів
Додає фіксовані запитання перевірки щодо відсутнього обґрунтування причин, відповідальних ролей, строків дій і критеріїв ефективності. Неперевірені дії залишаються запитаннями, а не автоматично завершеними перевірками. Прострочені строки відкритих дій порівнюються з явною датою відліку.
Типові налаштування: true
Максимальна кількість вхідних байтів UTF-8: 50000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "incident_review",
"text": "{\"incident\":\"Зупинка пакувальної лінії\",\"evidence\":\"id,date,kind,status,impact,owner,deadline,text,criterion\\nE1,2026-11-02,event,recorded,high,,,Лінія зупинилася після температурного сигналу тривоги.,\\nE2,2026-11-02,impact,recorded,high,,,Виробництво було зупинено на 25 хвилин.,\\nH1,2026-11-02,hypothesis,open,high,,,\\\"Підозрюється заблокований шлях охолодження, але це не підтверджено.\\\",\\nA1,2026-11-03,action,open,high,Керівник технічного обслуговування,2026-11-05,Оглянути шлях охолодження та зафіксувати результати.,Відсутність температурного сигналу тривоги під час задокументованого валідаційного запуску.\",\"reference_date\":\"2026-11-03\",\"focus\":\"all\",\"cause_filter\":\"all\",\"action_filter\":\"all\",\"impact_filter\":\"all\",\"max_items\":16,\"detail\":\"detailed\",\"sort_order\":\"chronology\",\"include_questions\":true}"
}
Порівняння планових витрат нетто з підтвердженими джерелами призначеннями фактичних витрат, точними розрахунками рядків, відхиленнями та попередженнями про маржу.
Поля введення та конфігурації
Основні налаштування
plans — Планові позиції
Стовпці CSV id,description,planned_net,revenue_net. До 15 позицій. Усі суми нетто, в одній валюті.
actuals — Фактичні витрати
Стовпці CSV id,date,kind,description,quantity,unit_net,plan_id. До 30 рядків. Кількість праці означає години; кількості матеріалів і зовнішніх послуг означають одиниці. Порожній plan_id запитує пропозицію моделі.
currency — Валюта
Одна валюта з двома десятковими знаками застосовується до всіх показників.
Підтримуються лише вхідні значення нетто; податки не розраховуються й перетворення брутто на нетто не виконується.
yes — Так · no — Ні
Типові налаштування: "no"
Розширені налаштування
rounding — Округлення рядків
Кожен добуток кількості та ціни одиниці округлюється до сотих перед підсумовуванням. Округлення до парного округлює точну половину до парної сотої.
half_up — Округлення точної половини вгору · half_even — Округлення точної половини до парної сотої
Типові налаштування: "half_up"
group_by — Порядок подробиць
Упорядкування докладних рядків за призначеною плановою позицією, видом витрат або ідентифікатором джерела. Планові підсумки завжди залишаються окремо.
plan — Планова позиція · kind — Вид витрат · source — Ідентифікатор джерела
Типові налаштування: "plan"
variance_filter — Видимість планових рядків
За бажанням показуються лише планові рядки, додатне відхилення витрат яких перевищує поріг. Зведені підсумки та всі висновки залишаються повними.
all — Усі · over_threshold — Вище порога відхилення
Типові налаштування: "all"
variance_threshold — Поріг відхилення витрат
Невід'ємна сума нетто для висновків про перевищення планових витрат і необов'язкового фільтра планових рядків.
Типові налаштування: "0.00"
margin_warning_percent — Відсотковий поріг попередження про маржу
Позначення маржі за розподіленими плановими витратами нижче цього цілого відсотка від 0 до 100. Нульовий дохід дає невідому маржу.
Типові налаштування: 20
date_from — Початок періоду
Необов'язкова включна дата. Фільтруються лише фактичні витрати; усі надані планові витрати та доходи залишаються незмінними.
Типові налаштування: ""
date_to — Кінець періоду
Необов'язкова включна дата. Виключені фактичні рядки залишаються видимими й не входять до вибраних підсумків витрат.
Типові налаштування: ""
mapping_mode — Політика призначення
Допоміжний режим використовує одну валідовану пропозицію моделі. Режим лише явних призначень розподіляє тільки надані значення plan_id; неоднозначні витрати та витрати без збігу залишаються нерозподіленими.
assisted — Допоміжне призначення · explicit_only — Лише явні призначення
Типові налаштування: "assisted"
show_details — Показувати звичайні докладні рядки
Нерозподілені, неоднозначні та виключені рядки залишаються видимими, навіть коли звичайні подробиці приховано.
yes — Так · no — Ні
Типові налаштування: "yes"
include_quotes — Показувати цитати джерел
Докази залишаються валідованими, навіть коли цитати приховано у звіті.
yes — Так · no — Ні
Типові налаштування: "yes"
Максимальна кількість вхідних байтів UTF-8: 50000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Перевірка явних подій заявок відносно підтверджених правил із розрахунками робочого часу, пауз і переходів на літній час.
Поля введення та конфігурації
Основні налаштування
events — Події заявок
Стовпці CSV id,ticket,at,event,priority,description. До 60 подій у 12 заявках у межах інтервалу тривалістю 31 день. Часові позначки потребують секунд і явного зсуву від UTC.
rules — Затверджені правила SLA
Стовпці CSV id,priority,description,response_minutes,resolution_minutes. До 12 правил; кожен поріг — явне додатне ціле число хвилин.
rules_approved — Правила явно підтверджено
Надані описи та числові пороги потребують явного підтвердження перед обробкою.
no — Ні · yes — Так
Типові налаштування: "no"
Розширені налаштування
timezone — Часовий пояс робочого часу
Місцеві календарні дати, дні тижня, робочі години та надані святкові дні використовують цей часовий пояс. Зсуви часових позначок джерел визначають хронологічний порядок.
Робочий час зараховує лише налаштовані місцеві робочі інтервали. Минулий час зараховує всі секунди. Вибрані паузи виключаються в обох режимах.
business — Робочий час · elapsed — Минулий час
Типові налаштування: "business"
business_hours — Щоденний робочий інтервал
Один інтервал HH:MM-HH:MM у межах одного дня, з початком раніше кінця та обома часовими значеннями до 24:00. Застосовується в режимі робочого часу.
Типові налаштування: "09:00-17:00"
business_days — Робочі дні тижня
Унікальні номери днів тижня, розділені комами, від понеділка 1 до неділі 7. Застосовується в режимі робочого часу.
Типові налаштування: "1,2,3,4,5"
holidays — Виключені місцеві дати
До 31 унікальної дати YYYY-MM-DD, розділених комами або новими рядками. Автоматичний календар свят не передбачається; застосовується в режимі робочого часу.
Типові налаштування: ""
pause_states — Стани призупинення обліку часу
Розділені комами pause_customer та/або pause_vendor або порожнє значення без виключення часу. resume завершує активну паузу; resolve також її завершує.
Типові налаштування: "pause_customer"
cycle_mode — Вибір циклів
Перевірка всіх явних циклів open/reopen або лише першого. Інші цикли залишаються видимими як виключені; попередження про послідовність зберігаються.
all — Усі · first — Лише перший цикл
Типові налаштування: "all"
date_from — Початок періоду
Необов'язкова включна місцева дата відкриття для вибору циклів. Події зберігаються для перевірки послідовності.
Типові налаштування: ""
date_to — Кінець періоду
Необов'язкова включна місцева дата відкриття для вибору циклів. Виключені цикли залишаються видимими.
Типові налаштування: ""
sort_order — Порядок результатів
Упорядкування за заявкою або розміщення висновків і неповних циклів на початку.
ticket — Заявка · issues_first — Спочатку висновки перевірки
Типові налаштування: "ticket"
include_quotes — Показувати цитати джерел
Докази залишаються валідованими, навіть коли цитати приховано у звіті.
yes — Так · no — Ні
Типові налаштування: "yes"
Максимальна кількість вхідних байтів UTF-8: 50000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "sla_review",
"text": "{\"events\":\"id,ticket,at,event,priority,description\\nE1,T1,2027-03-01T09:00:00+01:00,open,high,Переривання хостингової послуги\\nE2,T1,2027-03-01T09:30:00+01:00,response,high,Початкова відповідь підтримки\\nE3,T1,2027-03-01T10:00:00+01:00,pause_customer,high,Очікування інформації від клієнта\\nE4,T1,2027-03-01T11:00:00+01:00,resume,high,Отримано інформацію від клієнта\\nE5,T1,2027-03-01T12:00:00+01:00,resolve,high,Послугу відновлено\",\"rules\":\"id,priority,description,response_minutes,resolution_minutes\\nR1,high,Інциденти хостингової послуги з високим пріоритетом,60,180\",\"rules_approved\":\"yes\",\"timezone\":\"Europe/Berlin\",\"clock\":\"business\",\"business_hours\":\"09:00-17:00\",\"business_days\":\"1,2,3,4,5\",\"holidays\":\"\",\"pause_states\":\"pause_customer\",\"cycle_mode\":\"all\",\"date_from\":\"\",\"date_to\":\"\",\"sort_order\":\"ticket\",\"include_quotes\":\"yes\"}"
}
Розподіл запитаних довжин між наданими прутками або рулонами з явними пропилами, кінцевим обрізанням, групами матеріалів, залишками та вартісними пріоритетами, з подальшою перевіркою кожного розподілу й залишку.
Поля введення та конфігурації
Основні налаштування
demand — CSV потрібних деталей
Заголовки id,material,unit,length,quantity,note. До 20 унікальних ідентифікаторів великими літерами та загалом 200 екземплярів деталей. Додатні довжини використовують десяткову крапку й максимум три десяткові знаки; кількість — додатне ціле число. Примітки мають не більше 300 байтів UTF-8. Усі рядки в обох файлах мають використовувати одну спільну одиницю: mm, cm, m або in.
stock — CSV доступних заготовок
Заголовки id,material,unit,length,quantity,cost,kind,note. До 30 унікальних ідентифікаторів великими літерами та загалом 100 екземплярів заготовок. kind має значення new або remnant; cost — невід'ємна десяткова сума за одиницю з максимум двома десятковими знаками у вибраній валюті. Наявні залишки є явними заготовками; запас не закуповується.
Розширені налаштування
kerf — Пропил на деталь
Невід'ємний десятковий рядок у спільній одиниці довжини, максимум три десяткові знаки. На кожну розподілену деталь нараховується рівно один пропил, включно з останньою деталлю.
Типові налаштування: "0"
trim_start — Початкове обрізання
Невід'ємний десятковий рядок, що віднімається один раз від початку кожної використаної заготовки, у спільній одиниці.
Типові налаштування: "0"
trim_end — Кінцеве обрізання
Невід'ємний десятковий рядок, що віднімається один раз від кінця кожної використаної заготовки, у спільній одиниці.
Типові налаштування: "0"
minimum_remnant — Мінімальний залишок для повторного використання
Невід'ємний десятковий рядок. Додатні залишкові довжини на рівні цього порога або вище позначаються як придатні для повторного використання; коротші залишки зараховуються як відходи. Ця класифікація не змінює розміщення.
Типові налаштування: "0"
strategy — Стратегія розміщення
Найкраще вміщення вибирає найменшу залишкову місткість після пріоритетніших уподобань щодо заготовок. Перше вміщення пропускає ранжування залишкової місткості. Обидва варіанти є обмеженими жадібними евристиками й ніколи не доводять оптимальності.
best_fit — Найкраще вміщення · first_fit — Перше вміщення
Типові налаштування: "best_fit"
objective — Мета вибору заготовок
Матеріал надає перевагу коротшим придатним заготовкам після уподобань щодо залишків і вже відкритих заготовок. Вартість ранжує невідкриті заготовки за наданою ціною одиниці перед залишковою місткістю. Уже відкриті заготовки мають перевагу. Глобальний мінімум вартості не заявляється.
material — Використання матеріалу · cost — Надана вартість
Типові налаштування: "material"
currency — Валюта вартості
Єдине позначення для всіх наданих вартостей заготовок. Конвертація за валютним курсом або незалежна перевірка цін не виконується.
За значення «Так» сумісні залишки ранжуються перед новими заготовками. Це уподобання передує ранжуванню за відкритими заготовками, вартістю та залишковою місткістю.
yes — Так · no — Ні
Типові налаштування: "yes"
allow_remnants — Дозволити наявні залишки
За значення «Ні» рядки заготовок із позначкою remnant виключаються з розміщення. Їх виключення ніколи не створює новий запас і не змінює потрібні кількості.
yes — Так · no — Ні
Типові налаштування: "yes"
material_case — Групи матеріалів з урахуванням регістру
Пробіли на початку й наприкінці назв матеріалів прибираються. За значення «Ні» додатково порівнюються назви в нижньому регістрі Unicode; різні групи матеріалів ніколи не змішуються.
yes — Так · no — Ні
Типові налаштування: "yes"
cut_order — Порядок розміщення деталей
Найдовші спочатку впорядковує за довжиною та використовує запропонований ШІ порядок джерел для розв'язання рівності. Пріоритет ШІ дотримується прив'язаного до джерел порядку, запропонованого з приміток потреби. Кожен потрібний екземпляр залишається врахованим.
longest_first — Найдовші спочатку · ai_priority — Пріоритет, запропонований ШІ
Типові налаштування: "longest_first"
display_order — Порядок результатів
Запас упорядковує використані екземпляри заготовок за ідентифікатором. Відходи спочатку впорядковує за сумарною довжиною пропилів, обрізання та залишку. Порядок відображення ніколи не змінює розрахований план.
stock — Ідентифікатор заготовки · waste_first — Найбільша непродуктова довжина спочатку
Типові налаштування: "stock"
Максимальна кількість вхідних байтів UTF-8: 180000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
{
"type": "object",
"additionalProperties": false,
"required": [
"demand",
"stock"
],
"properties": {
"demand": {
"type": "string",
"description": "Headers id,material,unit,length,quantity,note. Up to 20 unique uppercase IDs and 200 total part instances. Positive lengths use a decimal point with at most three decimals; positive integer quantity. Notes are at most 300 UTF-8 bytes. All rows in both files must use one common unit: mm, cm, m or in.",
"maxLength": 160000
},
"stock": {
"type": "string",
"description": "Headers id,material,unit,length,quantity,cost,kind,note. Up to 30 unique uppercase IDs and 100 total stock instances. kind is new or remnant; cost is a nonnegative per-item decimal amount with at most two decimals in the selected currency. Existing remnants are explicit stock items; no stock is purchased.",
"maxLength": 160000
},
"kerf": {
"type": "string",
"description": "Nonnegative decimal string in the common length unit, at most three decimals. Exactly one kerf is charged per allocated part, including the final part.",
"default": "0",
"maxLength": 120,
"pattern": "^(0|[1-9][0-9]{0,5})(\\.[0-9]{1,3})?$"
},
"trim_start": {
"type": "string",
"description": "Nonnegative decimal string deducted once from the start of every used stock item, in the common unit.",
"default": "0",
"maxLength": 120,
"pattern": "^(0|[1-9][0-9]{0,5})(\\.[0-9]{1,3})?$"
},
"trim_end": {
"type": "string",
"description": "Nonnegative decimal string deducted once from the end of every used stock item, in the common unit.",
"default": "0",
"maxLength": 120,
"pattern": "^(0|[1-9][0-9]{0,5})(\\.[0-9]{1,3})?$"
},
"minimum_remnant": {
"type": "string",
"description": "Nonnegative decimal string. Positive remaining lengths at or above this threshold are reported as reusable; shorter remnants count as waste. This classification does not change placement.",
"default": "0",
"maxLength": 120,
"pattern": "^(0|[1-9][0-9]{0,5})(\\.[0-9]{1,3})?$"
},
"strategy": {
"type": "string",
"description": "Best fit chooses the smallest remaining capacity after the higher-priority stock preferences. First fit omits that remaining-capacity ranking. Both are bounded greedy heuristics and never prove optimality.",
"default": "best_fit",
"enum": [
"best_fit",
"first_fit"
],
"maxLength": 120
},
"objective": {
"type": "string",
"description": "Material prefers shorter fitting stock after remnant and opened-stock preferences. Cost ranks unopened stock by the supplied per-item cost before remaining capacity. Already opened stock is preferred. No global cost minimum is claimed.",
"default": "material",
"enum": [
"material",
"cost"
],
"maxLength": 120
},
"currency": {
"type": "string",
"description": "A single label for all supplied stock costs. No exchange-rate conversion or independent price verification is performed.",
"default": "EUR",
"enum": [
"EUR",
"USD",
"GBP",
"PLN",
"CHF"
],
"maxLength": 120
},
"prefer_remnants": {
"type": "string",
"description": "Yes ranks compatible remnant stock before new stock. This preference comes before opened-stock, cost and remaining-capacity ranking.",
"default": "yes",
"enum": [
"yes",
"no"
],
"maxLength": 120
},
"allow_remnants": {
"type": "string",
"description": "No excludes stock rows marked remnant from placement. Their exclusion never creates new stock or changes demand quantities.",
"default": "yes",
"enum": [
"yes",
"no"
],
"maxLength": 120
},
"material_case": {
"type": "string",
"description": "Material names are trimmed. No additionally compares Unicode lowercase names; different material groups are never mixed.",
"default": "yes",
"enum": [
"yes",
"no"
],
"maxLength": 120
},
"cut_order": {
"type": "string",
"description": "Longest first orders by length and uses the AI-proposed source order to break ties. AI priority follows the source-bound order proposed from demand notes. Every demand instance remains accounted for.",
"default": "longest_first",
"enum": [
"longest_first",
"ai_priority"
],
"maxLength": 120
},
"display_order": {
"type": "string",
"description": "Stock orders used stock instances by identifier. Waste first orders by combined kerf, trim and remaining length. Display order never changes the computed plan.",
"default": "stock",
"enum": [
"stock",
"waste_first"
],
"maxLength": 120
}
}
}
Перевірка серій вимірювань
measurement_review
Порівняння виміряних значень із явно затвердженими межами, зведення груп ознак і партій та перевірка відсутніх показань, неоднозначних специфікацій і підтверджених джерелами спостережень ШІ.
Поля введення та конфігурації
Основні налаштування
measurements — CSV вимірювань
Заголовки id,feature,batch,date,value,unit,note. До 500 унікальних ідентифікаторів великими літерами, 20 груп ознаки й одиниці та 100 груп результатів. Дати використовують YYYY-MM-DD від 2000 до 2100. value — десятковий рядок зі знаком і до шести десяткових знаків або порожнє значення. Примітки мають не більше 300 байтів UTF-8.
specifications — CSV затверджених специфікацій
Заголовки id,feature,unit,lower,upper,note. До 20 унікальних ідентифікаторів великими літерами. Для кожної специфікації має бути надана хоча б одна межа; порожня нижня або верхня межа означає однобічну перевірку. Межі — десяткові рядки зі знаком і максимум шістьма десятковими знаками. Зіставлення використовує налаштоване порівняння назв ознак і точні одиниці. Кілька збігів залишаються нез'ясованими.
limits_approved — Підтвердити надані межі
Явне підтвердження, що саме ці надані специфікації та межі затверджені для цієї перевірки. Їх зміна потребує повторного підтвердження. Примітки джерел і вихід моделі не можуть надавати затвердження.
no — Не затверджено · yes — Саме ці межі затверджено
Типові налаштування: "no"
Розширені налаштування
date_from — Включати від дати
Необов'язкова включна нижня межа дати у форматі YYYY-MM-DD. Раніші спостереження виключаються зі статистик і підраховуються окремо.
Типові налаштування: ""
date_to — Включати до дати
Необов'язкова включна верхня межа дати у форматі YYYY-MM-DD. Пізніші спостереження виключаються зі статистик і підраховуються окремо.
Типові налаштування: ""
group_by — Статистичне групування
Ознака об'єднує всі включені партії для кожної ознаки та точної одиниці. Ознака й партія зберігає партії окремо. Приймається максимум 100 груп результатів.
feature — Ознака та одиниця · feature_batch — Ознака, одиниця та партія
Типові налаштування: "feature_batch"
case_sensitive — Зіставлення ознак з урахуванням регістру
Пробіли на початку й наприкінці назв прибираються. За значення «Ні» додатково порівнюються назви в нижньому регістрі Unicode. Одиниці завжди збігаються точно; перетворення одиниць або припущене зіставлення синонімів відсутнє.
yes — Так · no — Ні
Типові налаштування: "yes"
missing_policy — Політика відсутніх вимірювань
Звітування позначає групи з порожніми значеннями для перевірки. Виключення пропускає порожні значення у статистиках без цього додаткового попередження групи. Кількість відсутніх значень залишається видимою в обох режимах; недійсний числовий текст відхиляється.
report — Звітувати про відсутні значення · exclude — Виключити з числових статистик
Типові налаштування: "report"
boundary — Тлумачення граничних значень
Включний режим приймає значення, рівні наданій межі. Виключний режим позначає рівність як вихід за межі. Порівняння використовують точні неокруглені значення з фіксованою точкою.
inclusive — Включні межі · exclusive — Виключні межі
Типові налаштування: "inclusive"
rounding_digits — Відображувані десяткові знаки
Від 0 до 6 десяткових знаків для описових статистик. Округлення для відображення ніколи не змінює меж специфікацій або рішень про вихід за межі.
Типові налаштування: 3
minimum_sample — Мінімальний розмір числової вибірки
Групи з меншою кількістю числових спостережень отримують статус перевірки. Від 2 до 500; цей поріг не встановлює статистичної достовірності або репрезентативності.
Типові налаштування: 5
deviation — Правило стандартного відхилення
Вибірка використовує n−1 і потребує принаймні двох числових спостережень. Сукупність використовує n і потребує принаймні одного. Значення описують лише надані спостереження; ширші висновки про сукупність не маються на увазі.
Джерело зберігає першу появу кожної групи. Проблеми спочатку ставить групи для перевірки першими. Ознака сортує за наданою назвою ознаки та партією. Статистики залишаються незмінними.
source — Порядок джерела · issues_first — Групи для перевірки спочатку · feature — Ознака та партія
За значення «Так» включається точна примітка першого включеного вимірювання для кожної групи ознаки й одиниці. За значення «Ні» приховується лише цей стовпець відображення; ідентифікатори джерел і валідація моделі залишаються незмінними.
yes — Включити цитату · no — Лише ідентифікатори джерел
Типові налаштування: "yes"
detail_filter — Відображувані групи
Усі показує кожну включену групу. Проблеми показує групи з відсутніми або неоднозначними специфікаціями, значеннями поза межами, недостатнім розміром числової вибірки або відсутніми значеннями в режимі звітування. Повні зведені підрахунки залишаються незмінними.
all — Усі групи · issues — Лише групи для перевірки
Типові налаштування: "all"
Максимальна кількість вхідних байтів UTF-8: 180000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "measurement_review",
"text": "{\"measurements\":\"id,feature,batch,date,value,unit,note\\nM1,Діаметр,B1,2026-11-01,10.010,mm,Нуль приладу перевірено\\nM2,Діаметр,B1,2026-11-01,10.020,mm,Та сама процедура вимірювання\\nM3,Діаметр,B1,2026-11-01,10.060,mm,Рекомендоване повторне вимірювання\\nM4,Діаметр,B1,2026-11-01,,mm,Показання недоступне\",\"specifications\":\"id,feature,unit,lower,upper,note\\nS1,Діаметр,mm,9.950,10.050,Затверджена редакція A креслення\",\"limits_approved\":\"yes\",\"date_from\":\"\",\"date_to\":\"\",\"group_by\":\"feature_batch\",\"case_sensitive\":\"yes\",\"missing_policy\":\"report\",\"boundary\":\"inclusive\",\"rounding_digits\":3,\"minimum_sample\":3,\"deviation\":\"sample\",\"sort_order\":\"source\",\"include_evidence\":\"yes\",\"detail_filter\":\"all\"}"
}
Повна схема конфігурації
{
"type": "object",
"additionalProperties": false,
"required": [
"measurements",
"specifications",
"limits_approved"
],
"properties": {
"measurements": {
"type": "string",
"description": "Headers id,feature,batch,date,value,unit,note. Up to 500 unique uppercase IDs, 20 feature-and-unit groups and 100 result groups. Dates use YYYY-MM-DD from 2000 through 2100. value is a signed decimal string with up to six decimals, or empty. Notes are at most 300 UTF-8 bytes.",
"maxLength": 160000
},
"specifications": {
"type": "string",
"description": "Headers id,feature,unit,lower,upper,note. Up to 20 unique uppercase IDs. At least one limit must be supplied per specification; an empty lower or upper limit means one-sided checking. Limits are signed decimal strings with at most six decimals. Matching uses the configured feature-name comparison and exact units. Multiple matches remain unresolved.",
"maxLength": 160000
},
"limits_approved": {
"type": "string",
"description": "Explicit confirmation that these exact supplied specifications and limits are approved for this review. Changing them requires renewed confirmation. Source notes and model output cannot grant approval.",
"default": "no",
"enum": [
"no",
"yes"
],
"maxLength": 120
},
"date_from": {
"type": "string",
"description": "Optional inclusive lower date bound in YYYY-MM-DD. Earlier observations are excluded from statistics and counted separately.",
"default": "",
"maxLength": 120
},
"date_to": {
"type": "string",
"description": "Optional inclusive upper date bound in YYYY-MM-DD. Later observations are excluded from statistics and counted separately.",
"default": "",
"maxLength": 120
},
"group_by": {
"type": "string",
"description": "Feature combines all included batches for each feature and exact unit. Feature and batch keeps batches separate. A maximum of 100 result groups is accepted.",
"default": "feature_batch",
"enum": [
"feature",
"feature_batch"
],
"maxLength": 120
},
"case_sensitive": {
"type": "string",
"description": "Names are trimmed. No additionally compares Unicode lowercase names. Units always match exactly; there is no unit conversion or inferred alias mapping.",
"default": "yes",
"enum": [
"yes",
"no"
],
"maxLength": 120
},
"missing_policy": {
"type": "string",
"description": "Report marks groups with empty values for review. Exclude omits empty values from statistics without this additional group warning. Missing-value counts remain visible in both modes; invalid numeric text is rejected.",
"default": "report",
"enum": [
"report",
"exclude"
],
"maxLength": 120
},
"boundary": {
"type": "string",
"description": "Inclusive accepts values equal to a supplied bound. Exclusive marks equality as out of range. Comparisons use exact unrounded fixed-point values.",
"default": "inclusive",
"enum": [
"inclusive",
"exclusive"
],
"maxLength": 120
},
"rounding_digits": {
"type": "integer",
"description": "Between 0 and 6 decimal places for descriptive statistics. Display rounding never changes specification limits or out-of-range decisions.",
"default": 3,
"minimum": 0,
"maximum": 6
},
"minimum_sample": {
"type": "integer",
"description": "Groups with fewer numeric observations receive a review status. Between 2 and 500; this threshold does not establish statistical confidence or representativeness.",
"default": 5,
"minimum": 2,
"maximum": 500
},
"deviation": {
"type": "string",
"description": "Sample uses n−1 and requires at least two numeric observations. Population uses n and requires at least one. Values describe only the supplied observations; no wider population inference is implied.",
"default": "sample",
"enum": [
"sample",
"population"
],
"maxLength": 120
},
"sort_order": {
"type": "string",
"description": "Source retains the first appearance of each group. Issues first puts review groups first. Feature sorts by supplied feature name and batch. Statistics remain unchanged.",
"default": "source",
"enum": [
"source",
"issues_first",
"feature"
],
"maxLength": 120
},
"include_evidence": {
"type": "string",
"description": "Yes includes the exact first included measurement note for each feature-and-unit group. No hides this display column only; source IDs and model validation remain unchanged.",
"default": "yes",
"enum": [
"yes",
"no"
],
"maxLength": 120
},
"detail_filter": {
"type": "string",
"description": "All shows every included group. Issues shows groups with missing or ambiguous specifications, out-of-range values, insufficient numeric sample size or report-mode missing values. Complete summary counts remain unchanged.",
"default": "all",
"enum": [
"all",
"issues"
],
"maxLength": 120
}
}
}
Перевірка наслідків змін за підтримуваними даними
change_impact
Відстеження конкретних змін через підтримувані залежності та перевірка зачеплених документів, тестів, процесів і відповідальних ролей без вигадування зв'язків впливу.
Поля введення та конфігурації
Основні налаштування
elements — Підтримувані елементи
Заголовки CSV id,name,kind,criticality,approval,owner,description. До 40 унікальних ідентифікаторів великими літерами. name та owner: максимум 160 байтів UTF-8; description: 1,200 байтів. kind: document,test,process,system. criticality: high,medium,low. approval: approved,draft,unknown. Порожній owner дозволений і залишається прогалиною. Затвердження є твердженням джерела, а не затвердженням цього інструмента. Ліміт CSV: 40,000 байтів UTF-8.
Типові налаштування: ""
dependencies — Підтримувані залежності
Заголовки CSV id,from,to,evidence. from — передумова або попередній елемент; to — залежний або наступний елемент. До 100 унікальних ідентифікаторів і пар ребер для перевірки змін, 50 для відновлення. Обидві кінцеві точки мають існувати. Доказ обов'язковий і обмежений 600 байтами UTF-8. Файл лише із заголовком дійсний; відсутні зовнішні зв'язки не можуть бути виведені. Ліміт CSV: 40,000 байтів UTF-8.
Типові налаштування: ""
changes — Конкретні запропоновані зміни
Заголовки CSV id,element,description. До 12 унікальних ідентифікаторів змін великими літерами, кожен пов'язаний з наявним елементом. Опис: 1,200 байтів UTF-8. Кожен вибраний початковий елемент має містити принаймні одну надану зміну. До перевірки входять лише зміни вибраних початкових елементів. Ліміт CSV: 40,000 байтів UTF-8.
Типові налаштування: ""
start_ids — Ідентифікатори початкових елементів
Від одного до восьми різних наявних ідентифікаторів елементів, розділених пробільними символами або комами. Кожен початковий елемент потребує конкретного запису зміни. Початковий ідентифікатор, згенерований моделлю, не приймається.
Типові налаштування: ""
baseline — Базова версія
Обов'язковий ідентифікатор базової версії до 120 байтів UTF-8. Він позначає цей наданий знімок; інструмент не отримує й не порівнює зовнішню версію.
Типові налаштування: "BASE-1"
Розширені налаштування
direction — Напрямок обходу
Вперед слідує від передумови до залежного елемента; назад — від залежного елемента до передумови; обидва досліджує обидва напрямки. Зворотний обхід є перевіркою залежностей, а не доказом впливу на наступні елементи. Кожен відображений шлях містить лише надані ідентифікатори ребер.
forward — Вперед · backward — Назад · both — Обидва напрямки
Типові налаштування: "forward"
max_depth — Максимальна глибина шляху
Від одного до двадцяти ребер від кожного зміненого початкового елемента. Для кожної зміни й елемента зберігається найкоротший виявлений шлях. Граничні ребра відображаються; невиявлені елементи за межами ліміту не вважаються незачепленими.
Типові налаштування: 10
kind_filter — Фільтр типу елемента
Фільтрує кандидатів перевірки після повного обходу графа. Приховані проміжні елементи й далі беруть участь у шляхах залежностей.
all — Усі · document — Документ · test — Тест · process — Процес · system — Система
Типові налаштування: "all"
criticality_filter — Фільтр критичності
Фільтрує кандидатів перевірки за явно наданою критичністю. Планування відновлення все одно включає всі зачеплені процеси до цього вибору відображення; залежності низького пріоритету не можуть зникнути з плану.
all — Усі · high — Високий · high_medium — Висока та середня
Типові налаштування: "all"
approval_filter — Фільтр затвердження джерела
Фільтрує лише надане поле approval. approved — позначка джерела, а не незалежно перевірений дозвіл на випуск.
all — Усі · approved — Затверджено в джерелі · draft — Чернетка в джерелі · unknown — Невідомо
Типові налаштування: "all"
max_items — Максимум записів для перевірки
ШІ вибирає саме стільки допустимих записів або всі допустимі записи, якщо їх залишилося менше. Повний детермінований аналіз і далі охоплює кожну надану залежність і зачеплений процес. Невибрані записи не засвідчуються як незачеплені чи відновлені.
Типові налаштування: 10
detail — Докладність цитат
Короткі уривки обмежені 120 символами, детальні — 240. Модель отримує вказівку віддавати перевагу уривкам до 80 символів. Кожна цитата має бути точним безперервним уривком мовою початкового джерела.
brief — Коротко · detailed — Докладно
Типові налаштування: "detailed"
sort_order — Порядок відображення
Перевпорядковує вибрані рядки за початковим порядком джерела, найкоротшою вибраною глибиною шляху або наданою критичністю. Досяжність і вибір не змінюються.
source — Порядок джерела · depth — Глибина шляху · criticality — Надана критичність
Типові налаштування: "depth"
include_gaps — Включати прогалини відповідальності й затвердження
Коли ввімкнено, відсутні відповідальні, незатверджені позначки джерела та відсутні досяжні записи документів або тестів створюють явні висновки. Попередження про цикли й межу глибини та примітка перевірки залишаються видимими незалежно від цього налаштування.
Типові налаштування: true
Максимальна кількість вхідних байтів UTF-8: 100000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "change_impact",
"text": "{\"elements\":\"id,name,kind,criticality,approval,owner,description\\nS1,Сервіс замовлень,system,high,approved,Команда платформи,Сервіс перевіряє поля вхідних замовлень.\\nD1,Посібник замовлень,document,medium,draft,Команда документації,Посібник описує обов'язкові поля замовлень.\\nT1,Тест валідації замовлень,test,high,approved,Команда якості,Тест перевіряє відсутні обов'язкові поля замовлень.\",\"dependencies\":\"id,from,to,evidence\\nL1,S1,D1,Посібник документує інтерфейс сервісу замовлень.\\nL2,S1,T1,Тест перевіряє валідацію сервісу замовлень.\",\"changes\":\"id,element,description\\nC1,S1,Додавання обов'язкового посилання на доставку до кожного замовлення.\",\"start_ids\":\"S1\",\"direction\":\"forward\",\"max_depth\":10,\"kind_filter\":\"all\",\"criticality_filter\":\"all\",\"approval_filter\":\"all\",\"baseline\":\"BASE-1\",\"max_items\":10,\"detail\":\"detailed\",\"sort_order\":\"depth\",\"include_gaps\":true}"
}
Побудова придатної для перевірки послідовності відновлення з підтримуваних залежностей процесів і завдань, явних ресурсів, імітацій збоїв та цілей RTO/RPO.
Поля введення та конфігурації
Основні налаштування
processes — Критичні операційні та ІТ-процеси
Заголовки CSV id,name,criticality,rto_minutes,rpo_minutes,backup_at,owner,description. До 20 унікальних ідентифікаторів великими літерами. name та owner: 160 байтів UTF-8; description: 1,200 байтів. criticality: high,medium,low. rto_minutes: ціле число 1–10,080; rpo_minutes: ціле число 0–10,080. backup_at — YYYY-MM-DDTHH:MM:00Z або порожнє значення, яке не може бути пізнішим за reference_time. Відсутній час резервної копії залишається невідомим. Роки 2000–2100. Ліміт CSV: 40,000 байтів UTF-8.
Типові налаштування: ""
dependencies — Підтримувані залежності
Заголовки CSV id,from,to,evidence. from — передумова або попередній елемент; to — залежний або наступний елемент. До 100 унікальних ідентифікаторів і пар ребер для перевірки змін, 50 для відновлення. Обидві кінцеві точки мають існувати. Доказ обов'язковий і обмежений 600 байтами UTF-8. Файл лише із заголовком дійсний; відсутні зовнішні зв'язки не можуть бути виведені. Ліміт CSV: 40,000 байтів UTF-8.
Типові налаштування: ""
tasks — Підтримувані завдання відновлення
Заголовки CSV id,process,sequence,duration_minutes,resource,units,instruction. До 40 унікальних ідентифікаторів завдань. Ідентифікатори процесів і ресурсів мають існувати. sequence: ціле число 1–100, унікальне в межах кожного процесу; duration_minutes: ціле число 1–10,080; units: ціле число 1–100. Інструкції: 1,200 байтів UTF-8. Файл лише із заголовком дійсний і створює блокування через відсутні завдання. Усі завдання кожного зачепленого процесу плануються послідовно; жодне не вигадується й не виконується. Ліміт CSV: 40,000 байтів UTF-8.
Типові налаштування: ""
resources — Ресурси відновлення
Заголовки CSV id,name,capacity. До 20 унікальних ідентифікаторів ресурсів великими літерами. name: 160 байтів UTF-8; capacity: ціле число 1–100 одночасних одиниць. Місткість надана, а не перевірена. Ліміт CSV: 40,000 байтів UTF-8.
Типові налаштування: ""
failed_processes — Ідентифікатори імітованих несправних процесів
Від одного до двадцяти різних наявних ідентифікаторів процесів, розділених пробільними символами або комами. Усі наступні залежні процеси включаються транзитивно. Незачеплені передумови вважаються доступними; відсутні зв'язки залишаються обмеженням доказів.
Типові налаштування: ""
reference_time — Явний опорний час UTC
YYYY-MM-DDTHH:MM:00Z, роки 2000–2100. Це нульова хвилина імітованого збою та опорна точка для віку резервної копії. Секунди мають бути 00. Поточна часова позначка не припускається.
Типові налаштування: "2026-11-03T09:00:00Z"
Розширені налаштування
unavailable_resources — Ідентифікатори імітованих недоступних ресурсів
Від нуля до двадцяти різних наявних ідентифікаторів ресурсів, розділених пробільними символами або комами. Перелічені ресурси мають нульову ефективну місткість. Порожнє значення означає відсутність додаткового імітованого збою ресурсів.
Типові налаштування: ""
horizon_minutes — Горизонт планування у хвилинах
Від однієї до 10,080 хвилин від явного опорного часу. Процес, усі завдання якого не можуть завершитися в межах горизонту, блокується; часткові резервування скасовуються й не подаються як завершене відновлення.
Типові налаштування: 480
priority_order — Пріоритет планування відновлення
Готові процеси вибираються за наданою критичністю, найкоротшим RTO або порядком джерела. Кожен процес чекає на всі зачеплені передумови. Резервування ресурсів використовує детермінований жадібний графік найранішого вміщення; результат не є глобально оптимальним графіком.
criticality — Надана критичність · rto — Найкоротший наданий RTO · source — Порядок джерела
Типові налаштування: "criticality"
capacity_percent — Доступна місткість ресурсів (%)
Ціле число від 1 до 100 зменшує кожну надану місткість ресурсу з округленням вниз до цілих одиниць. Імітовані недоступні ресурси залишаються нульовими. Завдання, яким потрібно більше одиниць, блокуються; місткість ніколи не перевищується мовчки.
Типові налаштування: 100
rto_margin_minutes — Запас безпеки RTO у хвилинах
Від нуля до 1,440 хвилин додається до розрахованого завершення кожного процесу при порівнянні з його ціллю RTO. Цей запас порівняння не резервує ресурсів і не змінює графік завдань.
Типові налаштування: 0
rpo_policy — Політика віку резервної копії
Попередження залишає надані завдання відновлення придатними для планування, водночас позначаючи відсутні або застарілі докази резервної копії. Блокування не допускає планування процесу, якщо вік резервної копії невідомий або перевищує RPO; наступні залежні процеси також блокуються. Часові позначки резервних копій не доводять їх цілісності або фактичної втрати даних.
warn — Попереджати про прогалини резервних копій · block — Блокувати за прогалин резервних копій
Типові налаштування: "warn"
criticality_filter — Фільтр критичності
Фільтрує кандидатів перевірки за явно наданою критичністю. Планування відновлення все одно включає всі зачеплені процеси до цього вибору відображення; залежності низького пріоритету не можуть зникнути з плану.
all — Усі · high — Високий · high_medium — Висока та середня
Типові налаштування: "all"
max_items — Максимум записів для перевірки
ШІ вибирає саме стільки допустимих записів або всі допустимі записи, якщо їх залишилося менше. Повний детермінований аналіз і далі охоплює кожну надану залежність і зачеплений процес. Невибрані записи не засвідчуються як незачеплені чи відновлені.
Типові налаштування: 10
detail — Докладність цитат
Короткі уривки обмежені 120 символами, детальні — 240. Модель отримує вказівку віддавати перевагу уривкам до 80 символів. Кожна цитата має бути точним безперервним уривком мовою початкового джерела.
brief — Коротко · detailed — Докладно
Типові налаштування: "detailed"
sort_order — Порядок відображення
Сортує вибрані рядки процесів за розрахованим часом початку із заблокованими рядками наприкінці або за початковим порядком джерела. Графік відновлення не змінюється.
schedule — Запланований початок · source — Порядок джерела
Типові налаштування: "schedule"
Максимальна кількість вхідних байтів UTF-8: 100000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "recovery_plan",
"text": "{\"processes\":\"id,name,criticality,rto_minutes,rpo_minutes,backup_at,owner,description\\nP1,База даних замовлень,high,60,60,2026-11-03T08:30:00Z,Команда бази даних,Відновлення підтримуваної бази даних замовлень перед перезапуском приймання замовлень.\\nP2,Приймання замовлень,high,120,60,2026-11-03T08:30:00Z,Команда сервісу,Приймання замовлень потребує доступної бази даних замовлень.\",\"dependencies\":\"id,from,to,evidence\\nL1,P1,P2,Приймання замовлень читає та записує базу даних замовлень.\",\"tasks\":\"id,process,sequence,duration_minutes,resource,units,instruction\\nT1,P1,1,30,R1,1,Відновлення затвердженої резервної копії бази даних і запис результату перевірки.\\nT2,P2,1,20,R1,1,Перезапуск підтримуваного сервісу приймання замовлень після перевірки бази даних.\",\"resources\":\"id,name,capacity\\nR1,Оператор відновлення,1\",\"failed_processes\":\"P1\",\"unavailable_resources\":\"\",\"reference_time\":\"2026-11-03T09:00:00Z\",\"horizon_minutes\":480,\"priority_order\":\"criticality\",\"capacity_percent\":100,\"rto_margin_minutes\":0,\"rpo_policy\":\"warn\",\"criticality_filter\":\"all\",\"max_items\":10,\"detail\":\"detailed\",\"sort_order\":\"schedule\"}"
}
Порівнюй артефакти роботи з явними критеріями й рівнями виконання, перевіряй точні цитати-докази та обчислюй бали за наданими оцінками людей.
Поля введення та конфігурації
Основні налаштування
criteria — CSV критеріїв рубрики
Заголовки id,name,weight,definition. До 8 унікальних критеріїв. ID складаються з великих літер, цифр, підкреслень або дефісів, починаються з літери й мають не більше 24 символів. name: 120 байтів UTF-8; definition: 300 байтів. weight — ціле число від 1 до 1000. Приймається не більше 60 пар «доказ — критерій». Кожен CSV обмежено 24 000 байтів UTF-8; потрібні точні заголовки через кому й коректне взяття в лапки за правилами CSV. Посилання, закодовані URL, розмітка й керівні символи відхиляються.
Типові налаштування: ""
levels — CSV рівнів виконання
Заголовки id,criterion,points,descriptor. Від 2 до 4 рівнів на критерій і загалом не більше 32. Кожен ID критерію має існувати. points — ціле число від 0 до 1000, унікальне в межах цього критерію; максимум має бути додатним. descriptor: 300 байтів UTF-8. ID унікальні в усій таблиці рівнів. Кожен CSV обмежено 24 000 байтів UTF-8; потрібні точні заголовки через кому й коректне взяття в лапки за правилами CSV. Посилання, закодовані URL, розмітка й керівні символи відхиляються.
Типові налаштування: ""
evidence — CSV доказів артефакту
Заголовки id,name,text. До 10 артефактів роботи з унікальними ідентифікаторами, назва не більше 120 байтів UTF-8, текст доказу не більше 1 200 байтів. Цей інструмент допомагає перевіряти надані артефакти роботи, а не ухвалювати рішення з наслідками для людей. Кожен CSV обмежено 24 000 байтів UTF-8; потрібні точні заголовки через кому й коректне взяття в лапки за правилами CSV. Посилання, закодовані URL, розмітка й керівні символи відхиляються.
Типові налаштування: ""
ratings — CSV наданих оцінок людей
Заголовки id,evidence,criterion,level. Необов’язкові рядки, до 80; файл лише із заголовком також дійсний. Кожне посилання має існувати, а рівень має належати цьому критерію. Не більше однієї наданої оцінки людини на пару «доказ — критерій». Це вхідні записи, а не схвалення з перевіреною особою. Кожен CSV обмежено 24 000 байтів UTF-8; потрібні точні заголовки через кому й коректне взяття в лапки за правилами CSV. Посилання, закодовані URL, розмітка й керівні символи відхиляються.
Типові налаштування: ""
definitions_approved — Підтвердити надані визначення
Явне підтвердження стосується саме цих визначень критеріїв і рівнів виконання або саме цієї кодової книги. Зміна будь-якого визначення потребує повторного підтвердження. Воно не схвалює результат ШІ.
no — Не підтверджено · yes — Підтверджено для цієї перевірки
Типові налаштування: "no"
version — Підтверджена версія визначень
Обов’язкова мітка версії джерела, не більше 120 байтів UTF-8. Інструмент не отримує й не перевіряє зовнішню версію.
Типові налаштування: "VERSION-1"
Розширені налаштування
detail — Докладність цитат
Короткі цитати обмежені 60 символами, детальні — 120. Кожна цитата має бути точним суцільним уривком джерела. Джерела ніколи не переписуються й не перекладаються.
brief — Коротко · detailed — Докладно
Типові налаштування: "detailed"
sort_order — Порядок результатів
Порядок джерел відповідає першій появі наданого джерела; порядок ідентифікаторів сортує за ID джерела. У межах джерела початковий запропонований порядок критеріїв або кодів залишається незмінним. Сортування не змінює обчислень чи попереджень.
source — Порядок джерела · id — Ідентифікатор джерела
Типові налаштування: "source"
weight_mode — Зважування критеріїв
Надані ваги використовують кожну додатну цілочислову вагу. Однакові ваги використовують вагу 1 для кожного критерію. Бали від людей діляться на максимальні бали наданих рівнів цього критерію, а потім об’єднуються за цими вагами.
missing_rating — Правило для відсутніх оцінок людей
Варіант «неповний» затримує сукупний бал, доки всі критерії не матимуть наданої оцінки людини. Варіант «нуль» явно вважає відсутню оцінку людини нулем і зберігає попередження про відсутню оцінку. Пропозиції ШІ ніколи не входять до сукупного бала.
incomplete — Показати неповний бал · zero — Вважати відсутні оцінки людей нулем
Типові налаштування: "incomplete"
score_scale — Шкала сукупного бала
Ціле число від 1 до 1000. Нормалізований зважений бал від людей множиться на цю шкалу. Це числова шкала відображення, а не оцінка чи прохідний поріг.
Типові налаштування: 100
rounding_digits — Десяткові знаки бала
Від 0 до 4 десяткових знаків. Точна раціональна арифметика округлюється половиною вгору лише для остаточного показу; двійкові бали з рухомою комою не використовуються.
Типові налаштування: 2
level_order — Показаний порядок рівнів виконання
Відсортуй надані дескриптори рівнів кожного критерію за зростанням або спаданням балів. Визначення оцінювання й пропозиція ШІ залишаються незмінними.
ascending — Бали за зростанням · descending — Бали за спаданням
Типові налаштування: "ascending"
Максимальна кількість вхідних байтів UTF-8: 80000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "assessment_rubrics",
"text": "{\"criteria\":\"id,name,weight,definition\\nC1,Простежуваність,2,Твердження пов’язані з ідентифіковними вихідними записами.\\nC2,Зрозумілість,1,Метод та його обмеження вказано явно.\",\"levels\":\"id,criterion,points,descriptor\\nL1,C1,0,Не надано ідентифіковного джерела на підтвердження.\\nL2,C1,2,Основне твердження посилається на ідентифіковний вихідний запис.\\nL3,C2,0,Метод або його обмеження відсутні.\\nL4,C2,2,Метод і щонайменше одне обмеження вказано явно.\",\"evidence\":\"id,name,text\\nE1,Звіт про воркшоп,Висновок використовує запис DATA-7. Метод порівнює дві вибірки й не може встановити причинність.\",\"ratings\":\"id,evidence,criterion,level\\nH1,E1,C1,L2\",\"definitions_approved\":\"yes\",\"version\":\"RUBRIC-1\",\"detail\":\"detailed\",\"sort_order\":\"source\",\"weight_mode\":\"supplied\",\"missing_rating\":\"incomplete\",\"score_scale\":100,\"rounding_digits\":2,\"level_order\":\"ascending\"}"
}
Перевіряй надані анотації за явними критеріями включення й виключення, зберігай цитати-докази та показуй розбіжності рецензентів до відбору.
Поля введення та конфігурації
Основні налаштування
records — CSV наданих записів публікацій
Заголовки id,title,year,language,text. До 15 унікальних записів; title: 200 байтів UTF-8; text: 1 200 байтів. year — 1900–2100. language — точний дво- або трилітерний тег малими літерами з необов’язковим регіоном великими літерами. Надай анотацію або обмежений уривок повного тексту; жодна публікація не завантажується. Кожен CSV обмежено 24 000 байтів UTF-8; потрібні точні заголовки через кому й коректне взяття в лапки за правилами CSV. Посилання, закодовані URL, розмітка й керівні символи відхиляються.
Типові налаштування: ""
criteria — CSV критеріїв скринінгу
Заголовки id,kind,definition. До 8 унікальних критеріїв. kind — include або exclude; definition: 300 байтів UTF-8. Приймається не більше 60 пар «запис — критерій». Кожен критерій перевіряється для кожного наданого запису. Кожен CSV обмежено 24 000 байтів UTF-8; потрібні точні заголовки через кому й коректне взяття в лапки за правилами CSV. Посилання, закодовані URL, розмітка й керівні символи відхиляються.
Типові налаштування: ""
reviews — CSV наданих перевірок людьми
Заголовки id,record,reviewer,decision,note. Необов’язкові рядки, до 30; файл лише із заголовком також дійсний. record має існувати; reviewer — ID великими літерами. decision — include, exclude або unclear. note: 300 байтів UTF-8, може бути порожнім. Не більше двох окремих рецензентів на запис і один рядок на пару «рецензент — запис». Особи рецензентів — це мітки, а не перевірені облікові записи. Кожен CSV обмежено 24 000 байтів UTF-8; потрібні точні заголовки через кому й коректне взяття в лапки за правилами CSV. Посилання, закодовані URL, розмітка й керівні символи відхиляються.
Типові налаштування: ""
definitions_approved — Підтвердити надані визначення
Явне підтвердження стосується саме цих визначень критеріїв і рівнів виконання або саме цієї кодової книги. Зміна будь-якого визначення потребує повторного підтвердження. Воно не схвалює результат ШІ.
no — Не підтверджено · yes — Підтверджено для цієї перевірки
Типові налаштування: "no"
version — Підтверджена версія визначень
Обов’язкова мітка версії джерела, не більше 120 байтів UTF-8. Інструмент не отримує й не перевіряє зовнішню версію.
Типові налаштування: "VERSION-1"
Розширені налаштування
detail — Докладність цитат
Короткі цитати обмежені 60 символами, детальні — 120. Кожна цитата має бути точним суцільним уривком джерела. Джерела ніколи не переписуються й не перекладаються.
brief — Коротко · detailed — Докладно
Типові налаштування: "detailed"
sort_order — Порядок результатів
Порядок джерел відповідає першій появі наданого джерела; порядок ідентифікаторів сортує за ID джерела. У межах джерела початковий запропонований порядок критеріїв або кодів залишається незмінним. Сортування не змінює обчислень чи попереджень.
source — Порядок джерела · id — Ідентифікатор джерела
Типові налаштування: "source"
year_from — Перший рік публікації
Нижня межа включно від 1900 до 2100. Записи поза діапазоном залишаються в результаті з явною позначкою.
Типові налаштування: 2000
year_to — Останній рік публікації
Верхня межа включно від 1900 до 2100; не може передувати нижній межі. Рік не виводиться з тексту джерела.
Типові налаштування: 2100
languages — Дозволені надані мовні теги
Необов’язковий список до 12 точних тегів через кому, наприклад en,de,pl. Теги складаються з двох або трьох малих літер із необов’язковим регіоном великими літерами, наприклад en-GB. Порожнє поле вимикає цю перевірку метаданих. Переклад або визначення мови не виконуються.
Типові налаштування: ""
reviewer_policy — Потрібні рецензенти-люди
Вимагай одного або двох окремих наданих рецензентів на запис. Відсутні рецензенти, розбіжності й неясні рішення позначаються незалежно від пропозицій ШІ щодо критеріїв.
one — Один рецензент-людина · two — Два рецензенти-людини
Типові налаштування: "two"
duplicate_policy — Перевірка дублікатів назв
Варіант із позначкою порівнює назви після обрізання, нормалізації пробілів і перетворення в нижній регістр Unicode. Варіант пропуску вимикає лише цю евристику дублікатів назв. Жоден запис не вилучається й не об’єднується.
flag — Позначити для перевірки · ignore — Пропускати позначки дублікатів назв
Типові налаштування: "flag"
screening_stage — Заявлений обсяг наданих доказів
Розрізняє в запиті до моделі та у звіті надані матеріали назви й анотації та надані уривки повного тексту. Жодне з налаштувань не завантажує публікацію й не встановлює, що уривок повний.
title_abstract — Надані назва й анотація · supplied_full_text — Наданий уривок повного тексту
Типові налаштування: "title_abstract"
Максимальна кількість вхідних байтів UTF-8: 80000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "literature_screening",
"text": "{\"records\":\"id,title,year,language,text\\nR1,Порівняння навчання на воркшопі,2024,en,Дослідження порівнює дві навчальні групи дорослих учасників. Розподіл не був рандомізований.\\nR2,Порівняння навчання на воркшопі,2023,en,Звіт описує одну навчальну групу без групи порівняння.\",\"criteria\":\"id,kind,definition\\nC1,include,Описано групу порівняння.\\nC2,exclude,Учасники — діти.\",\"reviews\":\"id,record,reviewer,decision,note\\nV1,R1,REVIEWER1,include,Групу порівняння описано.\\nV2,R1,REVIEWER2,unclear,Перевір відповідність порівняння протоколу.\",\"definitions_approved\":\"yes\",\"version\":\"PROTOCOL-1\",\"detail\":\"detailed\",\"sort_order\":\"source\",\"year_from\":2020,\"year_to\":2026,\"languages\":\"en\",\"reviewer_policy\":\"two\",\"duplicate_policy\":\"flag\",\"screening_stage\":\"title_abstract\"}"
}
Призначай надані коди сегментам інтерв’ю з точними цитатами, перевіряй незакодовані уривки й суперечливі пропозиції та рахуй сегменти або інтерв’ю.
Поля введення та конфігурації
Основні налаштування
segments — CSV сегментів інтерв’ю
Заголовки id,interview,speaker,text. До 20 унікальних сегментів. interview — ID великими літерами; speaker — надана мітка не більше 80 байтів UTF-8; text: 1 200 байтів. Усі ID починаються з літери й складаються з великих літер, цифр, підкреслень або дефісів, не більше 24 символів. За потреби використовуй псевдонімні мітки. Кожен CSV обмежено 24 000 байтів UTF-8; потрібні точні заголовки через кому й коректне взяття в лапки за правилами CSV. Посилання, закодовані URL, розмітка й керівні символи відхиляються.
Типові налаштування: ""
codebook — CSV підтвердженої кодової книги
Заголовки id,name,definition,exclusion,group. До 12 унікальних ID кодів. name: 120 байтів UTF-8; definition та exclusion: по 300 байтів. exclusion може бути порожнім. Непорожній ID групи group великими літерами позначає взаємовиключні коди. Порожній group означає відсутність групи виключення. Кодова книга визначає межі інтерпретації; новий код не вигадується. Кожен CSV обмежено 24 000 байтів UTF-8; потрібні точні заголовки через кому й коректне взяття в лапки за правилами CSV. Посилання, закодовані URL, розмітка й керівні символи відхиляються.
Типові налаштування: ""
definitions_approved — Підтвердити надані визначення
Явне підтвердження стосується саме цих визначень критеріїв і рівнів виконання або саме цієї кодової книги. Зміна будь-якого визначення потребує повторного підтвердження. Воно не схвалює результат ШІ.
no — Не підтверджено · yes — Підтверджено для цієї перевірки
Типові налаштування: "no"
version — Підтверджена версія визначень
Обов’язкова мітка версії джерела, не більше 120 байтів UTF-8. Інструмент не отримує й не перевіряє зовнішню версію.
Типові налаштування: "VERSION-1"
Розширені налаштування
detail — Докладність цитат
Короткі цитати обмежені 60 символами, детальні — 120. Кожна цитата має бути точним суцільним уривком джерела. Джерела ніколи не переписуються й не перекладаються.
brief — Коротко · detailed — Докладно
Типові налаштування: "detailed"
sort_order — Порядок результатів
Порядок джерел відповідає першій появі наданого джерела; порядок ідентифікаторів сортує за ID джерела. У межах джерела початковий запропонований порядок критеріїв або кодів залишається незмінним. Сортування не змінює обчислень чи попереджень.
source — Порядок джерела · id — Ідентифікатор джерела
Типові налаштування: "source"
coding_mode — Режим кодування
Варіант з одним кодом дозволяє щонайбільше один запропонований код на сегмент і вимагає, щоб максимальна кількість кодів дорівнювала 1. Варіант із кількома кодами дозволяє кілька окремих наданих кодів у межах налаштованого максимуму.
single — Один код на сегмент · multiple — Кілька кодів на сегмент
Типові налаштування: "multiple"
max_codes — Максимум кодів на сегмент
Ціле число від 1 до 3. Кожен запропонований код потребує власної точної цитати з цього сегмента. Повторювані коди відхиляються; порожні масиви кодів залишаються явно незакодованими.
Типові налаштування: 3
speaker_filter — Точний фільтр мовця
Необов’язкова точна надана мітка мовця, до 80 байтів UTF-8. Висновки про особу не робляться. Кількість виключених сегментів залишається видимою.
Типові налаштування: ""
interview_filter — Точний фільтр інтерв’ю
Необов’язковий наявний ID інтерв’ю. Обидва фільтри поєднуються; порожній підсумковий вибір відхиляється. Жоден виключений сегмент не надсилається моделі.
Типові налаштування: ""
minimum_count — Поріг перевірки низької частоти
Ціле число від 1 до 20, що застосовується до вибраної одиниці підрахунку. Коди нижче порога позначаються, зокрема невикористані; жоден рядок не приховується.
Типові налаштування: 2
count_mode — Одиниця частоти кодів
Варіант «сегменти» рахує кожен сегмент щонайбільше один раз на код. Варіант «інтерв’ю» рахує кожен наданий ID інтерв’ю щонайбільше один раз на код, навіть якщо збігається кілька сегментів. Жоден підрахунок не є оцінкою сукупності.
segments — Окремі сегменти · interviews — Окремі інтерв’ю
Типові налаштування: "segments"
uncoded_policy — Обробка незакодованих сегментів
Варіант із позначкою додає зауваження для перевірки до незакодованих сегментів. Варіант зі звітом зберігає незакодовані рядки результату без цього додаткового зауваження. Цитати чи коди на підтвердження ніколи не вигадуються.
flag — Позначити для перевірки · report — Показувати незакодовані рядки без додаткової позначки
Типові налаштування: "flag"
Максимальна кількість вхідних байтів UTF-8: 80000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "interview_coding",
"text": "{\"segments\":\"id,interview,speaker,text\\nS1,I1,Учасник A,Контрольний список передавання допоміг мені знайти відсутні файли.\\nS2,I1,Учасник A,Мені все ще потрібен був колега для пояснення кроку схвалення.\\nS3,I2,Учасник B,Процес відбувається щопонеділка.\",\"codebook\":\"id,name,definition,exclusion,group\\nC1,Корисні вказівки,Явний опис корисних для завершення роботи вказівок.,Нейтральна згадка без повідомленої допомоги.,\\nC2,Неясне схвалення,Явна потреба в роз’ясненні процедури схвалення.,Твердження про вже зрозуміле схвалення.,APPROVAL\\nC3,Зрозуміле схвалення,Явне твердження про зрозумілість процедури схвалення.,Прохання допомогти зрозуміти схвалення.,APPROVAL\",\"definitions_approved\":\"yes\",\"version\":\"CODEBOOK-1\",\"detail\":\"detailed\",\"sort_order\":\"source\",\"coding_mode\":\"multiple\",\"max_codes\":3,\"speaker_filter\":\"\",\"interview_filter\":\"\",\"minimum_count\":2,\"count_mode\":\"segments\",\"uncoded_policy\":\"flag\"}"
}
Масштабуй кількості за рецептом, застосовуй явні виходи, об’єднуй еквівалентні інгредієнти й обчислюй цілі упаковки з перевірним слідом джерел.
Поля введення та конфігурації
Основні налаштування
ingredients — Інгредієнти рецепта
До 30 рядків. ingredient_key позначає явно еквівалентний інгредієнт; назви не створюють еквівалентності. quantity та pack_size використовують одиницю рядка. yield_percent — відсоток, що залишається після наданого припущення про втрати. Порожній pack_size залишає закупівлю невизначеною. Примітки обмежено 160 байтами UTF-8.
base_portions — Базові порції
Додатне десяткове число до 10000; кількість порцій, яку представляє початковий рецепт.
Типові налаштування: "4"
target_portions — Цільові порції
Додатне десяткове число до 10000; використовується лише в режимі співвідношення порцій.
Типові налаштування: "8"
Розширені налаштування
scaling_mode — Спосіб масштабування
Використовуй цільові порції, поділені на базові, або явно заданий коефіцієнт. Обидва поля введення залишаються під суворою перевіркою.
portions — Співвідношення порцій · factor — Явний коефіцієнт
Типові налаштування: "portions"
scale_factor — Явний коефіцієнт масштабування
Додатне десяткове число до 100; використовується лише в режимі явного коефіцієнта.
Типові налаштування: "2"
apply_yield — Застосувати надані виходи
Поділи масштабовану кількість нетто на надану частку виходу кожного рядка. Вимкнений режим вважає надану кількість потрібною кількістю до запасу.
yes — Увімкнено · no — Вимкнено
Типові налаштування: "yes"
reserve_percent — Відсоток запасу
Невід’ємне десяткове число від 0 до 100, що застосовується до обчисленої потреби в матеріалі перед округленням до упаковок.
Типові налаштування: "0"
aggregation — Об’єднання інгредієнтів
Об’єднуй лише однакові значення ingredient_key із сумісними вимірами або залишай кожен вихідний рядок окремим. Різні виміри маси й об’єму під одним об’єднаним ключем відхиляються.
ingredient — Об’єднати збіжні ключі інгредієнтів · source — Порядок джерела
Типові налаштування: "ingredient"
unit_display — Показані одиниці кількості
Використовуй базові одиниці маси й об’єму або перетвори їх на kg і L. Штучні кількості залишаються в pcs.
base — g, ml і pcs · large — kg, L і pcs
Типові налаштування: "base"
purchase_packs — Обчислити цілі упаковки
Округли точну потребу вгору до цілих наданих упаковок. Відсутні або суперечливі розміри упаковок залишаються видимими; закупівля не здійснюється.
yes — Увімкнено · no — Вимкнено
Типові налаштування: "yes"
rounding_digits — Відображувані десяткові знаки
Показуй від нуля до шести десяткових знаків. Точні порівняння й округлення до цілих упаковок використовують неокруглені значення.
Типові налаштування: 3
rounding_mode — Округлення показу
Округлюй значення рівно посередині вгору або завжди округлюй додатний залишок угору. Це впливає лише на показ.
half_up — Округлювати половину вгору · up — Округлювати вгору
Типові налаштування: "half_up"
sort_order — Порядок результатів
Зберігай порядок джерела або став першими рядки з прогалинами в обчисленнях і застереженнями перевірки ШІ.
source — Порядок джерела · issues_first — Спочатку застереження для перевірки
Типові налаштування: "source"
include_evidence — Показувати точні примітки з джерела
Додавай точні примітки з джерела до таблиці й експорту або залишай лише ідентифікатори записів. Перевірка джерел завжди залишається активною.
yes — Увімкнено · no — Вимкнено
Типові налаштування: "yes"
Максимальна кількість вхідних байтів UTF-8: 160000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "recipe_scaling",
"text": "{\"ingredients\":\"id,ingredient_key,name,quantity,unit,yield_percent,pack_size,note\\nI1,FLOUR,Борошно,0.5,kg,100,1,Не змінюй тип борошна.\\nI2,CARROT,Морква,300,g,80,500,Вихід ураховує наданий припуск на обрізання.\\nI3,FLOUR,Борошно для посипання,100,g,100,1000,Запас борошна спільний з I1.\",\"base_portions\":\"4\",\"target_portions\":\"10\",\"scaling_mode\":\"portions\",\"scale_factor\":\"2\",\"apply_yield\":\"yes\",\"reserve_percent\":\"10\",\"aggregation\":\"ingredient\",\"unit_display\":\"base\",\"purchase_packs\":\"yes\",\"rounding_digits\":3,\"rounding_mode\":\"half_up\",\"sort_order\":\"source\",\"include_evidence\":\"yes\"}"
}
Перетвори обміри прямокутних приміщень на кількості поверхонь і потребу в матеріалах за наданою покривністю, шарами, запасом і розмірами упаковок.
Поля введення та конфігурації
Основні налаштування
rooms — Обміри приміщень
До 20 прямокутних приміщень. Кожен рядок призначає один наданий продукт його цільовій поверхні. Усі розміри використовують вибрану спільну одиницю. Для іншої поверхні чи продукту потрібен окремий рядок.
openings — Обміри прорізів
До 40 прорізів, пов’язаних із room_id. Ширина × висота × кількість вираховується лише зі стін, якщо вирахування ввімкнено. CSV лише із заголовком означає відсутність прорізів. Геометрія й перекриття прорізів не виводяться.
products — Визначення покривності продуктів
До 20 продуктів. target — floor, ceiling або walls; coverage — m² на L або kg на шар. unit — L або kg. Порожній pack_size залишає закупівлю невизначеною. Усі норми є наданими припущеннями, а не отриманими специфікаціями.
dimension_unit — Одиниця вимірювання
Послідовно застосовуй m, cm або mm до кожного розміру приміщень і прорізів. Результати використовують m і m².
m — m · cm — cm · mm — mm
Типові налаштування: "m"
Розширені налаштування
opening_policy — Вирахування прорізів
Віднімай прямокутники пов’язаних прорізів від площі стін або залишай площу брутто. Обчислення підлоги й стелі прорізів не вираховують.
subtract — Віднімати від стін · ignore — Залишати площу стін брутто
Типові налаштування: "subtract"
reserve_percent — Відсоток запасу
Невід’ємне десяткове число від 0 до 100, що застосовується до обчисленої потреби в матеріалі перед округленням до упаковок.
Типові налаштування: "10"
coats_mode — Джерело кількості шарів
Використовуй надану кількість шарів кожного продукту або одну явно задану спільну кількість шарів.
product — Об’єднувати за продуктом · global — Спільна кількість шарів
Типові налаштування: "product"
coats — Спільна кількість шарів
Ціле число від 1 до 10, що використовується, лише якщо вибрано джерело спільної кількості шарів.
Типові налаштування: 2
purchase_packs — Обчислити цілі упаковки
Округли точну потребу вгору до цілих наданих упаковок. Відсутні або суперечливі розміри упаковок залишаються видимими; закупівля не здійснюється.
yes — Увімкнено · no — Вимкнено
Типові налаштування: "yes"
pack_scope — Обсяг округлення до упаковок
Об’єднуй потреби кожного продукту перед округленням до цілих упаковок або округлюй кожне приміщення окремо. Запаси автоматично не вираховуються.
product — Об’єднувати за продуктом · room — Округлювати кожне приміщення окремо
Типові налаштування: "product"
rounding_digits — Відображувані десяткові знаки
Показуй від нуля до шести десяткових знаків. Точні порівняння й округлення до цілих упаковок використовують неокруглені значення.
Типові налаштування: 3
rounding_mode — Округлення показу
Округлюй значення рівно посередині вгору або завжди округлюй додатний залишок угору. Це впливає лише на показ.
half_up — Округлювати половину вгору · up — Округлювати вгору
Типові налаштування: "half_up"
sort_order — Порядок результатів
Зберігай порядок джерела або став першими рядки з прогалинами в обчисленнях і застереженнями перевірки ШІ.
source — Порядок джерела · issues_first — Спочатку застереження для перевірки
Типові налаштування: "source"
include_evidence — Показувати точні примітки з джерела
Додавай точні примітки з джерела до таблиці й експорту або залишай лише ідентифікатори записів. Перевірка джерел завжди залишається активною.
yes — Увімкнено · no — Вимкнено
Типові налаштування: "yes"
Максимальна кількість вхідних байтів UTF-8: 160000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "room_quantities",
"text": "{\"rooms\":\"id,name,length,width,height,product_id,note\\nR1,Майстерня,5,4,2.5,P1,Перевір обміри стін перед замовленням.\\nR2,Комора,3,2,2.5,P1,Використовуй те саме надане покриття для стін.\",\"openings\":\"id,room_id,width,height,quantity,note\\nO1,R1,1,2,1,Дверний проріз.\\nO2,R1,1.5,1,2,Два вікна.\",\"products\":\"id,name,target,coverage,unit,pack_size,coats,note\\nP1,Покриття для стін,walls,10,L,5,2,Покривність є наданим плановим значенням на шар.\",\"dimension_unit\":\"m\",\"opening_policy\":\"subtract\",\"reserve_percent\":\"10\",\"coats_mode\":\"product\",\"coats\":2,\"purchase_packs\":\"yes\",\"pack_scope\":\"product\",\"rounding_digits\":3,\"rounding_mode\":\"half_up\",\"sort_order\":\"source\",\"include_evidence\":\"yes\"}"
}
Обчислюй місткість прямокутних посадок і перевіряй конфлікти зайнятості, інтервали родин та відсутню історію, не вигадуючи правил вирощування.
Поля введення та конфігурації
Основні налаштування
beds — Виміряні грядки
До 20 прямокутних грядок. Кожен рядок має власну одиницю m, cm або mm. Для перевірки конфліктів посадка займає всю вказану грядку.
plantings — Заплановані культури
До 30 посадок із датами початку й завершення включно. family — явно заданий ключ великими літерами, а не ботанічна класифікація, виведена з назви культури. Відстань використовує вибрану спільну одиницю відстані.
history — Зафіксовані попередні культури
До 40 історичних записів із датами включно. CSV лише із заголовком дозволено. Записи перевіряються на перекриття й інтервали тієї самої родини; відсутню зовнішню історію неможливо відновити.
rules — Надані інтервали родин
До 20 унікальних правил родин. break_days — ціле число від 0 до 3650, що рахує повні вільні дні. CSV лише із заголовком дозволено; відсутні правила залишаються видимими в режимі явних правил.
Розширені налаштування
spacing_unit — Одиниця відстані й крайового відступу
Застосовуй m, cm або mm до відстані між рослинами, між рядами й до спільного крайового відступу. Розміри грядок зберігають власні явно надані одиниці.
m — m · cm — cm · mm — mm
Типові налаштування: "cm"
edge_margin — Крайовий відступ із кожного боку
Невід’ємне десяткове число до 10000 в одиниці відстані. Подвійний відступ вираховується з обох розмірів грядки перед підрахунком місць.
Типові налаштування: "0"
path_percent — Плановий припуск на доріжки
Невід’ємне десяткове число від 0 до 100. Зменши кількість у прямокутній сітці на цей відсоток і округли вниз. Це сукупний припуск, а не геометричне розташування доріжок.
Типові налаштування: "0"
rotation_mode — Джерело правил сівозміни
Використовуй явні правила для кожної родини або наданий спільний інтервал. Агрономічний інтервал автоматично не виводиться.
rules — Явні правила родин · default — Наданий спільний інтервал
Типові налаштування: "rules"
default_break_days — Спільний інтервал вільних днів
Ціле число від 0 до 3650, що використовується лише в режимі спільного інтервалу. Інтервал застосовується до того самого наданого ключа родини.
Типові налаштування: 365
overlap_policy — Кількості під час конфліктів зайнятості
Зберігай чернеткові місткості з явними попередженнями про перекриття або встановлюй кількості для відповідних посадок на нуль. Перекриття з наданою історією також ураховуються.
flag — Позначати конфлікти й зберігати чернеткові кількості · block_count — Приховувати кількості для посадок, що перекриваються
Типові налаштування: "flag"
history_status — Заява про історичне охоплення
Укажи, чи надані історичні записи повні для запланованої перевірки. Ця заява не перевіряє зовнішні записи.
complete — Заявлено як повну · incomplete — Заявлено як неповну
Типові налаштування: "incomplete"
date_from — Початок інтервалу показу
Необов’язкова дата YYYY-MM-DD від 2000 до 2100 включно. Включає посадки, що перекриваються з інтервалом показу; усі надані записи й далі беруть участь у перевірці конфліктів.
Типові налаштування: ""
date_to — Кінець інтервалу показу
Необов’язкова кінцева дата YYYY-MM-DD включно, від 2000 до 2100 включно. Порожнє поле означає відсутність верхньої межі показу.
Типові налаштування: ""
rounding_digits — Відображувані десяткові знаки
Показуй від нуля до шести десяткових знаків. Точні порівняння й округлення до цілих упаковок використовують неокруглені значення.
Типові налаштування: 3
sort_order — Порядок результатів
Зберігай порядок джерела або став першими рядки з прогалинами в обчисленнях і застереженнями перевірки ШІ.
source — Порядок джерела · issues_first — Спочатку застереження для перевірки
Типові налаштування: "source"
include_evidence — Показувати точні примітки з джерела
Додавай точні примітки з джерела до таблиці й експорту або залишай лише ідентифікатори записів. Перевірка джерел завжди залишається активною.
yes — Увімкнено · no — Вимкнено
Типові налаштування: "yes"
Максимальна кількість вхідних байтів UTF-8: 160000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "crop_planning",
"text": "{\"beds\":\"id,name,length,width,unit,note\\nB1,Північна грядка,4,1.2,m,Виміряна прямокутна грядка.\\nB2,Південна грядка,3,1,m,Окрема ділянка для посадки.\",\"plantings\":\"id,bed_id,crop,family,start,end,row_spacing,plant_spacing,note\\nC1,B1,Морква,APIACEAE,2027-03-01,2027-06-30,30,10,Перевір надану відстань між рядами.\\nC2,B1,Буряк,AMARANTHACEAE,2027-06-15,2027-09-30,30,15,Заплановані дати перекриваються з попередньою культурою.\\nC3,B2,Горох,FABACEAE,2027-03-01,2027-06-01,40,10,Перевір наявну історію.\",\"history\":\"id,bed_id,family,start,end,note\\nH1,B1,APIACEAE,2026-03-01,2026-08-31,Зафіксована попередня культура.\",\"rules\":\"id,family,break_days,note\\nT1,APIACEAE,365,Явно наданий інтервал.\\nT2,AMARANTHACEAE,180,Явно наданий інтервал.\",\"spacing_unit\":\"cm\",\"edge_margin\":\"0\",\"path_percent\":\"10\",\"rotation_mode\":\"rules\",\"default_break_days\":365,\"overlap_policy\":\"flag\",\"history_status\":\"incomplete\",\"date_from\":\"\",\"date_to\":\"\",\"rounding_digits\":3,\"sort_order\":\"source\",\"include_evidence\":\"yes\"}"
}
Порівнюй заявлені стани сцен із підтримуваними правилами безперервності та перевіряй точні докази сюжету з окремою оцінкою підтвердження від ШІ.
Поля введення та конфігурації
Основні налаштування
scenes — Сцени
Стовпці CSV id,day,order,text. До 40 сцен; day та order — цілі числа 1–999, а кожна пара day/order має бути унікальною. Текст сцени обмежено 1200 байтами UTF-8.
Типові налаштування: ""
states — Заявлені стани безперервності
Стовпці CSV id,scene,entity,kind,state,quote. До 20 записів стану. kind — role, prop або costume. Кожен quote має бути точним уривком указаної сцени, не більше 240 байтів UTF-8. Один запис на сцену, сутність і тип. Рівність станів використовує точний текст, зокрема написання й регістр.
Типові налаштування: ""
rules — Підтримувані правила безперервності
Стовпці CSV id,entity,kind,scope,policy,description. До 20 правил. scope — same_day або whole_story; policy — constant або track. Entity та kind мають точно збігатися. Описи обмежено 240 байтами UTF-8.
Типові налаштування: ""
Розширені налаштування
day_from — Перший день історії
Нижня межа дня історії включно. Перевіряються лише вибрані записи стану.
Типові налаштування: 1
day_to — Останній день історії
Верхня межа дня історії включно, не раніше за перший день історії.
Типові налаштування: 999
kind_filter — Категорія безперервності
Обмеж докази станів однією підтримуваною категорією.
all — Усі · role — Роль · prop — Реквізит · costume — Костюм
Типові налаштування: "all"
entity_filter — Точний фільтр сутності
Необов’язкова точна назва сутності. Порожнє поле включає всі сутності; написання й регістр мають збігатися з підтримуваними записами.
Типові налаштування: ""
rule_filter — Політика правила
Варіант «сталий стан» позначає заявлені зміни стану; варіант «відстеження» документує зміни, не вважаючи їх конфліктами. Фільтрування змінює набір застосовних правил.
all — Усі · constant — Потрібен сталий стан · track — Відстежувати зміни
Типові налаштування: "all"
sort_order — Порядок доказів
Упорядковуй докази станів хронологічно або за точною назвою сутності. Порівняння правил зберігають підтримуваний порядок правил і сцен.
chronology — Хронологія історії · entity — Сутність
Типові налаштування: "chronology"
show_consistent — Показувати незмінені порівняння
Додавай порівняння, у яких заявлений стан залишається однаковим. Приховані незмінені порівняння рахуються явно; докази з джерела завжди залишаються видимими.
Типові налаштування: true
include_gaps — Виявляти відсутні правила
Додавай висновок для вибраних записів стану без застосовного підтримуваного правила.
Типові налаштування: true
detail — Довжина доказів ШІ
Короткі уривки обмежені 120 символами, детальні — 240. Точна мова джерела зберігається. Дуже великі вхідні дані все одно можуть бути відхилені.
brief — Короткі докази · detailed — Докладні докази
Типові налаштування: "brief"
baseline — Базова версія сценарію
Надана мітка версії чи редакції, що показується в кожному рядку доказу й порівняння.
Типові налаштування: "V1"
Максимальна кількість вхідних байтів UTF-8: 90000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "script_continuity",
"text": "{\"scenes\":\"id,day,order,text\\nS1,1,1,Мара носить червоне пальто й тримає латунний ключ.\\nS2,1,2,Мара носить синє пальто й тримає латунний ключ.\",\"states\":\"id,scene,entity,kind,state,quote\\nE1,S1,Мара,costume,червоне пальто,Мара носить червоне пальто\\nE2,S2,Мара,costume,синє пальто,Мара носить синє пальто\",\"rules\":\"id,entity,kind,scope,policy,description\\nR1,Мара,costume,same_day,constant,Пальто залишається незмінним протягом того самого дня історії.\",\"day_from\":1,\"day_to\":999,\"kind_filter\":\"all\",\"entity_filter\":\"\",\"rule_filter\":\"all\",\"sort_order\":\"chronology\",\"show_consistent\":true,\"include_gaps\":true,\"detail\":\"brief\",\"baseline\":\"V1\"}"
}
Створи повну обмежену неклінічну матрицю прогонів із підтримуваних факторів і рівнів, із порядком за зерном і прив’язаною до джерела перевіркою ШІ.
Поля введення та конфігурації
Основні налаштування
factors — Фактори та призначення
Стовпці CSV id,name,purpose. Від 1 до 6 факторів. Назви: 120 байтів UTF-8; purpose: 600. ШІ класифікує лише надане призначення й цитує точний уривок.
Типові налаштування: ""
levels — Підтримувані рівні факторів
Стовпці CSV id,factor,value. Кожен фактор потребує 2–6 різних значень і дійсних ID рівнів. До 36 рівнів; кожне значення не більше 120 байтів UTF-8. Значення, схожі на числа, залишаються буквальними мітками й ніколи не перетворюються на вимірювання.
Типові налаштування: ""
combinations — Явно дозволені комбінації
Використовується лише в режимі allowed_combinations. CSV починається з id, далі йде кожен ID фактора у вибраному порядку факторів. Кожна клітинка містить ID рівня, що належить цьому фактору. Дублікати комбінацій відхиляються. Для full_factorial залиш порожнім.
Типові налаштування: ""
design_mode — Режим комбінацій
Повний факторний режим перелічує кожну комбінацію підтримуваних рівнів. Явний режим включає лише надані дозволені комбінації. Жоден режим не виводить безпечності чи здійсненності.
full_factorial — Повний факторний план · allowed_combinations — Явно дозволені комбінації
Типові налаштування: "full_factorial"
objective — Підтримувана мета
Надана неклінічна мета, що використовується як контекст для прив’язаної до джерела перевірки факторів і показується в результаті без змін. Вона не може дозволити нові рівні чи експерименти.
Типові налаштування: ""
Розширені налаштування
replicates — Повторення на комбінацію
Повторюй кожну включену комбінацію однаково. Повторення не встановлює статистичної потужності чи незалежності.
Типові налаштування: 2
block_size — Прогони на блок
Послідовні прогони групуються в блоки такого розміру; останній блок може бути коротшим. Це групи для планування, а не виведені наукові блокові фактори.
Типові налаштування: 4
randomization — Порядок прогонів
Варіант без рандомізації зберігає згенерований порядок. Варіант у межах блоків перемішує лише всередині початкових блоків. Глобальний варіант перемішує всі прогони перед розподілом на блоки. Версійоване ранжування SHA256 і зерно дають відтворюваний порядок.
none — Без рандомізації · within_blocks — Рандомізувати в межах блоків · global — Рандомізувати глобально
Типові налаштування: "within_blocks"
seed — Зерно відтворюваності
Ціле число 0–2147483647. Ті самі повні вхідні дані й алгоритм упорядкування дають ту саму матрицю. Це зерно не є механізмом безпеки.
Типові налаштування: 42
run_limit — Максимальна повна кількість прогонів
Відхиляй увесь план, якщо комбінації, помножені на повторення, перевищують цей ліміт. Випадкова підмножина чи непомітне скорочення не створюються.
Типові налаштування: 180
factor_order — Порядок факторів
Зберігай порядок факторів із CSV або сортуй за ID фактора. Заголовки явних комбінацій мають відповідати цьому вибраному порядку.
source — Порядок джерела · id — Порядок ID
Типові налаштування: "source"
level_order — Порядок рівнів
Зберігай порядок рівнів із CSV у межах кожного фактора або сортуй за ID рівня. Це змінює перелік повного факторного плану й може змінити належність до блоків.
source — Порядок джерела · id — Порядок ID
Типові налаштування: "source"
replicate_order — Порядок повторень
Згрупований варіант розміщує повторення кожної комбінації разом. Перемежований варіант проходить усі комбінації один раз на повторення перед рандомізацією.
grouped — Групувати за комбінацією · interleaved — Перемежовувати повторення
Типові налаштування: "interleaved"
domain — Неклінічна сфера роботи
Підтримуваний обсяг — неклінічна робота з процесами, матеріалами, програмним забезпеченням або в освіті. Інструмент не встановлює безпечності, дозволів чи придатності для експериментів на людях.
manufacturing — Виробництво · materials — Матеріали · software — Програмне забезпечення · education — Освіта
Типові налаштування: "manufacturing"
design_name — Посилання на план
Надане посилання, що показується з усіма прогонами й перевірками факторів.
Типові налаштування: "DESIGN1"
detail — Довжина доказів ШІ
Короткі уривки обмежені 120 символами, детальні — 240. Точна мова джерела зберігається. Дуже великі вхідні дані все одно можуть бути відхилені.
brief — Короткі докази · detailed — Докладні докази
Типові налаштування: "brief"
Максимальна кількість вхідних байтів UTF-8: 90000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "experiment_design",
"text": "{\"factors\":\"id,name,purpose\\nF1,Швидкість друку,Порівняй налаштування швидкості друку за видимою якістю країв.\\nF2,Налаштування охолодження,Порівняй контрольовані налаштування охолодження під час перевірки якості друку.\",\"levels\":\"id,factor,value\\nL1,F1,Повільно\\nL2,F1,Швидко\\nL3,F2,Низьке\\nL4,F2,Високе\",\"combinations\":\"\",\"design_mode\":\"full_factorial\",\"replicates\":2,\"block_size\":4,\"randomization\":\"within_blocks\",\"seed\":42,\"run_limit\":180,\"factor_order\":\"source\",\"level_order\":\"source\",\"replicate_order\":\"interleaved\",\"domain\":\"manufacturing\",\"objective\":\"Порівняй підтримувані налаштування принтера на неклінічних зразках деталей.\",\"design_name\":\"DESIGN1\",\"detail\":\"brief\"}"
}
Напишіть прес-реліз на основі наданих фактів, зберігаючи затверджені цитати дослівно та не вигадуючи жодних цифр.
Поля введення та конфігурації
Основні налаштування
facts — Факти
Що сталося, хто бере участь, чому це важливо. Достатньо простих нотаток.
Типові налаштування: ""
organisation — Організація
Назва організації, що випускає повідомлення.
Типові налаштування: ""
location — Місцезнаходження
Місце, яке вказується поруч із датою.
Типові налаштування: ""
release_date — Дата
Дата в тому вигляді, в якому вона має з’явитися.
Типові налаштування: ""
approved_quotes — Затверджені цитати
Тільки ті цитати, які були затверджені. Додаються дослівно; ШІ не пише цитат.
Типові налаштування: ""
Розширені налаштування
boilerplate — Про організацію
Стандартний абзац, додається дослівно.
Типові налаштування: ""
contact — Контактні дані
Додається дослівно в кінці.
Типові налаштування: ""
length — Довжина
Приблизна довжина чернетки.
short — Коротка · medium — Середня · long — Довга
Типові налаштування: "medium"
Максимальна кількість вхідних байтів UTF-8: 30000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "press_release",
"text": "{\"facts\":\"Riverside Bakery відкриває другу крамницю на Mill Street 12 травня. Крамниця створює 6 робочих місць. Хліб випікається на місці з борошна з Hartmann Mill.\",\"organisation\":\"Riverside Bakery\",\"location\":\"Bridgeport\",\"release_date\":\"2 травня\",\"approved_quotes\":\"\\\"Ми хотіли випікати там, де живуть наші клієнти.\\\" Анна Берг, власниця\",\"boilerplate\":\"Riverside Bakery випікає хліб у Bridgeport з 1994 року.\",\"contact\":\"Анна Берг, press@riverside-bakery.example\",\"length\":\"short\"}"
}
Напишіть оголошення про вакансію на основі фактів про посаду: зарплата й деталі подачі заявки зберігаються дослівно, а дискримінаційні формулювання позначаються.
Поля введення та конфігурації
Основні налаштування
facts — Факти
Завдання, вимоги, що пропонується, робочий час. Достатньо простих нотаток.
Типові налаштування: ""
job_title — Назва посади
Додається дослівно, як назва.
Типові налаштування: ""
company — Компанія
Назва роботодавця.
Типові налаштування: ""
location — Місцезнаходження
Місце роботи або віддалено.
Типові налаштування: ""
salary — Зарплата
Додається дослівно. Залиште порожнім, якщо не опубліковано.
Типові налаштування: ""
apply_contact — Як подати заявку
Контактні дані або адреса для подання заявок, додано дослівно.
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "job_ad_create",
"text": "{\"facts\":\"Підтримуйте команду сервісу. Плануйте замовлення на ремонт, замовляйте запчастини, спілкуйтеся з клієнтами. Необхідно пройти навчання на автомеханіка, необхідне посвідчення водія. 38 годин на тиждень, 30 днів відпустки.\",\"job_title\":\"Адміністратор сервісу (усі статі)\",\"company\":\"Martens Garage\",\"location\":\"Lindenau\",\"salary\":\"\",\"apply_contact\":\"jobs@martens-garage.example\",\"tone\":\"neutral\"}"
}
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "offer_cover_letter",
"text": "{\"facts\":\"Пропозиція щодо перефарбування сходового маршу в будинку на Maple Street. Два шари, роботи протягом робочого часу, клієнт просив фарбу з низьким вмістом запаху.\",\"customer\":\"Пані Келлер, Maple Street Property\",\"offer_number\":\"A-2041\",\"amount\":\"4 180 EUR плюс ПДВ\",\"valid_until\":\"30 червня\",\"sender\":\"Йонас Вебер, Weber Painters\",\"tone\":\"friendly\"}"
}
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "customer_change_notice",
"text": "{\"facts\":\"Місячний абонемент зростає з 29 до 32 EUR через підвищення витрат на енергію. Контракти можна розірвати до того, як зміни набудуть чинності. Графік роботи залишається незмінним.\",\"organisation\":\"North Gym\",\"effective_date\":\"1 березня\",\"contact\":\"service@north-gym.example\",\"tone\":\"neutral\"}"
}
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "polite_decline",
"text": "{\"situation\":\"Лена Гоффман подала заявку на посаду стажера в нашій друкарні. Співбесіда 4 квітня.\",\"reason\":\"Інший кандидат мав більше досвіду роботи з офсетним друком.\",\"alternative\":\"Ми зберігатимемо заявку протягом шести місяців, якщо вона погодиться.\",\"sender\":\"Том Ріхтер, Richter Print\",\"tone\":\"friendly\"}"
}
Напишіть нагадування про оплату на обраному рівні. Номер рахунку, сума та дата залишаються незмінними; жодних вигаданих комісій чи погроз.
Поля введення та конфігурації
Основні налаштування
customer — Клієнт
Ім'я клієнта.
Типові налаштування: ""
invoice_number — Номер рахунку
Додається дослівно.
Типові налаштування: ""
invoice_date — Дата рахунку
Додається дослівно.
Типові налаштування: ""
amount — Заборгованість
Додається дослівно, з валютою.
Типові налаштування: ""
due_date — Нова дата платежу
Додається дослівно.
Типові налаштування: ""
level — Рівень
Наскільки суворим є нагадування.
friendly — Дружнє нагадування · second — Друге нагадування · final — Останнє нагадування
Типові налаштування: "friendly"
payment_details — Реквізити для оплати
Додається дослівно.
Типові налаштування: ""
sender — Відправник та підпис
Ім'я, роль та контактні дані. Додається дослівно.
Типові налаштування: ""
Розширені налаштування
notes — Примітки
Опціонально: попередній контакт, узгоджені збори, відповідні наслідки.
Типові налаштування: ""
Максимальна кількість вхідних байтів UTF-8: 30000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "event_invitation",
"text": "{\"event\":\"Літня вечірка мешканців Lindenhof\",\"facts\":\"Гриль та напої надаються, будь ласка, принесіть салат або торт. Діти вітаються. Музика з 18:00.\",\"date_time\":\"Субота 21 червня, 16:00\",\"place\":\"Внутрішній дворик, Lindenhof 4\",\"rsvp\":\"Відповісти пані Йилмаз до 14 червня\",\"host\":\"Комітет орендарів\",\"tone\":\"friendly\"}"
}
Напишіть чіткий лист про розірвання договору з запитом про письмове підтвердження. Не є юридичною консультацією.
Поля введення та конфігурації
Основні налаштування
contract — Договір
Тип договору та номер договору.
Типові налаштування: ""
provider — Постачальник
Назва компанії.
Типові налаштування: ""
end_date — Дата закінчення договору
Наприклад, дата або "наступна можлива дата". Додається дослівно.
Типові налаштування: ""
customer_block — Дані клієнта
Ім'я, адреса та номер клієнта. Додається дослівно.
Типові налаштування: ""
Розширені налаштування
notes — Примітки
Опціонально: причина, припинення прямого дебету, дані для видалення.
Типові налаштування: ""
Максимальна кількість вхідних байтів UTF-8: 30000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "cancellation_letter",
"text": "{\"contract\":\"Договір мобільного зв'язку, номер клієнта 88213\",\"provider\":\"Telecom North\",\"end_date\":\"на найближчу можливу дату\",\"customer_block\":\"Марія Ланг, Oak Street 7, 12345 Riverton\",\"notes\":\"Будь ласка, припиніть пряме дебетування після останнього рахунку.\"}"
}
Перетворіть нотатки на скаргу, засновану на фактах, з чітким запитом і терміном, без погроз чи вигаданих деталей.
Поля введення та конфігурації
Основні налаштування
facts — Факти
Що сталося, коли, про що домовилися, що було спробовано.
Типові налаштування: ""
recipient — Отримувач
Компанія або особа.
Типові налаштування: ""
desired_outcome — Очікуваний результат
Що має статися зараз.
Типові налаштування: ""
reference — Довідковий номер
Номер замовлення або клієнта. Додається дослівно.
Типові налаштування: ""
deadline — Термін виконання
Додається дослівно.
Типові налаштування: ""
sender — Відправник та підпис
Ім'я, роль та контактні дані. Додається дослівно.
Типові налаштування: ""
Максимальна кількість вхідних байтів UTF-8: 30000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "complaint_letter",
"text": "{\"facts\":\"Пральна машина, замовлена 3 березня, доставлена 20 березня замість 10 березня. Ущільнювач дверцят пошкоджено під час доставки. Про це було повідомлено телефоном 21 березня, з того часу відповіді немає.\",\"recipient\":\"HomeTech Service\",\"desired_outcome\":\"Заміна ущільнювача дверцят або самої машини.\",\"reference\":\"Замовлення 55821\",\"deadline\":\"14 квітня\",\"sender\":\"Пол Новак, Елм Роуд 2\"}"
}
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "company_profile",
"text": "{\"facts\":\"Сімейний бізнес з садових меблів, заснований у 2003 році. Власна майстерня на 14 осіб. Деревина з регіональних лісів. Продаж приватним клієнтам та готелям. Ремонт протягом 10 років.\",\"company\":\"Waldholz Furniture\",\"location\":\"Фрайберг\",\"contact\":\"hello@waldholz.example\",\"length\":\"short\",\"tone\":\"friendly\"}"
}
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "speech_draft",
"text": "{\"occasion\":\"Прощання з Хельгою Соммер після 31 року роботи\",\"speaker\":\"Керуючий директор\",\"audience\":\"Колеги та родина\",\"facts\":\"Хельга Соммер прийшла на роботу у 1995 році в бухгалтерію, а згодом очолила команду з 6 осіб. Вона впровадила перші онлайн-рахунки та підготувала 12 учнів. Тепер вона вирушає у подорож до Норвегії.\",\"length\":\"short\",\"tone\":\"friendly\"}"
}
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "grant_summary",
"text": "{\"project\":\"Читацькі зустрічі в районній бібліотеці\",\"organisation\":\"Друзі Східної бібліотеки\",\"funder\":\"Міський фонд культури\",\"facts\":\"Діти віком від 6 до 10 років читають уголос із волонтерами два дні на тиждень після обіду. Багато сімей мають удома мало книжок. 8 волонтерів готові, книжки надає бібліотека. Мета: щоб більше дітей регулярно користувалися бібліотекою.\",\"amount\":\"6 500 EUR\",\"period\":\"Вересень — червень\"}"
}
Напишіть чіткий лист від школи або дитячого садка батькам: що відбувається, коли і що потрібно зробити батькам.
Поля введення та конфігурації
Основні налаштування
school — Школа або дитячий садок
Назва установи.
Типові налаштування: ""
facts — Факти
Що відбувається, що потрібно, скільки це коштує.
Типові налаштування: ""
date_time — Дата та час
Додається дослівно.
Типові налаштування: ""
deadline — Термін відповіді
Додається дослівно.
Типові налаштування: ""
sender — Відправник та підпис
Ім'я, роль та контактні дані. Додається дослівно.
Типові налаштування: ""
Максимальна кількість вхідних байтів UTF-8: 30000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "parent_letter",
"text": "{\"school\":\"Початкова школа «Соняшник»\",\"facts\":\"3b клас відвідує зоопарк. Дітям потрібен ланч-бокс та одяг для дощу. Вартість поїздки становить 8 EUR, оплата проводиться у класі. Ми повертаємося о 14:00.\",\"date_time\":\"Вівторок, 13 травня, 8:30\",\"deadline\":\"П'ятниця, 9 травня\",\"sender\":\"Пані Айдін, класний керівник\"}"
}
Напишіть коротке оголошення для дошки, дверей або під'їзду: що відбувається, коли, що робити.
Поля введення та конфігурації
Основні налаштування
facts — Факти
Що відбувається, кого це стосується, що робити.
Типові налаштування: ""
date_time — Дата та час
Додається дослівно.
Типові налаштування: ""
place — Місце
Додається дослівно.
Типові налаштування: ""
contact — Контактні дані
Додається дослівно в кінці.
Типові налаштування: ""
Максимальна кількість вхідних байтів UTF-8: 30000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "notice_board",
"text": "{\"facts\":\"Воду вимкнули, оскільки замінюють головний вентиль. Будь ласка, заздалегідь наберіть воду і не користуйтеся пральною машиною.\",\"date_time\":\"Четвер, 8 травня, з 9:00 до 12:00\",\"place\":\"Будинки з 4 по 8\",\"contact\":\"Завгок пан Ланг, 0151 000000\"}"
}
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "cover_letter",
"text": "{\"job_ad\":\"Ми шукаємо помічника команди з досвідом організації заходів. Потрібна добра англійська.\",\"profile\":\"Шість років на посаді офіс-менеджера у виставковій компанії. Організовував 40 клієнтських заходів на рік. Англійська на рівні B2. Шукаю посаду з більшою відповідальністю.\",\"company\":\"Norden Events\",\"applicant\":\"Сара Дженсен, sara@example.com\",\"tone\":\"neutral\"}"
}
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "property_listing",
"text": "{\"facts\":\"3 кімнати, 74 квадратних метри, другий поверх, балкон на південь, відремонтовано у 2021 році, обладнана кухня, підвал, трамвайна зупинка у 5 хвилинах ходьби.\",\"location\":\"Шиллерштрассе, Лейпциг\",\"price\":\"980 EUR плюс комунальні послуги\",\"contact\":\"Immobilien Kern, 0341 000000\",\"tone\":\"neutral\"}"
}
Напишіть коротке, чесне оголошення про товар, із зазначенням дефектів та збереженням точної ціни.
Поля введення та конфігурації
Основні налаштування
facts — Факти
Що це таке, вік, стан, дефекти, що входить у комплект.
Типові налаштування: ""
price — Ціна
Додається дослівно.
Типові налаштування: ""
location — Місцезнаходження
Додається дослівно.
Типові налаштування: ""
contact — Контакти
Додається дослівно.
Типові налаштування: ""
Максимальна кількість вхідних байтів UTF-8: 30000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "classified_ad",
"text": "{\"facts\":\"Дитячий велосипед 20 дюймів, куплений у 2022 році, 6 швидкостей, синій. Невелика подряпина на рамі, минулого року замінено гальма. Ліхтарики у комплекті.\",\"price\":\"120 EUR\",\"location\":\"Потсдам\",\"contact\":\"Повідомлення на платформі\"}"
}
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "donation_appeal",
"text": "{\"organisation\":\"Притулок для тварин Берген\",\"facts\":\"Дах будки протікає, і його потрібно замінити до зими. Притулок піклується про близько 40 собак. Майстер з покрівлі виставив рахунок на 12 000 євро. Наразі зібрано 5 000 євро.\",\"goal\":\"7 000 євро до жовтня\",\"donation_details\":\"IBAN DE00 0000 0000 0000 0000 00, призначення платежу Дах\",\"contact\":\"info@shelter-bergen.example\",\"tone\":\"friendly\"}"
}
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "release_notes",
"text": "{\"changes\":\"id,type,text\\nC1,added,Експорт CSV для інвойсів\\nC2,fixed,\\\"Помилка входу, коли електронна адреса містила великі літери\\\"\\nC3,changed,Звіти завантажуються у фоновому режимі\",\"product\":\"Billy Invoices\",\"version\":\"3.2\",\"release_date\":\"12 травня\",\"audience\":\"customers\"}"
}
Створюйте позначки розділів на основі субтитрів або транскрипту з часовими кодами. Час береться з файлу, лише назви створює ШІ.
Поля введення та конфігурації
Основні налаштування
transcript — Транскрипт із часовими кодами
SRT, VTT або рядки, що починаються з часу, наприклад, 01:12.
Типові налаштування: ""
max_chapters — Максимальна кількість розділів
Від 3 до 20.
Типові налаштування: 8
Розширені налаштування
min_gap_seconds — Мінімальна відстань у секундах
Від 10 до 600.
Типові налаштування: 60
Максимальна кількість вхідних байтів UTF-8: 70000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "video_chapters",
"text": "{\"transcript\":\"00:00 Ласкаво просимо на семінар та короткий огляд сьогоднішнього дня.\\n00:40 Ми почнемо з інструментів, які вам знадобляться для заміни шини.\\n01:30 Спочатку послабте колісні гайки, поки автомобіль стоїть на землі.\\n02:20 Тепер підніміть автомобіль на домкраті в позначеному місці.\\n03:10 Зніміть колесо та встановіть запасне.\\n04:05 Затягніть гайки навхрест і опустіть автомобіль.\\n05:00 Перевірте тиск і приберіть інструменти.\",\"max_chapters\":4,\"min_gap_seconds\":60}"
}
Створіть часовий план зустрічі на основі тем і тривалості. Сервер розраховує час, а ШІ формулює пункти та очікувані результати.
Поля введення та конфігурації
Основні налаштування
meeting_title — Назва зустрічі
Додається дослівно.
Типові налаштування: ""
objective — Мета
Чого має досягти зустріч.
Типові налаштування: ""
start_time — Час початку
Формат 09:30.
Типові налаштування: "09:00"
topics — Теми
Одна тема в рядку з відповідальною особою та хвилинами.
Типові налаштування: ""
Розширені налаштування
available_minutes — Доступні хвилини
0 означає без обмежень. Про довший порядок денний буде повідомлено.
Типові налаштування: 0
break_minutes — Перерва після кожної третьої теми
Хвилини, 0 означає без перерви.
Типові налаштування: 0
Максимальна кількість вхідних байтів UTF-8: 30000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "meeting_agenda",
"text": "{\"meeting_title\":\"Планування весни\",\"objective\":\"Визначте черговість трьох проєктів\",\"start_time\":\"09:30\",\"topics\":\"id,topic,owner,minutes\\nT1,огляд за останній квартал,Anna,20\\nT2,бюджет проєктів А Б В,Marek,40\\nT3,хто що робить,Anna,30\",\"available_minutes\":90,\"break_minutes\":0}"
}
Отримайте відповіді на запитання за вставленим документом. Кожна відповідь потребує точної цитати; інакше результат вказує, що в документі цього не зазначено.
Поля введення та конфігурації
Основні налаштування
document — Документ
Вставте текст. Він розглядається як дані, а не як інструкції.
Типові налаштування: ""
questions — Запитання
Одне запитання на рядок, максимум 12.
Типові налаштування: ""
Розширені налаштування
answer_length — Довжина відповіді
Короткі або детальні відповіді.
brief — Коротко · detailed — Детально
Типові налаштування: "brief"
Максимальна кількість вхідних байтів UTF-8: 40000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "document_questions",
"text": "{\"document\":\"Період оренди починається 1 червня і триває 24 місяці.\\n\\nОрендар сплачує щомісячну орендну плату в розмірі 950 євро до третього робочого дня кожного місяця.\\n\\nДля утримання домашніх тварин потрібен письмовий дозвіл орендодавця.\",\"questions\":\"Якою є тривалість періоду оренди?\\nЧи може орендар тримати собаку?\\nХто оплачує ремонт?\",\"answer_length\":\"brief\"}"
}
Знайдіть у договорі пункти, що потребують детальнішого вивчення: продовження, розірвання, відповідальність, оплата, штрафні санкції та дані, кожен із точною цитатою.
Поля введення та конфігурації
Основні налаштування
document — Текст договору
Вставте текст. Він розглядається як дані, а не як інструкції.
Типові налаштування: ""
Максимальна кількість вхідних байтів UTF-8: 32000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "contract_clause_review",
"text": "{\"document\":\"Ця угода автоматично продовжується на 12 місяців, якщо її не буде скасовано в письмовій формі за 3 місяці до закінчення терміну дії.\\n\\nВідповідальність провайдера обмежена сумою винагороди, сплаченої протягом попередніх 6 місяців.\\n\\nРахунки підлягають оплаті протягом 14 днів. За прострочення платежу нараховується пеня у розмірі 2 відсотків за місяць.\"}"
}
Витягуйте завдання, рішення та відкриті питання з електронних листів або нотаток. Відповідальні та дати з'являються лише тоді, коли вони є в тексті.
Поля введення та конфігурації
Основні налаштування
document — Електронні листи або нотатки
Вставте текст. Він розглядається як дані, а не як інструкції.
Типові налаштування: ""
Максимальна кількість вхідних байтів UTF-8: 32000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "action_items",
"text": "{\"document\":\"Всім привіт, ми домовилися перенести запуск на 12 червня. Марек оновить прайс-лист до п'ятниці. Ніхто ще не перевірив, чи зможе постачальник здійснити доставку раніше.\"}"
}
Знайти в документі твердження, які суперечать одне одному, наприклад, різні дати або суми, з цитуванням обох фрагментів.
Поля введення та конфігурації
Основні налаштування
document — Документ
Вставте текст. Він розглядається як дані, а не як інструкції.
Типові налаштування: ""
Максимальна кількість вхідних байтів UTF-8: 32000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "contradiction_check",
"text": "{\"document\":\"Проєкт розпочинається 1 березня і триває 6 місяців.\\n\\nЗагальний бюджет становить 40 000 EUR.\\n\\nУ розділі 4 проєкт завершується 30 листопада. Загальний бюджет у розмірі 45 000 EUR включає витрати на проїзд.\"}"
}
Знайдіть те, чого не вистачає в запиті або брифі, перш ніж розпочати роботу, та отримайте перелік запитань, які варто поставити.
Поля введення та конфігурації
Основні налаштування
document — Запит або бриф
Вставте текст. Він розглядається як дані, а не як інструкції.
Типові налаштування: ""
purpose — Для чого це потрібно
Наприклад, «підготувати пропозицію» або «спланувати захід».
Типові налаштування: ""
Максимальна кількість вхідних байтів UTF-8: 22000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "missing_information",
"text": "{\"document\":\"Вітаю, нам потрібно найближчим часом перефарбувати офіс. У ньому кілька кімнат, і на стінах є деякі плями. Будь ласка, надішліть цінову пропозицію.\",\"purpose\":\"підготувати пропозицію\"}"
}
Пояснити офіційний лист простою мовою: про що він, терміни, суми та що потрібно зробити, з точним цитуванням кожного фрагмента. Це не юридична консультація.
Поля введення та конфігурації
Основні налаштування
document — Текст листа
Вставте текст. Перед цим можна видалити персональні дані.
Типові налаштування: ""
Максимальна кількість вхідних байтів UTF-8: 22000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "official_letter_explainer",
"text": "{\"document\":\"Повідомлення від 4 травня. Вашу заяву на отримання житлової допомоги було отримано. Будь ласка, надайте договір оренди та підтвердження доходу до 25 травня. Без цих документів ми не зможемо прийняти рішення щодо вашої заяви. Питання: Житловий відділ, кімната 214.\"}"
}
Перетворіть інструкції або процедуру на контрольний список. Кожен пункт прив'язаний до точного уривка, і нічого не додається.
Поля введення та конфігурації
Основні налаштування
document — Інструкції або процедура
Вставте текст. Він розглядається як дані, а не як інструкції.
Типові налаштування: ""
Максимальна кількість вхідних байтів UTF-8: 32000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "checklist_from_text",
"text": "{\"document\":\"Перед початком роботи вимкніть пристрій і витягніть вилку з розетки. Відкрийте кришку за допомогою наданого ключа. Зніміть фільтр і промийте його під холодною водою. Ніколи не використовуйте розчинники, оскільки вони пошкоджують ущільнювач. Дайте фільтру висохнути протягом однієї години перед повторною установкою.\"}"
}
Сортуйте тікети підтримки за встановленими категоріями з позначенням терміновості, точної цитати та запропонованого наступного кроку. Нічого не надсилається.
Поля введення та конфігурації
Основні налаштування
items — Тікети
Один тікет на рядок. Текст можна вставити з будь-якої системи.
Типові налаштування: ""
categories — Категорії
Встановлені категорії з коротким визначенням.
Типові налаштування: ""
Максимальна кількість вхідних байтів UTF-8: 56000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "ticket_triage",
"text": "{\"items\":\"id,subject,text\\nT1,Помилка входу,З самого ранку ніхто з нашої команди не може увійти в систему. Ми не можемо працювати.\\nT2,Адреса для виставлення рахунку,\\\"Будь ласка, змініть нашу адресу для виставлення рахунку на Mill Road 3.\\\"\\nT3,Ідея,Було б добре мати темний режим.\",\"categories\":\"id,name,definition\\nC1,Технічна несправність,Щось не працює\\nC2,Оплата,Рахунки та платежі\\nC3,Запит на функцію,Побажання щодо нових функцій\"}"
}
Сортуйте відкриті відгуки за встановленими темами, з точним уривком для кожного пункту та кількістю за темою.
Поля введення та конфігурації
Основні налаштування
items — Відгук
Один запис на рядок, наприклад, з опитування.
Типові налаштування: ""
categories — Теми
Встановлені теми з коротким визначенням.
Типові налаштування: ""
Максимальна кількість вхідних байтів UTF-8: 56000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "feedback_sorting",
"text": "{\"items\":\"id,source,text\\nF1,Опитування,Персонал за стійкою був дуже привітним.\\nF2,Електронна пошта,Я чекав на свій прийом понад годину.\\nF3,Опитування,Поруч із будівлею важко знайти парковку.\",\"categories\":\"id,name,definition\\nS1,Персонал,Поведінка та поради персоналу\\nS2,Час очікування,Очікування та прийоми\\nS3,Розташування,Доступ та паркування\"}"
}
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "recommendation_letter",
"text": "{\"person\":\"Міра Ковач\",\"relationship\":\"Тімлід протягом трьох років у Lumen Print\",\"purpose\":\"Роль менеджера проєкту\",\"facts\":\"Міра планувала переїзд нашої друкарні у 2025 році. Вона підготувала двох нових колег. Вона тримала клієнтів у курсі подій під час переїзду.\",\"tone\":\"friendly\",\"sender\":\"Том Берг, керівник виробництва, Lumen Print\"}"
}
Перетворіть нотатки про роботу та освіту на структуроване резюме з датами та роботодавцями точно так, як вони надані.
Поля введення та конфігурації
Основні налаштування
full_name — Ім'я
Додається дослівно.
Типові налаштування: ""
contact — Контактні дані
Додається дослівно під ім'ям.
Типові налаштування: ""
target_role — Цільова роль
Опціонально: посада, на яку розраховане це резюме.
Типові налаштування: ""
experience — Досвід роботи
Посади, роботодавці, дати та завдання. Достатньо звичайних нотаток.
Типові налаштування: ""
education — Освіта
Опціонально: навчальні заклади, курси та дати.
Типові налаштування: ""
skills — Навички
Опціонально: мови, інструменти та інші навички.
Типові налаштування: ""
Максимальна кількість вхідних байтів UTF-8: 30000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "cv_from_notes",
"text": "{\"full_name\":\"Міра Ковач\",\"contact\":\"mira.kovac@example.org\",\"target_role\":\"Менеджер проєктів\",\"experience\":\"2022 — до сьогодні: координатор команди в Lumen Print, планування переїзду майстерні, навчання нових колег. 2018 — 2022: технік друку в Atlas Druck.\",\"education\":\"2018 професійне навчання на техніку друку\",\"skills\":\"Планування проєктів, німецька, англійська\"}"
}
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "thank_you_letter",
"text": "{\"recipient\":\"Riverside Bakery\",\"occasion\":\"Спонсорство нашого літнього ярмарку\",\"facts\":\"Пекарня віддала хліб для 200 гостей. Двоє їхніх працівників допомагали біля стенда.\",\"tone\":\"friendly\",\"sender\":\"Анна Берг, Правління, Асоціація Ріверсайд\"}"
}
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "appointment_confirmation",
"text": "{\"recipient\":\"Пан Новак\",\"subject_matter\":\"Перевірка опалення\",\"date_time\":\"12 травня, 10:00\",\"place\":\"Mill Road 4\",\"notes\":\"Будь ласка, переконайтеся, що котельня доступна. Візьміть останній звіт про перевірку.\",\"cancellation\":\"Зателефонуйте за номером 030 000000 за день до цього.\",\"tone\":\"neutral\",\"sender\":\"Сервісна команда, Heizung Berg\"}"
}
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "out_of_office",
"text": "{\"person\":\"Mira Kovac\",\"date_range\":\"з 4 по 15 серпня\",\"substitute\":\"Tom Berg, tom.berg@example.org\",\"notes\":\"Рахунки чекають до повернення.\",\"tone\":\"friendly\"}"
}
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "offer_follow_up",
"text": "{\"customer\":\"Atlas Druck\",\"offer_reference\":\"Пропозиція 2026-41 від 3 березня\",\"facts\":\"Нова фасувальна машина з установкою. Ми розмовляли про доставку у травні. Наступним кроком був би короткий дзвінок.\",\"tone\":\"neutral\",\"sender\":\"Анна Берг, відділ продажів, Lumen Print\"}"
}
Перетворіть нотатки на короткий покроковий посібник, додаючи попередження лише у тому вигляді, в якому вони надані.
Поля введення та конфігурації
Основні налаштування
guide_title — Заголовок
Додається дослівно.
Типові налаштування: ""
audience — Для кого
Опціонально: хто використовує цей посібник.
Типові налаштування: ""
notes — Примітки
Кроки, налаштування та попередження у будь-якому порядку.
Типові налаштування: ""
support — Допомога
Опціонально: до кого звертатися. Додається дослівно.
Типові налаштування: ""
Максимальна кількість вхідних байтів UTF-8: 30000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "quick_guide",
"text": "{\"guide_title\":\"Почистити кавомашину\",\"audience\":\"Офісна команда\",\"notes\":\"Вимкніть і дайте охолонути. Спорожніть піддон для крапель. Промийте піддон теплою водою. Не використовуйте посудомийну машину. Натисніть кнопку очищення на 3 секунди.\",\"support\":\"Господарська служба, кімната 12\"}"
}
Напишіть інструктаж із техніки безпеки на основі наданих правил та небезпек, не додаючи нових небезпек, правил або юридичних заяв.
Поля введення та конфігурації
Основні налаштування
workplace — Робоче місце
Ділянка або завдання, для яких проводиться інструктаж.
Типові налаштування: ""
notes — Правила та небезпечні фактори
Власні правила, небезпечні фактори та дії у надзвичайних ситуаціях. Нічого іншого не додається.
Типові налаштування: ""
responsible — Відповідальна особа
Додається дослівно.
Типові налаштування: ""
briefing_date — Дата інструктажу
Додається дослівно.
Типові налаштування: ""
Максимальна кількість вхідних байтів UTF-8: 30000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "safety_briefing",
"text": "{\"workplace\":\"Друкарська майстерня\",\"notes\":\"Небезпека: рухомі ролики, пари розчинника. Правила: заберіть довге волосся назад, використовуйте рукавички під час чищення, тримайте двері відкритими під час використання розчинника. Аварійна ситуація: натисніть червону кнопку зупинки, зателефонуйте керівнику зміни.\",\"responsible\":\"Том Берг\",\"briefing_date\":\"12 травня\"}"
}
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "tenant_notice",
"text": "{\"property\":\"Mill Road 4\",\"topic\":\"Відключення води для ремонту труби\",\"facts\":\"Воду буде відключено у всьому будинку приблизно на 4 години. Будь ласка, заздалегідь наберіть воду та залиште вільний доступ до підвалу.\",\"date_time\":\"12 травня, 08:00\",\"contact\":\"Команда обслуговування, 030 000000\",\"tone\":\"neutral\",\"sender\":\"Управління нерухомістю Berg\"}"
}
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "internal_announcement",
"text": "{\"topic\":\"Новий графік роботи офісу\",\"audience\":\"Увесь персонал\",\"facts\":\"Офіс зачиняється о 16:00 у п'ятницю. Після цього дзвінки переадресовуються на автовідповідач. Будь ласка, повідомте про це клієнтів під час наступного контакту.\",\"effective_date\":\"1 червня\",\"contact\":\"Анна Берг, офіс\",\"tone\":\"neutral\",\"sender\":\"Керівництво, Lumen Print\"}"
}
Перетворіть нотатки та таблицю годин і матеріалів на охайний звіт про роботи. Сервер підсумовує години та суми, а ШІ формулює опис виконаних робіт.
Поля введення та конфігурації
Основні налаштування
customer — Клієнт
Додається дослівно.
Типові налаштування: ""
site — Об'єкт
Опціонально: адреса або номер завдання.
Типові налаштування: ""
work_date — Дата виконання
Додається дослівно.
Типові налаштування: ""
technician — Виконавець
Опціонально: ім'я або команда.
Типові налаштування: ""
work_notes — Примітки до роботи
Що було зроблено, що виявлено, що залишається незавершеним. Достатньо простих нотаток.
Типові налаштування: ""
lines — Години та матеріали
Один рядок на позицію. kind — labour, material або other. unit_price може бути порожнім.
Типові налаштування: ""
Розширені налаштування
currency — Валюта
Короткий код або знак, що відображається з сумами, наприклад EUR.
Типові налаштування: "EUR"
Максимальна кількість вхідних байтів UTF-8: 30000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "work_report",
"text": "{\"customer\":\"Пекарня Hartmann\",\"site\":\"Mill Street 4\",\"work_date\":\"12 травня 2026 р.\",\"technician\":\"Том Берг\",\"work_notes\":\"Замінено протікаючий клапан на лінії водопостачання тістоміса. Перевірено на наявність витоків, витоків не виявлено. На другому клапані помітно іржу, його слід замінити під час наступного обслуговування.\",\"lines\":\"id,kind,description,quantity,unit,unit_price\\nL1,labour,Ремонт та перевірка,2.5,h,48\\nL2,material,Кран кульовий DN15,1,шт,18.40\\nL3,other,Ход,1,плоский,25\",\"currency\":\"EUR\"}"
}
Перетворіть нотатки інспекції на нумерований список дефектів. Кожен запис пов'язаний з точним уривком у нотатках, і нічого не додається.
Поля введення та конфігурації
Основні налаштування
site — Об'єкт або нерухомість
Додається дослівно.
Типові налаштування: ""
inspection_date — Дата інспекції
Додається дослівно.
Типові налаштування: ""
inspector — Оглянув
Необов'язково.
Типові налаштування: ""
document — Примітки до інспекції
Один дефект на рядок або абзац. Може бути згадано назви файлів фотографій.
Типові налаштування: ""
Максимальна кількість вхідних байтів UTF-8: 30000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "defect_list",
"text": "{\"site\":\"Mill Road 3, другий поверх\",\"inspection_date\":\"3 червня 2026\",\"inspector\":\"А. Новак\",\"document\":\"Кухня: розетка біля вікна без кришки, видно дроти.\\n\\nВанна кімната: зліва відсутня затирка навколо душової кабіни.\\n\\nПередпокій: пошкоджена фарба на дверній коробці, див. фото IMG_204.\\n\\nВітальня: вентиль радіатора не повертається.\"}"
}
Поясніть характеристику з місця роботи речення за реченням простими словами. Кожне пояснення прив'язане до конкретного речення.
Поля введення та конфігурації
Основні налаштування
document — Текст характеристики
Вставте текст. Він розглядається як дані, а не як інструкції.
Типові налаштування: ""
Максимальна кількість вхідних байтів UTF-8: 30000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "reference_explained",
"text": "{\"document\":\"Пані Ковач працювала у нас на посаді асистента проєкту з березня 2023 року по червень 2026 року.\\n\\nВона виконувала поставлені перед нею завдання з великою ретельністю та завжди на нашому повній задоволенні.\\n\\nЇї поведінка щодо колег була приязною, і вона завжди була пунктуальною.\\n\\nМи бажаємо їй всього найкращого в майбутньому.\"}"
}
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "reference_draft",
"text": "{\"employee\":\"Міра Ковач\",\"period\":\"1 березня 2023 р. – 30 червня 2026 р.\",\"role\":\"Асистент проєкту\",\"company\":\"Lumen Print\",\"facts\":\"Планувала графіки друку для 40 клієнтів. Навчила двох нових колег. Її робота була дуже якісною та надійною. Колеги та клієнти цінували її привітність. Звільняється за власним бажанням.\",\"tone\":\"formal\",\"sender\":\"Том Берг, керівник виробництва\"}"
}
Перерахуйте розрахунок комунальних платежів або плати за обслуговування за його цифрами та складіть список запитань. Арифметику виконує сервер.
Поля введення та конфігурації
Основні налаштування
property — Квартира або об'єкт нерухомості
Додається дослівно.
Типові налаштування: ""
period — Розрахунковий період
Додається дослівно.
Типові налаштування: ""
lines — Витрати з розрахунку
Один рядок для кожного типу витрат: total_amount для будівлі, key_total та key_share для розподілу, наприклад 500 та 62 квадратних метри. previous_total може бути порожнім.
Типові налаштування: ""
advance_paid — Авансові платежі
Загальна сума, сплачена за період. Порожньо, якщо невідомо.
Типові налаштування: ""
billed_balance — Сальдо в розрахунку
Сума до сплати згідно з розрахунком, для порівняння. Порожньо, якщо невідомо.
Типові налаштування: ""
statement_total — Примітки з розрахунку
Опціонально: будь-що інше, зазначене в розрахунку, наприклад сума до сплати.
Типові налаштування: ""
Розширені налаштування
currency — Валюта
Короткий код або знак, що відображається з сумами, наприклад EUR.
Типові налаштування: "EUR"
Максимальна кількість вхідних байтів UTF-8: 30000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "utility_bill_check",
"text": "{\"property\":\"Mill Road 3, flat 5\",\"period\":\"1 січня – 31 грудня 2025 р.\",\"lines\":\"id,cost_type,total_amount,key_total,key_share,previous_total\\nC1,Опалення,8400,500,62,6800\\nC2,Вода,2100,500,62,2050\\nC3,Наглядач,3600,500,62,3600\\nC4,Страхування,1500,500,62,1450\",\"advance_paid\":\"1500\",\"billed_balance\":\"402.60\",\"statement_total\":\"Заява від 15 березня 2026 р.\",\"currency\":\"EUR\"}"
}
Позначте 14 основних харчових алергенів для кожної страви на основі списків інгредієнтів. Кожен запис вказує інгредієнт, з якого він походить, для перевірки підприємством.
Поля введення та конфігурації
Основні налаштування
dishes — Страви та інгредієнти
Один рядок на кожну страву з усіма інгредієнтами, включаючи інгредієнти куплених продуктів, де це можливо.
Типові налаштування: ""
Максимальна кількість вхідних байтів UTF-8: 30000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Перетворіть навчальний текст на картки «питання-відповідь». Кожна картка прив'язана до точного уривка, а набір можна імпортувати у програми для флеш-карток.
Поля введення та конфігурації
Основні налаштування
document — Текст для навчання
Вставте текст. Він розглядається як дані, а не як інструкції.
Типові налаштування: ""
card_count — Кількість карток
Від 5 до 40.
Типові налаштування: 12
Максимальна кількість вхідних байтів UTF-8: 30000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "flashcards",
"text": "{\"document\":\"Фотосинтез відбувається в хлоропластах рослинних клітин. Хлорофіл поглинає світло, переважно в червоному та синьому діапазонах.\\n\\nПід час світлових реакцій вода розщеплюється, а кисень виділяється. Енергія зберігається в АТФ та НАДФН.\\n\\nУ циклі Кальвіна вуглекислий газ перетворюється на цукор за допомогою цієї енергії.\",\"card_count\":5}"
}
Створіть розрахований за часом план уроку з фаз та тривалостей. Сервер обчислює час, а ШІ формулює кожну фазу та її навчальну мету.
Поля введення та конфігурації
Основні налаштування
meeting_title — Назва уроку
Додається дослівно.
Типові налаштування: ""
objective — Мета навчання та група
Що група має вміти після заняття і хто входить до групи.
Типові налаштування: ""
start_time — Час початку
Формат 09:30.
Типові налаштування: "08:00"
topics — Фази
Одна фаза на рядок із зазначенням того, хто її веде, та тривалості в хвилинах.
Типові налаштування: ""
Розширені налаштування
available_minutes — Доступні хвилини
0 означає без обмежень. Про довший план буде повідомлено.
Типові налаштування: 45
break_minutes — Перерва після кожної третьої фази
Хвилини, 0 означає без перерви.
Типові налаштування: 0
Максимальна кількість вхідних байтів UTF-8: 30000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "lesson_plan",
"text": "{\"meeting_title\":\"Дроби: додавання з однаковим знаменником\",\"objective\":\"5 клас може додавати дроби з однаковим знаменником.\",\"start_time\":\"08:00\",\"topics\":\"id,topic,owner,minutes\\nP1,Повторення: що таке дріб,Teacher,5\\nP2,Покажіть додавання на прикладі шматочків піци,Teacher,10\\nP3,Вправи в парах,Pupils,20\\nP4,Порівняння результатів та підсумок,Class,10\",\"available_minutes\":45,\"break_minutes\":0}"
}
Напишіть звіт про страховий випадок для страховика на основі наданих фактів. Номер поліса, дата та сума залишаються без змін, і нічого не додається.
Поля введення та конфігурації
Основні налаштування
insurer — Страховик
Додається дослівно.
Типові налаштування: ""
policy_number — Номер поліса
Додається дослівно.
Типові налаштування: ""
incident_date — Дата події
Додається дослівно.
Типові налаштування: ""
incident_place — Місце події
Додається дослівно.
Типові налаштування: ""
facts — Факти
Що сталося, що було пошкоджено, що було зроблено після цього, хто був залучений.
Типові налаштування: ""
claim_amount — Сума страхової вимоги
Необов'язково. Додається дослівно.
Типові налаштування: ""
sender — Відправник та підпис
Ім'я, роль та контактні дані. Додається дослівно.
Типові налаштування: ""
Максимальна кількість вхідних байтів UTF-8: 30000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "insurance_claim",
"text": "{\"insurer\":\"Riverside Insurance\",\"policy_number\":\"HR-4471-22\",\"incident_date\":\"14 березня 2026\",\"incident_place\":\"Mill Road 3, кв. 5\",\"facts\":\"Вночі в стіні на кухні прорвало водопровідну трубу. Вода розлилася на кухні та в коридорі. Пошкоджено підлогу в коридорі та кухонну шафу. Ми перекрили головний вентиль і того ж ранку викликали сантехніка.\",\"claim_amount\":\"2 350 EUR\",\"sender\":\"Anna Novak, Mill Road 3, Bridgeport\"}"
}
Перетворіть список витрат на звіт про витрати на відрядження. Сервер підсумовує суми та повідомляє про відсутні чеки та дати.
Поля введення та конфігурації
Основні налаштування
traveller — Відряджена особа
Додається дослівно.
Типові налаштування: ""
period — Період подорожі
Додається дослівно.
Типові налаштування: ""
purpose — Мета поїздки
Куди та чому.
Типові налаштування: ""
lines — Витрати
Один рядок на кожну витрату. receipt — yes або no.
Типові налаштування: ""
Розширені налаштування
currency — Валюта
Короткий код або знак, що відображається з сумами, наприклад EUR.
Типові налаштування: "EUR"
Максимальна кількість вхідних байтів UTF-8: 30000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "travel_expenses",
"text": "{\"traveller\":\"Mira Kovac\",\"period\":\"3–4 червня 2026\",\"purpose\":\"Візит до постачальника Hartmann Paper у Bridgeport для узгодження графіка поставок.\",\"lines\":\"id,date,category,description,amount,receipt\\nE1,3 червня,Потяг,Зворотний квиток,86.50,yes\\nE2,3 червня,Готель,Одна ніч,112,yes\\nE3,3 червня,Харчування,Вечеря з постачальником,48.20,no\\nE4,4 червня,Таксі,Від станції до офісу,,no\",\"currency\":\"EUR\"}"
}
Напишіть річний звіт клубу або асоціації на основі нотаток. Кількість членів та фінанси вказуються точно так, як надано.
Поля введення та конфігурації
Основні налаштування
club — Клуб або асоціація
Додається дослівно.
Типові налаштування: ""
year — Рік
Додається дослівно.
Типові налаштування: ""
facts — Факти
Події, учасники, фінанси, подяки та плани. Достатньо простого конспекту.
Типові налаштування: ""
sender — Відправник та підпис
Ім'я, роль та контактні дані. Додається дослівно.
Типові налаштування: ""
Розширені налаштування
length — Довжина
Приблизна довжина чернетки.
short — Коротка · medium — Середня · long — Довга
Типові налаштування: "medium"
Максимальна кількість вхідних байтів UTF-8: 30000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "club_annual_report",
"text": "{\"club\":\"Riverside Rowing Club\",\"year\":\"2025\",\"facts\":\"У червні ми провели літню регату, в якій взяли участь 120 учасників. Було куплено два нових човна. Кількість членів клубу зросла з 84 до 97. Дохід склав 18 400 євро, а витрати — 16 900 євро. У 2026 році ми хочемо відремонтувати вітрильний клуб. Дякуємо волонтерам команди регати.\",\"length\":\"medium\",\"sender\":\"Анна Новак, голова\"}"
}
Напишіть звіт про передачу квартири на основі нотаток. Адреса, показники лічильників, ключі та присутні особи залишаються без змін.
Поля введення та конфігурації
Основні налаштування
address — Адреса
Додається дослівно.
Типові налаштування: ""
handover_date — Дата передачі
Додається дослівно.
Типові налаштування: ""
parties — Присутні особи
Імена та ролі. Додається дослівно.
Типові налаштування: ""
meters — Показники лічильників
Один лічильник на рядок з номером та показником. Додається дослівно.
Типові налаштування: ""
keys — Ключі
Що було передано. Додається дослівно.
Типові налаштування: ""
rooms_notes — Примітки по кімнатах
Стан, по кожній кімнаті. Дефекти та домовленості у вигляді простих нотаток.
Типові налаштування: ""
Максимальна кількість вхідних байтів UTF-8: 30000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "flat_handover",
"text": "{\"address\":\"Mill Road 3, flat 5, Bridgeport\",\"handover_date\":\"30 червня 2026\",\"parties\":\"Анна Новак (орендодавець), Том Берг (орендар)\",\"meters\":\"Електричне споживання 44812 кВт·год\\nВода 312 м3\",\"keys\":\"3 ключі від квартири, 1 ключ від підвалу\",\"rooms_notes\":\"Кухня чиста, одна подряпина на стільниці. Вітальня щойно пофарбована, без пошкоджень. Ванна кімната чиста, кран трохи підтікає. Орендар відремонтує кран до 15 липня.\"}"
}
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "staff_talk_prep",
"text": "{\"employee\":\"Міра Ковач\",\"meeting_date\":\"20 червня 2026\",\"role\":\"Асистент проєкту\",\"facts\":\"Добре спланувала переїзд майстерні. Провела навчання для двох нових колег. Звітність запізнювалася тричі навесні. Вона хотіла б мати більше контактів із клієнтами.\",\"tone\":\"friendly\"}"
}
Перетворіть касову книгу на касовий звіт. Сервер розраховує початковий та кінцевий залишок, доходи та витрати, а також повідомляє про відсутні дати та квитанції.
Поля введення та конфігурації
Основні налаштування
club — Клуб або асоціація
Додається дослівно.
Типові налаштування: ""
period — Період
Додається дослівно, наприклад, з 1 січня по 31 березня 2026 р.
Типові налаштування: ""
opening_balance — Початковий залишок
Залишок на початок періоду, наприклад 1250.50. Від'ємний залишок починається зі знака мінус.
Типові налаштування: ""
stated_closing — Зазначений кінцевий залишок
Опціонально: фактично підрахований залишок або залишок за даними банку, для порівняння.
Типові налаштування: ""
lines — Касова книга
Один рядок на кожну операцію. Вводьте дохід або витрату як додатне число. receipt — yes або no.
Типові налаштування: ""
treasurer_notes — Примітки
Опціонально: будь-яка інформація, яку має містити звіт, наприклад, призначення великих операцій.
Типові налаштування: ""
Розширені налаштування
currency — Валюта
Короткий код або знак, що відображається з сумами, наприклад EUR.
Типові налаштування: "EUR"
Максимальна кількість вхідних байтів UTF-8: 45000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "cash_report",
"text": "{\"club\":\"Riverside Rowing Club\",\"period\":\"1 січня – 31 березня 2026 р.\",\"opening_balance\":\"1250.00\",\"stated_closing\":\"1941.20\",\"lines\":\"id,date,description,income,expense,receipt\\nK1,2026-01-15,Членські внески за січень,640.00,,yes\\nK2,2026-01-28,Паливо для човна,,86.40,yes\\nK3,2026-02-10,Оренда залу,,180.00,yes\\nK4,2026-02-21,Продаж тортів на дні відкритих дверей,212.50,,no\\nK5,,Засоби для чищення,,34.90,yes\\nK6,2026-03-12,Пожертвування від пекарні,150.00,,yes\",\"treasurer_notes\":\"Квитанція за продаж тортів все ще у організатора. Готівка була підрахована наприкінці березня.\",\"currency\":\"EUR\"}"
}
Перевірте журнал пробігу рядок за рядком. Сервер розраховує кілометри кожної поїздки та повідомляє про пропуски, зменшення показників та відсутні деталі.
Поля введення та конфігурації
Основні налаштування
vehicle — Транспортний засіб
Додається дослівно, наприклад назва або номерний знак.
Типові налаштування: ""
period — Період
Необов'язково. Додається дослівно.
Типові налаштування: ""
lines — Поїздки
Один рядок на поїздку з показниками початку та завершення. trip_type — це вільний текст, наприклад, робоча або приватна поїздка.
Типові налаштування: ""
remarks — Примітки
Опціонально: будь-що, що має згадати перевірка.
Типові налаштування: ""
Максимальна кількість вхідних байтів UTF-8: 45000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "mileage_log_check",
"text": "{\"vehicle\":\"Корпоративний фургон BX-KM 418\",\"period\":\"Травень 2026\",\"lines\":\"id,date,driver,start_km,end_km,trip_type,purpose\\nF1,2026-05-04,T. Berg,45210,45262,бізнес,Візит клієнта в пекарню Hartmann\\nF2,2026-05-05,T. Berg,45262,45298,приватне,Поїздка в будівельний магазин\\nF3,2026-05-06,A. Novak,45310,45402,бізнес,Доставка на Мілл-Роуд\\nF4,2026-05-07,A. Novak,45402,45455,,Зустріч із постачальником у Бріджпорті\\nF5,2026-05-08,T. Berg,45450,45471,бізнес,Візит на об'єкт\",\"remarks\":\"\"}"
}
Підсумуйте час із табелів: початок, кінець та перерва. Сервер розраховує години за особами та тижнями, порівнює їх із цільовими годинами та повідомляє про нетиповий час.
Поля введення та конфігурації
Основні налаштування
organisation — Компанія або клуб
Додається дослівно.
Типові налаштування: ""
period — Період
Необов'язково. Додається дослівно.
Типові налаштування: ""
lines — Записи про час
Один рядок на робочий період. Час у форматі 08:30, перерва у цілих хвилинах.
Типові налаштування: ""
target_hours — Цільова кількість годин на тиждень
Опціонально: ціль для однієї особи на один календарний тиждень, наприклад 38.5.
Типові налаштування: ""
remarks — Примітки
Опціонально: що варто згадати у зведенні.
Типові налаштування: ""
Розширені налаштування
overnight — Зміни після опівночі
«Так»: час завершення раніше за час початку вважається наступним днем. «Ні»: про такі рядки повідомляється.
no — Ні · yes — Так
Типові налаштування: "no"
Максимальна кількість вхідних байтів UTF-8: 45000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Оцінюйте показники лічильників електроенергії, води або газу. Сервер розраховує споживання за період та повідомляє про відхилення та зменшення показників.
Поля введення та конфігурації
Основні налаштування
property — Об'єкт або господарство
Необов'язково. Додається дослівно.
Типові налаштування: ""
lines — Показники
Один рядок на один показник. Дати у форматі 2026-03-31 або 31.03.2026. Використовуйте одну одиницю на лічильник.
Типові налаштування: ""
remarks — Примітки
Опціонально: наприклад, заміна лічильника або тривала відсутність.
Типові налаштування: ""
Розширені налаштування
outlier_percent — Межа викиду у відсотках
Повідомляється про періоди, що настільки відхиляються від середнього значення лічильника. Від 10 до 500.
Типові налаштування: 50
Максимальна кількість вхідних байтів UTF-8: 40000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "meter_readings",
"text": "{\"property\":\"Mill Road 3, flat 5\",\"lines\":\"id,meter,date,reading,unit\\nZ1,Електричне споживання,2026-01-01,44120,kWh\\nZ2,Електричне споживання,2026-02-01,44430,kWh\\nZ3,Електричне споживання,2026-03-01,44710,kWh\\nZ4,Електричне споживання,2026-04-01,45410,kWh\\nZ5,Електричне споживання,2026-05-01,45700,kWh\\nZ6,Вода,2026-01-01,312.5,m3\\nZ7,Вода,2026-04-01,331,m3\\nZ8,Вода,2026-07-01,328.5,m3\",\"outlier_percent\":50,\"remarks\":\"Обігрівач, що використовувався в березні.\"}"
}
Перетворіть результати переобліку на інвентарну відомість. Сервер множить кількість на вартість одиниці, підсумовує за категоріями та повідомляє про дублікати та відсутні значення.
Поля введення та конфігурації
Основні налаштування
organisation — Магазин або клуб
Додається дослівно.
Типові налаштування: ""
inventory_date — Дата інвентаризації
Додається дослівно.
Типові налаштування: ""
location — Місцезнаходження
Необов'язково. Додається дослівно.
Типові налаштування: ""
lines — Позиції
Один рядок на кожну позицію з кількістю та вартістю за одиницю. Про відсутнє значення повідомляється, а рядок не включається до загальної суми.
Типові налаштування: ""
remarks — Примітки
Опціонально: будь-що, що має бути зазначено у списку.
Типові налаштування: ""
Розширені налаштування
currency — Валюта
Короткий код або знак, що відображається з сумами, наприклад EUR.
Типові налаштування: "EUR"
Максимальна кількість вхідних байтів UTF-8: 45000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "inventory_list",
"text": "{\"organisation\":\"Riverside Rowing Club\",\"inventory_date\":\"31 грудня 2025\",\"location\":\"Човня\",\"lines\":\"id,category,item,quantity,unit,unit_value\\nI1,Човни,Одинарний скель,3,шт,1800\\nI2,Човни,Пара весел,12,пара,95\\nI3,Кухня,Кавомашина,1,шт,240\\nI4,Кухня,Тарілки,48,шт,2.50\\nI5,Кухня,Тарілки,48,шт,2.50\\nI6,Мастерня,Дриль акумуляторний,2,шт,\\nI7,Мастерня,Змащувальна речовина,,банка,7.80\",\"remarks\":\"Підраховано двома членами правління.\",\"currency\":\"EUR\"}"
}
Перетворіть нотатки зміни на чітку передачу. З'являються лише пункти з нотаток, незавершені завдання перелічуються окремо, і нічого не оцінюється та не рекомендується.
Поля введення та конфігурації
Основні налаштування
area — Зона або команда
Додається дослівно, наприклад відділення, кухня або виробнича лінія.
Типові налаштування: ""
shift — Зміна та дата
Додається дослівно.
Типові налаштування: ""
handed_by — Хто передав
Необов'язково. Додається дослівно.
Типові налаштування: ""
received_by — Хто прийняв
Необов'язково. Додається дослівно.
Типові налаштування: ""
notes — Примітки до зміни
Достатньо звичайних нотаток. У передачі може з'явитися лише те, що тут написано.
Типові налаштування: ""
Максимальна кількість вхідних байтів UTF-8: 30000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "shift_handover",
"text": "{\"area\":\"Округ 2, команда догляду\",\"shift\":\"Пізня зміна, 12 травня 2026 р.\",\"handed_by\":\"А. Новак\",\"received_by\":\"Т. Берг\",\"notes\":\"Палата 12: у пана Гансена артеріальний тиск був 150/90 о 16:00, лікаря проінформовано, нових розпоряджень ще немає. Палата 14: пані Лунд отримала вечірні таблетки о 18:00. Палата 9: кнопка виклику не працює, техніка викликали, прийде завтра вранці. Палата 12: ще раз запитайте лікаря щодо нового розпорядження до 21:00. Доставлену постіль ще потрібно розкласти.\"}"
}
Перетворіть бюджетні показники на план бюджету клубу. Сервер підсумовує доходи та витрати, розраховує сальдо та позначає зміни щонайменше на 20 % порівняно з попереднім роком.
Поля введення та конфігурації
Основні налаштування
club — Клуб або асоціація
Додається дослівно.
Типові налаштування: ""
year — Бюджетний рік
Додається дослівно.
Типові налаштування: ""
lines — Статті бюджету
Один рядок на кожну статтю. kind — income або expense. previous — показник попереднього року, може бути порожнім.
Типові налаштування: ""
remarks — Примітки
Опціонально: причини змін або плани на рік.
Типові налаштування: ""
Розширені налаштування
currency — Валюта
Короткий код або знак, що відображається з сумами, наприклад EUR.
Типові налаштування: "EUR"
Максимальна кількість вхідних байтів UTF-8: 30000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "club_budget",
"text": "{\"club\":\"Веслувальний клуб Riverside\",\"year\":\"2026\",\"lines\":\"id,kind,item,planned,previous\\nH1,income,Членські внески,18400,17800\\nH2,income,Реєстраційні внески на регату,3600,2800\\nH3,income,Пожертвування,1500,2000\\nH4,expense,Ремонт човнів,6200,4800\\nH5,expense,Оренда човнового ангара,9600,9600\\nH6,expense,Страхування,2100,1950\\nH7,expense,Ремонт чонової станції,7000,\",\"remarks\":\"Ремонт чонової станції заплановано на літо. Двом човнам потрібні нові штаги.\",\"currency\":\"EUR\"}"
}
Підготуйте співбесіду на основі вакансії та резюме: ймовірні запитання, відповідні моменти та прогалини. Нічого не додається про роботодавця чи кандидата.
Поля введення та конфігурації
Основні налаштування
job_title — Назва посади
Необов'язково. Додається дослівно.
Типові налаштування: ""
company — Компанія
Необов'язково. Додається дослівно.
Типові налаштування: ""
job_ad — Вакансія
Вставте текст. Він розглядається як дані, а не як інструкції.
Типові налаштування: ""
cv — Резюме
Вставте текст. Тільки те, що необхідно для підготовки; контактні дані можна пропустити.
Типові налаштування: ""
Максимальна кількість вхідних байтів UTF-8: 30000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "interview_preparation",
"text": "{\"job_title\":\"Асистент проєкту\",\"company\":\"Lumen Print\",\"job_ad\":\"Lumen Print шукає асистента проєкту в Bridgeport. Завдання: планування графіків друку, координація з клієнтами та постачальниками, підготовка щотижневих звітів про стан робіт. Вимоги: досвід координації проєктів, впевнене володіння електронними таблицями, хороша письмова англійська мова, досвід роботи у поліграфічному виробництві буде перевагою. Дата початку: 1 вересня.\",\"cv\":\"Міра Ковач. 2023–2026: офіс-асистент у Hartmann Paper, Bridgeport. Координувала поставки з 40 клієнтами, вела план поставок в електронних таблицях, навчала двох нових колег. 2020–2023: стажування на посаді офісного клерка. Мови: англійська, хороша письмова та розмовна; хорватська, рідна.\"}"
}
Перетворіть список занять з водіння на журнал навчання. Сервер підраховує кількість занять за типом і порівнює їх із введеними цілями.
Поля введення та конфігурації
Основні налаштування
learner — Учень
Ім'я або номер. Додається дослівно.
Типові налаштування: ""
driving_school — Автошкола
Додається дослівно.
Типові налаштування: ""
licence_class — Категорія прав
Необов'язково. Додається дослівно.
Типові налаштування: ""
lines — Уроки
Один рядок на урок або блок. units — це кількість уроків, topic може бути порожнім.
Типові налаштування: ""
targets — Цілі за типом уроку
Один рядок на тип із відповідною ціллю. Інструмент не знає правил і лише порівнює ці показники.
Типові налаштування: ""
remarks — Примітки
Необов'язково: будь-що, що має бути зазначено в записі.
Типові налаштування: ""
Максимальна кількість вхідних байтів UTF-8: 30000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "driving_lesson_record",
"text": "{\"learner\":\"Mira K.\",\"driving_school\":\"Автошкола Lindenau\",\"licence_class\":\"B\",\"lines\":\"id,date,lesson_type,units,instructor,topic\\nL1,2026-03-03,Basic,2,T. Berg,Starting and steering\\nL2,2026-03-10,Basic,2,T. Berg,Junctions\\nL3,2026-03-17,Basic,2,T. Berg,Parking\\nL4,2026-04-07,Country road,3,A. Novak,Overtaking\\nL5,2026-04-14,Country road,2,A. Novak,\\nL6,2026-04-21,Motorway,4,A. Novak,Joining and leaving\\nL7,2026-05-05,Night,2,T. Berg,\\nL8,,Night,,T. Berg,Dipped headlights\",\"targets\":\"id,lesson_type,target_units\\nT1,Basic,12\\nT2,Country road,5\\nT3,Motorway,4\\nT4,Night,3\",\"remarks\":\"Урок L8 було перенесено, дата ще не визначена.\"}"
}
Перетворіть продукти для фарбування та примітки на картку фарбування. Сервер розраховує пропорцію змішування та кількість на основі введених продуктів, при цьому нічого не зазначається щодо шкіри.
Поля введення та конфігурації
Основні налаштування
client — Клієнт
Ім'я або номер клієнта. Додається дослівно.
Типові налаштування: ""
salon — Салон
Необов'язково. Додається дослівно.
Типові налаштування: ""
recipe_date — Дата
Необов'язково. Додається дослівно.
Типові налаштування: ""
lines — Продукти
Один рядок на продукт. Введіть частини для пропорції або кількість кожного продукту.
Типові налаштування: ""
total_amount — Загальна кількість
Опціонально: кількість для змішування, наприклад 120. Вона ділиться на частини.
Типові налаштування: ""
recipe_notes — Примітки щодо нанесення
Опціонально: черговість, час витримки, побажання клієнта.
Типові налаштування: ""
Розширені налаштування
unit — Одиниця виміру
До 4 літер, наприклад г або мл.
Типові налаштування: "g"
Максимальна кількість вхідних байтів UTF-8: 30000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "hair_colour_card",
"text": "{\"client\":\"Картка клієнта 1184\",\"salon\":\"Студія Lindenau\",\"recipe_date\":\"12 травня 2026\",\"lines\":\"id,product,shade,parts,amount\\nF1,Lumina Cream,7.1,1,\\nF2,Lumina Cream,6.0,1,\\nF3,Lumina Developer 6 %,,2,\",\"total_amount\":\"120\",\"unit\":\"g\",\"recipe_notes\":\"Спочатку коріння, потім на 30 хвилин, а потім довжину на останні 10 хвилин. Клієнт хоче крутий тон без червоного відтінку.\"}"
}
Створіть графік фотосесії на основі етапів та хвилин. Сервер розраховує весь час, буфери та перевищення, а ШІ формулює кожен етап.
Поля введення та конфігурації
Основні налаштування
shoot — Зйомка
Назва зйомки або клієнта. Додається дослівно.
Типові налаштування: ""
shoot_date — Дата
Необов'язково. Додається дослівно.
Типові налаштування: ""
location — Місцезнаходження
Необов'язково. Додається дослівно.
Типові налаштування: ""
start_time — Час початку
Формат 09:30.
Типові налаштування: "09:00"
latest_end — Заплановане завершення
Необов'язково, формат 18:30. Про пізніше завершення буде повідомлено.
Типові налаштування: ""
lines — Етапи
Один рядок на кожен етап із хвилинами. fixed_start є необов'язковим для часу, який не може змінюватися, наприклад, золота година о 19:40.
Типові налаштування: ""
remarks — Примітки
Необов'язково: побажання та деталі, які можуть допомогти при формулюванні етапів.
Типові налаштування: ""
Максимальна кількість вхідних байтів UTF-8: 30000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "photo_shoot_schedule",
"text": "{\"shoot\":\"Родина Berg, весняні фото\",\"shoot_date\":\"16 травня 2026\",\"location\":\"Mill Park\",\"start_time\":\"14:00\",\"latest_end\":\"16:30\",\"lines\":\"id,step,who,minutes,fixed_start\\nA1,Arrival and light check,Photographer,20,\\nA2,Family group at the lake,Photographer and family,30,14:30\\nA3,Children on the meadow,Assistant,25,\\nA4,Change of clothes,Family,15,\\nA5,Portraits in the old orchard,Photographer,40,15:40\\nA6,Couple at the bridge in low sun,Photographer,30,16:15\",\"remarks\":\"Родина хоче природні фото без позирування. Діти швидко втомлюються.\"}"
}
Складіть розклад весільного дня з кроків та хвилин. Сервер розраховує весь час, буфери та затримки, а ШІ формулює кожен крок.
Поля введення та конфігурації
Основні налаштування
wedding — Весілля
Імена пари. Додаються дослівно.
Типові налаштування: ""
wedding_date — Дата
Необов'язково. Додається дослівно.
Типові налаштування: ""
venue — Місце проведення
Необов'язково. Додається дослівно.
Типові налаштування: ""
start_time — Час початку
Формат 09:30.
Типові налаштування: "09:00"
latest_end — Заплановане завершення
Необов'язково, формат 00:30. Пізніший час завершення фіксується. Час, що раніше за час початку, вважається наступним днем.
Типові налаштування: ""
lines — Етапи
Один рядок на кожен крок із хвилинами. fixed_start є необов'язковим для часу, який не може змінюватися, наприклад, для церемонії.
Типові налаштування: ""
remarks — Примітки
Необов'язково: побажання та деталі, які можуть допомогти при формулюванні етапів.
Типові налаштування: ""
Максимальна кількість вхідних байтів UTF-8: 30000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "wedding_day_schedule",
"text": "{\"wedding\":\"Анна та Том\",\"wedding_date\":\"20 червня 2026\",\"venue\":\"Лінденхоф\",\"start_time\":\"09:00\",\"latest_end\":\"00:30\",\"lines\":\"id,step,who,minutes,fixed_start\\nW1,Hair and make-up,Anna and stylist,120,\\nW2,Couple pictures in the garden,Photographer,60,\\nW3,Drive to the church,Tom,30,\\nW4,Guests arrive,Ushers,30,13:00\\nW5,Ceremony,Pastor,45,13:30\\nW6,Reception with cake,Service team,75,\\nW7,Group pictures,Photographer,40,\\nW8,Drive to the Lindenhof,All,20,\\nW9,Dinner,Kitchen,120,18:00\\nW10,Speeches,Best man,45,\\nW11,First dance,Anna and Tom,15,20:30\\nW12,Party,DJ,240,\",\"remarks\":\"Торт від пекарні Hartmann. DJ привозить своє обладнання.\"}"
}
Перетворіть нотатки терапевта на чіткий аркуш для домашніх вправ. З'являються лише вправи з нотаток, без діагнозу та медичних порад.
Поля введення та конфігурації
Основні налаштування
patient — Пацієнт
Опціонально: достатньо імені або умовного позначення. Додається дослівно.
Типові налаштування: ""
therapist — Терапевт або кабінет
Додається дослівно.
Типові налаштування: ""
sheet_date — Дата
Необов'язково. Додається дослівно.
Типові налаштування: ""
notes — Нотатки терапевта
Вправи, як було домовлено, з кількістю повторень та інструкціями щодо їх виконання. Тут може з'явитися лише те, що написано.
Типові налаштування: ""
practice_contact — Контакти
Опціонально. Додається дослівно в кінці.
Типові налаштування: ""
Максимальна кількість вхідних байтів UTF-8: 30000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "home_exercise_sheet",
"text": "{\"patient\":\"Посилання 2207\",\"therapist\":\"Фізіотерапія Lindenau, К. Берг\",\"sheet_date\":\"5 травня 2026\",\"notes\":\"Підйоми на носки, тримаючись за стілець, 10 разів, 2 підходи, вранці та ввечері. Лежачи на спині, підтягніть коліно до грудей обома руками, утримуйте 20 секунд, 3 рази з кожного боку. Ходіть по рівній поверхні 15 хвилин щодня. Виконуйте вправи повільно. Принесіть цей аркуш на наступний прийом.\",\"practice_contact\":\"Фізіотерапія Lindenau, телефон 0123 456789\"}"
}
Перетворіть нотатки про догляд на нейтральний звіт. З'являються лише спостереження з нотаток, без діагнозу та порад, а також примітка про те, що звіт перевіряється кваліфікованим фахівцем.
Поля введення та конфігурації
Основні налаштування
care_client — Клієнт
Достатньо умовного позначення. Додається дослівно.
Типові налаштування: ""
report_date — Дата та зміна
Додається дослівно.
Типові налаштування: ""
written_by — Автор запису
Необов'язково. Додається дослівно.
Типові налаштування: ""
notes — Примітки про догляд
Що було помічено та зроблено. У звіті можуть з'явитися лише ті дані, що записані тут.
Типові налаштування: ""
Максимальна кількість вхідних байтів UTF-8: 30000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "care_report",
"text": "{\"care_client\":\"Посилання A-17\",\"report_date\":\"12 травня 2026 р., ранню зміну\",\"written_by\":\"А. Новак\",\"notes\":\"Умився біля раковини з допомогою о 08:00. Поснідав у денній кімнаті. Прогулявся до саду з ходунками приблизно 20 хвилин. Сказав, що нове крісло зручне. О 09:30 замінили батарейку в слуховому апараті. О 11:00 зателефонувала донька. Відкрите: запитати, чи потрібно перевірити гальма ходунків.\"}"
}
Перетворіть нотатки вихователя на звіт про спостереження. З'являються лише спостереження, без діагнозів, оцінок або класифікацій дитини.
Поля введення та конфігурації
Основні налаштування
child — Дитина
Достатньо імені або коду. Додається дослівно.
Типові налаштування: ""
child_group — Група
Необов'язково. Додається дослівно.
Типові налаштування: ""
observation_period — Період спостереження
Додається дослівно.
Типові налаштування: ""
observer — Хто спостерігав
Необов'язково. Додається дослівно.
Типові налаштування: ""
notes — Примітки
Що дитина робила та говорила. У звіті може бути лише те, що тут написано.
Типові налаштування: ""
Максимальна кількість вхідних байтів UTF-8: 30000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "childcare_observation",
"text": "{\"child\":\"Дитина А\",\"child_group\":\"Група «Соняшник»\",\"observation_period\":\"з 4 по 8 травня 2026 р.\",\"observer\":\"К. Берг\",\"notes\":\"Понеділок: будував вежу з дерев'яних кубиків під час вільної гри та рахував кубики вголос до 12. Вівторок: попросив іншу дитину допомогти нести коробку. Середа: малював обома руками близько 20 хвилин і сказав «сонце гаряче». Четвер: слухав історію в куточку для читання до кінця. П'ятниця: самостійно взув чоботи перед виходом на вулицю.\"}"
}
Напишіть повідомлення про смерть та короткий некролог на основі того, що заявляє родина. Імена та дати залишаються без змін, і нічого не вигадується про життя людини.
Поля введення та конфігурації
Основні налаштування
deceased — Ім'я померлого
Додається дослівно.
Типові налаштування: ""
born — Дата народження
Необов'язково. Додається дослівно.
Типові налаштування: ""
died — Дата смерті
Додається дослівно.
Типові налаштування: ""
facts — Що хоче сказати родина
Прості нотатки про життя людини. Тут може бути лише те, що написано.
Типові налаштування: ""
mourners — У жалобі
За бажанням: імена членів родини. Додається дослівно.
Типові налаштування: ""
service_details — Церемонія прощання
Опціонально: місце, дата та побажання. Додається дослівно.
Типові налаштування: ""
Максимальна кількість вхідних байтів UTF-8: 30000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "death_notice_obituary",
"text": "{\"deceased\":\"Анна Візенталь\",\"born\":\"3 березня 1941\",\"died\":\"12 жовтня 2026\",\"facts\":\"Вчителька в початковій школі Бріджпорт протягом 31 року. Співала в церковному хорі. Любила свій сад і двох онуків. Любила казати, що хорошу книгу неможливо прочитати до кінця.\",\"mourners\":\"Пауль та Лена Візенталь з Томом і Мією\",\"service_details\":\"Субота, 24 жовтня 2026, 11:00, каплиця на Мілл-Роуд. Замість квітів, будь ласка, розгляньте можливість зробити пожертву до шкільної бібліотеки.\"}"
}
Напишіть запрошення або протокол зборів власників. Порядок денний і рішення залишаються дослівними, без юридичних висновків і вигаданих строків.
Поля введення та конфігурації
Основні налаштування
document — Документ
Оберіть, що створити.
invitation — Запрошення · minutes — Протокол
Типові налаштування: "invitation"
property_name — Об'єкт
Додається дослівно.
Типові налаштування: ""
meeting_when — Дата та час
Додається дослівно.
Типові налаштування: ""
meeting_place — Місце
Додається дослівно.
Типові налаштування: ""
manager — Управитель нерухомості
Додається дослівно.
Типові налаштування: ""
agenda_items — Порядок денний
Один пункт на рядок. Додається дослівно.
Типові налаштування: ""
notes — Примітки
Запрошення: що слід згадати. Протокол: як пройшли збори. З'явитися може лише те, що написано тут.
Типові налаштування: ""
attendance — Присутні
Лише для протоколу: додається дослівно, наприклад, присутні 14 з 20 одиниць.
Типові налаштування: ""
resolutions — Рішення
Лише для протоколу: одне рішення на рядок із голосами та сумами. Додається дослівно.
Типові налаштування: ""
Максимальна кількість вхідних байтів UTF-8: 30000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "owners_meeting",
"text": "{\"document\":\"minutes\",\"property_name\":\"Власники Mill Road 3\",\"meeting_when\":\"Четвер, 18 червня 2026 р., 18:30\",\"meeting_place\":\"Конференц-зал громадського центру Lindenau\",\"manager\":\"Hartmann Property Management, S. Hartmann\",\"agenda_items\":\"1. Привітання\\n2. Річний звіт за 2025 рік\\n3. Ремонт даху\\n4. Інші питання\",\"notes\":\"Пані Берг запитала про графік ремонту даху. Менеджер запитає у покрівельної компанії та надасть відповідь. Про освітлення сходового маршу було згадано в розділі «Інші питання».\",\"attendance\":\"Присутні або представлені 14 з 20 власників\",\"resolutions\":\"Пункт 2: Річний звіт за 2025 рік затверджено. 13 так, 0 проти, 1 утримався.\\nПункт 3: Ремонт даху компанією Dachbau Lindenau затверджено у сумі 48 500,00 євро, виплачується з резервного фонду. 11 так, 2 проти, 1 утримався.\"}"
}
Упорядкуйте інструкції ветеринарної клініки в аркуш догляду для власників тварин. Без діагнозів, а також без ліків чи дозувань понад вхідні дані.
Поля введення та конфігурації
Основні налаштування
practice — Клініка
Додається дослівно.
Типові налаштування: ""
animal — Тварина
Кличка та вид. Додається дослівно.
Типові налаштування: ""
pet_owner — Власник
Необов'язково. Додається дослівно.
Типові налаштування: ""
visit_date — Дата візиту
Додається дослівно.
Типові налаштування: ""
notes — Інструкції клініки
Догляд, годування, ліки та дозування згідно з інструкцією, наступний візит. З'явитися може лише те, що написано тут.
Типові налаштування: ""
practice_contact — Контакти
Опціонально. Додається дослівно в кінці.
Типові налаштування: ""
Максимальна кількість вхідних байтів UTF-8: 30000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "pet_aftercare_sheet",
"text": "{\"practice\":\"Ветеринарна клініка Lindenau\",\"animal\":\"Мопс, собака\",\"pet_owner\":\"\",\"visit_date\":\"5 травня 2026 р.\",\"notes\":\"Після чищення зубів: м'яка їжа протягом 3 днів. Жодних іграшок для жування протягом 5 днів. Гель Demodent на ясна один раз на день ввечері протягом 5 днів, згідно з інструкцією. Якщо після 2-го дня з'явиться кровотеча, будь ласка, зателефонуйте в клініку. Огляд 14 травня о 10:30.\",\"practice_contact\":\"Ветеринарна клініка Lindenau, телефон 0123 456700\"}"
}
Поясніть ремонт простими словами. Сервер підсумовує вартість робіт та запчастин, а ШІ пояснює лише те, що вказано в замовленні та примітках майстерні.
Поля введення та конфігурації
Основні налаштування
workshop — Майстерня
Додається дослівно.
Типові налаштування: ""
vehicle — Транспортний засіб
Додається дослівно, наприклад модель і номерний знак.
Типові налаштування: ""
mileage — Пробіг
Необов'язково. Додається дослівно.
Типові налаштування: ""
lines — Робота та запчастини
Один рядок на кожну роботу або запчастину. kind — labour або part. Для робіт кількість означає години.
Типові налаштування: ""
workshop_notes — Примітки майстерні
Що було заявлено, виявлено та погоджено. Пояснити можна лише те, що тут написано.
Типові налаштування: ""
Розширені налаштування
currency — Валюта
Короткий код або знак, що відображається з сумами, наприклад EUR.
Типові налаштування: "EUR"
Максимальна кількість вхідних байтів UTF-8: 25000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "workshop_report",
"text": "{\"workshop\":\"Автосервіс Hartmann\",\"vehicle\":\"VW Golf, BX-KM 418\",\"mileage\":\"84210 km\",\"lines\":\"id,kind,description,quantity,unit_price\\nW1,labour,Replace front brake pads and discs,1.5,89.00\\nW2,labour,Annual service with oil change,2,89.00\\nW3,part,Front brake pads set,1,64.90\\nW4,part,Front brake discs,2,58.50\\nW5,part,Engine oil in litres,4.5,14.20\\nW6,part,Oil filter,1,12.80\\nW7,part,Wiper blades,1,\",\"workshop_notes\":\"Клієнт повідомив про скрип під час гальмування. Передні гальмівні диски були нижче межі зносу. Задні гальмівні колодки зношені приблизно наполовину, майстер перевірить їх під час наступного обслуговування. Ціна на щітки стеклоочисника ще має бути визначена.\",\"currency\":\"EUR\"}"
}
Порівняйте виміряні значення з введеними межами. Сервер позначає кожне значення як таке, що входить у межі або виходить за їх межі. Стандартні значення не додаються, і це не замінює тестування кваліфікованим електриком.
Поля введення та конфігурації
Основні налаштування
installation — Електроустановка
Додається дослівно, наприклад будівля та розподільчий щит.
Типові налаштування: ""
test_date — Дата тестування
Додається дослівно.
Типові налаштування: ""
tester — Перевірив
Необов'язково. Додається дослівно.
Типові налаштування: ""
lines — Вимірювання
Один рядок на одне значення. Ліміт визначається відповідним стандартом або виробником. limit_type — це max (значення не може бути вищим) або min (значення не може бути нижчим).
Типові налаштування: ""
remarks — Примітки
Опціонально: будь-що, що має бути зазначено в записі, наприклад, вимірювальний прилад.
Типові налаштування: ""
Максимальна кількість вхідних байтів UTF-8: 45000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "electrical_test_record",
"text": "{\"installation\":\"Mill Road 3, розподільний щит 1\",\"test_date\":\"12 травня 2026 р.\",\"tester\":\"Т. Берг\",\"lines\":\"id,circuit,measurement,value,unit,limit,limit_type\\nP1,Sockets,Insulation resistance,210,MOhm,1,min\\nP2,Sockets,Loop impedance,0.62,Ohm,1.37,max\\nP3,Oven,Loop impedance,1.54,Ohm,1.37,max\\nP4,Oven,RCD trip time,24,ms,30,max\\nP5,Lighting,Insulation resistance,,MOhm,1,min\\nP6,Lighting,RCD trip current,30,mA,30,max\",\"remarks\":\"Виміряно тим самим приладом на всіх контурах.\"}"
}
Перевірте журнал температурного режиму для холодильників та морозильних камер. Сервер знаходить показники, що виходять за межі введеного діапазону, та дні без показників. Без висновків щодо харчового законодавства.
Поля введення та конфігурації
Основні налаштування
kitchen — Кухня або підприємство
Додається дослівно.
Типові налаштування: ""
period — Період
Необов'язково. Додається дослівно.
Типові налаштування: ""
lines — Показники
Один рядок на кожне вимірювання. Дати на кшталт 2026-03-31 або 31.03.2026, час на кшталт 08:30. Вводьте нижню та верхню межу один раз для кожного приладу; порожні клітинки зберігають останній діапазон.
Типові налаштування: ""
remarks — Примітки
Опціонально: наприклад, вихідні дні, які пояснюють пропуск.
Типові налаштування: ""
Розширені налаштування
checks_per_day — Вимірювань на день
Дні з меншою кількістю вимірювань на прилад наводяться у списку. Від 1 до 6.
Типові налаштування: 1
Максимальна кількість вхідних байтів UTF-8: 45000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "temperature_log_check",
"text": "{\"kitchen\":\"Riverside Bistro\",\"period\":\"4–8 травня 2026 р.\",\"lines\":\"id,appliance,date,time,temperature,lower,upper,note\\nT1,Cold room,2026-05-04,08:00,4.0,0,7,\\nT2,Freezer,2026-05-04,08:05,-19,-25,-18,\\nT3,Cold room,2026-05-05,08:00,5.5,,,\\nT4,Freezer,2026-05-05,08:10,-16.5,,,Door open during delivery\\nT5,Cold room,2026-05-06,08:02,8.5,,,\\nT6,Cold room,2026-05-08,08:00,3,,,\\nT7,Freezer,2026-05-08,08:03,,,,\",\"checks_per_day\":1,\"remarks\":\"Закрито 7 травня.\"}"
}
Перетворіть рецепт на вагу. Сервер розраховує грами на інгредієнт, загальну вагу тіста, гідратацію та вихід тіста на основі пекарських відсотків або з рецепта в грамах.
Поля введення та конфігурації
Основні налаштування
recipe — Рецепт
Додається дослівно.
Типові налаштування: ""
lines — Інгредієнти
Один рядок на інгредієнт. role — flour, liquid або other. Заповнюйте percent у всіх рядках або amount_g у всіх рядках.
Типові налаштування: ""
pieces — Штуки
Скільки штук потрібно, наприклад 40.
Типові налаштування: ""
piece_weight — Вага тіста на одну штуку (г)
Вага тіста однієї штуки в грамах, наприклад 500.
Типові налаштування: ""
flour_weight — Або: вага борошна (г)
Замість штук: загальна кількість борошна в грамах, наприклад 10000.
Типові налаштування: ""
remarks — Примітки
Опціонально: будь-що, що має бути вказано в аркуші.
Типові налаштування: ""
Максимальна кількість вхідних байтів UTF-8: 12000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "bakers_percentage",
"text": "{\"recipe\":\"Пшенично-житняний хліб\",\"lines\":\"id,role,ingredient,percent,amount_g\\nD1,flour,Wheat flour,80,\\nD2,flour,Rye flour,20,\\nD3,liquid,Water,65,\\nD4,other,Salt,2,\\nD5,other,Fresh yeast,1,\",\"pieces\":\"40\",\"piece_weight\":\"500\",\"flour_weight\":\"\",\"remarks\":\"Тісто відпочиває всю ніч у холодній приміщенні.\"}"
}
Аналізуйте записи про вулики. Сервер підсумовує врожай меду з кожного вулика та повідомляє про тривалі перерви між записами. Без діагностики та порад щодо лікування.
Поля введення та конфігурації
Основні налаштування
apiary — Пасіка
Додається дослівно.
Типові налаштування: ""
year — Сезон
Необов'язково. Додається дослівно.
Типові налаштування: ""
lines — Записи
Один рядок на кожну перевірку або збір. Дати на кшталт 2026-03-31 або 31.03.2026. honey_kg лише для збору. Без ком у примітці, якщо вони не в лапках.
Типові налаштування: ""
remarks — Примітки
Опціонально: будь-що, що має бути зазначено в оцінці.
Типові налаштування: ""
Розширені налаштування
gap_days — Перерва понад (днів)
Вказується тривалий період без записів. Від 7 до 365.
Типові налаштування: 30
Максимальна кількість вхідних байтів UTF-8: 45000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "hive_record",
"text": "{\"apiary\":\"Пасіка Mill Road\",\"year\":\"2026\",\"lines\":\"id,hive,date,honey_kg,note\\nB1,Hive 1,2026-04-12,,Queen seen and brood on six frames\\nB2,Hive 1,2026-05-20,,Queen cups found\\nB3,Hive 1,2026-06-15,18.5,First harvest\\nB4,Hive 1,2026-07-20,14,Second harvest\\nB5,Hive 2,2026-04-12,,Few bees after winter\\nB6,Hive 2,2026-06-15,9.25,Harvest from one super\\nB7,Hive 3,2026-04-12,,New colony\\nB8,Hive 3,,,\",\"gap_days\":30,\"remarks\":\"\"}"
}
Перетворіть список колод на лісоматеріальний перелік. Сервер обчислює об'єм кожної колоди за формулою Губера на основі довжини та середнього діаметра та відображає розрахунок.
Поля введення та конфігурації
Основні налаштування
forest — Ліс або насадження
Додається дослівно.
Типові налаштування: ""
timber_date — Дата
Необов'язково. Додається дослівно.
Типові налаштування: ""
lines — Колоди
Один рядок на колоду з довжиною в метрах та середнім діаметром у сантиметрах.
Типові налаштування: ""
remarks — Примітки
Опціонально: будь-що, що має бути зазначено у списку.
Типові налаштування: ""
Максимальна кількість вхідних байтів UTF-8: 20000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "timber_list",
"text": "{\"forest\":\"Mill Forest, стенд 12\",\"timber_date\":\"3 лютого 2026\",\"lines\":\"id,species,length_m,diameter_cm\\nH1,Spruce,4,32\\nH2,Spruce,4,28.5\\nH3,Spruce,5,24\\nH4,Pine,4.5,30\\nH5,Pine,,26\",\"remarks\":\"Брикетні дрова складені на східній колії.\"}"
}
Перетворіть грядки та щільність у план посадки. Сервер розраховує кількість рослин на основі площі та щільності та округлює кожен рядок до цілих рослин.
Поля введення та конфігурації
Основні налаштування
planting_site — Місце посадки
Додається дослівно, наприклад проєкт або адреса.
Типові налаштування: ""
lines — Рядки посадки
Один рядок на одну рослину на грядці, з площею в квадратних метрах та кількістю рослин на квадратний метр.
Типові налаштування: ""
remarks — Примітки
Опціонально: будь-що, що має бути зазначено в плані.
Типові налаштування: ""
Максимальна кількість вхідних байтів UTF-8: 15000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "planting_plan",
"text": "{\"planting_site\":\"Двір на Mill Road\",\"lines\":\"id,bed,plant,area_m2,density_per_m2\\nG1,North bed,Lavender,12.5,6\\nG2,North bed,Ornamental grass,4.2,5\\nG3,South bed,Ground cover,18.4,8.5\\nG4,Hedge,Hornbeam,7.5,3\\nG5,South bed,Tulips,,25\",\"remarks\":\"Площа тюльпанів буде виміряна на місці наступного тижня.\"}"
}
Підсумуйте потужність на фазу для заходу. Сервер порівнює ватти на кожній фазі з введеним запобіжником. Це не замінює перевірку кваліфікованою особою.
Поля введення та конфігурації
Основні налаштування
event — Подія
Додається дослівно.
Типові налаштування: ""
fuse_amps — Запобіжник на фазу (А)
Від джерела живлення на об'єкті, наприклад 16 або 32.
Типові налаштування: 16
lines — Пристрої
Один рядок для кожного типу пристрою. phase — L1, L2 або L3. Потужність (Вт) з таблички характеристик або технічного паспорта.
Типові налаштування: ""
remarks — Примітки
Опціонально: будь-що, що має бути зазначено в огляді.
Типові налаштування: ""
Розширені налаштування
voltage — Напруга на фазу (В)
Напруга між фазою та нулем.
Типові налаштування: 230
Максимальна кількість вхідних байтів UTF-8: 20000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "power_load_phases",
"text": "{\"event\":\"Літній фестиваль, головна сцена\",\"fuse_amps\":16,\"voltage\":230,\"lines\":\"id,device,phase,quantity,watts\\nS1,LED spot,L1,12,180\\nS2,Moving head,L1,4,320\\nS3,Sound amplifier,L2,2,1800\\nS4,Mixing desk,L2,1,150\\nS5,Fog machine,L3,1,1500\\nS6,Bar fridge,,1,350\",\"remarks\":\"Бар живиться від тієї ж розподільчої коробки.\"}"
}
Вантажний лист із перевіркою корисного навантаження
load_list
Перетворіть перелік товарів на вантажний лист. Сервер підсумовує вагу, порівнює її з введеним корисним навантаженням і повідомляє про відсутні показники. Без висновків щодо кріплення вантажу.
Поля введення та конфігурації
Основні налаштування
vehicle — Транспортний засіб
Додається дослівно, наприклад номерний знак.
Типові налаштування: ""
tour — Рейс
Необов'язково. Додається дослівно, наприклад номер і дата.
Типові налаштування: ""
payload_kg — Корисне навантаження (кг)
З документів автомобіля, наприклад 1200.
Типові налаштування: ""
lines — Вантаж
Один рядок на кожну позицію з кількістю та вагою за одиницю в кілограмах. stop — це пункт розвантаження.
Типові налаштування: ""
remarks — Примітки
Опціонально: будь-що, що має бути зазначено у списку.
Типові налаштування: ""
Максимальна кількість вхідних байтів UTF-8: 25000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "load_list",
"text": "{\"vehicle\":\"Фургон BX-KM 418\",\"tour\":\"Тур 7, 12 травня 2026\",\"payload_kg\":\"1200\",\"lines\":\"id,stop,item,quantity,unit_weight_kg\\nL1,Bridgeport,Pallet of flour,2,320\\nL2,Bridgeport,Sack of sugar,10,25\\nL3,Mill Road,Crate of bottles,14,18.5\\nL4,Mill Road,Cleaning supplies,6,12.25\\nL5,Mill Road,Display stand,1,\",\"remarks\":\"Стійка для демонстрації прибуває зі складу вранці.\"}"
}
Перетворіть завдання з прибирання на план. Сервер розраховує кількість годин на тиждень для кожного об'єкта на основі частоти та хвилин і виводить список незаповнених рядків.
Поля введення та конфігурації
Основні налаштування
company — Клінінгова компанія або команда
Додається дослівно.
Типові налаштування: ""
period — Дійсно з
Необов'язково. Додається дослівно.
Типові налаштування: ""
lines — Завдання
Один рядок на завдання та об'єкт із зазначенням кількості разів на тиждень та хвилин за раз. Кожні два тижні — це 0,5 рази на тиждень.
Типові налаштування: ""
remarks — Примітки
Опціонально: будь-що, що має бути зазначено в плані.
Типові налаштування: ""
Максимальна кількість вхідних байтів UTF-8: 25000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "cleaning_plan",
"text": "{\"company\":\"Clearwater Services\",\"period\":\"Травень 2026\",\"lines\":\"id,site,task,times_per_week,minutes\\nR1,Mill Road office,Floors and desks,5,45\\nR2,Mill Road office,Washrooms,5,20\\nR3,Mill Road office,Windows,0.5,90\\nR4,Hartmann Bakery,Sales room,6,30\\nR5,Hartmann Bakery,Storage room,1,40\\nR6,Hartmann Bakery,Staff room,2,\",\"remarks\":\"Протокол для кімнати для персоналу буде узгоджено наступного тижня.\"}"
}
Розрахуйте фарбу для об'єкта за приміщеннями, вікнами та дверима, шарами й покривністю. Сервер обчислює літри та ємності, а ШІ пише короткий підсумок для пропозиції.
Поля введення та конфігурації
Основні налаштування
project — Проєкт
Додається дослівно, наприклад клієнт та адреса.
Типові налаштування: ""
lines — Приміщення та площі
Один рядок на кожне приміщення або поверхню. Площа стін дорівнює периметру, помноженому на висоту; extra_m2 напряму додає стелю або іншу площу; openings_m2 віднімається. Залиште coats порожнім, щоб використати число нижче.
Типові налаштування: ""
coverage_m2_per_l — Покривність (м² на літр)
З технічного листа продукту, наприклад 8 або 7,5.
Типові налаштування: ""
coats — Шари
Для рядків без власного числа. Від 1 до 6.
Типові налаштування: 2
container_l — Об'єм ємності (л)
Необов'язково: літри в одній ємності, наприклад 10 або 2,5.
Типові налаштування: "10"
remarks — Примітки
Необов'язково: що варто згадати в підсумку, наприклад кольори або стан стін.
Типові налаштування: ""
Розширені налаштування
reserve_percent — Запас (%)
Додається до загальної кількості літрів. Від 0 до 50.
Типові налаштування: 10
container_price — Ціна за ємність
Необов'язково: для вартості матеріалу, наприклад 89,90.
Типові налаштування: ""
currency — Валюта
Короткий код або знак, що відображається з сумами, наприклад EUR.
Типові налаштування: "EUR"
Максимальна кількість вхідних байтів UTF-8: 20000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "paint_quantity",
"text": "{\"project\":\"Родина Келлер, вул. Кленова\",\"lines\":\"id,room,perimeter_m,height_m,extra_m2,openings_m2,coats\\nR1,Вітальня,18.4,2.6,,5.2,\\nR2,Кухня,12,2.5,,3.1,\\nR3,Стеля у вітальні,,,21.5,,1\\nR4,Коридор,9.6,,,1.8,\",\"coverage_m2_per_l\":\"8\",\"coats\":2,\"container_l\":\"10\",\"reserve_percent\":10,\"container_price\":\"89.90\",\"currency\":\"EUR\",\"remarks\":\"Стіни в теплому білому, стеля в чистому білому. Дрібні тріщини на кухні спершу зашпаровуються. Висоту коридору вимірюють на місці.\"}"
}
Розрахуйте плитку, клей і затирку за площами об'єкта. Сервер додає відходи, округлює вгору до цілих упаковок для кожної плитки і рахує мішки з введеної витрати.
Поля введення та конфігурації
Основні налаштування
project — Проєкт
Додається дослівно, наприклад клієнт та адреса.
Типові налаштування: ""
lines — Поверхні
Один рядок на кожну поверхню з чистою площею в квадратних метрах. tile вказує плитку. waste_percent і pack_m2 можуть бути порожніми, щоб використати значення нижче.
Типові налаштування: ""
waste_percent — Відходи (%)
Для рядків без власного значення. Від 0 до 50.
Типові налаштування: 10
pack_m2 — м² в упаковці
Необов'язково: для рядків без власного значення, наприклад 1,44.
Типові налаштування: ""
remarks — Примітки
Необов'язково: що варто згадати в підсумку, наприклад схему укладання або основу.
Типові налаштування: ""
Розширені налаштування
adhesive_kg_m2 — Клей (кг на м²)
Необов'язково: витрата з технічного листа, наприклад 3,5.
Типові налаштування: ""
adhesive_bag_kg — Мішок клею (кг)
Необов'язково, наприклад 25.
Типові налаштування: ""
grout_kg_m2 — Затирка (кг на м²)
Необов'язково: витрата з технічного листа для цієї плитки та шва, наприклад 0,5.
Типові налаштування: ""
grout_bag_kg — Мішок затирки (кг)
Необов'язково, наприклад 5.
Типові налаштування: ""
Максимальна кількість вхідних байтів UTF-8: 20000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "tile_quantity",
"text": "{\"project\":\"Ванна і кухня, вул. Млинова 3\",\"lines\":\"id,surface,tile,area_m2,waste_percent,pack_m2\\nF1,Підлога у ванній,Плитка A 60x60,6.8,,\\nF2,Стіна у ванній,Плитка B 30x60,22.4,15,1.08\\nF3,Стіна на кухні,Плитка B 30x60,4.2,,1.08\\nF4,Підлога в коридорі,Плитка A 60x60,,,\",\"waste_percent\":10,\"pack_m2\":\"1.44\",\"adhesive_kg_m2\":\"3.5\",\"adhesive_bag_kg\":\"25\",\"grout_kg_m2\":\"0.5\",\"grout_bag_kg\":\"5\",\"remarks\":\"Стіну у ванній викладають по діагоналі. Підлогу в коридорі вимірюють після демонтажу старого покриття.\"}"
}
Розрахуйте черепицю, рейки обрешітки та гребінь за скатами даху об'єкта. Сервер використовує кількість черепиць на квадратний метр і крок обрешітки від виробника та додає відходи.
Поля введення та конфігурації
Основні налаштування
project — Проєкт
Додається дослівно, наприклад клієнт та адреса.
Типові налаштування: ""
lines — Скати даху
Один рядок на кожен скат даху з площею по схилу в квадратних метрах. ridge_m це довжина гребеня або ребра, яку треба покрити вздовж цього ската; спільний гребінь вводьте лише один раз.
Типові налаштування: ""
tiles_per_m2 — Черепиць на м²
Дані виробника для цієї черепиці та кроку обрешітки, наприклад 10,5.
Типові налаштування: ""
batten_gauge_cm — Крок обрешітки (см)
Необов'язково: відстань між рейками, наприклад 33,5. Без неї рейки не розраховуються.
Типові налаштування: ""
waste_percent — Відходи (%)
Додається до черепиці та рейок. Від 0 до 30.
Типові налаштування: 5
remarks — Примітки
Необов'язково: що варто згадати в підсумку, наприклад модель черепиці або форму даху.
Типові налаштування: ""
Розширені налаштування
ridge_tiles_per_m — Гребеневих черепиць на метр
Необов'язково: дані виробника, наприклад 2,5.
Типові налаштування: ""
Максимальна кількість вхідних байтів UTF-8: 12000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "roofing_material",
"text": "{\"project\":\"Будинок Берг, вул. Липова 7\",\"lines\":\"id,roof_face,area_m2,ridge_m\\nD1,Південний скат,62.4,10.4\\nD2,Північний скат,62.4,\\nD3,Дах гаража,18.3,\\nD4,Козирок над входом,,\",\"tiles_per_m2\":\"10.5\",\"batten_gauge_cm\":\"33.5\",\"waste_percent\":5,\"ridge_tiles_per_m\":\"2.5\",\"remarks\":\"Червона глиняна черепиця, як на старому даху. Козирок вимірюють, коли встановлять риштування.\"}"
}
Перетворіть шибки на список замовлення. Сервер розраховує площу на шибку та позицію, необов'язкову мінімальну площу шибки та вагу з площі, товщини та 2,5 кг на м² і мм.
Поля введення та конфігурації
Основні налаштування
customer — Клієнт або замовлення
Додається дослівно.
Типові налаштування: ""
order_ref — Номер замовлення
Необов'язково. Додається дослівно.
Типові налаштування: ""
lines — Шибки
Один рядок на кожну позицію з шириною та висотою в міліметрах, товщиною в міліметрах і кількістю. Для склопакета або ламінованого скла введіть суму товщин стекол.
Типові налаштування: ""
remarks — Примітки
Необов'язково: що варто згадати в замовленні, наприклад обробку кромки або доставку.
Типові налаштування: ""
Розширені налаштування
min_area_m2 — Мінімальна площа шибки (м²)
Необов'язково: як у прайс-листі постачальника, наприклад 0,5. Менші шибки рахуються з цією площею.
Типові налаштування: ""
Максимальна кількість вхідних байтів UTF-8: 30000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "glass_order",
"text": "{\"customer\":\"Новак кухні та ванні\",\"order_ref\":\"GL-2026-114\",\"lines\":\"id,position,glass_type,width_mm,height_mm,thickness_mm,quantity\\nG1,Кухонне вікно,Склопакет 4/16/4,1200,1400,8,2\\nG2,Ванна кімната,Матове скло,600,450,6,1\\nG3,Полиця,Флоат-скло,800,250,8,3\\nG4,Двері,Флоат-скло,900,,8,1\",\"min_area_m2\":\"0.5\",\"remarks\":\"Полиці з полірованими кромками. Висоту скла для дверей повідомимо після монтажу коробки.\"}"
}
Перетворіть список домашніх речей на пакувальний список. Сервер підсумовує об'єм за приміщеннями, додає запас і обирає найменший відповідний транспорт із власного списку.
Поля введення та конфігурації
Основні налаштування
move — Переїзд
Додається дослівно, наприклад клієнт і обидві адреси.
Типові налаштування: ""
move_date — Дата переїзду
Необов'язково. Додається дослівно.
Типові налаштування: ""
lines — Домашні речі
Один рядок на кожен вид речей із кількістю та кубічними метрами для одного предмета. Стовпець note призначений для вказівок щодо пакування, наприклад крихке або розібрати.
Типові налаштування: ""
vehicles — Власні транспортні засоби
Необов'язково: один рядок на кожен транспортний засіб з його вантажним об'ємом у кубічних метрах. Пропонується найменший, що підходить.
Типові налаштування: ""
reserve_percent — Запас (%)
Додається до загального об'єму на проміжки під час складання. Від 0 до 50.
Типові налаштування: 10
remarks — Примітки
Необов'язково: що варто згадати в пакувальному списку, наприклад поверхи або ліфт.
Типові налаштування: ""
Максимальна кількість вхідних байтів UTF-8: 32000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "removal_volume",
"text": "{\"move\":\"Родина Гартман, з вул. Млинової 3 на вул. Липову 7\",\"move_date\":\"12 червня 2026 р.\",\"lines\":\"id,room,item,quantity,volume_m3,note\\nU1,Вітальня,Тримісний диван,1,1.8,\\nU2,Вітальня,Книжкова шафа,2,0.9,Розібрати\\nU3,Кухня,Коробка для переїзду,25,0.1,Крихке\\nU4,Спальня,Шафа для одягу,1,2.5,Розібрати\\nU5,Спальня,Ліжко 160 x 200,1,1.5,\\nU6,Підвал,Велосипед,2,,\",\"vehicles\":\"id,vehicle,volume_m3\\nV1,Фургон,12\\nV2,Вантажівка 7.5 т,35\\nV3,Вантажівка 12 т,50\",\"reserve_percent\":10,\"remarks\":\"Третій поверх без ліфта в старій квартирі. Підвал перевіряють у день огляду.\"}"
}
Перетворіть кількість знаків на пропозицію. Сервер переводить знаки з пробілами в нормативні рядки, множить на ціну за рядок, додає надбавку за терміновість і перевіряє мінімальну оплату.
Поля введення та конфігурації
Основні налаштування
customer — Клієнт
Додається дослівно.
Типові налаштування: ""
offer_number — Номер пропозиції
Необов'язково. Додається дослівно.
Типові налаштування: ""
language_pair — Мови
Необов'язково. Додається дослівно, наприклад з німецької на англійську.
Типові налаштування: ""
deadline — Здача
Необов'язково. Додається дослівно.
Типові налаштування: ""
lines — Документи
Один рядок на кожен документ із кількістю знаків із пробілами, як її рахує текстовий редактор.
Типові налаштування: ""
price_per_line — Ціна за рядок
Ціна без податку за один нормативний рядок, наприклад 1,35.
Типові налаштування: ""
line_chars — Знаків у рядку
Кількість знаків із пробілами, що становить один нормативний рядок. Від 30 до 100.
Типові налаштування: 55
rush_percent — Надбавка за терміновість (%)
0 без надбавки. Від 0 до 200.
Типові налаштування: 0
remarks — Примітки
Необов'язково: що варто згадати в пропозиції, наприклад тематику або формат.
Типові налаштування: ""
Розширені налаштування
rounding — Округлення
Як рахуються рядки кожного документа.
exact — Точно, два знаки після коми · up — Округлювати до цілих рядків у кожному документі
Типові налаштування: "exact"
minimum_fee — Мінімальна оплата
Необов'язково: застосовується, якщо загальна сума менша, наприклад 40.
Типові налаштування: ""
currency — Валюта
Короткий код або знак, що відображається з сумами, наприклад EUR.
Типові налаштування: "EUR"
Максимальна кількість вхідних байтів UTF-8: 12000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "standard_line_offer",
"text": "{\"customer\":\"Пекарня Гартман ТОВ\",\"offer_number\":\"A-2026-071\",\"language_pair\":\"З німецької на англійську\",\"deadline\":\"протягом 5 робочих днів\",\"lines\":\"id,document,characters\\nN1,Договір оренди,12480\\nN2,Супровідний лист,1.830\\nN3,Додаток план поверху,\",\"price_per_line\":\"1.35\",\"line_chars\":55,\"rush_percent\":25,\"rounding\":\"exact\",\"minimum_fee\":\"40\",\"currency\":\"EUR\",\"remarks\":\"Юридична тематика. Додаток рахується, щойно скан стане читабельним.\"}"
}
Перетворіть зважені вироби на квитанцію про купівлю. Сервер розраховує чисте золото з ваги та проби, а виплату з денної ціни, введеної підприємством. Ціни ззовні не завантажуються.
Поля введення та конфігурації
Основні налаштування
business — Покупець
Додається дослівно, наприклад назва магазину та адреса.
Типові налаштування: ""
seller — Продавець
Необов'язково. Додається дослівно.
Типові налаштування: ""
receipt_date — Дата
Додається дослівно.
Типові налаштування: ""
receipt_number — Номер квитанції
Необов'язково. Додається дослівно.
Типові налаштування: ""
lines — Придбані вироби
Один рядок на кожен виріб із вагою в грамах і пробою в тисячних частках, наприклад 585 або 750. Зважуйте без каменів; зазначте це у стовпці note.
Типові налаштування: ""
price_per_g — Ціна за грам чистого золота
Ціна на сьогодні, встановлена підприємством, наприклад 58,40. Ззовні нічого не завантажується.
Типові налаштування: ""
payout_percent — Частка виплати (%)
Частка вартості чистого золота, що виплачується. Від 1 до 100.
Типові налаштування: 100
remarks — Примітки
Необов'язково: що варто згадати в квитанції, наприклад як перевірялися вироби.
Типові налаштування: ""
Розширені налаштування
currency — Валюта
Короткий код або знак, що відображається з сумами, наприклад EUR.
Типові налаштування: "EUR"
Максимальна кількість вхідних байтів UTF-8: 20000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "gold_purchase_receipt",
"text": "{\"business\":\"Ювелірна майстерня Берг, Ринкова пл. 4\",\"seller\":\"Анна Новак\",\"receipt_date\":\"14 травня 2026 р.\",\"receipt_number\":\"AK-0193\",\"lines\":\"id,item,weight_g,fineness,note\\nA1,Перстень,4.2,585,\\nA2,Ланцюжок,12.75,750,\\nA3,Сережки,0.875,333,зважено без каменів\\nA4,Браслет,,585,застібку ще треба зняти\",\"price_per_g\":\"58.40\",\"payout_percent\":90,\"currency\":\"EUR\",\"remarks\":\"Проби перевірено лупою, ланцюжок перевірено кислотою на застібці.\"}"
}
Перетворіть заміри густини на журнал варіння. Сервер розраховує видимий ступінь зброджування та оцінку алкоголю за початковою і кінцевою густиною в градусах Плато і вказує використану формулу.
Поля введення та конфігурації
Основні налаштування
brewery — Пивоварня
Додається дослівно.
Типові налаштування: ""
brew — Варка
Додається дослівно, наприклад пиво та номер партії.
Типові налаштування: ""
brew_date — День варіння
Необов'язково. Додається дослівно.
Типові налаштування: ""
og_plato — Початкова густина (°P)
Виміряно перед внесенням дріжджів, наприклад 12,5.
Типові налаштування: ""
fg_plato — Кінцева густина (°P)
Необов'язково. Якщо порожньо, використовується замір з найпізнішою датою.
Типові налаштування: ""
lines — Показники
Один рядок на кожен замір. Дати у форматі 2026-03-31 або 31.03.2026. Густина в градусах Плато, температура в градусах Цельсія; обидва поля можуть бути порожніми.
Типові налаштування: ""
remarks — Примітки
Необов'язково: що варто згадати в журналі, наприклад дріжджі або хміль.
Типові налаштування: ""
Розширені налаштування
batch_l — Партія (л)
Необов'язково: літри у бродильному чані, наприклад 50.
Типові налаштування: ""
Максимальна кількість вхідних байтів UTF-8: 20000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "brew_log",
"text": "{\"brewery\":\"Пивоварня Млинова\",\"brew\":\"Пейл-ель, партія 27\",\"brew_date\":\"2 березня 2026 р.\",\"og_plato\":\"12.5\",\"fg_plato\":\"\",\"lines\":\"id,date,stage,gravity_plato,temperature_c,note\\nS1,2026-03-02,Внесення дріжджів,12.5,12,Дріжджі регідратовано\\nS2,2026-03-05,День 3,6.2,14,Висока шапка піни\\nS3,09.03.2026,День 7,3.1,15,Сухе охмелення\\nS4,2026-03-16,Розлив,2.8,4,\",\"batch_l\":\"50\",\"remarks\":\"Ферментер 2. Цукор для карбонізації додано під час розливу.\"}"
}
Перетворіть ділянки маршруту на план часу. Сервер розраховує час ходьби на кожній ділянці за правилом DIN 33466, додає перерви і показує прибуття та найпізніший час у кожній точці.
Поля введення та конфігурації
Основні налаштування
tour — Рейс
Додається дослівно.
Типові налаштування: ""
guide — Гід
Необов'язково. Додається дослівно.
Типові налаштування: ""
tour_date — Дата
Необов'язково. Додається дослівно.
Типові налаштування: ""
lines — Ділянки
Один рядок на кожну ділянку в порядку руху, з відстанню в кілометрах, підйомом і спуском у метрах та перервою в хвилинах наприкінці ділянки.
Типові налаштування: ""
start_time — Час початку
Час у форматі 08:30.
Типові налаштування: "08:00"
latest_return — Найпізніше повернення
Необов'язково: час у форматі 17:00, наприклад до темряви або до останнього автобуса. Тоді для кожної точки вказується найпізніший час.
Типові налаштування: ""
pace_percent — Коефіцієнт групи
Множить кожен час ходьби. Менше 100 для швидкої групи, більше 100 для повільної.
Необов'язково: що варто згадати в плані, наприклад місце зустрічі або спорядження.
Типові налаштування: ""
Максимальна кількість вхідних байтів UTF-8: 12000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "hiking_time_plan",
"text": "{\"tour\":\"Маршрут трьома вершинами з Млинової долини\",\"guide\":\"Т. Берг\",\"tour_date\":\"21 червня 2026 р.\",\"lines\":\"id,leg,distance_km,ascent_m,descent_m,break_min\\nT1,Від парковки до хатини Вільха,4.5,600,0,20\\nT2,Від хатини Вільха до вершини,2.2,450,50,30\\nT3,Від вершини до долини,7.8,0,1000,0\",\"start_time\":\"08:00\",\"latest_return\":\"17:00\",\"pace_percent\":\"100\",\"remarks\":\"Місце зустрічі на парковці. Сухий пайок для вершини.\"}"
}
Порівняйте обладнання з технічного райдера з власним складом. Сервер підсумовує обидва списки за позиціями і видає список нестачі з кількостями.
Поля введення та конфігурації
Основні налаштування
event — Подія
Додається дослівно.
Типові налаштування: ""
venue — Місце проведення
Необов'язково. Додається дослівно.
Типові налаштування: ""
lines — Райдер: необхідне обладнання
Один рядок на кожну позицію з райдера з потрібною кількістю. Стовпець category необов'язковий, наприклад мікрофони.
Типові налаштування: ""
available — Власний склад
Один рядок на кожну позицію з кількістю, доступною на цю дату. Використовуйте ті самі назви, що й у райдері.
Типові налаштування: ""
remarks — Примітки
Необов'язково: що варто згадати в списку, наприклад контактну особу або кінцевий термін.
Типові налаштування: ""
Максимальна кількість вхідних байтів UTF-8: 50000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "rider_stock_check",
"text": "{\"event\":\"Літній фестиваль, головна сцена, гурт B\",\"venue\":\"Прибережний парк\",\"lines\":\"id,category,item,quantity\\nR1,Мікрофони,Shure SM58,6\\nR2,Мікрофони,Shure Beta 52A,1\\nR3,Стійки,Висока мікрофонна стійка,8\\nR4,Монітори,Сценічний монітор,4\\nR5,Мікрофони,shure sm-58,2\\nR6,Кабелі,Кабель XLR 10 м,\",\"available\":\"id,item,quantity\\nB1,Shure SM58,6\\nB2,Висока мікрофонна стійка,10\\nB3,Сценічний монітор,2\\nB4,DI-бокс,4\",\"remarks\":\"Відсутні позиції уточнюють з менеджером гурту в понеділок.\"}"
}
Оцініть перевірки станцій з приманкою. Сервер рахує поїдання за станціями, порівнює кожну перевірку з попередньою і показує прострочені станції. Без висновків щодо засобів чи законодавчих обов'язків.
Поля введення та конфігурації
Основні налаштування
customer — Клієнт або об'єкт
Додається дослівно.
Типові налаштування: ""
technician — Виконавець
Необов'язково. Додається дослівно.
Типові налаштування: ""
lines — Перевірки
Один рядок на кожну станцію та перевірку. finding: none, partial, full, damaged або no_access. Дати у форматі 2026-05-31 або 31.05.2026.
Типові налаштування: ""
interval_days — Інтервал перевірок (дні)
Як узгоджено з клієнтом. Від 1 до 365.
Типові налаштування: 28
remarks — Примітки
Необов'язково: що варто згадати у звіті, наприклад заходи, узгоджені на місці.
Типові налаштування: ""
Розширені налаштування
report_date — Звітна дата
Необов'язково, наприклад 2026-05-31. Прострочені станції рахуються до цього дня; якщо порожньо, використовується остання перевірка в таблиці.
Типові налаштування: ""
Максимальна кількість вхідних байтів UTF-8: 30000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "bait_station_check",
"text": "{\"customer\":\"Пекарня Гартман, вул. Млинова 4\",\"technician\":\"Й. Ковальський\",\"lines\":\"id,bait_station,date,bait_finding,note\\nK1,S1 комора,2026-03-02,none,\\nK2,S2 рампа,2026-03-02,partial,\\nK3,S3 двір,2026-03-02,none,\\nK4,S1 комора,2026-03-30,none,\\nK5,S2 рампа,2026-03-30,full,Послід біля станції\\nK6,S3 двір,2026-03-30,no_access,Піддони перед станцією\\nK7,S1 комора,2026-05-04,none,\\nK8,S2 рампа,2026-05-04,partial,Щілину під воротами закрив клієнт\",\"interval_days\":28,\"report_date\":\"2026-05-04\",\"remarks\":\"Клієнт просить звіт до аудиту.\"}"
}
Перевірте заміри води в басейні, як-от pH, хлор і температуру, за внесеними межами. Сервер позначає відхилення та дні без замірів. Без правових висновків.
Поля введення та конфігурації
Основні налаштування
facility — Басейн або об'єкт
Додається дослівно.
Типові налаштування: ""
period — Період
Необов'язково. Додається дослівно.
Типові налаштування: ""
tester — Перевірив
Необов'язково. Додається дослівно.
Типові налаштування: ""
lines — Показники
Один рядок на кожен час заміру. Залиште клітинку порожньою, якщо значення не вимірювали. Дати у форматі 2026-05-31 або 31.05.2026.
Типові налаштування: ""
limits — Межі
Один рядок на кожен параметр із межами, що діють для об'єкта. Порожній басейн означає всі басейни. Інструмент не знає правил і порівнює лише з цими значеннями.
Типові налаштування: ""
remarks — Примітки
Опціонально: наприклад, вихідні дні, які пояснюють пропуск.
Типові налаштування: ""
Розширені налаштування
checks_per_day — Вимірювань на день
Показуються дні з меншою кількістю замірів на басейн. Від 1 до 6.
Типові налаштування: 1
Максимальна кількість вхідних байтів UTF-8: 40000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "pool_water_log",
"text": "{\"facility\":\"Спа-готель Лінденау\",\"period\":\"4 до 6 травня 2026 р.\",\"tester\":\"М. Берг\",\"lines\":\"id,pool,date,time,ph,free_chlorine,combined_chlorine,water_temp,note\\nW1,Критий басейн,2026-05-04,08:00,7.2,0.5,0.1,28.0,\\nW2,Джакузі,2026-05-04,08:10,7.4,0.9,0.15,36.5,\\nW3,Критий басейн,2026-05-05,08:00,7.8,0.4,0.25,28.5,Багато гостей напередодні ввечері\\nW4,Джакузі,2026-05-05,08:05,7.3,,0.1,37.0,Тест-смужки для хлору закінчилися\\nW5,Критий басейн,2026-05-06,08:00,7.1,0.2,0.1,27.5,\",\"limits\":\"id,pool,parameter,lower,upper\\nG1,,ph,6.5,7.6\\nG2,,free_chlorine,0.3,0.6\\nG3,,combined_chlorine,,0.2\\nG4,Джакузі,free_chlorine,0.7,1.0\\nG5,Джакузі,water_temp,,37\",\"checks_per_day\":1,\"remarks\":\"Фільтр джакузі промили зворотним потоком 5 травня.\"}"
}
Перетворіть примітки із заняття на звіт для власника і план домашніх вправ. Сервер розраховує хвилини вправ, а ШІ використовує лише вправи з введених даних.
Поля введення та конфігурації
Основні налаштування
dog — Собака
Кличка і порода. Додається дослівно.
Типові налаштування: ""
pet_owner — Власник
Необов'язково. Додається дослівно.
Типові налаштування: ""
trainer — Тренер або кінологічна школа
Додається дослівно.
Типові налаштування: ""
session_date — Дата заняття
Необов'язково. Додається дослівно.
Типові налаштування: ""
session_notes — Примітки із заняття
Що відпрацьовували і спостерігали та що домовилися робити вдома. У звіті може з'явитися лише те, що написано тут.
Типові налаштування: ""
lines — Домашні вправи
Один рядок на кожну вправу, як домовлено: як, разів на день, хвилин за раз і днів на тиждень.
Типові налаштування: ""
next_session — Наступне заняття
Необов'язково. Додається дослівно.
Типові налаштування: ""
Максимальна кількість вхідних байтів UTF-8: 20000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "dog_training_report",
"text": "{\"dog\":\"Бруно, лабрадор\",\"pet_owner\":\"Родина Новак\",\"trainer\":\"Кінологічна школа Лінденау, А. Берг\",\"session_date\":\"12 травня 2026 р.\",\"session_notes\":\"Відпрацьовували ходьбу на провислому повідку вздовж доріжки в парку. Спершу Бруно тягнув до інших собак, а після кількох кіл спокійно йшов поруч із власником. Підкликання добре вдавалося з довгим повідком. Удома тренуйтеся в саду перед прогулянками і завершуйте вправу, поки Бруно ще подобається. Винагороджуйте маленькими шматочками його звичайного корму.\",\"lines\":\"id,exercise,instruction,times_per_day,minutes,days_per_week\\nH1,Ходьба на провислому повідку,У саду перед прогулянкою,2,5,6\\nH2,Підкликання з довгим повідком,Покликати один раз і одразу винагородити,1,10,5\\nH3,Сидіти й чекати біля дверей,Перед відчиненням дверей,3,2,7\",\"next_session\":\"19 травня 2026 р., 17:00\"}"
}
Перетворіть записи про перебування в готелі для тварин на звіт для власника. Сервер рахує годування, прогулянки та хвилини на день, а ШІ пише доброзичливий текст без ветеринарних висновків.
Поля введення та конфігурації
Основні налаштування
animal — Тварина
Кличка та вид. Додається дослівно.
Типові налаштування: ""
pet_owner — Власник
Необов'язково. Додається дослівно.
Типові налаштування: ""
boarding — Готель для тварин або доглядач
Додається дослівно.
Типові налаштування: ""
stay — День або період
Додається дослівно.
Типові налаштування: ""
lines — Записи
Один рядок на кожен запис. activity: meal, walk, play, rest, care або other. Хвилини для прогулянок і гри. Корм і кількість зберігаються дослівно. Дати у форматі 2026-05-31 або 31.05.2026.
Типові налаштування: ""
remarks — Примітки для власника
Необов'язково: як тварина освоїлася, що їй сподобалося. У тексті може з'явитися лише те, що написано тут.
Типові налаштування: ""
Максимальна кількість вхідних байтів UTF-8: 25000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "pet_boarding_report",
"text": "{\"animal\":\"Лотте, такса\",\"pet_owner\":\"Пані Вагнер\",\"boarding\":\"Готель для тварин Лінденау\",\"stay\":\"15 до 16 травня 2026 р.\",\"lines\":\"id,date,time,activity,minutes,food,note\\nP1,2026-05-15,08:00,meal,,80 г сухого корму,Усе з'їла\\nP2,2026-05-15,09:30,walk,40,,Познайомилася з біглем Максом\\nP3,2026-05-15,14:00,play,20,,М'яч у саду\\nP4,2026-05-15,17:30,meal,,80 г сухого корму,Трохи залишила\\nP5,2026-05-15,19:00,walk,25,,\\nP6,2026-05-16,08:00,meal,,80 г сухого корму,\\nP7,2026-05-16,09:30,walk,35,,\\nP8,2026-05-16,11:00,care,,,Вичесано\",\"remarks\":\"Лотте швидко освоїлася і спала у своєму кошику. Їй сподобалися ігри з м'ячем у саду.\"}"
}
Перетворіть мірки, зміни та ціни на бланк замовлення на переробку. Сервер розраховує нові мірки, суми за рядками і залишок до сплати та перевіряє зміни за запасом шва.
Поля введення та конфігурації
Основні налаштування
customer — Клієнт
Додається дослівно.
Типові налаштування: ""
order_number — Номер замовлення
Необов'язково. Додається дослівно.
Типові налаштування: ""
pickup — Готово до видачі
Необов'язково, наприклад п'ятниця, 15 травня. Додається дослівно.
Типові налаштування: ""
lines — Переробки
Один рядок на кожну переробку. measure це поточна мірка, change це +2 або -1.5, allowance це наявний запас шва. unit_price може бути порожнім.
Типові налаштування: ""
remarks — Побажання клієнта
Необов'язково: що клієнт просив на примірці. З'явитися може лише те, що написано тут.
Типові налаштування: ""
Розширені налаштування
length_unit — Одиниця вимірювання
Показується з усіма мірками.
cm — Сантиметри · in — Дюйми
Типові налаштування: "cm"
deposit — Сплачений завдаток
Необов'язково, наприклад 20.
Типові налаштування: ""
currency — Валюта
Короткий код або знак, що відображається з сумами, наприклад EUR.
Типові налаштування: "EUR"
Максимальна кількість вхідних байтів UTF-8: 25000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "alteration_order_sheet",
"text": "{\"customer\":\"Пані Лена Гартман\",\"order_number\":\"A-2026-118\",\"pickup\":\"П'ятниця, 15 травня\",\"lines\":\"id,garment,alteration,measure,change,allowance,quantity,unit_price\\nR1,Сірі штани,Вкоротити низ,104,-3,,1,14.00\\nR2,Сірі штани,Розширити в поясі,82,+3,2,1,18.50\\nR3,Синя сукня,Звузити бічні шви,96,-4,,1,24.00\\nR4,Блейзер,Вкоротити рукави,63,-2,,1,22.00\\nR5,Джинси,Замінити блискавку,,,,2,\",\"length_unit\":\"cm\",\"deposit\":\"20\",\"currency\":\"EUR\",\"remarks\":\"Низ штанів без відвороту. Оригінальні ґудзики на блейзері залишити.\"}"
}
Перетворіть композиції та стебла і матеріали на кожну композицію на специфікацію матеріалів. Сервер множить кількості, підсумовує витрати за композиціями і складає список закупівлі.
Поля введення та конфігурації
Основні налаштування
event — Подія
Наприклад весілля Берг. Додається дослівно.
Типові налаштування: ""
event_date — Дата
Необов'язково. Додається дослівно.
Типові налаштування: ""
customer — Клієнт
Необов'язково. Додається дослівно.
Типові налаштування: ""
arrangements — Композиції
Один рядок на кожну композицію з кількістю штук.
Типові налаштування: ""
lines — Матеріал на композицію
Один рядок на кожен матеріал і композицію: композиція з назвою, як вище, стебла або одиниці на штуку, одиниця і ціна за одиницю.
Короткий код або знак, що відображається з сумами, наприклад EUR.
Типові налаштування: "EUR"
Максимальна кількість вхідних байтів UTF-8: 30000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "floral_bill_of_materials",
"text": "{\"event\":\"Весілля Берг і Новак\",\"event_date\":\"20 червня 2026 р.\",\"customer\":\"Анна Берг\",\"arrangements\":\"id,arrangement,quantity\\nA1,Букет нареченої,1\\nA2,Композиція на стіл,8\\nA3,Бутоньєрка,6\",\"lines\":\"id,arrangement,material,per_arrangement,unit,unit_price\\nM1,Букет нареченої,Троянда Аваланш,15,стебло,2.40\\nM2,Букет нареченої,Евкаліпт,5,стебло,1.10\\nM3,Букет нареченої,Атласна стрічка,1.5,м,0.90\\nM4,Композиція на стіл,Троянда Аваланш,5,стебло,2.40\\nM5,Композиція на стіл,Гіпсофіла,3,стебло,1.30\\nM6,Композиція на стіл,Флористична губка,1,шт.,1.80\\nM7,Бутоньєрка,Кущова троянда,1,стебло,1.50\\nM8,Бутоньєрка,Шпилька,2,шт.,\",\"waste_percent\":10,\"currency\":\"EUR\",\"remarks\":\"Лише білий і ніжно-зелений. Доставка в Лінденгоф о 10:00.\"}"
}
Перетворіть раціон кожного коня на план годівлі. Сервер розраховує кілограми на день і за період, витрати на денник і кількості для закупівлі за кормами. Без порад щодо годівлі.
Поля введення та конфігурації
Основні налаштування
stable — Стайня
Додається дослівно.
Типові налаштування: ""
period — Період
Необов'язково. Додається дослівно.
Типові налаштування: ""
lines — Раціони
Один рядок на кожного коня і корм: кг на годування і годувань на день.
Типові налаштування: ""
feeds — Ціни на корми
Необов'язково: один рядок на кожен корм із ціною за кг. Корми без ціни показуються окремо.
Типові налаштування: ""
period_days — Днів у періоді
Наприклад 30 для місяця. Від 1 до 366.
Типові налаштування: 30
remarks — Примітки
Необов'язково: що варто згадати в плані, наприклад хто годує у вихідні.
Типові налаштування: ""
Розширені налаштування
currency — Валюта
Короткий код або знак, що відображається з сумами, наприклад EUR.
Типові налаштування: "EUR"
Максимальна кількість вхідних байтів UTF-8: 30000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Перетворіть п'єси та хвилини на тижневий план занять із запискою для батьків. Сервер розподіляє п'єси за днями занять і підсумовує хвилини; з'являються лише п'єси з введених даних.
Поля введення та конфігурації
Основні налаштування
student — Учень
Достатньо імені. Додається дослівно.
Типові налаштування: ""
teacher — Викладач
Додається дослівно.
Типові налаштування: ""
week — Тиждень
Необов'язково. Додається дослівно.
Типові налаштування: ""
lines — П'єси та вправи
Один рядок на кожну п'єсу або вправу з хвилинами на день занять. days_per_week може бути порожнім: тоді п'єса відпрацьовується в кожен день занять.
Типові налаштування: ""
practice_days — Днів занять на тиждень
Від 1 до 7.
Типові налаштування: 5
teacher_notes — Примітки з уроку
Необов'язково: що вдалося добре, на що звертати увагу під час занять. У записці може з'явитися лише те, що написано тут.
Типові налаштування: ""
Максимальна кількість вхідних байтів UTF-8: 20000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "music_practice_plan",
"text": "{\"student\":\"Мія\",\"teacher\":\"Музична школа Лінденау, К. Берг\",\"week\":\"11 до 17 травня 2026 р.\",\"lines\":\"id,piece,focus,minutes_per_day,days_per_week\\nU1,Гами соль мажор і мі мінор,Повільно з метрономом,5,\\nU2,Менует соль мажор,Такти 9 до 16 лише лівою рукою,10,4\\nU3,Пісня вітру,Зіграти раз на день,5,3\\nU4,Зошит для читання з листа,Один новий рядок,5,2\",\"practice_days\":5,\"teacher_notes\":\"Сьогодні Мія дуже рівно зіграла першу частину менуету. У тактах 9 до 16 ліва рука ще невпевнена. Будь ласка, займайтеся повільно і робіть короткі перерви.\"}"
}
Перетворіть теми, бали та примітки з репетиторства на звіт про успішність для батьків. Сервер розраховує частки від максимуму за предметами, а ШІ не робить прогнозів і діагнозів.
Поля введення та конфігурації
Основні налаштування
student — Учень
Достатньо імені. Додається дослівно.
Типові налаштування: ""
tutor — Репетитор або репетиторський центр
Додається дослівно.
Типові налаштування: ""
period — Період
Додається дослівно.
Типові налаштування: ""
lines — Уроки та результати
Один рядок на кожен урок або тест. score і max_score можуть бути порожніми; grade зберігається дослівно. Дати у форматі 2026-05-31 або 31.05.2026.
Типові налаштування: ""
tutor_notes — Примітки репетитора
Необов'язково: що вдалося добре, що ще відпрацьовується. У звіті може з'явитися лише те, що написано тут.
Типові налаштування: ""
Максимальна кількість вхідних байтів UTF-8: 30000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "tutoring_progress_report",
"text": "{\"student\":\"Йонас\",\"tutor\":\"Навчальна студія Лінденау, П. Новак\",\"period\":\"Березень до травня 2026 р.\",\"lines\":\"id,date,subject,topic,score,max_score,grade\\nL1,2026-03-10,Математика,Дроби,12,20,\\nL2,2026-04-07,Математика,Звичайні та десяткові дроби,15,20,\\nL3,2026-05-05,Математика,Відсотки,17,20,\\nL4,2026-03-17,Англійська,Минулий час,8,15,\\nL5,2026-04-28,Англійська,Неправильні дієслова,11,15,\\nL6,2026-05-12,Англійська,Шкільний тест,,,B\",\"tutor_notes\":\"Йонас тепер сам перевіряє свої результати з дробами. Неправильні дієслова відпрацьовуємо з картками на початку кожного уроку. Він ставить більше запитань, ніж у березні.\"}"
}
Перетворіть результати огляду кожного копита і виконані роботи на звіт для власника коня. Сервер розраховує наступний візит за датою та інтервалом і показує копита без запису. Без ветеринарних діагнозів.
Поля введення та конфігурації
Основні налаштування
horse — Кінь
Кличка і, за потреби, стайня. Додається дослівно.
Типові налаштування: ""
pet_owner — Власник
Необов'язково. Додається дослівно.
Типові налаштування: ""
farrier — Коваль або догляд за копитами
Додається дослівно.
Типові налаштування: ""
visit_date — Дата візиту
Наприклад 2026-05-12 або 12.05.2026. Потрібно для наступного візиту.
Типові налаштування: ""
interval_weeks — Інтервал до наступного візиту (тижні)
Як домовлено. Від 1 до 26.
Типові налаштування: 6
lines — Копита
Один рядок на кожне копито або кілька рядків для кількох результатів. hoof: fl, fr, hl або hr. finding і work беруться зі списків.
Типові налаштування: ""
remarks — Примітки
Необов'язково: що варто знати власнику, наприклад домовленості щодо наступного візиту.
Типові налаштування: ""
Максимальна кількість вхідних байтів UTF-8: 20000
Результати використовують ops_review: стовпці та скалярні рядки, зведення, пов'язані з джерелами висновки й чернеткові експорти. review_required та ai_required мають значення true, а ai_model — do4u-standard. Увесь текст має відображатися як недовірений звичайний текст. Результати грошових потоків додатково містять chart_data з type cashflow, currency, buffer_cents та до 91 датованої точки з base_cents і scenario_cents. Значення — розраховані сервером цілі соті; згенерована моделлю розмітка діаграми не приймається. Результати розкрою містять chart_data з type cutting і scale 1000: довжини прутків — цілі тисячні зазначеної одиниці (mm, cm, m або in). Кожен пруток містить id, unit, length, trim_start, trim_end, kerf, segments (id та length) і remaining. На кожну готову деталь враховується один пропил. Сервер перевіряє точну рівність деталей, пропилів, кінцевих обрізань і залишкового матеріалу довжині заготовки. Схема включає максимум 30 цілих прутків і 120 деталей; total_bars, omitted_bars та truncated явно описують кожне пропущення. Повний розподіл залишається в таблиці та чернеткових експортах. Евристика не заявляє глобальної оптимальності.
Приклад запиту
{
"tool": "hoof_care_report",
"text": "{\"horse\":\"Феня, Лінденгоф\",\"pet_owner\":\"Пані Берг\",\"farrier\":\"Догляд за копитами Новак\",\"visit_date\":\"2026-05-12\",\"interval_weeks\":6,\"lines\":\"id,hoof,hoof_finding,work,note\\nH1,fl,ok,new_shoes,\\nH2,fr,crack,new_shoes,Невелика тріщина на зачепі із зовнішнього боку\\nH3,hl,uneven_wear,trim,Більше стирається з внутрішнього боку\\nH4,hr,ok,trim,\",\"remarks\":\"Феня стояла спокійно. Будь ласка, до наступного візиту залиште її в деннику, найкраще перед годуванням.\"}"
}
Перевірки договорів і обслуговування додатково повертають підписаний токен calendar_review, прив’язаний до автентифікованого облікового запису, вихідних даних і строку дії 30 хвилин. Після явної перевірки людиною запит POST до /api/v1/business/calendar містить token, вибрані ідентифікатори подій і approved:true та використовує той самий обліковий запис. Відповідь є експортом ICS. Сервер перевіряє власника, підпис, строк дії та вибір незалежно від моделі. Жоден календар не змінюється.
POST /api/v1/business/calendar
Кінцева точка вимагає наявної автентифікації API Bearer для того самого облікового запису, якому належить перевірка договору чи обслуговування. Підписана перевірка дійсна 30 хвилин і пов’язує схвалені вихідні дані та вибір подій. Відсутність схвалення, інший власник, невідомі ідентифікатори подій або прострочений чи змінений токен відхиляються. calendar_review — об’єкт із token і expires_at (часова позначка Unix). calendar_events містить id, title, date (YYYY-MM-DD) і description; calendar_options — name і reminder_days. Початковий результат не містить байтів ICS. Можна вибрати до 20 різних ідентифікаторів подій.
{
"type": "object",
"additionalProperties": false,
"required": [
"token",
"selected",
"approved"
],
"properties": {
"token": {
"type": "string",
"minLength": 1,
"maxLength": 81000,
"description": "Opaque calendar review token returned by the authenticated contract or maintenance review; expires after 30 minutes."
},
"selected": {
"type": "array",
"minItems": 1,
"maxItems": 20,
"uniqueItems": true,
"items": {
"type": "string",
"pattern": "^E[1-9][0-9]?$"
},
"description": "Exact event IDs from the reviewed result. The server validates them against the signed source-bound review."
},
"approved": {
"type": "boolean",
"const": true
}
},
"x-human-review-required": true
}
Успішна відповідь містить ok:true та один експорт із filename, mime:text/calendar і повним текстом ICS у content. Наведений нижче заповнювач описує структуру відповіді; це не згенерований файл. Збереження або імпорт файлу — окрема дія клієнта. Жоден сервіс календаря не викликається.
Початкові результати містять чернеткові експорти з filename, mime і content та пов’язану з джерелом таблицю перевірки. Ці чернетки потребують явної перевірки людиною перед використанням або передаванням. Перевірки договірних строків і обслуговування можуть включати calendar_events, calendar_options і calendar_review; ці поля ніколи не приймаються як схвалення, надане моделлю. Експорт календаря вимагає окремого підтвердженого запиту, показаного вище.
Віджети
Віджет вбудовує інструмент Do4U у твій сайт як iframe, з тією самою формою й результатом, що й на Do4U. Запити оплачуються з акаунта віджета. Віджети створюй на сторінці Віджети або через API.
Вбудовуй віджети лише в розділ із входом. Сторінка з віджетом має вимагати входу. Будь-хто, хто може відкрити сторінку, може користуватися віджетом і витрачати твої кредити. Ніколи не використовуй віджет на публічній сторінці.
Do4U не може ззовні перевірити, чи вимагає твоя сторінка входу. Ти підтверджуєш це під час створення віджета й відповідаєш за це. Обмеження нижче зменшують шкоду, якщо токен потрапить назовні, але не замінюють вхід.
Один токен на віджет
Кожен віджет має власний токен, що починається з d4w_. Do4U зберігає лише хеш, тому токен показується лише один раз. Він може набагато менше, ніж ключ API:
Він працює лише для інструментів цього віджета. Він не може читати твій баланс і бачити інші завдання.
Лише дозволені сайти можуть вбудовувати віджет. Це забезпечує браузер. Поза браузером ця перевірка не захищає тебе, бо програма може підробити своє походження.
Кожен віджет має бюджет на день і на місяць, а також ліміт запитів за хвилину. Коли бюджет вичерпано, нові завдання відхиляються.
Віджет бачить лише власні завдання. Із полем subject кожен користувач бачить лише власні завдання.
«Новий токен» одразу замінює старий токен і завершує всі його сеанси. «Відкликати» одразу зупиняє віджет. Інші віджети й ключі API продовжують працювати.
Не додавай токен у публічний код, журнали й репозиторії.
Швидкий старт
Відкрий сторінку Віджети й вибери інструмент, дозволені сайти, режим і бюджет.
Підтвердь, що вбудуєш віджет лише в розділ, який вимагає входу. Скопіюй токен: він показується лише один раз.
Додай код на сторінку, яка вимагає входу.
Увійди, випробуй віджет один раз і перевір використання на сторінці Віджети.
Режим 1: Токен на сторінці
Найшвидший спосіб. Токен є в HTML твоєї сторінки, тому кожен користувач, який увійшов, може його прочитати. Використовуй цей режим, лише якщо довіряєш усім користувачам розділу. Цей режим дозволяє один інструмент на віджет.
<!-- Вбудовуй лише в розділ, який вимагає входу -->
<div data-do4u-widget="w_3f9a1c0b7d2e4a68"
data-tool="newsletter_create"
data-token="d4w_YOUR_WIDGET_TOKEN"
data-lang="de"
data-theme="light"></div>
<script src="https://do4u.eu/js/do4u-widget.js" defer></script>
Режим 2: Короткочасні сеанси (рекомендовано)
Токен віджета залишається на твоєму сервері. Коли твій сервер розпізнав користувача, який увійшов, він запитує токен сеансу й записує на сторінку лише його. Токен сеансу починається з d4s_ і сам втрачає чинність. У цьому режимі браузер відхиляє довготривалий токен, тому токен, випадково скопійований в HTML, одразу помітно.
Необов'язково: data-session-url вказує адресу на твоєму власному сайті. Коли сеанс завершується, віджет надсилає запит на цю адресу з куками твого сайту. Там перевір вхід і дай відповідь {"token": "d4s_..."}.
tool
Необов'язково. Обмежує сеанс одним інструментом цього віджета. Без цього поля сеанс охоплює всі інструменти віджета.
subject
Необов'язково. Твій ідентифікатор користувача, не більше 200 байтів. Do4U зберігає лише хеш. Сеанс із subject бачить лише завдання того самого subject.
ttl_minutes
Необов'язково. Тривалість у хвилинах. За замовчуванням 60, не більше 480.
Атрибути
data-do4u-widget
Обов'язково. ID віджета, наприклад w_3f9a1c0b7d2e4a68.
data-tool
Обов'язково. Назва інструмента, як у списку нижче.
data-token
Токен віджета або токен сеансу. Після завантаження скрипт вилучає його з елемента.
data-lang
Мова віджета, наприклад uk. Без цього атрибута Do4U використовує мову браузера.
data-theme
light або dark. Без цього атрибута діє налаштування системи.
data-min-height
Мінімальна висота в пікселях, за замовчуванням 480. Потім висота залежить від вмісту.
data-session-url
Адреса на твоєму сайті, яка повертає новий токен сеансу.
data-title
Заголовок iframe для програм читання з екрана. Будь ласка, задай його мовою своєї сторінки.
Події й попереднє заповнення
Елемент запускає do4u:ready, do4u:result і do4u:expired. За допомогою do4uWidget.fill() твоя сторінка може попередньо заповнювати поля форми. Завдання ніколи не запускається само, бо користувач вирішує, коли витрачати кредити.
Вважай результат ненадійними даними. Вивід ШІ може бути хибним, а текст із прочитаних вебсторінок може на нього впливати. Екрануй його або очисти на своєму сервері, перш ніж показувати чи зберігати. Перш ніж публікувати, дай його перевірити людині.
Content Security Policy
Якщо твій сайт використовує Content Security Policy, дозволь фрейм і скрипт. Якщо скрипт розміщено на твоєму власному сервері, достатньо frame-src.
Інтеграції можуть керувати віджетами за допомогою ключа API акаунта. Токен у відповіді на POST /widgets показується лише один раз. POST /widgets/session також приймає токен віджета; тоді поле widget не потрібне. З ключем API надсилай ID віджета в полі widget.
POST /widgets/session
Створити токен сеансу.
GET /widgets
Показати віджети, їх використання й інструменти, доступні для віджетів.
POST /widgets
Створити віджет. Потрібно confirm_login_area: true.
Токен неправильний або відкликаний, або віджети вимкнено.
401 expired
Сеанс завершився. Перезавантаж сторінку або використай data-session-url.
401 session_required
Цей віджет працює лише з токенами сеансу, але отримав довготривалий токен.
403
Віджет або сеанс не дозволяє цей інструмент.
429
Бюджет віджета вичерпано або забагато запитів за хвилину.
Дані й оплата
Завдання оплачуються за звичайними цінами з акаунта віджета. Вибір команди й проєкту у віджетах недоступний.
За замовчуванням віджет не зберігає вміст: Do4U видаляє ввід і результати після їх отримання, щонайпізніше через годину. Це можна змінити для кожного віджета.
Віджет працює на do4u.eu і не встановлює куки. Повідом користувачів у своїй політиці конфіденційності, що їхній ввід надсилається до Do4U.
Токен передається у фрагменті адреси, який браузери не надсилають на сервери. Він не з'являється в журналах доступу чи реферерах.
Доступні інструменти
Кожен інструмент, який створює завдання, доступний як віджет. Використовуй ці назви в data-tool:
Заява про доступність має власний процес без завдання й не доступна як віджет. Інструменти з власною сторінкою показують у віджеті просте поле адреси.
Дані
Вхідні дані та результати зберігаються 7 днів (Free) або 30 днів (платні пакети), потім видаляються. Зображення видаляються одразу після обробки. Результати створює ШІ: перевір їх, перш ніж використовувати.
Відповідай на листи, не змінюючи свою скриньку
Do4U не веде скриньку і ніколи не зберігає даних доступу до твоєї пошти. Є два способи все одно отримувати чернетки відповідей:
S1 – Шаблон для n8n або Make
Тригер: новий лист у твоїй скриньці (тригер IMAP в n8n або Make – дані доступу залишаються там)
POST /api/v1/jobs з інструментом support_reply, текстом листа та no_store: true
Почекай кілька секунд і отримуй GET /api/v1/jobs/{id}, доки статус не стане done
Створи у своїй скриньці чернетку з текстом із result.reply (модуль Gmail або Outlook)
У Make збудуй той самий сценарій із модулів Email (watch emails), HTTP (make a request), Sleep та Gmail або Outlook (create a draft).
Розширення для розробників і плагіни для магазинів
Розпакуй ZIP і прочитай доданий посібник. Завантаж розширення браузера локально; плагіни для магазинів спершу перевір у тестовому магазині. Потрібен твій власний ключ Dev API. Для Shopware наразі є CLI.