> Перевод даётся для удобства чтения. Нормативным является английский оригинал.

# Образцовый пример: Acme HR ⇄ Government Tax объединяются вокруг Лица

Это **сквозной образцовый пример**. Две суверенные вселенные - **Acme**
(работодатель) и **Government Tax** - объединяются так, чтобы сведения о
сотруднике можно было использовать для подачи налоговой декларации, причём ни
одна сторона не поступается владением своей моделью или своими данными. Одного
человека можно проследить на всём пути:

> **Идентичность → Отображение → Контракт → Проекция → Синхронизация → Конфликт.**

Здесь всё конкретно и проверено машиной: мета-модели несут настоящие
Семантические отпечатки, федерация есть настоящая расшифровка
[MUFP](../../03-federation/MUFP-Messages.md), а обе модели проходят валидацию
V0-V4.

## Две вселенные

| | Acme | Government Tax |
|--|------|----------------|
| Мета-модель | [`acme/employee-mm.muif.json`](acme/employee-mm.muif.json) | [`gov/taxpayer-mm.muif.json`](gov/taxpayer-mm.muif.json) |
| Объект | `employee.person` | `taxpayer.taxpayer` |
| Имена | `givenName`, `familyName` | `forename`, `surname` |
| Отпечаток | `sha256:0b4965f1…38c40` | `sha256:d51f639e…37ba6` |
| Валидация | [отчёт](acme/validation-report.json) (V4) | [отчёт](gov/validation-report.json) (V4) |

Две модели описывают одну и ту же реальность **разными словарями** - а это ровно
то, через что федерация и обязана перебросить мост.

## Проследите нить

1. **Идентичность** - один и тот же человек есть `employee:12345` в Acme и
   `taxpayer:99821` в Government Tax. Они привязаны к одной Канонической
   идентичности через [`identity-binding.json`](identity-binding.json),
   сопоставленные по общему налоговому номеру.
2. **Отображение** - словари выровнены через
   [`mapping/acme-to-gov.mapping.json`](mapping/acme-to-gov.mapping.json):
   `employee.familyName ≡ taxpayer.surname` и так далее. Отображение закрепляет
   отпечатки обеих сторон, так что оно действительно лишь для этих самых версий
   моделей.
3. **Контракт** - раскрытие управляется [`contract.json`](contract.json)
   (`Federation`, назначение `tax-filing`, три дозволенных поля, привязка к
   назначению, без дальнейшего раскрытия). Отпечаток `sha256:44582ad8…28af0`.
4. **Проекция** - Acme никогда не отправляет объект; она отправляет Проекцию под
   конкретное назначение, выставляющую лишь три законтрактованных поля.
5. **Синхронизация и конфликт** - Government Tax обнаруживает, что у Acme
   `familyName = "Smith"` расходится с его записью `surname = "Smyth"`. По
   [Сохранению конфликта](../../03-federation/Conflict-Resolution.md) конфликт
   записывается Событием `Conflict` первого класса, разрешается к полномочному
   значению, а **событие конфликта остаётся в истории** (Событие разрешения
   ссылается на него через `causality`).

Весь обмен лежит в [`transcript.json`](transcript.json) - 17 конвертов MUFP. Как
всегда, первое знание (Проекция) движется лишь на сообщении 14, после того как
улажены идентичность, доверие, контракт и схема.

## Проверка

```bash
# fingerprints round-trip (mu-fingerprint, see ../../tools/)
mu-fingerprint acme/employee-mm.muif.json   # sha256:0b4965f1...
mu-fingerprint gov/taxpayer-mm.muif.json    # sha256:d51f639e...

# models validate against the MUIF schemas
npx ajv-cli validate -s ../../schemas/manifest.schema.json -r "../../schemas/*.schema.json" \
  -d acme/employee-mm.muif.json --spec=draft2020

# every envelope validates against the MUFP envelope schema
npx ajv-cli validate -s ../../schemas/mufp-envelope.schema.json -r "../../schemas/*.schema.json" \
  -d transcript.json --spec=draft2020
```