Перейти до вмісту
Siftable
UK
Меню
Поточна · v4 · Серпень 2026 Siftable / ExecuFunction Inc. · Публічна операційна конституція

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

Конституція для людей та агентів

Як ми працюємо

Ми намагаємося зрозуміти, що є істинним, будувати на основі цього розуміння і змінювати свою думку, коли змінюються докази.

Наша місія — дати людям та їхнім агентам спільне, надійне, переглядуване розуміння їхнього світу, щоб те, що вони вивчають, накопичувалося, а не зникало.

Бач ясно.
Вирішуй, що важливо.
Дій.
Читати по рівнях

Як влаштовано цей документ. Чотири шари у порядку їхньої стійкості:

  1. Конституція — ідея, що лежить в основі компанії, та сім принципів. Майже незмінна. Вона все ще повинна мати сенс, коли в компанії буде 500 людей.
  2. Угоди — що означає бути технічним спеціалістом тут, та операційна система, спільна для людей та агентів. Довговічні, але можуть бути змінені із зафіксованим обґрунтуванням.
  3. Робочі нотатки — точніші пояснення принципів. Можуть коригуватися в міру нашого навчання.
  4. Доктрина та механізми — застарілі, залежні від етапу й свідомо одноразові. Їхнє видалення, коли вони перестають допомагати, свідчить про роботу системи, а не про її збій.

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


Частина перша: Конституція

Якщо ти запам'ятаєш лише цю частину, ти знатимеш, як ми працюємо.

Ідея, що лежить в основі всього

Ми намагаємося зрозуміти, що є істинним, будувати на основі цього розуміння і змінювати свою думку, коли змінюються докази.

Реальність говорить нам, що є істинним. Наша місія говорить нам, що варто робити.

Наша місія — дати людям та їхнім агентам спільне, надійне, переглядуване розуміння їхнього світу, щоб те, що вони вивчають, накопичувалося, а не зникало.

Розуміння корисне лише тоді, коли воно змінює те, що ми робимо. Бачити ясно — це початок роботи, а не її кінець.

Бач ясно. Вирішуй, що важливо. Дій.

Це операційні правила для людей та агентів у Siftable.

Їхні можливості, дозволи, обов'язки та повноваження для прийняття рішень відрізняються. Стандарти для доказів, чесності, походження, невизначеності, протиріч та перегляду — ні.

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

Все, що нижче, випливає з цих ідей.

1. Говори, що є правдою

Чітко розрізняй, що ми знаємо, що думаємо, і що нам ще потрібно з'ясувати.

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

«Це наше найкраще припущення» і «ми це перевірили» — це різні твердження.

Так само, як і «ми експериментуємо з цим» та «ми це реалізуємо».

Ми обіцяємо обережно і дотримуємося даних обіцянок.

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

2. Одна людина відповідає за проблему

За кожну важливу проблему відповідає одна людина, яка розуміє її від початку до кінця.

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

Відповідальний завжди знає:

  • чого ми намагаємося досягти;
  • у що ми зараз віримо;
  • що залишається невідомим;
  • які докази існують;
  • що сталося насправді;
  • що не вдалося;
  • і що буде далі.

Ми організовуємося навколо проблем, а не систем.

Завдання команди, що займається пам'яттю, — вирішити проблеми пам'яті, а не зберігати поточну систему пам'яті. Якщо заміна створеного нами є правильним рішенням, її власник має першим про це сказати.

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

Відповідальний залишається підзвітним за результат.

3. Дослідження та розробка нероздільні

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

Дослідження — це дисципліноване зменшення невизначеності. Це не теоретизування заради самого процесу.

Розробка — це створення корисних речей. Це не сліпе виконання рішень, прийнятих деінде.

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

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

4. Залишайся близько до реальності

Користуйся продуктом.

Спілкуйся з користувачами.

Спостерігай, як вони насправді працюють.

Читай логи.

Досліджуй збої самостійно.

Звертай увагу на те, що люди роблять насправді, а не на те, що, на нашу думку, вони повинні робити.

Звіти, дашборди, метрики, резюме та моделі можуть допомогти нам зрозуміти реальність. Вони не є самою реальністю.

Технічно елегантна система, яка не вирішує реальної проблеми, не є успіхом.

5. Змінювати думку — це прогрес

Помилятися — це не провал. Відмовлятися оновлювати свої погляди — ось провал.

Хороший експеримент, що спростовує ідею, може заощадити місяці марної роботи.

Видалення непотрібного коду може бути ціннішим за додавання нового.

Спрощення системи може бути складнішим і ціннішим, ніж її розширення.

Припинення роботи, яка більше не має сенсу, є законним результатом.

Навчання має значення, коли воно зменшує невизначеність і змінює те, що ми робимо.

Ми не створюємо складнощів, щоб виглядати важливими.

Ми не підтримуємо проєкти живими, щоб виправдати вже витрачені на них кошти.

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

6. Процес має виправдовувати своє існування

Процес існує, бо досвід навчив нас, що щось має відбуватися надійно.

Коли ми неодноразово засвоюємо один і той же урок, ми його кодифікуємо. За будь-якої практичної можливості ми віддаємо перевагу інструментам, тестам, автоматизації та чітким системним обмеженням над зайвими церемоніями.

Процеси не є священними.

Покращуй їх, коли вони не працюють.

Видаляй їх, коли вони перестають допомагати.

І не автоматизуй процес, перш ніж довести, що він заслуговує на існування.

Мета процесу — полегшити хорошу роботу і ускладнити повторення помилок, а не змусити організацію виглядати зрілою.

7. Повага походить від суджень, а не від посади

Слухай того, хто найкраще розуміє проблему.

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

Важлива якість міркувань та доказів.

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

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

Якщо з'являються суттєво нові докази, переглянь рішення. Зміна курсу через зміну реальності — це не нелояльність.

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

Чотири робочі максими

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

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

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

Видаляй, перш ніж оптимізувати.
Став під сумнів вимогу. Видаляй непотрібне. Спрощуй те, що залишилося. Потім роби це швидшим і автоматизуй.

Занурся в проблему.
Не просто збирай вимоги здалеку. Працюй пліч-о-пліч з людьми, які стикаються з проблемою. Побач фактичний робочий процес і візьми на себе відповідальність за результат.

Правило простої мови

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

Складність може жити під капотом.

Спільне розуміння повинно залишатися достатньо простим для комунікації.


Частина друга: Угоди

Угода з технічним персоналом (MTS)

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

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

Але кожен член технічного персоналу повинен вміти:

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

Будівельник не означає «людина, яка вручну пише найбільше коду».

З удосконаленням інструментів агенти виконуватимуть більше реалізації. Будувати означає бути здатним створювати реальну, робочу, зрозумілу систему — через архітектуру, специфікації, тести, оцінки, інструменти, логи, код та судження над виводом агента — і брати відповідальність за її поведінку.

Той, хто може лише створювати пропозиції, але не може зробити нічого реального, був би тут незвичайним.

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

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

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

Одна операційна система для людей та агентів

Люди та агенти не отримують різних правил для істини.

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

Обидва працюють з одними й тими ж основними ідеями:

твердження · доказ · висновок · невизначеність · зобов'язання · протиріччя · перегляд

Обидва зберігають походження важливої інформації.

Обидва можуть помилятися.

Від обох очікується оновлення.

Обидва виявляють протиріччя, а не тихо їх згладжують.

Обидва розрізняють:

«Я думаю» від «Я перевірив».

Агенти діють лише в межах наданих їм повноважень. Люди залишаються відповідальними за вирішення, які повноваження делегувати, і підзвітними за наслідки цього делегування.

Мета не в тому, щоб вдавати, ніби люди та агенти є взаємозамінними.

Мета — переконатися, що жоден не отримує іншого стандарту для реальності.

Важлива робота має бути розбірливою

Важлива робота залишає достатньо стійких, атрибутованих доказів, щоб інша уповноважена особа чи агент могли зрозуміти:

  • що сталося;
  • чому це сталося;
  • що було вирішено;
  • які докази це підтверджували;
  • і до чого це призвело.

Правило таке:

Ніщо важливе не повинно залежати від недоступних племінних знань.

Це не означає записувати все.

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

Розбірливість служить роботі. Вона не скасовує розсудливість, приватність, безпеку чи довіру.

Повторювана робота повинна навчатися

Коли це практично, повторювана робота стає замкненим циклом:

спостерігати → розуміти → вирішувати → діяти → вимірювати → вчитися → оновлювати

Відгуки клієнтів повинні покращувати наступне рішення щодо продукту.

Інциденти повинні покращувати наступну систему.

Розмови з продажу повинні покращувати наступну розмову з продажу.

Збої агентів повинні покращувати наступний запуск агента.

Людські помилки повинні покращувати наступне рішення людини.

Те, що ми вивчаємо, повинно накопичуватися, а не зникати.

Операційна формула

Вся система в русі така:

Бач реальність ясно. Обирай, що важливо. Признач відповідального. Будуй. Спостерігай за тим, що сталося. Оновлюй. Видаляй те, що більше не служить місії. Повторюй.

Компанія є догфудинг-примірником філософії Siftable.

Та сама дисципліна, якої ми хочемо від продукту, стосується людей та агентів, які його створюють.


Частина третя: Операційні нотатки

Вони точніші за Конституцію і більш схильні до змін.

Про істину

Не кожне рішення вимагає однакової суворості.

Планка доказовості підвищується з трьома речами:

невизначеність × наслідки × незворотність

Невелике, оборотне рішення? Використовуй розсуд і випускай.

Фундаментальна зміна пам'яті, пошуку чи онтології? Виклади, у що ми віримо, що ще могло б пояснити докази, як ми будемо це вимірювати, і що змусить нас змінити думку.

Рішення, що впливає на безпеку, цілісність даних, приватність чи довіру? Використовуй значно вищу планку перед випуском.

Ми відкидаємо обидві крайнощі:

комфортну невизначеність, замасковану під прагматизм

та

академічну церемонію, замасковану під суворість.

Два питання мають значення

Для невизначеної роботи над продуктом нам зазвичай потрібно відповісти на два різні питання:

Чи це працює?

та

Чи це має значення?

Перше — це наукова чи технічна істина.

Друге — це продуктова істина.

Ідеальний експеримент, що відповідає на питання, яке нікого не хвилює, — це суворість, спрямована не на ту ціль.

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

Про відповідальність

Кожна важлива проблема має рівно одного відповідального.

Відповідальний володіє поточним станом проблеми і може відповісти:

  1. Чого ми намагаємося досягти і чому це важливо?
  2. У що ми зараз віримо?
  3. Що залишається невідомим?
  4. Які докази ми маємо?
  5. Що фактично було випущено?
  6. Що не вдалося?
  7. Що змусило нас змінити думку?
  8. Що буде далі?

Відповідальність є наскрізною.

Внесок необмежений.

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

Але делегування не знімає відповідальності з людини.

Інформація не проходить через відповідального. Відповідальність залишається на ньому.

Про владу та засновника

Існують два різні види влади.

Епістемічна влада: наскільки вагомим ми повинні вважати твердження чи судження про те, що є істинним?

Влада приймати рішення: хто відповідає за прийняття рішення?

Це не одне й те саме.

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

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

Влада приймати рішення призначається явно.

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

Роль засновника

Відповідальність розподілена. Загальноорганізаційний контекст — ні.

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

Це не означає автоматичної передачі відповідальності.

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

Засновник не має автоматичного права бути правим.

Інтуїція засновника входить до системи як гіпотеза, а не як доказ.

Про координацію

Жодна роль не повинна існувати переважно для передачі інформації вгору чи вниз по організації.

Ми не хочемо:

резюме інженера → резюме менеджера → резюме директора → резюме керівника

коли основну роботу можна перевірити безпосередньо.

Люди також не повинні витрачати свій час на ручне маршрутування інформації, яку уповноважена система чи агент можуть зробити розбірливою напряму.

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

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

«Робити статус розбірливим для наступного менеджера» — недостатня причина для існування посади.

Купуй можливості, а не бюрократію

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

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

Величезний рахунок за висновки, що створює марну роботу, все одно є марнотратством.

Споживання токенів — це не показник продуктивності.

Про знання та механізми

Зберігай знання. Відтворюй механізми.

Речі, які ми вважаємо довговічними, включають:

  • докази та походження;
  • важливі рішення та чому вони були прийняті;
  • розуміння клієнта;
  • обмеження;
  • доменні моделі;
  • тести та оцінки;
  • специфікації;
  • набуті навички.

Речі, які ми набагато охочіше замінюємо, включають:

  • дашборди;
  • клейовий код;
  • одноразові внутрішні інструменти;
  • тимчасові інтерфейси;
  • оркестрація;
  • деталі реалізації.

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

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

Про навчання та спрощення

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

Видалення цінне пропорційно до складності, яку воно усуває, не руйнуючи цінності.

Повний цикл такий:

вчитися → змінювати переконання → змінювати дії → покращувати

«Ми провели 47 експериментів» — це не досягнення, якщо нічого корисного не змінилося.

Так само, як і «ми видалили 10 000 рядків».

Ми не замінюємо театр запусків на театр навчання.

Про процес

Процес — це компіляція інституційного навчання.

Коли ми вчимося чомусь на гіркому досвіді, ми зберігаємо урок, щоб не довелося вчитися на ньому вічно.

Віддавай перевагу, по порядку:

  1. усунути непотрібну вимогу;
  2. видалити непотрібну роботу;
  3. спростити те, що залишилося;
  4. зробити це швидшим;
  5. автоматизувати це.

Автоматизація йде останньою.

Коли процес необхідний, віддавай перевагу його впровадженню через хороші інструменти та системи, а не через прозу, яку люди повинні пам'ятати вручну.

Кожен процес повинен відповідати на питання:

Чому це існує?

Якщо ніхто не може відповісти, це кандидат на видалення.

Інциденти повинні призводити до кращого розуміння та кращих механізмів, а не до автоматичного додавання нового чекбокса.


Частина четверта: Доктрина та механізми

Доктрина раннього етапу — 2026

Це те, як, на нашу думку, повинен функціонувати Siftable на ранньому етапі. Це не конституція і має змінитися, коли зміниться компанія.

  • Створюй те, що хочуть люди.
  • Постійно спілкуйся з користувачами.
  • Роби те, що не масштабується, коли це вчить нас чомусь важливому.
  • Випускай продукт, перш ніж все стане комфортним. Розробка генерує знання, яких не може дати планування.
  • Залишайся меншим, ніж здається комфортним. Найм сам по собі не є прогресом.
  • Ніколи не наймай, щоб приховати невирішену невизначеність продукту.
  • Витрачай агресивно на реальні можливості та навчання; витрачай обережно на організаційний вигляд.
  • Використовуй агентів агресивно там, де вони збільшують реальні можливості, а не для імітації впровадження AI.
  • Засновник залишається в деталях.
  • Уникай відволікань. Фокус — це перевага для виживання.

Поточні механізми — 2026

Це інструменти, а не заповіді. Замінюй або видаляй їх, коли з'явиться щось краще.

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

Огляд логів з продакшену
Люди, що працюють над системою, регулярно перевіряють реальні логи та реальні збої — як людські, так і агентські — замість того, щоб покладатися лише на зведення.

Догфудинг
Ми використовуємо Siftable для власної роботи всюди, де це вчить нас чомусь корисному. Це включає наші робочі процеси «людина-агент»: сама компанія повинна випробовувати систему, яку вона будує.

Журнал зупиненого та спрощеного
Ми записуємо значущі речі, які ми припинили, спростували, видалили або спростили — разом із причиною.

Шаблон експерименту
Для достатньо важливої невизначеності:

  • твердження;
  • конкуруюче пояснення;
  • вимірювання;
  • що змусило б нас змінити думку;
  • результат;
  • інтерпретація;
  • рішення.

Використовуй його пропорційно до ставок.

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


Внесення змін

Різні рівні змінюються з різною швидкістю.

Аксіома та місія мають змінюватися лише тоді, коли сама компанія стає чимось іншим.

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

Операційні нотатки змінюються в міру покращення нашого розуміння.

Доктрина та механізми є датованими та одноразовими.

Корисний тест для всього, що пропонується як новий конституційний принцип:

  1. Чи можна його вивести з основної ідеї?
  2. Чи можемо ми назвати привабливу річ, від якої він змусить нас відмовитися?

Якщо ні, то це, ймовірно, декорація.

Помісти це на нижчий рівень — або залиш.


Що робить це реальним

Цей документ — не культура.

Культура — це те, що ми винагороджуємо.

Від чого ми відмовляємося.

Кого ми наймаємо.

Що ми толеруємо.

Як люди використовують владу.

Як люди делегують завдання агентам.

Як агенти поводяться, коли ніхто не дивиться.

Як ми реагуємо, коли щось йде не так.

Що ми робимо, коли докази незручні.

Конституція зрештою пишеться тим, що ми робимо, коли це боляче.

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

Історія змін

v4 · Серпень 2026. Поточна публічна версія. Майбутні зміни фіксуватимуть, що ми дізналися і чому попереднє формулювання більше не слугувало роботі.