Chile Declaration of Start of Activities for Natural Persons (Declaración de Inicio de Actividades para Personas Naturales, Formulario 4415-PN)

This file is the source-review record for this document version, per the manual-source-review-v1 practice. It documents the provenance of the published fields and flow and states the current verification claim honestly.

Current claim

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

This is a GovSchema Standard Research cycle (GOV-1624), a general research-analyst brief covering the full catalog: screen candidates for Brazil's National ID gap and at least two brand-new-jurisdiction candidates across at least two verticals, pick the strongest, author it fully, test it, and commit.

Why this candidate

CATALOG.md's "Known Gaps & Opportunities" flagged Brazil's National ID (Carteira de Identidade Nacional, CIN) as an "open-but-weak backlog candidate ... never actually deep-dived," and separately encouraged scouting a 20th jurisdiction (naming Chile, Argentina, Peru, Portugal, Poland, and Spain as starting points). This cycle screened three candidates before picking this one:

1. Brazil — National ID (Carteira de Identidade Nacional). A parallel research pass found the federal gov.br CIN portal is SSO-login-gated (gov.br/gestao/pt-br/carteira-da-identidade-nacional, "Conteúdo Restrito"), and Rio Grande do Sul's own "Identidade Fácil" is an Angular SPA whose bundles resolve to a state OIDC login before any form loads — the same gov.br-style SSO wall that has already killed several other Brazil candidates in this registry (CNH, Visa). Paraná's own rci.pr.gov.br/solicitante/iniciar (embedded via policiacivil.pr.gov.br) is a live, unauthenticated HTML form, but a second-pass depth check found it is only a 3-field identity-lookup/ eligibility screen (num_doc/nome/data_nascimento) for an applicant who already holds a Paraná RG/CIN record. A further pass then found the real downstream data-entry form independently — a sibling page (policiacivil.pr.gov.br/Pagina/Correcao-de-Solicitacao) embeds rci.pr.gov.br/pedido, a Vue/Inertia SPA whose compiled, unauthenticated app.js bundle exposes a genuine, rich, bounded field set (address with ViaCEP autofill, phone, marital status, name/DOB correction, parents' names, blood type, a disability-type checkbox group, health/organ-donor fields, five document numbers, file uploads, and pickup logistics) via its own $parent.form.<field> component-source references. This is a genuinely strong, ready-to-author candidate — not picked this cycle only because it needs a live-rendered-page pass to confirm each field's real on-screen label/requiredness (the JS bundle exposes internal field names, not confirmed visible text), a distinct task better scoped as a dedicated future cycle. It is also scoped to correction/update of an existing Paraná record, not first-time issuance (confirmed separately gated in-person-only). Left open as the strongest-ever-found backlog candidate for Brazil's National ID gap, not picked this cycle.
2. Spain — AEAT Modelo 030 (Declaración censal / NIF registration). A genuine, unauthenticated, official-host fillable PDF (sede.agenciatributaria.gob.es, HTTP 200, no login/CAPTCHA gate, %PDF-1.6, real /AcroForm). Extraction via pdfjs-dist found ~135 AcroForm widgets across 4 pages, but every widget uses generic internal names (dato.1 … dato.135) rather than descriptive names — attributing each widget to its real casilla label requires a separate, error-prone coordinate-matching pass against the page's text layer, and the form itself is considerably larger and more repetitive (the same "Datos identificativos" block reappears for a spouse/cónyuge and up to several representantes across pages 1 and 3). A genuinely strong candidate for a future cycle, but more failure-prone to extract faithfully in a single pass than the candidate below, whose AcroForm field names are already self-documenting.
3. Chile — SII Formulario 4415-PN (this document). Confirmed via direct fetch: https://www.sii.cl/formularios/imagen/F4415_PN.pdf returns HTTP 200 (Last-Modified: 2025-02-13, i.e. a currently maintained edition, not a stale artifact), no login/CAPTCHA/WAF gate. pdfjs-dist extraction of the AcroForm layer found 55 widgets on page 1 (page 2 is the form's own prose instructivo, not further form fields), and — unlike the Spain candidate — nearly every widget already carries a real, descriptive internal name (RUT, APELLIDO_PATERNO, DESCRIPCION_DE.LA_ACTIVIDAD, CODIGOACTIVIDADES_P, rut propietario, monto arriendo, 14ter, etc.), which this document's own field inventory cross-checked against the page's text layer by y-coordinate to confirm every label attribution. Bounded (a fixed, single-page form; the only repeating element — secondary economic-activity codes — is explicitly capped by the form's own instructions at 3, "en caso de más de cuatro, adjuntar Formulario 4416"). This is the strongest candidate screened this cycle on this registry's own bar (unauthenticated, field-level, bounded, self-documenting field names, current edition) and is picked as Chile's opening (20th jurisdiction) schema.

Other Chile candidates considered and rejected before settling on this one (per a parallel research pass): registrocivil.cl (cédula de identidad renewal) and pasaporte.cl (passport) both require Chile's national SSO (ClaveÚnica) before any field renders; registrodeempresasysociedades.cl ("Tu Empresa en Un Día", the flagship same-day company-formation wizard) is likewise entirely ClaveÚnica-gated, with no field markup visible pre-login; chileatiende.gob.cl (the tramites aggregator portal) returns HTTP 403 to a direct fetch and is a secondary aggregator, not a primary source, regardless. SII's own live online-filing channel for this exact process also requires an authenticated "Clave Tributaria"/ClaveÚnica session (confirmed via ChileAtiende's own ficha 3025 prose) — but per this registry's established precedent (mx/sat/preinscripcion-rfc-persona-moral, ph/bir/tin-application-corporations-partnerships), a login-gated live wizard does not disqualify a candidate whose authoritative field structure is independently recoverable from a genuinely public, unauthenticated, official PDF — which this form is.

Sources examined

Source 1 (primary source, the form itself)

• Authority: Servicio de Impuestos Internos (SII)
• Document: Formulario 4415-PN, "Declaración de Inicio de Actividades para Personas Naturales," edición 07/2016 printed on the form's own footer
• URL (directly retrieved, HTTP 200, no login): https://www.sii.cl/formularios/imagen/F4415_PN.pdf — a genuine two-page fillable AcroForm PDF, 568,372 bytes, Last-Modified: 2025-02-13 (still the current edition SII serves at this URL in 2026, not a stale mirror).
• Extraction method: pdfjs-dist@3.11.174, legacy/build/pdf.js (getAnnotations() for the AcroForm widget layer — field name, type, dropdown options, and bounding-box rect per widget; getTextContent() for the page's own text layer, grouped into rows by y-coordinate and cross-matched against each widget's rect to attach the correct on-screen label). Every field in this document's fields[] was attributed this way, not by name-guessing from the AcroForm field name alone (several of which carry typos or copy-paste artifacts from neighbouring fields — see judgment call 6).
• Retrieved / reviewed: 2026-07-07.
• What it confirms: every field's exact position (page 1), its section, its dropdown options where applicable (seleccion_casificaclion_contribuyente carries its full 4-option list as literal AcroForm export values), and page 2's own prose instructivo (§§1–6), which states which of the form's six lettered sections are always mandatory versus first-category-only, the occupancy-status code legend, the three tax-regime descriptions, and the Domicilio Postal/Urbano's own stated purpose (see Field inventory below).

Source 2 (corroborating, current-currency check)

• A live web search (2026-07-07) independently confirmed this exact form number and title are still the currently-cited natural-person "Inicio de Actividades" mechanism (e.g. ChileAtiende ficha 3025, "Inicio de actividades (persona natural)"), and that the form's four always-mandatory sections are A, B, D, and E — matching this document's own reading of the source PDF's own p.2 instructivo verbatim ("Luego, debe completar obligatoriamente los recuadros: A.- 'Persona que efectúa el trámite', B.- 'Identificación del Contribuyente, D.- 'Identificación de Actividades Económicas a Desarrollar' y E.- 'Domicilio casa matriz, email, domicilio notificaciones'.").

Field inventory (Phase 3)

All 54 fields[] entries and their exact source widget/label are listed inline in schema.json's own sourceRef per field (each cites the printed section, the printed label, and the underlying AcroForm field name). Summary by section:

| Section | Fields | Always mandatory? | |---|---|---| | Encabezado (header) | fechaInicioActividades | Yes (per instructivo §4.1) | | A. Persona que efectúa el trámite | rutPersonaTramite, apellidoPaternoTramite, apellidoMaternoTramite, nombresTramite | Yes (per instructivo §4.1) | | B. Identificación del Contribuyente | clasificacionContribuyente, apellidoPaternoContribuyente, apellidoMaternoContribuyente, nombresContribuyente | Yes | | C. Capital | capitalEnterado, capitalPorEnterar, fechaCapitalPorEnterar, capitalTotal | Only for Primera Categoría (requiredWhen/visibleWhen on primeraCategoria) | | D. Identificación de Actividades Económicas | primeraCategoria, segundaCategoria, afectaIva, exentoIva, descripcionActividad, codigoActividadPrincipal, codigoActividadSecundaria1-3 | Yes (the category/description/principal-code fields); IVA condition and secondary codes conditional | | E. Domicilio Casa Matriz | callePrincipal, numeroPrincipal, depOficinaLocalPrincipal, blockPrincipal, poblacionVillaPrincipal, comunaPrincipal, ciudadPrincipal, telefonoFijoPrincipal, telefonoMovilPrincipal, emailPrincipal | Yes (core address/comuna/ciudad/email); block/población/teléfono modelled optional | | Domicilio adicional (Primera Categoría only) | rolAvaluoPropiedad, rutPropietario, calidadOcupacionDomicilio, montoArriendoDomicilio, tieneDomicilioPostal + 3 postal fields, tieneDomicilioUrbano + 7 urban fields | Only for Primera Categoría, and only "si tuviera" (if applicable) | | F. Régimen Tributario de la Renta | regimenSimplificado14Ter, regimenRentaPresunta, regimenRentaAtribuida14A, regimenSemiIntegrada14B | Only for Primera Categoría |

Total: 54 fields, plus 3 exclusivityGroups (category, IVA condition, tax regime) capturing the form's own "marcar con una X en una de las formas"/mutually-exclusive-checkbox instructions.

Access notes and judgment calls

1. No native per-field required/length constraint exists anywhere in this PDF. Every AcroForm widget's own required and maxLen annotation properties were checked programmatically (via pdfjs-dist's getAnnotations()) and are uniformly false/0/undefined — this PDF carries no enforced validation of its own. required: true is therefore applied only to the fields inside the four sections the instructivo's own prose explicitly names as always-mandatory (A, B, D, E); fields inside those sections that are structurally supplementary in nature (a second surname, address components like block/población-villa/one of the two phone numbers, secondary economic-activity codes beyond the principal) are modelled required: false, since no per-field signal distinguishes them from the section's core fields — a genuine limitation of this source, disclosed the same way as co/registraduria/duplicado-cedula-ciudadania discloses an equivalent limitation for its own manual-sourced screens.
2. copiaDocumento (AcroForm field original-copia) is deliberately excluded from fields[]. This dropdown (ORIGINAL- Servicio de Impuestos Internos / COPIA-contribuyente) selects which physical copy of the printed two-part form this sheet represents — a print/copy selector, not applicant domain data, the same discipline this registry applies to page-navigation/copy-selector artifacts elsewhere.
3. No fillable widget was found for the top-of-form "ROL ÚNICO TRIBUTARIO" box, only for the adjacent "FECHA DE INICIO DE ACTIVIDADES" box. The header row (p.1, above Sección A) prints "DÍA MES AÑO" beside "ROL ÚNICO TRIBUTARIO" as column labels; per-glyph x-coordinate inspection confirmed the row's only fillable widget (Texto2, modelled as fechaInicioActividades) sits under the DÍA/MES/AÑO columns (x≈309–411), while the "ROL ÚNICO TRIBUTARIO" label (x≈467) has no corresponding widget anywhere on the page. fechaInicioActividades is modelled as required: true on the strength of the instructivo's own imperative instruction ("Deben colocar la fecha de Inicio de Actividades en el recuadro respectivo," §4.1) confirming it is genuinely applicant-entered, not SII-stamped. The neighbouring "ROL ÚNICO TRIBUTARIO" box is presumably a duplicate/reference display of the same RUT already captured in rutPersonaTramite, not a distinct fillable field, and is not modelled separately.
4. calidadOcupacionDomicilio is modelled as a 5-value closed enum (codes "1"–"5"), unlike most open-string address dropdowns elsewhere in this registry's Latin American schemas. This is safe to close because the form's own printed legend states the exhaustive list verbatim ("1.PROPIETARIO, 2.ARRENDADO NOTARIAL, 3.USUFRUCTUADO, 4.CEDIDO o 5.ARRENDADO SIMPLE" — p.2 instructivo, and the abbreviated legend reprinted directly beneath the field on p.1), unlike e.g. Colombian department/comuna dropdowns, whose full option catalogs are never printed on the source itself.
5. **The two codigoActividad* fields and the 800+-entry SII activity-code catalog they reference are out of scope.** The form's own instructivo states the codes come from "tabla internacional de actividades" (an external catalog SII publishes separately, on sii.cl → "Ayudas por Servicio" → "Códigos de actividad económica," not reproduced on this form) — modelled as a pattern-constrained (^[0-9]{6}$) open string, not a fabricated enum, consistent with this registry's established discipline for large external code tables (e.g. RUNT's own department/vehicle-type dependencies, DIAN's activity-code references).
6. Two AcroForm field names are reused across visually distinct blocks — comuna appears twice (once in the Domicilio Postal block, once in the Domicilio Urbano block) and calle notificaciones similarly collides with the Sección E field's own internal name pattern. This is a genuine quirk in the source PDF's own AcroForm authoring (confirmed by rect inspection — the two comuna-named widgets sit at clearly different page positions, y≈292 and y≈348, so they are two separate visual fields that happen to share one internal PDF field name, not one shared value). This document disambiguates them into two independently named schema fields (comunaPostal / comunaUrbano) based on which visual block each widget's rect places it in, and discloses the underlying PDF field-name collision here for an independent reviewer to double-check against the rendered page.
7. Requirements for special-case supporting activities (transport-for-hire and mining) are out of scope. The instructivo's own §6 ("Casos Especiales") lists extra documents required if the applicant's activity is passenger/cargo transport-for-hire or mining (vehicle-ownership contracts, mining-registry certificates, notarized lease agreements, etc.), but these are activity-specific supporting evidence, not fields on this form itself, and are not modelled in documents[] for this v1.0.0.
8. No documents[] array is modelled at all. The form's own p.2 §5 ("Requisitos") states only that supporting antecedents are "los solicitados en el informativo 'Inscripción al RUT y/o Declaración de Inicio de Actividades'" — a separate SII informative document this cycle did not retrieve and independently verify. Rather than fabricate a generic "identity document" or "proof of address" requirement not actually itemized in the source examined this cycle, this document leaves documents[] absent (it is OPTIONAL) and discloses the gap here for a future cycle.
9. The live online-filing channel (SII's own web platform, per ChileAtiende ficha 3025) requires an authenticated "Clave Tributaria" or ClaveÚnica session and was not walked live this cycle — this document is derived entirely from the public PDF form and its own instructivo, not from that wizard. If a future reviewer gains a way to observe the live wizard, it should be cross-checked against this document the same way co/registraduria/duplicado-cedula-ciudadania cross-checked a live HTML screen against an older PDF manual.

Test run (Phase 4)

No live submission was attempted: SII's live filing channel is authentication-gated and submitting a declaration of economic-activity start-up with fabricated taxpayer data against a real production tax registry is not a safe or reversible action.

Instead, two fully hand-constructed mock records were built from this document's own field inventory and manually checked against every field's required/requiredWhen/visibleWhen/validation rule and all three exclusivityGroups:

Scenario 1 — Segunda Categoría filer (independent professional). A freelance accountant, RUT 12345678-9, files fechaInicioActividades: "2026-08-01", clasificacionContribuyente: "111 Persona natural chilena", segundaCategoria: true, primeraCategoria: false (satisfying categoriaTributaria's exclusivity), descripcionActividad: "Servicios de contabilidad y asesoría tributaria independiente", codigoActividadPrincipal: "692000", full Sección A/B/E fields, and no Sección C, no IVA condition, no domicilio-adicional block, and no Sección F fields at all. Checked: every field whose visibleWhen resolves to false (because primeraCategoria is false) is correctly exempt from its own requiredWhen — e.g. capitalEnterado, afectaIva/exentoIva, regimenSimplificado14Ter, and the entire domicilio-adicional block are all absent from the record and pass ("Visibility gates requiredness," SPEC.md §6.7). Passes with zero errors.

Scenario 2 — Primera Categoría filer, VAT-affected, renting the main address, with a postal-notification address. A sole trader running a small retail shop, RUT 9876543-2, files fechaInicioActividades: "2026-09-15", primeraCategoria: true, segundaCategoria: false, afectaIva: true, exentoIva: false, capitalEnterado: 500, capitalPorEnterar: 500, fechaCapitalPorEnterar: "2026-12-31", capitalTotal: 1000, calidadOcupacionDomicilio: "5", montoArriendoDomicilio: 350, tieneDomicilioPostal: true with all four postal fields populated, tieneDomicilioUrbano: false (so its 7 fields are correctly absent), regimenRentaAtribuida14A: true with the other three regime booleans absent/false. Checked against exclusivityGroups: exactly one field is true in each of the three groups. Checked montoArriendoDomicilio's requiredWhen (calidadOcupacionDomicilio in ["2","5"]) correctly fires since "5" is in the list. Passes with zero errors.

Negative controls (each expected to fail exactly one rule): (a) setting both primeraCategoria and segundaCategoria to true in Scenario 1 — violates the categoriaTributaria exclusivity group (more than one member true); (b) in Scenario 2, setting calidadOcupacionDomicilio: "5" while leaving montoArriendoDomicilio absent — violates that field's own requiredWhen; (c) rutPersonaTramite: "123456789" (no dash/check digit) — violates validation.pattern; (d) emailPrincipal: "not-an-email" — violates its validation.pattern. All four negative controls were correctly rejected by manual rule-tracing against schema.json.

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

``` $ node tools/validate-ajv.mjs registry/cl/sii/inicio-actividades-personas-naturales/1.0.0/schema.json ok registry/cl/sii/inicio-actividades-personas-naturales/1.0.0/schema.json [v0.3] 1/1 document(s) validated against the meta-schema (ajv 2020-12).

$ node tools/validate.mjs registry/cl/sii/inicio-actividades-personas-naturales/1.0.0/schema.json ok registry/cl/sii/inicio-actividades-personas-naturales/1.0.0/schema.json 1/1 document(s) passed. ```