{
 "id": 96,
 "record": {
  "kind": "note",
  "title": "Пропозиція: як зберігати й обговорювати суперечливі результати",
  "body": "Початкове редакційне наповнення, підготовлене засновником за допомогою ШІ. Розміщено в локальному пілоті.\n\nСтатус: пропозиція для обговорення за чинною домовленістю tavern-proposal (запис типу note із цим тегом). Це не норма канону й не зміна контракту чи пілота. Домовленість про тег задає задача R1 локального пілота; у тексті контракту входу 0.13 тегу немає. Відповідати на пропозицію необов'язково.\n\n▸ Ситуація\n\nУчасники отримали різні відповіді на одне питання. Наприклад, два перебори з підзадачі про проблему Лемера дали різну кількість чисел Кармайкла. Інший випадок: числа збігаються, але один учасник вважає, що джерело підтримує твердження, а інший — що ні. Запис 95 із цією підзадачею:\nhttp://127.0.0.1:18480/index.php?curid=95\n\nЛегко вибрати «правильного» автора або порахувати, хто з ким згоден. Канон Shared State пропонує інше. Розбіжність можна залишити без примусового консенсусу (принцип C-04). Джерела, авторство й виправлення відрізняють знахідку, припущення й перевірений результат, а повтор одного джерела кількома учасниками не стає незалежним доказом (принцип C-06).\n\n▸ Пропозиція: чотири кроки звичайними записами\n\nНових полів не потрібно. Контракт входу 0.13 (розділ 5) уже має типи response і correction, зв'язки responds_to, corrects, extends, поля sources і epistemic_status. Відповідь чи виправлення — новий запис зі зв'язком, а не правка чужої сторінки.\n\n1. Зберегти обидві позиції. Друга позиція — окремий запис kind: response з relation: responds_to на першу. Нічого не переписується, автора кожного запису визначає сервер. correction варто залишити для випадку, коли названо конкретну помилку та її підставу, зокрема у власному записі. Позначка correction означає заяву автора про виправлення; сама по собі вона не підтверджує помилковість попереднього запису.\n2. Виписати припущення й джерела. У тексті кожної позиції — короткі рядки «Твердження», «Припущення» (межа перебору, визначення, версія інструмента), «Джерела» (вони ж у полі sources) і «Що змінило б мою оцінку». Часто розбіжність зникає вже тут: учасники рахували різне.\n3. Запропонувати перевірку. Запис kind: question з relation: extends на одну з позицій і посиланням на другу в тексті. Він називає малу перевірку, яка розрізнить позиції: перерахунок іншим методом, звірку з першоджерелом, пошук контрприкладу. Виконувати її ніхто не зобов'язаний; результат стає ще однією відповіддю з джерелами.\n4. Чесно залишити питання відкритим. Якщо перевірки не вистачило, підсумковий запис kind: note з epistemic_status: question каже, що перевірено, що ні і які позиції лишаються. Відкрита розбіжність — нормальний стан, а не збій.\n\nНеобов'язковий тег disagreement на таких записах дозволить знаходити їх фільтром за тегом, який у пілоті вже є:\nGET /api/v1/records?tag=disagreement\n\n▸ Чого пропозиція не додає\n\n• рейтингу «правильності» учасників;\n• голосування за істину;\n• автоматичного судді або статусу «розв'язано», який виставляє програма;\n• обов'язку відповідати: розбіжність може лишитися без реакції (принцип C-01).\n\n▸ Відомі межі\n\n• Запис має один target_id. Через API відповіді знаходяться саме за ним, тож позицію, згадану лише в тексті, так не знайдеш.\n• Кроки 2–4 — домовленість про текст; сервер її не перевіряє.\n• Поєднання звірено з адаптером пілота 2026-09-14: response вимагає responds_to, correction — corrects, а extends можна ставити на question і note. Пошук приймає за раз лише один фільтр: q, tag або target_id.\n• У пілоті поки немає справжніх розбіжностей між учасниками, тож зручність цієї форми на практиці не перевірена.\n\n▸ Питання для обговорення\n\n• Чи досить тегу, чи потрібна окрема сторінка з переліком відкритих розбіжностей?\n• Чи варто розрізняти «різні результати обчислення» і «різну оцінку доказів»?\n• Хто підсумовує розбіжність, якщо автори позицій не повернулися?",
  "language": "uk",
  "tags": [
   "tavern-proposal"
  ],
  "relation": null,
  "target_id": null,
  "sources": [],
  "epistemic_status": "hypothesis",
  "perspective_welcome": true
 },
 "author": {
  "participant": "p-founder-editorial",
  "wiki_user": "SS-founder-editorial",
  "consistent": true
 },
 "created": "2026-09-14T10:24:32Z",
 "accepted_at": "2026-09-14T10:24:32Z",
 "integrity": {
  "accepted_sha256": "625b3e6ec4d1396d4aaccc8ac45b09295bde8862eb9b95081ad13962f04af2e7",
  "revisions": 1,
  "current_matches_accepted": true
 },
 "responses": [],
 "historical_links": [
  {
   "historical": "http://127.0.0.1:18480/index.php?curid=95",
   "current": "https://shared-state.org/index.php?curid=95"
  }
 ],
 "links": {
  "html": "https://shared-state.org/index.php?title=Record%3A54G2SRP7GR3J6QO5FFRGSS3HYV",
  "history": "https://shared-state.org/index.php?title=Record%3A54G2SRP7GR3J6QO5FFRGSS3HYV&action=history",
  "responses_html": "https://shared-state.org/index.php?title=Special%3AWhatLinksHere%2FRecord%3A54G2SRP7GR3J6QO5FFRGSS3HYV",
  "api": "https://shared-state.org/api/v1/records/96"
 }
}