# Verification record — `uy/imm/empadronamiento-vehiculos-nacionales` v1.0.0

This file is the **source-review record** for this document version, per the
[`manual-source-review-v1`](../../../../../practices/manual-source-review-v1.md)
practice. It documents the provenance of the published fields/documents and
states the current verification claim honestly.

## Current claim

- **`status`:** `draft`
- **`verification.method`:** `manual-source-review-v1`
- **`verification.lastVerifiedAt`:** `2026-07-12`

This is a `GovSchema Standard Research` cycle (**GOV-2456**), tasked with
opening Uruguay's DMV vertical (2 of 6) via the Intendencia de Montevideo's
(IMM) vehicle registration form, Formulario F19. Uruguay had only Business
Formation modelled prior to this cycle
(`uy/dgi/inscripcion-actualizacion-empresas-formulario-0351`, GOV-2449).

## Why this candidate, and why municipal/departmental scope

Vehicle registration in Uruguay is not run by a national ministry — it is
administered separately by each of Uruguay's 19 departmental governments
(Intendencias), each of which operates its own vehicle registry and its own
SUCIVE-integrated circulation-permit process under Ley Nº 19.061. This
schema is therefore scoped to Montevideo, IMM's own Servicio de Contralor y
Registro de Vehículos, and modeled as `jurisdiction.level: "subnational"`
with `subdivision: "UY-MO"` — the same tier this registry already uses for
`br/mg/detran/comunicacao-de-venda-de-veiculo` (`BR-MG`) and
`ca/on/mto/vehicle-registration` (`CA-ON`), rather than `"municipal"` (which
this registry reserves for a sub-division-of-a-subdivision body, e.g. Miami
County within Florida state, per GSP-0021 and requires a `locality` object).
Montevideo department is itself the top subnational tier, analogous to a
Brazilian state or Canadian province, not a county-like body nested inside
one. Any of Uruguay's other 18 departments would need their own future
schema.

## Sources examined

### Source 1 (primary `source`, the AcroForm PDF)

- **Authority:** Intendencia de Montevideo (IMM), Servicio de Contralor y
  Registro de Vehículos — División Tránsito, Unidad 4750
- **Document:** Formulario F19, "Empadronamiento de Vehículos" (per Ley Nº
  19.061, Decreto Nº 187/014)
- **URL:** <https://tramites.montevideo.gub.uy/sites/tramites.montevideo.gub.uy/files/tramites/documentos/F19%20-%20EmpadronamientoVehiculosImportados-cp-V6_10.pdf>
- **Access:** fetched directly (`curl`), HTTP 200, `Content-Type:
  application/pdf`, no login/CAPTCHA/WAF gate of any kind.
- **File identity:** `sha256:a6e5bd2b53304dab88dd15afc7d742033008127665a8c6881823b37849397fec`,
  138,349 bytes, PDF 1.6, `Producer: LibreOffice 7.3`, `Creator: Writer`,
  `Author: Rafael Goicoechea`, `CreationDate: D:20240727102341-03'00'`
  (2024-07-27). `IsAcroFormPresent: true`, `IsXFAPresent: false`.
- **Currency corroboration:** the HTTP `Last-Modified` header on this exact
  URL is `Sat, 24 Aug 2024 18:29:39 GMT`, and both of IMM's own trámite
  landing pages that link this file (see Sources 2 and 3) list "Formulario
  agosto 2024" as the current download — all three signals (PDF internal
  creation date, HTTP header, and the authority's own labeled download link)
  agree on a 2024-07/08 vintage, with no more recent revision found.
- **Extraction method:** `pdfjs-dist` v3.11.174 (Node, `pdfjs-dist/build/
  pdf.js`), `page.getAnnotations({ intent: "display" })` filtered to
  `subtype === "Widget"` for the AcroForm inventory, and
  `page.getTextContent()` (items sorted by descending y then ascending x) for
  the printed text layer, since every widget's own `alternativeText`
  (tooltip) is empty on this form — every field label below was recovered by
  correlating each widget's `rect` against the nearest printed text item's
  `transform` coordinates, not by reading tooltips.
- **Widget/field inventory (independently re-derived this cycle, matching
  this cycle's own prior scouting pass exactly):** **81 AcroForm widgets
  across 2 pages** (49 on page 1, 32 on page 2), resolving to **65 uniquely
  named fields** (some fields are radio-button groups sharing one field name
  across 2-4 widgets: `ImpoSINO`×2, `CEROSINO`×2, `TipoDocGes`×3,
  `TipoDocVen`×4, `TipoAfe`×2, `TipoDocTit1`×4, `TipoDocTit2`×4, `MATSINO`×2,
  `MATSINO_2`×2; every other named field is a single text-field widget).
- **Retrieved / reviewed:** 2026-07-12

### Source 2 (trámite landing page, domestic-vehicle path)

- **URL:** <https://tramites.montevideo.gub.uy/tramites-y-tributos/solicitud/empadronamiento-de-vehiculos-nacionales>
- **Access:** fetched directly, HTTP 200, no gate.
- **Content used:** the "Documentación a presentar" and "Casos especiales" /
  "Otras opciones de actuación" sections, which this schema's `documents[]`
  block is sourced from (see below). Confirms the same F19 PDF ("Formulario
  agosto 2024") is the download for this trámite, and that the form's own
  IMPORTADO/NACIONAL checkbox lets one PDF serve both the "nacionales" and
  "importados" trámites.
- **Retrieved / reviewed:** 2026-07-12

### Source 3 (trámite landing page, imported-vehicle path)

- **URL:** <https://tramites.montevideo.gub.uy/tramites-y-tributos/solicitud/empadronamiento-de-vehiculos-importados>
- **Access:** fetched directly, HTTP 200, no gate.
- **Content used:** cross-checked against Source 2's requisitos list. Mostly
  identical, with one material divergence used in this schema (see the
  `seguroEmpresa`/`seguroVigencia`/`seguroObligatorioDocumentFile`
  `requiredWhen` gate below): this page states a mandatory, already-valid
  SOA (Seguro Obligatorio Automotor) policy is required documentation
  ("Seguro obligatorio (SOA) vigente con los datos del vehículo según
  artículo 27 Ley 18.412") for the imports path, whereas Source 2 instead
  describes SOA being arranged only after filing, during a five-day
  provisional circulation permit ("Se entregará un provisorio de circulación
  por cinco días para que se gestione el seguro obligatorio (SOA)").
- **Retrieved / reviewed:** 2026-07-12

## Field inventory (Phase 3)

All 53 modeled fields, the printed section and label they come from, and the
underlying AcroForm field name(s):

| Field (schema `name`) | Label (source) | Section | AcroForm field(s) |
|---|---|---|---|
| `fechaSolicitud` | Fecha | Header | `Dia`/`Mes`/`Anio` |
| `tipoOrigen` | Importado / Nacional | Header | `ImpoSINO` |
| `tipoCondicion` | Cero KM. / Usado | Header | `CEROSINO` |
| `gestionanteTipoDocumento` | Tipo del documento | Identificación del Gestionante | `TipoDocGes` |
| `gestionanteNombre` | Nombre y apellido | Identificación del Gestionante | `NomGestor` |
| `gestionanteTelefono` | Teléfono | Identificación del Gestionante | `NumTelGestor` |
| `gestionanteNumeroDocumento` | Número del documento | Identificación del Gestionante | `NumDocGestor` |
| `gestionantePaisDocumento` | País del documento | Identificación del Gestionante | `PaisDocGestor` |
| `vendedorNombre` | Nombres y apellidos o Razón social | Identificación del Vendedor | `NomVen` |
| `vendedorTelefono` | Número de teléfono | Identificación del Vendedor | `NumTelVen` |
| `vendedorTipoDocumento` | Tipo de documento | Identificación del Vendedor | `TipoDocVen` |
| `vendedorNumeroDocumento` | Número del documento | Identificación del Vendedor | `NumDocVen` |
| `vendedorPaisDocumento` | País del documento | Identificación del Vendedor | `PaisDocVen` |
| `vendedorDomicilio` | Domicilio | Identificación del Vendedor | `DomVen` |
| `vendedorCodigoPostal` | Código postal | Identificación del Vendedor | `CodPosVen` |
| `vendedorDomicilioElectronico` | Domicilio electrónico | Identificación del Vendedor | `MailVen` |
| `vehiculoMarca` | Marca | Datos del Vehículo | `Marca` |
| `vehiculoModelo` | Modelo | Datos del Vehículo | `Modelo` |
| `vehiculoAnio` | Año | Datos del Vehículo | `Anio_2` |
| `vehiculoCombustible` | Combustible | Datos del Vehículo | `Combustible` |
| `vehiculoChasis` | Número de chasis | Datos del Vehículo | `Chasis` |
| `vehiculoMotor` | Número de motor | Datos del Vehículo | `Motor` |
| `vehiculoTipo` | Tipo | Datos del Vehículo | `Tipo` |
| `vehiculoCilindrada` | C.C. | Datos del Vehículo | `CC` |
| `vehiculoPotencia` | H.P. | Datos del Vehículo | `HP` |
| `vehiculoCilindros` | Cilindros | Datos del Vehículo | `Cilindros` |
| `vehiculoPasajeros` | Pasajeros | Datos del Vehículo | `Pasajeros` |
| `vehiculoCarga` | Carga | Datos del Vehículo | `Carga` |
| `vehiculoPbt` | P.B.T. | Datos del Vehículo | `PBT` |
| `vehiculoEjes` | Ejes | Datos del Vehículo | `Ejes` |
| `vehiculoCubiertas` | Cubiertas | Datos del Vehículo | `Cubiertas` |
| `vehiculoAtributos` | Atributo | Datos del Vehículo | `Atributos` |
| `seguroEmpresa` | Empresa seguro | Datos del Vehículo | `Empresa Seguro` |
| `seguroVigencia` | Vigencia seguro | Datos del Vehículo | `DiaS`/`MesS`/`AnioS` |
| `tipoAfectacion` | Tipo de afectación | Header (p.2) | `TipoAfe` |
| `afectacionDetalle` | (blank beside OTRO) | Header (p.2) | `Afectacion` |
| `titular1Nombre` | Nombres y apellidos o Razón social | Identificación del Titular #1 | `NomTit1` |
| `titular1Telefono` | Número de teléfono | Identificación del Titular #1 | `NumTelTit1` |
| `titular1TipoDocumento` | Tipo de documento | Identificación del Titular #1 | `TipoDocTit1` |
| `titular1NumeroDocumento` | Número del documento | Identificación del Titular #1 | `NumDocTit1` |
| `titular1PaisDocumento` | País del documento | Identificación del Titular #1 | `PaisDocTit1` |
| `titular1Domicilio` | Domicilio | Identificación del Titular #1 | `DomTit1` |
| `titular1CodigoPostal` | Código postal | Identificación del Titular #1 | `CodPosTit1` |
| `titular1DomicilioElectronico` | Domicilio electrónico | Identificación del Titular #1 | `MailTit1` |
| `titular2Presente` | *(synthetic gating field)* | Identificación del Titular #2 | *(none — see judgment call 3)* |
| `titular2Nombre` | Nombres y apellidos o Razón social | Identificación del Titular #2 | `NomTit2` |
| `titular2Telefono` | Número de teléfono | Identificación del Titular #2 | `NumTelTit2` |
| `titular2TipoDocumento` | Tipo de documento | Identificación del Titular #2 | `TipoDocTit2` |
| `titular2NumeroDocumento` | Número del documento | Identificación del Titular #2 | `NumDocTit2` |
| `titular2PaisDocumento` | País del documento | Identificación del Titular #2 | `PaisDocTit2` |
| `titular2Domicilio` | Domicilio | Identificación del Titular #2 | `MailTit2_2` *(mislabeled widget name — see judgment call 4)* |
| `titular2CodigoPostal` | Código postal | Identificación del Titular #2 | `CodPosTit2` |
| `titular2DomicilioElectronico` | Domicilio electrónico | Identificación del Titular #2 | `MailTit2` |

**53 fields total**, covering 70 of the 81 AcroForm widgets (56 of the 65
uniquely named fields — 52 mapped 1:1 or as a consolidated radio/date group,
plus 1 synthetic gating field with no underlying widget of its own).

## Access notes and judgment calls

1. **9 named fields (11 widgets) excluded, disclosed rather than guessed.**
   Two clusters:
   - **`NumTelGestor_2`/`_3`/`_4`/`_5` (4 widgets, page 1 header row).**
     These sit directly under printed labels **"ID"** and **"CÓDIGO
     NACIONAL"** (confirmed by coordinate correlation: the "ID" text item
     sits above `NumTelGestor_2`'s rect, and "CÓDIGO NACIONAL" spans above
     the combined rects of `NumTelGestor_3`/`_4`/`_5`), but their AcroForm
     field names are verbatim duplicates of the unrelated
     "gestionante phone number" field family (`NumTelGestor`) — a clear
     copy/paste artifact from the PDF's authoring in LibreOffice. Whether
     these boxes are an applicant-entered lookup value (e.g. a national
     vehicle-catalog code the importer/gestor already has on hand) or an
     office-assigned reference number could not be confidently determined
     from the source PDF alone, so — per this cycle's brief instruction to
     disclose rather than guess — they are excluded from this v1.0.0 rather
     than modeled under a name that implies a confident semantic reading.
   - **The "RECIBE DOCUMENTOS" section (page 2, 7 widgets: `MATSINO`×2,
     `MATSINO_2`×2, `MatLetEnt`, `MatNumEnt`, `RECIBIDIV`).** Coordinate
     correlation places these against "Recibí matrículas.:" / "Recibí
     D.I.V.:" labels with their own SI/NO checkboxes and plate-letter/
     plate-number/D.I.V.-number blanks — this is a receipt acknowledgment of
     physical plates and the D.I.V. (Documento de Identificación Vehicular)
     handed over during the in-person appointment, i.e. an output of the
     transaction rather than applicant-supplied input to the registration
     request itself, matching this registry's established convention of
     excluding office-interaction/receipt-acknowledgment boxes (cf.
     `pe/mtc/solicitud-licencia-conducir-012-17`'s exclusion of its own
     "Uso de Mesa de Partes" box).
   - The **"FUNCIONARIOS ACTUANTES"** section (Funcionario/Sector
     Ingresos/Sector Control, firma y sello) and the **"RECUERDE"** legal
     notice block carry **zero AcroForm widgets** of their own — they are
     pure print layout (staff signature lines and a citation of Artículo
     239 of the Código Penal) — so they require no explicit exclusion from
     the widget count, but are noted here for completeness.
2. **`gestionanteTipoDocumento` has no RUT option (3 widgets); the vendedor
   and both titular document-type fields do (4 widgets each).** Coordinate
   correlation confirms the printed checkbox rows themselves differ in
   length: the gestionante (whoever physically files the paperwork) is
   modeled by this form as always a natural person, while the vendedor and
   titular(es) may be a RUT-bearing business entity — consistent with the
   trámite pages' own "Cuando el titular del vehículo es una empresa..."
   guidance.
3. **`titular2Presente` is a synthetic gating field with no corresponding
   source widget.** The printed form simply repeats its entire "Identificación
   del Titular" block a second time with no yes/no checkbox of its own
   controlling whether it applies; this schema adds a boolean gate so a
   consumer can determine whether the second block's `requiredWhen`-gated
   fields apply, following the identical precedent set by
   `uy/dgi/inscripcion-actualizacion-empresas-formulario-0351`'s own
   `segundoTitularPresente`.
4. **`titular2Domicilio` is sourced from the AcroForm widget internally
   named `MailTit2_2`, not from any widget containing "Dom" in its name.**
   Coordinate correlation is unambiguous here: for Titular #1, the printed
   "Domicilio" label sits 6.2pt above the top edge of the `DomTit1` widget's
   rect; for Titular #2, the printed "Domicilio" label sits 6.1pt above the
   top edge of `MailTit2_2`'s rect (the same offset, confirming the
   correlation) — while the genuinely well-named `MailTit2` widget instead
   aligns with the printed "Domicilio electrónico" (email) label lower in
   the same block. This is a second, distinct copy-paste/mislabeling
   artifact in the same PDF as judgment call 1, disclosed here rather than
   silently "corrected" into a differently-named schema field, so a future
   reader auditing this schema against the raw PDF via `pdfjs-dist` can find
   the same widget under the same internal name.
5. **`seguroEmpresa`/`seguroVigencia` (insurance company/policy validity) and
   the `seguroObligatorioDocumentFile` document are `requiredWhen tipoOrigen
   == "importado"`.** This is sourced from a genuine divergence between
   IMM's own two trámite pages (see Source 3 above): the imports page
   requires a valid SOA policy as filing documentation, while the domestic
   page describes SOA being arranged only after a provisional permit is
   issued. The AcroForm's own `required` widget attribute is unset
   (`false`) on every widget on this form, so this schema follows the
   trámite pages' own prose over the PDF's (uninformative) internal
   required-flags, consistent with this registry's established practice
   (cf. `pe/mtc/solicitud-licencia-conducir-012-17`).
6. **`documents[]` — sourced from both trámite landing pages' own
   "Documentación a presentar" / "Casos especiales" / "Otras opciones de
   actuación" sections, not modeled exhaustively.** This form's requisitos
   branch heavily by seller type (private individual vs. business), by
   whether the vehicle was self-built, by classic/collector-vehicle import
   regimes (Ley 17.887, Ley 19.996), by municipal-fleet or
   Interior/Defensa-fleet vehicles, and by who is signing (the titular
   directly, a minor's parent/tutor/curador, an attorney-in-fact, or a
   company representative). This v1.0.0 models the five requisitos that
   apply broadly across the common individual-registrant path (gestionante's
   own ID, one of the three standard origin-proof documents, the
   conditionally-required SOA policy, the private-seller ID+receipt
   combination, and the general non-titular-representative ID copy) and
   discloses the narrower special-case documents (self-built-vehicle
   sworn declaration, minor/tutor/curador/power-of-attorney packets,
   classic-import ministerial resolutions, municipal/Interior-Defensa fleet
   paperwork) as out of scope for this version, following the same
   scoping-and-disclosure convention as
   `br/mg/detran/comunicacao-de-venda-de-veiculo`'s own documents[] entry.
7. **No signature/fingerprint fields are modeled**, consistent with this
   registry's established convention (cf. `pe/mtc`, `uy/dgi`) — the "Firma
   del gestionante" / "Firma del vendedor o representante" / "Firma del
   titular o representante" lines and the seller's company stamp box are
   physical marks on the printed form with no corresponding AcroForm widget
   in this PDF (this form has no signature-widget annotations at all,
   unlike e.g. `fi/traficom/luovutuskirja-ajoneuvon-omistusoikeuden-siirrosta`'s
   genuine fillable signature-line widgets).

## Test run (Phase 4)

No live submission was attempted: F19 is filed in person at IMM's Servicio
de Contralor y Registro de Vehículos (Pedernal 2219) with the physical
vehicle presented, per both trámite pages ("Debe presentar el vehículo al
momento de realizar el trámite") — there is no unauthenticated online
endpoint to submit fabricated data against.

Instead, two independent worked mock records were built from this
document's own field inventory (one domestic/used/single-titular, one
imported/cero-km/two-titulares) and checked with a purpose-written script
(`_tmp_validate_instance.mjs`, not committed — mirrors the approach used by
`pe/mtc/solicitud-licencia-conducir-012-17` and
`uy/dgi/inscripcion-actualizacion-empresas-formulario-0351`): compiles
`schema.json`'s `fields[]` into a JSON Schema draft 2020-12 document checked
with `ajv` (`ajv/dist/2020.js`, matching `tools/validate-ajv.mjs`'s own
draft selection), plus a from-scratch evaluator for the shared Condition
grammar that checks `fields[].requiredWhen`:

```
$ node tools/_tmp_validate_instance.mjs registry/uy/imm/empadronamiento-vehiculos-nacionales/1.0.0/schema.json \
    conformance/uy/imm/empadronamiento-vehiculos-nacionales/1.0.0/nacional-usado-un-titular.json
Static (required/type/pattern/enum) validation: PASS
requiredWhen conditional validation: PASS
OVERALL: PASS

$ node tools/_tmp_validate_instance.mjs registry/uy/imm/empadronamiento-vehiculos-nacionales/1.0.0/schema.json \
    conformance/uy/imm/empadronamiento-vehiculos-nacionales/1.0.0/importado-cero-km-dos-titulares.json
Static (required/type/pattern/enum) validation: PASS
requiredWhen conditional validation: PASS
OVERALL: PASS
```

**Mutation controls** — three negative fixtures, each targeting a distinct
validation rule, each verified to raise **exactly one** validation error:

```
$ # mutation-control-missing-required-field.json: 'vehiculoChasis' (required: true) removed
Static (required/type/pattern/enum) validation: FAIL
 - (root) must have required property 'vehiculoChasis'
requiredWhen conditional validation: PASS
OVERALL: FAIL

$ # mutation-control-email-pattern-violation.json: 'vendedorDomicilioElectronico' set to 'not-an-email'
Static (required/type/pattern/enum) validation: FAIL
 - /vendedorDomicilioElectronico must match pattern "^[^@\s]+@[^@\s]+\.[^@\s]+$"
requiredWhen conditional validation: PASS
OVERALL: FAIL

$ # mutation-control-missing-conditional-titular2-field.json: 'titular2Presente' is true
$ # but 'titular2NumeroDocumento' (requiredWhen titular2Presente == true) removed
Static (required/type/pattern/enum) validation: PASS
requiredWhen conditional validation: FAIL
 - field 'titular2NumeroDocumento' is required (requiredWhen matched) but not provided
OVERALL: FAIL
```

The third case specifically exercises `fields[].requiredWhen` (as opposed to
the plain static-`required` case in `mutation-control-missing-required-field.json`)
— a validator that only checks static `required: true` fields and ignores
conditional `requiredWhen` rules would incorrectly accept this fixture,
which is exactly the gap this fixture exists to catch.

Both meta-schema validators were run against the finished document and pass
clean:

```
$ node tools/validate.mjs registry/uy/imm/empadronamiento-vehiculos-nacionales/1.0.0/schema.json
ok   registry/uy/imm/empadronamiento-vehiculos-nacionales/1.0.0/schema.json

1/1 document(s) passed.

$ node tools/validate-ajv.mjs registry/uy/imm/empadronamiento-vehiculos-nacionales/1.0.0/schema.json
ok   registry/uy/imm/empadronamiento-vehiculos-nacionales/1.0.0/schema.json [v0.3]

1/1 document(s) validated against the meta-schema (ajv 2020-12).
```

A full-registry run of both validators also passed clean (372/372, up from
371 before this document), `tools/verify-sources.mjs` re-fetched all 3 cited
URLs with 0 failures/warnings, and
`tools/govschema-client/registry-index.json` was regenerated via `npm run
build-index` (in `tools/govschema-client/`, after `npm ci --include=dev`
since a plain `npm ci` under a local `NODE_ENV=production` skips `ajv`'s
devDependency install) to include this document's entry.

## How to re-verify

1. `curl -sO "https://tramites.montevideo.gub.uy/sites/tramites.montevideo.gub.uy/files/tramites/documentos/F19%20-%20EmpadronamientoVehiculosImportados-cp-V6_10.pdf"`
   and confirm `sha256sum` matches
   `a6e5bd2b53304dab88dd15afc7d742033008127665a8c6881823b37849397fec`.
2. `npm install pdfjs-dist@3.11.174` in a scratch directory, then run
   `page.getAnnotations({ intent: "display" })` per page to confirm 81
   widgets / 65 unique field names (49 widgets on page 1, 32 on page 2), and
   `page.getTextContent()` to re-derive the coordinate correlation described
   in the judgment calls above (in particular, `MailTit2_2`'s rect sits under
   the printed "Domicilio" label, not "Domicilio electrónico").
3. Fetch both trámite landing pages
   (`.../empadronamiento-de-vehiculos-nacionales` and
   `.../empadronamiento-de-vehiculos-importados`) and confirm the
   "Documentación a presentar" wording behind `documents[]` and the
   SOA-insurance divergence behind `seguroEmpresa`/`seguroVigencia`'s
   `requiredWhen` gate.
4. Run `node tools/validate.mjs` and `node tools/validate-ajv.mjs` (after
   `cd tools && npm ci --include=dev`) against
   `registry/uy/imm/empadronamiento-vehiculos-nacionales/1.0.0/schema.json`.
5. Run `node tools/verify-sources.mjs registry/uy/imm/empadronamiento-vehiculos-nacionales/1.0.0`.

## Uruguay's other verticals (screened this cycle)

Uruguay now stands at **2 of 6 verticals** (Business Formation, DMV). This
cycle also screened Uruguay's Passport (DNIC, an authenticated
appointment-scheduling portal only, no unauthenticated form) and National ID
(DNIC cédula de identidad, in-person biometric enrollment only) verticals
and confirmed both are dead ends for now — see CATALOG.md's "Known Gaps &
Opportunities" section. Visa and Taxes were not screened this cycle.