# Verification record — `co/runt/formulario-solicitud-tramites-vehiculo` 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.

## Current claim

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

This document was derived directly from RUNT's own published `.xls` form, not
a live-browser walk of any wizard (RUNT's public-facing services for this
form are a physical/PDF intake process at a transit-authority counter, not a
live online wizard — see "Why this document exists" below). It remains
`draft`, not `verified`, pending an independent second reviewer's
field-by-field pass.

## Why this document exists

This is a `GovSchema Standard Research` cycle (GOV-1567). Phase 1 catalogued
the registry's existing 18 jurisdictions and confirmed DMV, Business
Formation, and Taxes are each already closed to 18/18 (100%); the only open
verticals are Passport (16/18), Visa (14/18, three confirmed dead ends), and
National ID (15/18, remaining gaps legally blocked or in-person/biometric
only — see CATALOG.md). Phase 2 research re-screened those existing-jurisdiction
gaps (findings logged separately in CATALOG.md this same cycle: Indonesia's
Passport and Visa gaps both reversed from a prior cycle's "not viable" finding
to newly-viable backlog candidates) and separately evaluated whether a strong,
well-sourced candidate existed to open a **19th jurisdiction**, per this
registry's charter that GovSchema's scope is global/multi-jurisdictional from
the start (`AGENTS.md`). Colombia's DIAN RUT (Formulario 001, Business
Formation) had been flagged by a prior cycle (GOV-1444) as a viable-but-weak
backlog candidate — current here still fails this registry's boundedness bar
(three of its six sub-sections are explicitly unbounded repeating groups,
"puede agregar tantas páginas como necesite"). This cycle instead found RUNT's
own **"Formulario de Solicitud de Trámites del Registro Nacional Automotor"**
(DMV vertical) to be a materially stronger candidate: a static, two-page,
fully-bounded form (zero unbounded repeating sections) with minimal external
code-table dependence, hosted directly and unauthenticated on `runt.gov.co`.
This document opens Colombia as the registry's 19th jurisdiction via its DMV
vertical.

## Source examined

- **Document `(id, version)`:** `co/runt/formulario-solicitud-tramites-vehiculo` / `1.0.0`
- **Spec version:** GovSchema `0.3.0`
- **Authority:** Registro Único Nacional de Tránsito (RUNT), operated under
  Colombia's Ministerio de Transporte; the paper form is filed at any of
  Colombia's decentralised local transit authorities (organismos de
  tránsito), each of which feeds the single national RUNT registry.
- **Primary source:**
  `https://www.runt.gov.co/sites/default/files/documentos/ftrunt_0.xls` —
  fetched directly (`curl`, User-Agent `Mozilla/5.0`). HTTP 200,
  `Content-Type: application/vnd.ms-excel`, `Content-Length: 668160`,
  `Last-Modified: Tue, 25 Apr 2023 16:26:35 GMT`. Re-fetched a second time
  from a fresh connection and confirmed byte-for-byte identical
  (SHA-256 `3b1a222f6fef53bdf424a12cc2a0a5f451d453a7fe52da93c9e7b64acb958f05`),
  ruling out a per-request dynamically-generated file. No login, CAPTCHA, or
  WAF gate on this URL. `runt.gov.co`'s own site does not serve a text-layer
  PDF of this exact form directly, but the identical form is independently
  mirrored — as PDFs matching this same layout — on multiple official
  municipal transit-authority (`.gov.co`) sites (e.g. `transitoitagui.gov.co`,
  `movilidadpereira.gov.co`, `cundinamarca.gov.co`), corroborating this is the
  single, current, nationally-standard RNA form, not a superseded or
  locally-modified variant.
- **Retrieved / reviewed:** 2026-07-07
- **Reviewer:** GovSchema Engineering (initial authoring source-review)

## Extraction method

1. Fetched the `.xls` file directly from `runt.gov.co` (see above).
2. Parsed it with the `xlsx` (SheetJS) npm package — the file is a genuine
   Excel Binary File Format (`.xls`, OLE2 compound document; confirmed by its
   `D0 CF 11 E0 A1 B1 1A E1` magic bytes), not a renamed CSV/HTML file. It
   contains three sheets (`Hoja1`, `Hoja2`, `Hoja3`); `Hoja1` (294 rows) is
   the two-page form layout itself with every label as a cell value, exactly
   as it would print; `Hoja2` and `Hoja3` are empty/unused print-layout
   artifacts and are not sourced from.
3. Converted `Hoja1` to CSV and read it cell-by-cell against the visual grid
   it represents, cross-referencing every field against the form's own
   23-item numbered `INSTRUCCIONES` (Instructions) key printed on the same
   sheet (rows 79–112), which the form itself directs the filer to ("NOTA:
   VER INSTRUCCIONES AL RESPALDO" — see instructions on the back). Every
   field's label, grouping, and — where the instruction text is explicit —
   its scope/required nuance in this document is read from this combination
   of the printed box label and its own paired instruction, not inferred
   from general DMV-form conventions.

## What was confirmed directly (verbatim, from the form's own cells)

- The form's own title and issuing authority: "MINISTERIO DE TRANSPORTE ...
  FORMULARIO DE SOLICITUD DE TRAMITES DEL REGISTRO NACIONAL AUTOMOTOR".
- All 18 `tramiteType` options and their exact printed order/numbering
  (casilla 3): Matrícula/Registro, Traspaso, Traslado Matrícula/Registro,
  Radicado Matrícula/Registro, Cambio de Color, Cambio de Servicio, Regrabar
  Motor, Regrabar Chasis, Transformación, Duplicado Licencia Tránsito,
  Inscripc. Prenda, Levanta. Prenda, Cancelación Matrícula/Registro, Cambio
  de Placas, Duplicado de Placas, Rematrícula, Cambio de Carrocería, Otros.
- All 14 `vehicleClass` options (casilla 4), all 8 `fuelType` options
  (casilla 7, individually numbered 1–8), all 6 `serviceType` options
  (casilla 18), all 5 `alertType` options (casilla 20), and the 8
  document-type codes shared by casillas 21/22 (`C`=C.C, `N`=NIT,
  `X`=N.N., `P`=Pasaporte, `E`=C.Extranj., `T`=T.Identi., `U`=NUIP,
  `D`=C.Diplomático).
- Instruction §1's own explicit statement that casilla 1 ("1. ORGANISMO DE
  TRÁNSITO") is office-only: "NO ESCRIBA EN ESTE ESPACIO DEBE SER
  DILIGENCIADO POR EL ORGANISMO DE TRANSITO" (do not write in this space, it
  must be filled in by the transit authority) — this is why
  `transitAuthorityName`/`City`/`Code` are **not** modelled as applicant
  fields at all (see "What is out of scope" below), unlike every other
  casilla on the form.
- Instruction §18's explicit "en ambos casos" (in both cases) framing for the
  import/auction document city, and its explicit statement that the
  customs/aduana "Código" box is filled in by the transit office, not the
  applicant ("SERA SUMINISTRADO POR LA OFICINA DE TRANSITO
  CORRESPONDIENTE").
- Instruction §22's explicit "persona indeterminada" (undetermined person)
  provision for a traspaso whose buyer is not a specific identified person.
- Instruction §23's explicit framing that `generalNotes` is used, among other
  things, to write out and clarify the word "OTRO" wherever it was checked
  elsewhere on the form, and to describe a `transformacion` modification.
- The two "IMPRONTAS" (rubbing-impression) boxes near casillas 12–13/16
  (`IMPRONTAS DEL MOTOR O SERIE`, `IMPRONTAS CHASIS O SERIAL`) — physical
  ink/pencil-rubbing impression areas for the transit office to take a
  physical imprint of the vehicle's stamped numbers, confirmed by their
  large blank-grid layout and total absence of any instruction referencing
  them as an applicant input; excluded as a physical mechanic, not a data
  field, the same category of exclusion this registry already applies to
  login/CAPTCHA steps on other documents.
- The owner's and buyer's signature lines ("FIRMA DEL PROPIETARIO", "FIRMA
  DEL COMPRADOR") — a physical-signature mechanic, not a data field.

## Interpretive judgment calls flagged for an independent reviewer

1. **RESOLVED during independent review ([GOV-1570](../../../../../GOV-1570)):
   the import/auction documentation sub-table (casilla 17) has six numbered
   cells, not four, and the authoring pass's `importDocumentType` field
   omitted the sixth.** The original authoring pass read this sub-table from
   a CSV-flattened export in which the raw cells concatenate a label with a
   bare digit across a line break (e.g. a cell reading `"MANIF. O ACTA\n1"`),
   and modelled only a two-value `importDocumentType` (manifiesto o acta /
   declaración de importación) plus `auctionEntity` and the shared
   `importOrAuctionCity`. Independent review re-opened the original `.xls` in
   SheetJS and inspected its `!merges` array directly (not CSV-flattened),
   and separately located an identical official PDF mirror
   (`transitoitagui.gov.co/wp-content/uploads/2015/03/FORMULARIO-SOLICITUD-DE-TRAMITES-RNA.pdf`)
   and cross-checked its text-layer glyph coordinates via `pdfjs-dist`. Both
   independently confirm the same six-cell, sequentially-numbered layout:
   under the "IMPORTACION" header, cell 1 = "MANIF. O ACTA" and cell 2 =
   "DEC. DE IMPOR."; under the "REMATE" header, cell 3 = "ACTA" (a third,
   previously unmodelled document-type checkbox), cell 4 = "ENTIDAD", cell 5
   = "LUGAR (CIUDAD)", and cell 6 = "CODIGO" (office-only, correctly out of
   scope — see below). The three document-type checkboxes (1, 2, 3) share one
   continuous numbering sequence across both the "IMPORTACION" and "REMATE"
   headers rather than resetting at "REMATE", indicating they form a single
   selection group scoped to whichever of the two the applicant chose, not
   two independent binary choices. `importDocumentType` was replaced with
   `importOrAuctionDocumentType`: same two import-side values
   (`manifiesto_o_acta`, `declaracion_importacion`) plus a new
   `acta_remate` value for cell 3, `requiredWhen` widened to fire on either
   `importOrAuctionType` value instead of `importacion` only. Instruction
   §18's own prose ("SI EL VEHICULO ES IMPORTADO INDIQUE CON UNA EQUIS (X) EL
   DOCUMENTO RESPECTIVO, SI ES DE REMATE INDIQUE LA ENTIDAD, EN AMBOS CASOS
   LA CIUDAD...") explicitly names only the entity and city for the remate
   case, not a document checkbox — the "ACTA" checkbox's exact legal effect
   is not spelled out in the instruction text itself, but a web search on the
   RUNT auction-transfer process independently corroborates that a remate
   registration is always evidenced by an "acta de remate" (adjudication
   act), consistent with cell 3 functioning as a document-type confirmation
   parallel to the import side's two options, rather than a stray label.
   `auctionEntity` (cell 4) and the shared `importOrAuctionCity` (cell 5) were
   already correctly modelled and are unchanged; cell 6 ("CODIGO") remains
   correctly out of scope per Instruction §18's own "SERA SUMINISTRADO POR LA
   OFICINA DE TRANSITO CORRESPONDIENTE" (office-only).
2. **`ownerDocumentIssueDate`'s meaning is not fully confirmed** — independently
   re-checked during review ([GOV-1570](../../../../../GOV-1570)) and still
   genuinely unresolved. A `DIA/MES/AÑO` triplet appears in the row
   immediately below "No. DOCUMENTO" inside casilla 21's cell region, but
   nothing on the form labels what date this represents (a document issue
   date is a plausible reading, consistent with similar Colombian
   ID-collection forms, but this form does not state it explicitly the way
   it does for `Fecha de trámite` at the very top of the form). Independent
   review confirmed, via the PDF mirror's own text-layer coordinates, that
   this triplet is positioned exactly as described (immediately beside/below
   the owner's document-number entry box in casilla 21, not misattributed to
   a neighbouring casilla) and that Instruction §21's own prose ("TRANSCRIBA
   LOS DATOS PERSONALES DEL PROPIETARIO ACTUAL DEL VEHICULO... NUMERO,
   DIRECCIÓN, CIUDAD, TELEFONO Y FIRMA") does not mention a date at all,
   confirming the ambiguity is a genuine gap in the source's own
   documentation, not something a closer reading resolves. Remains modelled
   as optional (`required: false`) rather than omitted, with this ambiguity
   disclosed rather than asserted with confidence.
3. **`bodyworkCode`/`bodyworkType` and `importOrAuctionCity`'s office-code
   sibling are left as open strings, not closed enums**, because RUNT's own
   bodywork-code and city/organismo-de-tránsito code tables are external to
   this form and are not reproduced anywhere on it — consistent with this
   registry's established precedent for external-code-table dependence (e.g.
   `mx/semovi/alta-vehiculo-foraneo`'s `previousPlateState`).
4. **`affiliatedCompanyName`/`affiliatedCompanyNit` are not gated by
   `serviceType`.** Domain knowledge suggests an "empresa vinculadora" is
   typically only relevant for a public-service vehicle, but the form's own
   instruction (§20) states no such conditional ("ESPECIFIQUE EL NOMBRE DE LA
   EMPRESA VINCULADORA Y SU CORRESPONDIENTE NIT", with no "cuando aplique" or
   service-type qualifier), so no `requiredWhen`/`visibleWhen` gate is
   asserted here without direct textual support.
5. **`plateLetters`/`plateNumbers` patterns (3 letters / 2–3 digits) follow
   Colombia's well-known standard civilian plate format** (this is general
   public knowledge about Colombian vehicle plates, not something stated on
   the form itself, which shows only blank boxes); left `required: false`
   since a brand-new `matricula_registro` vehicle has no plate yet.
6. **VIN pattern validation uses the standard 17-character ISO 3779 VIN
   shape** (excluding I/O/Q), a generic international standard, since the
   form does not publish its own VIN format rule.
7. **Document-number patterns for Colombian cédula/NIT/etc. are not
   asserted** (modelled as open strings) since the form's own boxes carry no
   printed format mask and Colombian identity-document number lengths vary
   by document type; asserting a specific digit-count pattern here would be
   this document's own invention, not a source-derived fact.

## What is out of scope for v1.0.0

- **Casilla 1 ("Organismo de Tránsito" — name/city/code)** — explicitly
  office-only per the form's own Instruction §1; not an applicant field.
- **The customs/aduana "Código" box inside casilla 17** — explicitly
  office-only per Instruction §18.
- **The two "IMPRONTAS" physical rubbing-impression boxes** — a physical
  mechanic, not a data field (see above).
- **The owner's and buyer's signature lines** — a physical-signature
  mechanic, not a data field.
- **The third-party aditamentos/pickup or any downstream RUNT processing,
  payment, or appointment-scheduling step** — this form is itself the
  complete, single-page intake artifact; RUNT's own subsequent internal
  processing of a submitted form is out of scope, consistent with this
  registry's standing convention of modelling the applicant-facing
  data-entry artifact, not government-side back-office processing.
- **The full "persona indeterminada" (undetermined buyer) designation** — the
  form's own instruction confirms this exists as a way of completing the
  buyer section for a traspaso with no identified buyer, but does not
  describe it as a distinct enumerable field value (see judgment call under
  `buyerDocumentType`'s own description); this document does not add a
  fabricated enum value for it.

## Test run (Phase 4 — mock data)

Two mock-filled instances were constructed and checked field-by-field against
every field's `validation` (pattern/enum/minimum/maximum) and against the
conditional-requiredness graph (`required`/`requiredWhen`), using a small
throwaway Node script (not committed — equivalent logic to
`tools/validate-ajv.mjs`'s per-field checks, run ad hoc for this review):

1. **`matricula_registro` (first-time registration)** — a fictional new
   private automobile (Chevrolet Spark GT, 2026, gasoline, white/grey,
   1200cc, 85hp, sedan bodywork, plausible-format engine/chassis/serial/VIN
   all matching, particular service) filed by owner "Juan Carlos Gómez
   Pérez" (cédula de ciudadanía). All populated fields passed their
   `validation`; every field with `required: true` (unconditional) was
   present; no `requiredWhen` condition evaluated true for a missing field
   (`tramiteType` ≠ `traspaso`, `isArmored`/`isArmorRemoved` absent/false,
   `importOrAuctionType` absent, `alertType` absent). Result: **valid**.
2. **`traspaso` (ownership transfer)** — a fictional used Renault Logan
   (2019, plates `ABC123`) being transferred from owner "Ana María Ramírez"
   to buyer "Luis Fernando Torres" (both cédula de ciudadanía). This exercises
   the `requiredWhen tramiteType == "traspaso"` gate on
   `buyerDocumentType`/`buyerDocumentNumber`/`buyerFirstSurname`/
   `buyerGivenNames`, each supplied and passing validation; unconditional
   required fields were all present. Result: **valid**.

Both runs used only fabricated example values, consistent with this document
carrying no verbatim worked example from RUNT itself (this static form
carries no filled-in specimen, unlike a screenshot-driven user-guide source).

## Independent review record (GOV-1570 / PR #263)

- **Reviewer:** GovSchema Engineering (Standards Engineer), independent second
  pass per the [`manual-source-review-v1`](../../../../../practices/manual-source-review-v1.md)
  practice's second-reviewer requirement.
- **Re-fetch:** independently re-fetched `ftrunt_0.xls` from a fresh
  connection — HTTP 200, `Content-Length: 668160`, SHA-256
  `3b1a222f6fef53bdf424a12cc2a0a5f451d453a7fe52da93c9e7b64acb958f05`, byte-
  identical to the authoring pass's fetch and confirmed genuine OLE2 (`.xls`)
  by magic bytes. `Last-Modified` unchanged (2023-04-25); no newer edition
  found.
- **Judgment call 1 (import/auction sub-table): resolved, schema fixed.**
  Opened the `.xls`'s own `!merges` array directly with SheetJS (not
  CSV-flattened) and independently located and rendered (via `pdfjs-dist`)
  an identical official PDF mirror at `transitoitagui.gov.co`. Both sources
  independently confirm casilla 17 has **six** numbered sub-cells, not four;
  the authoring pass's `importDocumentType` field omitted the third
  ("ACTA", under "REMATE") entirely. Fixed by replacing it with
  `importOrAuctionDocumentType` (adds an `acta_remate` enum value, widens
  `requiredWhen` to fire on either `importOrAuctionType` value) — see the
  updated judgment call 1 above and `schema.json`.
- **Judgment call 2 (`ownerDocumentIssueDate`): re-checked, remains
  genuinely unconfirmed** (see updated note above) — no filled specimen or
  RUNT procedural regulation was found this cycle that resolves it; left
  optional and disclosed, unchanged.
- **Re-validated:** `node tools/validate.mjs`, `node tools/validate-ajv.mjs`,
  and `npm test` (`tools/govschema-client/`) all pass against the fixed
  schema.
- **Verdict:** merged with the one fix above. Document remains `status:
  draft` per this registry's convention that a clean independent second
  pass is necessary but not sufficient for `verified` — the two `Path to a
  verified claim` items below (freshness re-check cadence and the still-open
  `ownerDocumentIssueDate` ambiguity) remain the gating items for that
  claim.

## Path to a `verified` claim (next step)

To advance this document to `status: verified`, a reviewer needs to (a)
periodically re-fetch `ftrunt_0.xls` and confirm no newer edition has been
published (only a `Last-Modified` HTTP header, 2023-04-25, is available as a
freshness proxy — the form carries no visible revision date of its own; two
independent fetches, authoring and this review, now agree), and (b) confirm
`ownerDocumentIssueDate`'s meaning (judgment call 2) against RUNT's own
procedural regulations or a filled specimen — the sole remaining open item
after this review resolved judgment call 1.

## Re-verification

Per the practice's **Cadence**, `nextReviewBy` is set to **2027-01-07** (~6
months): this is the registry's first Colombian document, still carries one
materially uncertain field (judgment call 2), and its freshness proxy is an
HTTP `Last-Modified` header rather than a dated, versioned manual — all of
which argue for the shorter end of the cadence. Re-check the source and
resolve the open judgment call on or before that date and on any
`source.url` change.