Skip to content

Latest commit

 

History

History
112 lines (71 loc) · 9.74 KB

File metadata and controls

112 lines (71 loc) · 9.74 KB

Knowledge as Code

English version

Краткий гайд по корпоративной памяти: как делать знания понятными, проверяемыми и пригодными для совместной работы. AI не создаёт эти принципы, но делает цену их отсутствия выше, становясь ещё одним быстрым и буквальным потребителем корпоративных знаний.

AI не создаёт корпоративную память. Он становится полезным, когда память различает источники, утверждения, свидетельства, выводы, решения и неизвестное.

Рабочая модель

Стрелка здесь — маршрут чтения, а не конвейер хранения. На практике знание образует ациклический граф типизированных связей.

источник ──evidence_for──▶ каноническое утверждение
    │                              │
    └──────derived_from───────────▶ отчёт
                                   │
утверждения + ограничения ────────▶ решение ──implemented_by──▶ действие или код

Независимые оси метаданных

Не смешивайте достоверность, роль документа, авторство и lifecycle в одном статусе. Каждое поле применяется только там, где имеет смысл.

Поле Ось Значения Что описывает
epistemic_state Эпистемический статус verified, claim, hypothesis, unknown Что известно и насколько это подтверждено. verified всегда подразумевает названный критерий проверки.
record_kind Роль записи source, assertion, decision, instruction, report Какой ответственностью владеет запись. Evidence — типизированная связь, а не конкурирующая роль записи.
generation_mode Способ создания captured, human_authored, machine_generated, mixed Как появилось содержимое. Производность отдельно фиксируется через derived_from.
lifecycle Lifecycle документ: draft, active, archived; решение: proposed, accepted, superseded, rejected Статус документа и состояние сущности разделены. Черновик не может молча переопределить действующее знание.

Правила

KAC-01 — Один scope — один canonical owner

У каждого существенного утверждения есть ровно один canonical owner в объявленном scope. Owner — запись или система, которая поддерживает актуальное утверждение; источники-свидетельства и steward-человек фиксируются отдельно.

KAC-02 — Разделяйте источник, утверждение и производное

Источник сохраняет то, что произошло или было сказано. Каноническое утверждение фиксирует то, что организация сейчас принимает. Производное преобразует upstream-материал. Они не подменяют друг друга.

KAC-03 — Происхождение не равно истинности

Provenance отвечает, кто, когда, из чего и каким преобразованием создал запись. Проверка отдельно указывает, что именно доказывает свидетельство, по какому критерию, в каком scope и на какую дату.

KAC-04 — Один вопрос — одна ось метаданных

Не кодируйте достоверность, роль, авторство и lifecycle одной меткой. Независимые поля позволяют машинно-сгенерированному отчёту одновременно быть производным, active и основанным на claims без противоречия.

KAC-05 — Типизированные ссылки вместо копий

Ссылайтесь на каноническую запись с явным типом связи: evidence_for, derived_from, implements или supersedes. Полезная ссылка объясняет, что находится по адресу и зачем туда переходить.

KAC-06 — Устойчивый owner, переписка как транспорт

Решения, договорённости и инструкции живут у правильного canonical owner; чат и почта передают ссылки и уведомления. Код владеет реализацией, операционные системы — транзакционным состоянием, документация — intent, rationale и contracts.

KAC-07 — Сначала upstream, затем синхронизация downstream

Сначала меняйте смысл у canonical owner. Затем проверяйте прямые зависимости и обновляйте, инвалидируйте либо явно оставляйте их без изменений. Конфликтующее active-знание — дефект, а не альтернативная истина.

KAC-08 — Явно задавайте схему и lifecycle

Повторяющиеся типы записей используют небольшую схему с условными полями. Отделяйте статус документа от статуса решения или delivery; фиксируйте as_of, дату пересмотра и supersedes там, где время или замена действительно имеют значение.

KAC-09 — Один артефакт — одна ответственность

Полезная граница атомарности — независимый owner, lifecycle или граница изменения, а не каждое предложение. Разделяйте монолиты, не создавая лабиринт из фрагментов.

KAC-10 — Сначала индекс, детали по необходимости

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

KAC-11 — Результат ведёт обратно к свидетельствам

Ответ человека или AI, отчёт и решение называют поддерживающие свидетельства, отделяют цитату от вывода и сохраняют неизвестное. Уверенный тон не заменяет проверку.

KAC-12 — Контекст и доступ следуют за источником

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

Минимальный пример записи

Пример фиксирует ровно то, что доказывает свидетельство: клиент сделал заявление. Он не превращает это заявление в доказательство наличия денег.

id: AST-042
record_kind: assertion
status: active
canonical_for:
  - customer_budget_status
steward: sales-lead
as_of: "2026-08-14"
epistemic_state: claim
generation_mode: human_authored
evidence:
  - path: correspondence/client-message.md
    supports: customer_stated_that_budget_is_approved
derived_from: []
supersedes: AST-037
access: internal

Более подробное объяснение, производное от этого реестра: «Корпоративная память, пригодная для AI».

Основания

  • W3C PROV Primer — происхождение через сущности, действия и агентов.
  • FAIR Guiding Principles — находимые, доступные, совместимые и повторно используемые данные для людей и машин.
  • Pro Git: About Version Control — история изменений как часть рабочего объекта.