# ТЗ Этап 3
## Lifecycle Formalization для Assistant Mode

---

## 0. Назначение этапа

Этап 3 вводит в Assistant Mode формальную модель жизненных циклов бухгалтерских объектов и цепочек, чтобы система могла определять не только факт аномалии или конфликта, но и **тип нарушения бухгалтерской логики во времени**.

После Этапа 2 ассистент уже должен уметь поднимать `problem units`: конфликтные документы, разорванные цепочки, проблемные кластеры расчётов, узлы несогласованности между ветками. Но без формальной lifecycle-модели система всё ещё остаётся на уровне:

- «обнаружен разрыв»;
- «есть признаки незавершённости»;
- «цепочка подтверждена неполно»;
- «найдены признаки broken_lifecycle».

Для бухгалтерского copilot этого недостаточно. Реальная ценность возникает тогда, когда система может ответить:

- **какая стадия должна была наступить, но не наступила**;
- **какой переход произошёл неправильно**;
- **какая запись зависла во времени и почему**;
- **какой контур формально закрыт, но смыслово закрыт некорректно**;
- **какой lifecycle-дефект влияет на закрытие периода, вычет, амортизацию, списание или расчётный контур**.

Этап 3 нужен для перехода:

**от problem-centric retrieval → к lifecycle-aware accounting reasoning**.

---

## 1. Цель этапа

Цель Этапа 3 — построить рабочий lifecycle knowledge layer, который позволит:

1. формально описать допустимые стадии и переходы по ключевым бухгалтерским доменам;
2. определять текущее состояние объекта или цепочки по данным из 1С/snapshot/retrieval output;
3. выявлять типовые lifecycle-дефекты;
4. обогащать problem units информацией о состоянии, переходах и нарушениях;
5. объяснять пользователю проблему через логику бухгалтерского жизненного цикла, а не через общие labels.

---

## 2. Границы этапа

### 2.1. Что входит в этап

Этап 3 включает:

- формализацию lifecycle-доменов;
- описание lifecycle-сущностей и состояний;
- описание допустимых переходов;
- описание lifecycle-дефектов;
- создание runtime-слоя определения состояния и дефекта;
- интеграцию lifecycle в problem units;
- интеграцию lifecycle в ranking и answer synthesis;
- создание eval-контуров для lifecycle-aware ответов.

### 2.2. Что не входит в этап

На этом этапе **не строится**:

- полный ontology graph по всей бухгалтерии;
- полный rule engine по всем типам учёта;
- полная live-verification архитектура;
- полноценный investigation orchestrator;
- полное покрытие всех возможных бухгалтерских доменов;
- универсальная state machine для всей 1С.

Этап 3 должен быть **достаточно глубоким, но не бесконечным**: он закладывает формальную основу жизненных циклов на ключевых доменах высокой продуктовой ценности.

---

## 3. Архитектурный смысл этапа

### 3.1. От какой проблемы идём

Текущий ассистент может:

- распознать предмет вопроса;
- сузить выборку;
- собрать problem unit;
- показать конфликт или кластер;
- частично объяснить механизм разрыва.

Но он всё ещё недостаточно понимает:

- что именно считалось «нормальным» состоянием объекта;
- какой следующий шаг ожидался в бухгалтерской логике;
- где объект застрял или перескочил стадию;
- какой статус формально есть, но смыслово противоречив;
- чем отличается «зависло» от «закрыто неправильно»;
- чем отличается «не успело» от «системно не дошло до нужной стадии».

### 3.2. Что меняется после этапа

После Этапа 3 ассистент должен оперировать не только problem units, но и:

- `current_lifecycle_state`;
- `expected_lifecycle_state`;
- `missing_transition`;
- `invalid_transition`;
- `stale_state_duration`;
- `lifecycle_defect_type`;
- `lifecycle_confidence`;
- `business_lifecycle_interpretation`.

То есть reasoning начинает строиться не только от “что сломано”, но и от “**на какой стадии и по какой логике это сломано**”.

---

## 4. Ключевой риск этапа и принцип защиты

### 4.1. Главный риск

Главный риск Этапа 3 — скатиться в **формальную, но бесполезную state-model архитектуру**, когда:

- состояния красиво описаны в документации;
- переходы перечислены;
- дефекты названы;
- но runtime по ним почти не работает;
- retrieval их не использует;
- ranking не учитывает;
- ответы не улучшаются.

Это недопустимо.

### 4.2. Принцип защиты

Lifecycle formalization считается выполненным только если каждый lifecycle-элемент имеет **четыре обязательных уровня реализации**:

1. **spec-level** — состояние/переход/дефект описан;
2. **runtime-level** — он реально может быть определён на основании текущих данных;
3. **retrieval-level** — он может быть включён в problem unit и ranking;
4. **answer-level** — он отражается в объяснении пользователю.

Если хотя бы один из этих уровней отсутствует, lifecycle-элемент считается не введённым в систему, а только формально описанным.

### 4.3. Обязательное правило

Любая lifecycle-модель, вводимая в Этапе 3, должна сопровождаться:

- списком входных признаков из данных;
- формулой/правилом разрешения состояния;
- типами выходных lifecycle-полей в runtime;
- способом использования в ranking;
- шаблоном user-facing интерпретации.

---

## 5. Домены, которые покрываются на этапе 3

На этапе 3 покрываются только домены высокой боли и высокой продуктовой полезности.

### 5.1. Банк и расчётный контур

**Основной фокус:** 51/60, 51/62, выписка, платёж, расчёт, закрытие, зачёт, разрыв между движением денег и расчётным результатом.

Почему важен:

- много вопросов пользователей связано с 51 счётом и “не тем закрытием”;
- часто проблема находится не в факте оплаты, а в том, что движение денег не доведено до ожидаемой расчётной стадии;
- именно здесь особенно часто встречается mismatch между выпиской, документом, проводкой и расчётным контуром.

### 5.2. Покупатели и дебиторский контур

**Основной фокус:** 62, реализация, оплата, аванс, зачёт, дебиторка, незавершённые расчёты.

Почему важен:

- похож по природе на поставщиков, но имеет свои финальные стадии и ошибки;
- нужен для вопросов про зависшие оплаты, незакрытые авансы, искусственно живую дебиторку.

### 5.3. РБП / 97

**Основной фокус:** возникновение РБП, срок, график списания, частичное списание, полное списание, просроченное состояние, отсутствие ожидаемого продолжения.

Почему важен:

- это один из самых естественных и наглядных lifecycle-доменов;
- здесь критична временная логика и окно корректной жизни объекта;
- по нему можно получить сильные ответы в стиле “объект живёт дольше допустимого lifecycle”.

### 5.4. ОС / 08 / 01 / 02

**Основной фокус:** капитальные вложения, принятие к учёту, ввод в эксплуатацию, амортизация, выбытие, противоречивый статус объекта.

Почему важен:

- это домен, где без lifecycle reasoning ответы почти всегда поверхностны;
- проблема часто находится не в записи, а в том, что объект находится между стадиями или в противоречивом состоянии.

### 5.5. НДС / 19 / 68

**Основной фокус:** первичка, счёт-фактура, отражение НДС, вычет, период, связь бухгалтерского и налогового отражения.

Почему важен:

- много cross-domain конфликтов;
- нужна стадийность, а не только document matching;
- налоговый контур хорошо показывает ценность lifecycle formalization.

### 5.6. Закрытие периода

**Основной фокус:** готовность объекта к закрытию, блокирующие состояния, незавершённые хвосты, stale states, period impact.

Почему важен:

- это мета-домен, который связывает lifecycle-дефекты остальных доменов с реальной управленческой болью;
- пользователю часто важен не только сам дефект, но и влияет ли он на закрытие.

---

## 6. Бухгалтерские сущности, которые участвуют в lifecycle-модели

Ниже перечислены сущности, которые должны использоваться для построения lifecycle-моделей. Список фиксирует не только названия, но и смысловую роль сущности в жизненном цикле.

### 6.1. Документ

Роль:

- фиксирует событие учётного действия;
- часто является маркером стадии lifecycle;
- может подтверждать переход или завершение стадии.

Типовые примеры:

- банковская выписка;
- платёжное поручение;
- поступление;
- реализация;
- счёт-фактура;
- ввод ОС в эксплуатацию;
- принятие ОС к учёту;
- регламентная операция;
- документ списания РБП.

### 6.2. Проводка

Роль:

- подтверждает отражение документа в учёте;
- служит индикатором того, что стадия не просто оформлена документно, но и проведена в учётном контуре.

### 6.3. Движение регистра / запись регистра

Роль:

- подтверждает состояние объекта в прикладном/расчётном контуре;
- особенно важно для расчётов, НДС, закрытия периода, взаиморасчётов.

### 6.4. Счёт / субсчёт

Роль:

- задаёт предметный контур lifecycle;
- помогает отличать домен и стадию.

### 6.5. Контрагент

Роль:

- не должен быть главной retrieval unit;
- выступает носителем связанного расчётного контекста.

### 6.6. Договор

Роль:

- ограничивает расчётный и документный lifecycle;
- важен для определения правильного завершения цепочки.

### 6.7. Объект ОС

Роль:

- primary lifecycle object в домене основных средств.

### 6.8. Объект РБП

Роль:

- primary lifecycle object в домене deferred expenses.

### 6.9. НДС-контур / счёт-фактура / налоговая запись

Роль:

- primary lifecycle object в налоговой ветке согласования.

### 6.10. Период / регламентный шаг закрытия

Роль:

- вводит внешний temporal frame;
- позволяет понимать stale state и impact on close.

---

## 7. Архитектурные сущности, которые должны быть введены на этапе 3

Это новые runtime и schema-level сущности, которые должны появиться в системе.

### 7.1. `lifecycle_domain`

Назначение: верхнеуровневая область применения lifecycle-модели.

Примеры значений:

- `bank_settlement`
- `customer_settlement`
- `deferred_expense`
- `fixed_asset`
- `vat_flow`
- `period_close`

Смысл:

- определяет, какие состояния, переходы и дефекты допустимы;
- связывает raw retrieval и lifecycle resolver.

---

### 7.2. `lifecycle_object`

Назначение: конкретный объект, для которого определяется lifecycle.

Типы `lifecycle_object`:

- расчётная позиция;
- связка платёж + обязательство;
- объект ОС;
- запись РБП;
- НДС-цепочка;
- периодный проблемный объект.

Обязательные поля:

- `lifecycle_object_id`
- `lifecycle_object_type`
- `lifecycle_domain`
- `source_entities`
- `period_context`
- `account_context`
- `document_context`

Смысл:

- lifecycle применяется не к абстрактному “контрагенту вообще”, а к объекту правильного масштаба.

---

### 7.3. `lifecycle_state`

Назначение: формально определённая стадия жизни lifecycle_object.

Обязательные поля:

- `state_code`
- `state_label`
- `state_class`
- `entry_conditions`
- `exit_conditions`
- `is_terminal`
- `is_problematic`
- `business_meaning`

Смысл:

- состояние — это не только label, а интерпретируемая бизнес-стадия объекта.

---

### 7.4. `lifecycle_transition`

Назначение: допустимый или обнаруженный переход между состояниями.

Обязательные поля:

- `from_state`
- `to_state`
- `transition_type`
- `required_evidence`
- `optional_evidence`
- `forbidden_conditions`
- `business_meaning`

Смысл:

- переходы нужны, чтобы понимать, что объект не просто “есть”, а движется по нормальной бухгалтерской логике.

---

### 7.5. `lifecycle_defect`

Назначение: тип нарушения жизненного цикла.

Базовые типы:

- `missing_expected_transition`
- `invalid_transition`
- `stale_active_state`
- `contradictory_state`
- `premature_terminal_state`
- `misclosed_state`
- `orphan_intermediate_state`
- `cross_branch_state_conflict`

Обязательные поля:

- `defect_code`
- `defect_class`
- `severity_hint`
- `business_meaning`
- `evidence_requirements`
- `period_impact_potential`

---

### 7.6. `lifecycle_resolution`

Назначение: runtime-результат определения состояния объекта.

Обязательные поля:

- `lifecycle_object_id`
- `resolved_current_state`
- `resolved_expected_state`
- `resolved_previous_states`
- `missing_transitions`
- `invalid_transitions`
- `detected_defects`
- `state_confidence`
- `resolution_evidence`
- `snapshot_limitations`

Смысл:

- это не описание модели, а фактическое применение модели к данным.

---

### 7.7. `lifecycle_enriched_problem_unit`

Назначение: problem unit из Этапа 2, обогащённый lifecycle-смыслом.

Обязательные поля:

- `problem_unit_id`
- `problem_unit_type`
- `lifecycle_domain`
- `current_lifecycle_state`
- `expected_lifecycle_state`
- `lifecycle_defect_type`
- `missing_transition`
- `invalid_transition`
- `stale_duration`
- `lifecycle_confidence`
- `business_lifecycle_interpretation`

Смысл:

- problem unit должен отвечать не только на вопрос “что сломано”, но и “на какой стадии и как именно это сломано”.

---

## 8. Domain lifecycle models: подробная классификация

Ниже — обязательная структура lifecycle-моделей по доменам.

---

## 8.1. Домен `bank_settlement`

### 8.1.1. Основные lifecycle objects

- движение по выписке;
- платёжный документ;
- связанная расчётная позиция;
- обязательство/аванс в расчётном контуре;
- связка платёж → закрытие обязательства.

### 8.1.2. Базовые состояния

- `initiated_payment`
- `bank_recorded`
- `accounting_reflected`
- `linked_to_settlement`
- `settlement_closed`
- `partially_closed`
- `stalled_after_payment`
- `misclosed`
- `contradicted`

### 8.1.3. Допустимые переходы

- initiated_payment → bank_recorded
- bank_recorded → accounting_reflected
- accounting_reflected → linked_to_settlement
- linked_to_settlement → settlement_closed

### 8.1.4. Типовые дефекты

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

### 8.1.5. Бизнес-интерпретация

Этот домен нужен для ответов типа:

- “проблема не в платеже, а в том, что дальше нормальной жизни не случилось”;
- “закрыли не тем документом”;
- “деньги ушли, но обязательство не дошло до корректного состояния”.

---

## 8.2. Домен `customer_settlement`

### 8.2.1. Основные lifecycle objects

- реализация;
- оплата;
- аванс;
- дебиторская позиция;
- связка реализация ↔ оплата ↔ зачёт.

### 8.2.2. Базовые состояния

- `sale_recorded`
- `payment_received`
- `linked_to_receivable`
- `receivable_closed`
- `advance_open`
- `advance_settled`
- `stalled_receivable`
- `contradicted_customer_state`

### 8.2.3. Типовые дефекты

- оплата есть, реализация или зачёт не дошли до закрытия;
- аванс остался открытым без нормального продолжения;
- дебиторка выглядит активной, хотя ожидаемый lifecycle уже должен был завершиться.

---

## 8.3. Домен `deferred_expense`

### 8.3.1. Основные lifecycle objects

- запись РБП;
- основание возникновения РБП;
- график списания;
- факты списания.

### 8.3.2. Базовые состояния

- `deferred_registered`
- `writeoff_window_active`
- `partially_written_off`
- `fully_written_off`
- `stale_unwritten`
- `stale_partially_written`
- `contradictory_writeoff_state`

### 8.3.3. Допустимые переходы

- deferred_registered → writeoff_window_active
- writeoff_window_active → partially_written_off
- partially_written_off → fully_written_off

### 8.3.4. Типовые дефекты

- срок списания уже активен, но движение не подтверждено;
- объект живёт за пределами допустимого окна;
- формально есть основание, но lifecycle не развивается;
- запись выглядит частично списанной, но фактический путь продолжения не подтверждён.

### 8.3.5. Бизнес-интерпретация

Нужна для ответов в стиле:

- “это висит слишком долго”;
- “по смыслу объект уже должен был уйти дальше”;
- “формальная жизнь записи не соответствует ожидаемому окну списания”.

---

## 8.4. Домен `fixed_asset`

### 8.4.1. Основные lifecycle objects

- вложение / 08;
- объект ОС;
- документ принятия к учёту;
- документ ввода в эксплуатацию;
- начисление амортизации;
- документ выбытия.

### 8.4.2. Базовые состояния

- `capex_in_progress`
- `accepted_to_assets`
- `commissioned`
- `depreciating`
- `disposed`
- `accepted_not_commissioned`
- `commissioned_not_depreciating`
- `contradictory_asset_state`

### 8.4.3. Допустимые переходы

- capex_in_progress → accepted_to_assets
- accepted_to_assets → commissioned
- commissioned → depreciating
- depreciating → disposed

### 8.4.4. Типовые дефекты

- объект принят, но не введён в ожидаемую стадию;
- объект формально активен, но начисления не соответствуют статусу;
- карточка и амортизационный контур не согласованы;
- стадия выбытия противоречит фактическим движениям.

---

## 8.5. Домен `vat_flow`

### 8.5.1. Основные lifecycle objects

- первичный документ;
- счёт-фактура;
- отражение НДС;
- налоговая запись;
- стадия вычета/периода.

### 8.5.2. Базовые состояния

- `base_document_recorded`
- `vat_document_present`
- `vat_reflected`
- `vat_ready_for_period`
- `vat_applied`
- `stalled_vat_state`
- `period_misaligned_vat`
- `cross_domain_vat_conflict`

### 8.5.3. Типовые дефекты

- счёт-фактура и учётный контур не дошли до согласованной стадии;
- НДС формально присутствует, но периодная логика не подтверждена;
- документный и налоговый контур расходятся по состоянию.

---

## 8.6. Домен `period_close`

### 8.6.1. Основные lifecycle objects

- объект/цепочка, влияющая на закрытие;
- регламентный шаг;
- незавершённая расчётная, складская, налоговая или lifecycle-позиция.

### 8.6.2. Базовые состояния

- `ready_for_close`
- `close_sensitive`
- `close_blocking`
- `close_contradicted`
- `close_unverified`

### 8.6.3. Типовые дефекты

- объект не дошёл до стадии, требуемой для закрытия;
- stale state пересекает границу периода;
- формально допустимое состояние на локальном уровне становится блокирующим на уровне закрытия периода.

---

## 9. Архитектура lifecycle runtime

Этап 3 должен ввести не только модели, но и runtime-компоненты.

### 9.1. Компонент `Lifecycle Registry`

Назначение:

- хранит доменные lifecycle-модели;
- предоставляет доступ к state/transition/defect definitions;
- служит единым source of truth для lifecycle-логики.

Содержимое:

- домен;
- список состояний;
- список переходов;
- дефекты;
- evidence requirements;
- business meaning.

### 9.2. Компонент `Lifecycle Resolver`

Назначение:

- по lifecycle_object и доступным данным определяет состояние, ожидаемое состояние, дефект и уверенность.

Входы:

- normalized retrieval data;
- problem unit source entities;
- account/document/register context;
- period context.

Выходы:

- `lifecycle_resolution`.

### 9.3. Компонент `Lifecycle Defect Classifier`

Назначение:

- преобразует “факты несоответствия” в тип lifecycle-дефекта.

Примеры:

- object active too long → `stale_active_state`
- expected closure absent → `missing_expected_transition`
- closed by inconsistent path → `misclosed_state`
- two branches disagree → `cross_branch_state_conflict`

### 9.4. Компонент `Lifecycle Enricher`

Назначение:

- обогащает `problem_unit` lifecycle-смыслом.

Выход:

- `lifecycle_enriched_problem_unit`.

---

## 10. Логика разрешения состояния

Для каждого домена должна быть описана стандартная схема resolution.

### 10.1. Общая логика

1. определить domain;
2. выбрать lifecycle_object правильного масштаба;
3. собрать evidence из документов, проводок, регистров, периода, статусов;
4. проверить entry/exit conditions по известным states;
5. построить допустимый path;
6. найти missing или invalid transitions;
7. вычислить current state и expected state;
8. классифицировать defect;
9. вычислить confidence;
10. передать результат в problem unit assembler / answer layer.

### 10.2. Правило масштаба

Lifecycle нельзя разрешать на слишком грубом объекте.

Например:

- не “контрагент вообще”,
- а “связка конкретного движения оплаты и ожидаемого закрытия”;
- не “все ОС по компании”,
- а “конкретный объект ОС и его стадия”;
- не “НДС в целом”,
- а “конкретная НДС-цепочка документа/периода”.

Это обязательное правило против формализма.

---

## 11. Интеграция lifecycle в problem units

Этап 3 должен использовать problem-centric модель Этапа 2, а не конкурировать с ней.

### 11.1. Что меняется в problem unit schema

В problem unit добавляются поля:

- `lifecycle_domain`
- `lifecycle_object_id`
- `current_lifecycle_state`
- `expected_lifecycle_state`
- `missing_transition`
- `invalid_transition`
- `lifecycle_defect_type`
- `stale_duration`
- `lifecycle_confidence`
- `business_lifecycle_interpretation`

### 11.2. Что это меняет по смыслу

Problem unit перестаёт быть просто:

- конфликтом,
- разрывом,
- аномалией,
- cluster.

Он становится:

- конфликтом на конкретной lifecycle-стадии;
- разрывом ожидаемого перехода;
- незавершённым состоянием с понятной business-интерпретацией;
- проблемой, у которой есть temporal и stage-based смысл.

---

## 12. Интеграция lifecycle в ranking

### 12.1. Почему это нужно

Без lifecycle ranking продолжает сильно зависеть от:

- частоты,
- суммы,
- количества связей,
- общей тревожности.

Но в бухгалтерии многие важные проблемы ценны не частотой, а тем, что:

- они глубоко сломаны по стадии;
- давно висят;
- влияют на закрытие;
- формально маскируются под “обычные” сущности.

### 12.2. Новые ranking factors

Добавить факторы:

- `lifecycle_defect_severity`
- `stale_duration_weight`
- `expected_transition_importance`
- `period_close_impact`
- `cross_branch_conflict_weight`
- `state_confidence_weight`
- `repeated_lifecycle_pattern_weight`

### 12.3. Обязательное правило

Если пользователь спрашивает не “по сумме”, а “по риску / по зависанию / по логике жизни объекта”, lifecycle-ranking должен иметь больший вес, чем money magnitude.

---

## 13. Интеграция lifecycle в answer layer

### 13.1. Новый стандарт объяснения

После Этапа 3 answer layer должен объяснять проблему по схеме:

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

### 13.2. Что запрещается

После Этапа 3 больше недопустимы объяснения вида:

- “обнаружены признаки broken_lifecycle”;
- “часть этапов подтверждена неполно”;
- “есть риск структурной незавершённости”.

Если lifecycle был успешно разрешён, ответ обязан использовать именно lifecycle-логику.

---

## 14. Как не скатиться в формальную архитектуру: обязательные правила реализации

Это отдельный критический блок этапа.

### 14.1. Правило 1. Не моделировать абстрактные состояния без evidence mapping

Каждое состояние должно быть связано с конкретными входными признаками из ваших данных из 1С/snapshot.

Если состояние нельзя распознать по реально доступным признакам, его нельзя вводить в runtime lifecycle model.

### 14.2. Правило 2. Не вводить домены, которые нельзя поддержать текущими данными

Lifecycle-модель домена разрешается только если:

- доступны документы и/или проводки;
- доступны признаки следующего шага;
- можно различить хотя бы 3–4 meaningful states;
- можно выявить хотя бы 2–3 meaningful defect types.

### 14.3. Правило 3. Не строить state model ради документации

Каждый lifecycle domain после введения должен иметь:

- unit tests на resolution;
- benchmark scenarios;
- пример problem unit enrichment;
- пример user-facing explanation.

### 14.4. Правило 4. Не использовать слишком крупный lifecycle object

Если lifecycle строится на уровне “контрагент”, “счёт вообще”, “НДС вообще”, “все ОС”, это признак ложной формализации.

Lifecycle должен применяться к объекту, у которого есть:

- осмысленная последовательность стадий;
- конкретные подтверждающие документы/движения;
- понятный business outcome.

### 14.5. Правило 5. Не скрывать низкую уверенность

Если состояние выведено эвристически, а не жёстко подтверждено, это должно отражаться в:

- `lifecycle_confidence`;
- answer wording;
- ranking weight.

### 14.6. Правило 6. Не отделять lifecycle от problem unit

Если lifecycle живёт отдельно в “аналитическом модуле”, а problem unit и answer composer продолжают работать по старому, значит этап выполнен формально, но не по сути.

---

## 15. Артефакты, которые должны быть созданы на этапе 3

### 15.1. Спецификационные артефакты

1. `lifecycle_domain_registry.md/json/yaml`
2. `domain_state_definitions`
3. `domain_transition_definitions`
4. `lifecycle_defect_catalog`
5. `lifecycle_object_mapping_spec`

### 15.2. Runtime-артефакты

1. `LifecycleRegistry`
2. `LifecycleResolver`
3. `LifecycleDefectClassifier`
4. `LifecycleEnricher`
5. updated `problem_unit_schema`
6. updated `ranking_policy`
7. updated `answer_policy`

### 15.3. Quality-артефакты

1. benchmark suite by domain
2. lifecycle resolution tests
3. defect classification tests
4. lifecycle-aware explanation tests
5. before/after eval report

---

## 16. Acceptance criteria

Этап 3 считается выполненным только если выполняются все условия.

### 16.1. По моделям

- для каждого целевого домена есть formal lifecycle model;
- states, transitions и defects описаны и привязаны к данным;
- lifecycle-модели не абстрактны и не висят отдельно от runtime.

### 16.2. По runtime

- есть lifecycle resolver;
- problem units реально обогащаются lifecycle-полями;
- defects вычисляются автоматически на основании retrieval data.

### 16.3. По ranking

- lifecycle severity влияет на ranking;
- stale и period-impact defects поднимаются выше при соответствующих вопросах;
- ranking больше не сводится к объёму и сумме.

### 16.4. По ответу

- ответы по covered domains объясняют проблему через state/transition logic;
- generic lifecycle labels уходят на второй план;
- у пользователя появляется понятное объяснение, какая стадия нарушена.

### 16.5. По ценности

- на сценариях 51/60, 97, ОС, НДС и period close ответы становятся содержательно глубже;
- system can distinguish “stalled”, “misclosed”, “not yet completed”, “contradicted”.

### 16.6. По защите от формализма

- для каждого lifecycle domain есть working examples;
- есть benchmark cases;
- есть связка spec → runtime → retrieval → answer.

---

## 17. Что не считается результатом этапа

Этап не считается выполненным, если:

- составлены красивые таблицы состояний, но runtime их не использует;
- lifecycle-поля появились в логах, но не используются в ranking/answer;
- ответы всё ещё формулируются общими lifecycle labels;
- состояния невозможно определить по реальным данным;
- домены выбраны слишком широко и нерешаемо;
- lifecycle применён к слишком крупным сущностям и ничего не даёт пользователю.

---

## 18. Идеальный результат этапа

После Этапа 3 Assistant Mode должен приобрести новую качественную способность:

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

Для пользователя это должно выражаться так:

- система понимает, где объект завис;
- система понимает, какой шаг ожидался дальше;
- система понимает, что закрыто не так, а не просто “не бьётся”;
- система может объяснить, почему запись формально жива, но смыслово некорректна;
- система начинает отвечать на бухгалтерском языке стадий, переходов, завершений и нарушений.

---

## 19. Короткое управленческое резюме

Этап 3 — это не “ещё немного логики”.

Это переход от problem-centric ассистента к системе, которая умеет понимать **бухгалтерскую жизнь объекта во времени**.

Именно этот этап создаёт базу для следующего архитектурного шага:

- ontology graph core;
- investigation engine;
- period-impact reasoning;
- зрелые causal answers.

Без lifecycle formalization ассистент останется системой, которая видит проблемы, но ещё недостаточно понимает, **почему они возникли как нарушение бухгалтерского пути объекта**.
