Стандарт данных и электронных таблиц

Актуальность: 3 августа 2026 года.

Решение

Использовать гибрид, а не один формат:

Тип информации	Основной формат	Почему
выводы, интервью, решения, отчёты и чек-листы	Markdown	читается человеком/Codex, удобно связывать и версионировать
P&L, cash flow, воронка, проекты, часы, scorecard и расчётные реестры	XLSX или Google Sheets	формулы, фильтры, ввод командой и сценарный анализ
обмен с Codex/CRM/API, импорт и архив снимка	UTF-8 CSV	переносимость, проверяемая схема, отсутствие скрытых формул
большая история событий и связи многих сущностей	SQLite/PostgreSQL	целостность, запросы и аудит изменений; только после исчерпания таблицы
дашборд/BI	производное представление	не источник истины; подключать при устойчивых определениях

Для большинства бизнесов 1–10 человек достаточно одной владельческой и одной производственной книги. СУБД/BI раньше появления объёма, нескольких писателей или проблем целостности создают лишнюю систему.

Пошаговый жизненный цикл рабочей копии — от скачивания шаблона до решения, снимка и архива — описан в WORKING_WITH_FILLED_DATA.md.

Источник истины

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

Почему не Markdown-таблицы для всего

Markdown подходит для небольшого реестра и отчёта, но слаб для формул, фильтрации, ввода сотен строк, сверки и сценариев. При 20–50 регулярно обновляемых строках или вычисляемых показателях реестр переносится в таблицу, а Markdown содержит вывод и ссылку на срез.

Почему не только XLSX

В XLSX легко получить скрытые формулы, разные версии файла и неясные ручные исправления. Поэтому обязательны:

• лист README с назначением, владельцем и правилами;
• словарь полей/метрик;
• стабильный ID строк;
• разделение ручных полей и формул цветом/защитой;
• журнал изменений для критических данных;
• контрольные суммы/сверки и дата закрытия периода;
• экспорт ключевых листов в CSV перед значимым аудитом;
• резервная копия и проверка восстановления.

XLSX или Google Sheets

XLSX/LibreOffice — когда данные должны оставаться локально, важны сложные модели/сценарии или нет устойчивого интернета. Google Sheets — когда нужен совместный ввод, история изменений, Apps Script и ограниченные доступы.

Google Sheets не должен автоматически получать всю папку Drive. Давать доступ к конкретным книгам/папкам, разделять владельческую и производственную книги, использовать MFA, минимальные OAuth scopes и бэкап. Перед автоматической записью — снимок, allowlist книги/диапазона, dry-run и идемпотентность.

Разделение доступа

• владельческая книга: деньги, маржа, долги, капитал, стратегия и стартапы;
• производственная: задачи, часы, клиенты, SLA и мощность без личных/стратегических финансов владельца;
• бухгалтер/юрист получают только необходимый контур;
• внешнему аудитору по возможности передаётся обезличенный срез;
• Codex сначала получает экспорт/read-only, не право записи.

Анализ Codex

Перед передачей таблицы:

1. зафиксировать бизнес, решение, период, валюту и определения;
2. удалить/заменить секреты и лишние персональные данные;
3. указать листы и колонки — источники истины;
4. отметить ручные формулы, пропуски, НДС/налоги и внутренние переводы;
5. передать неизменённый снимок и контрольные суммы;
6. попросить Codex разделить факты, расчёты, аномалии и гипотезы;
7. проверить критические строки в первичном источнике;
8. решение сохранить отдельно в журнале.

Codex не должен молча исправлять исходную книгу. Предложенное исправление оформляется отдельным патчем/списком строк с возможностью отката.

Когда переходить к базе данных

Признаки:

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

Даже после перехода Markdown остаётся слоем решений, а таблица — удобным экспортом/сценарием.

Практика Rosveb

Проект уже реализует полезные общие принципы:

• отдельные владельческая и производственная книги;
• воспроизводимую сборку XLSX отдельными генераторами, которые не входят в документационные сайты;
• импорт в Google Sheets, контроль формул/сумм, резервные копии;
• ограниченный OAuth и allowlist конкретных таблиц;
• idempotency, карантин ошибок и read-only AI-диагностику.

Для общей системы переносится метод, а не значения, клиенты, ставки или финансовые данные «Росвеб».

Критерий готовности таблицы

• одна строка имеет однозначный смысл и стабильный ID;
• ручные поля и формулы различимы;
• деньги/даты/статусы имеют единый формат;
• определения метрик воспроизводимы;
• есть сверка с первичным источником и дата среза;
• доступы минимальны, бэкап восстанавливается;
• таблица отвечает на решение и не требует несоразмерного обслуживания.

Связанные документы

• карта раздела — INDEX.md;
• заполнение, решение и архив — WORKING_WITH_FILLED_DATA.md;
• структура книг — WORKBOOK_SCHEMA.md;
• финансовые определения — ../METRICS_AND_FINANCE.md;
• CSV-схемы — ../../templates/tabular/README.md;
• решения и контекст — ../../templates/DECISION_LOG.md и ../../templates/BUSINESS_PASSPORT.md.