> Esta traducción se ofrece por comodidad. El texto normativo es el original en inglés.

# Ejemplo dorado: Acme HR ⇄ Government Tax federan en torno a una Persona

Este es el **ejemplo dorado de principio a fin**. Dos universos soberanos -
**Acme** (un empleador) y **Government Tax** - federan para que los datos de un
empleado puedan usarse en la declaración fiscal, sin que ninguna de las partes
ceda la propiedad de su modelo ni de sus datos. Se puede seguir a una sola
persona todo el recorrido:

> **Identidad → Correspondencia → Contrato → Proyección → Sincronización → Conflicto.**

Todo aquí es concreto y comprobado por máquina: los meta-modelos llevan Huellas
semánticas reales, la federación es una transcripción
[MUFP](../../03-federation/MUFP-Messages.md) real, y ambos modelos pasan la
validación V0-V4.

## Los dos universos

| | Acme | Government Tax |
|--|------|----------------|
| Meta-modelo | [`acme/employee-mm.muif.json`](acme/employee-mm.muif.json) | [`gov/taxpayer-mm.muif.json`](gov/taxpayer-mm.muif.json) |
| Objeto | `employee.person` | `taxpayer.taxpayer` |
| Nombres | `givenName`, `familyName` | `forename`, `surname` |
| Huella | `sha256:0b4965f1…38c40` | `sha256:d51f639e…37ba6` |
| Validación | [informe](acme/validation-report.json) (V4) | [informe](gov/validation-report.json) (V4) |

Los dos modelos describen la misma realidad con **vocabularios distintos**, que
es exactamente lo que la federación debe salvar.

## Sigue el hilo

1. **Identidad**: el mismo ser humano es `employee:12345` en Acme y
   `taxpayer:99821` en Government Tax. Quedan vinculados a una sola Identidad
   canónica mediante [`identity-binding.json`](identity-binding.json), casados
   por el identificador fiscal compartido.
2. **Correspondencia**: los vocabularios se alinean mediante
   [`mapping/acme-to-gov.mapping.json`](mapping/acme-to-gov.mapping.json):
   `employee.familyName ≡ taxpayer.surname`, etc. La correspondencia fija las
   huellas de ambos lados, de modo que solo vale para esas versiones exactas de
   los modelos.
3. **Contrato**: la divulgación se rige por [`contract.json`](contract.json)
   (`Federation`, propósito `tax-filing`, tres campos permitidos, atado al
   propósito, sin divulgación ulterior). Huella `sha256:44582ad8…28af0`.
4. **Proyección**: Acme nunca envía el objeto; envía una Proyección específica
   para el propósito que expone solo los tres campos contratados.
5. **Sincronización y conflicto**: Government Tax detecta que el
   `familyName = "Smith"` de Acme discrepa de su registro `surname = "Smyth"`.
   Según la [Preservación del conflicto](../../03-federation/Conflict-Resolution.md),
   el conflicto se registra como un Suceso `Conflict` de primera clase, se
   resuelve hacia el valor autoritativo y **el suceso de conflicto se conserva en
   la historia** (el Suceso de resolución lo referencia mediante `causality`).

El intercambio entero está en [`transcript.json`](transcript.json): 17 sobres
MUFP. Como siempre, el primer conocimiento (la Proyección) se mueve solo en el
mensaje 14, una vez resueltos identidad, confianza, contrato y esquema.

## Verificar

```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
```