Portugal Cartão de Cidadão and/or Passport Request at the São Paulo Consulate (Requerimento de Atos Presenciais)

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

This is GOV-1797: a "GovSchema Standard Research" follow-up cycle re-screening Portugal's three remaining open verticals — Business Formation, Passport, and National ID — after GOV-1750's opening cycle gave all three a light, non-exhaustive screening pass (documented in CATALOG.md around lines 209-253). All three were re-screened live this cycle, prioritizing the National ID consular-PDF lead GOV-1750 explicitly flagged as unpursued.

Candidate screening

1. National ID — picked: São Paulo consulate's cc_e_pep_formulario.pdf

GOV-1750's own record for this vertical read: "a consulate-hosted application PDF (req_cc.pdf) was located with 42 distinct field labels — but it is consular-only... and required a proxy workaround to retrieve directly." Re-fetching req_cc.pdf (Consulado-Geral de Portugal no Rio de Janeiro, https://riodejaneiro.consuladoportugal.mne.gov.pt/images/req_cc.pdf) this cycle confirms that description: it is a genuine, current PDF, but its pdfjs-dist annotation layer returns zero Widget annotations — a flat print facsimile (blank underscore lines for hand-filling), not a fillable AcroForm. GOV-1750 counted 42 "field labels" from its printed text, not 42 AcroForm fields; that distinction was not fully spelled out in the prior record.

This cycle searched further and found a second, stronger consulate-hosted PDF: the Consulado-Geral de Portugal em São Paulo's https://saopaulo.consuladoportugal.mne.gov.pt/images/cc_e_pep_formulario.pdf ("Requerimento de Atos Presenciais — Cartão do Cidadão e/ou Passaporte"). Its pdfjs-dist annotation layer, scoped to the page's own /Annots array, lists 46 raw Widget annotations collapsing to 45 unique positions: 12 of the 26 unique text-field positions are each backed by two near-identically- rects widgets (an artifact of the online form-builder tool that appears to have produced this PDF, not a government-authored native AcroForm export), while the two radio groups' own widgets are each a genuinely distinct position (one per selectable option), not duplicates. Separately, the file's underlying AcroForm field tree also carries roughly 40 additional Widget objects that are not attached to this page's /Annots array — orphaned, invisible, unfillable leftovers from the same form-builder tool, confirmed via a direct pdf-lib field-tree walk cross-referenced against the page's own annotation list; they carry no rendered label and are not part of the live, fillable form a user actually sees or fills, so no field here is sourced from them. The two radio groups are vou solicitar (3-option modality selector) and Estado Civil Actual (4-option marital-status selector), plus 1 checkbox and 26 unique text fields. This is a genuine, currently-linked, unauthenticated, fillable AcroForm — the strongest Portuguese candidate either this cycle or GOV-1750 found across all three gaps. A third PDF, São Paulo's older formulario_cc__pep.pdf, is also a flat, widget-free 2-page facsimile, confirming cc_e_pep_formulario.pdf is that consulate's newer, upgraded fillable version.

2. Business Formation — re-screened, still weak

Re-searched for a downloadable AcroForm ("Empresa na Hora formulário download pdf pacto social"). justica.gov.pt/Servicos/Empresa-na-Hora/Pactos confirms the pre-approved pacto-social models remain pre-formatted specimen documents a notary/Conservatória fills in on the applicant's behalf at the counter, not a citizen-facing fillable AcroForm; the sole-trader "Início de Atividade" self-service route remains behind the acesso.gov.pt authenticated portal with no PDF fallback found. Re-confirms GOV-1750's finding: no qualifying source found this cycle either.

3. Passport — re-screened, still weak

Re-searched ("requerimento passaporte português formulário pdf SEF PEP"). gov.pt's "Pedir o passaporte português para estrangeiros" and IRN's "Passaporte eletrónico" pages both confirm the domestic Passaporte Eletrónico Português (PEP) remains an in-person, biometric-enrolment appointment with no separate citizen-facing application PDF (Decreto-Lei n.º 83/2000 Art. 16 still holds, matching GOV-1750's finding). The only passport-adjacent PDF this cycle found is the same São Paulo consulate cc_e_pep_formulario.pdf picked for National ID above — its requestModality field's "Somente Passaporte" option and its "Documento de Viagem" bring-along-document panel jointly cover a consular passport-only or combined request, but the form's own header lists Cartão de Cidadão first and the "Somente Passaporte" option is explicitly conditioned on already holding a valid CC or lifetime BI — i.e. it is a National-ID-centric intake form that happens to also carry a passport sub-option, not a passport-specific application. Portugal's Passport vertical therefore remains an open backlog candidate; this schema's own top-level description discloses that the same source document also serves that option.

Access notes

saopaulo.consuladoportugal.mne.gov.pt could not be reached directly from this environment: a plain curl/openssl s_client connection and a Playwright/Chromium fetch (real browser, realistic UA) both get a TLS handshake reset (ECONNRESET) immediately after the ClientHello, for every path on the domain including its own root page — consistent with an IP/ASN range-level block on the consulate's WAF rather than a dead or gated resource. irn.justica.gov.pt and other .gov.pt/.pt domains fetched fine from the same environment during this cycle, isolating the block to this specific consular subdomain. Per this registry's established Wayback workaround (see project memory gov-au-wayback-workaround.md and ee-rik/ee-ppa's prior use of the same technique), all three PDFs and the page discovery were instead retrieved via web.archive.org's most recent snapshot of each URL:

• cc_e_pep_formulario.pdf — Wayback snapshot 20251208090724 (2025-12-08), HTTP 200, application/pdf, 648,610 bytes, %PDF-1.5.
• formulario_cc__pep.pdf and req_cc.pdf — also retrieved via Wayback, used only as comparison/contrast evidence (see above), not as this document's own source.

tools/verify-sources.mjs was run against this document; both saopaulo.consuladoportugal.mne.gov.pt URLs report WARN (ECONNRESET, tolerated as a transient/blocked-access signature per the tool's own design), not FAIL — consistent with the network-level block described above rather than a dead or fabricated citation.

Extraction method

pdfjs-dist (legacy Node build) was used to extract both the page text content and the full AcroForm annotation layer (field name, type, rect, radio/checkbox button values) from cc_e_pep_formulario.pdf. Because this particular PDF's extractable text layer is sparse (many printed labels did not surface as extractable text items, likely due to how the originating form-builder tool encoded its layout), field-to-label mapping was independently confirmed by rendering the PDF to a full-page image via a headless Chromium (Playwright, using this environment's bundled chrome-sysroot shared libraries) opening the local PDF file directly and using Chromium's native PDF viewer — not by trusting AcroForm field names or coordinate proximity alone. Every field's label below was read directly off that rendered image, cross-checked against each widget's rect coordinates.

Field inventory

29 fields[] entries (28 with a real AcroForm widget — 2 radio groups, 1 checkbox, and 25 unique logical text fields, one of which, fullName, is backed by two distinct on-page positions; dateOfRequest is modelled from a printed, self-documenting but widget-less blank line — see judgment call 4) and 2 documents[] entries.

| Step | Fields | Source | |---|---|---| | Vou solicitar | requestModality | radio_group_48upva (3-option) | | REQUERENTE | age, maritalStatus, fullName, identityCardNumber, maidenOrBirthName, dateOfBirth, height, rgOrRne, cpf, phoneNumbers, email, civilParishOfBirth, municipalityOfBirth, districtOfBirth, dateOfEntryToCountry, placeOfBirthAbroad | text_2ekak/text_20uiwp, radio_group_38phjd, text_7itaa/text_26flad (+text_38yiag/text_28kzzv signature-block duplicate), text_8eeil/text_21yfrl, text_9naqb/text_22nbxo, text_11xlqu/text_27vgjt, text_2kmuq, text_10wctv/text_25odgd, text_12emvn/text_24suxm, text_13afpn/text_23crdk, text_14agec/text_18eebr, text_3udii, text_4sglc, text_5rxtu, text_6omfi, text_7xnrh | | ENDEREÇO | confirmSameDeliveryAddress, streetAddress, addressNumber, addressUnit, neighborhood, postalCode, cityState | checkbox_1syxn, text_8exzx, text_12sxyk, text_13rqc, text_10byds, text_11dswr, text_9emie | | PAIS DO(A) REQUERENTE | fatherName, fatherDateOfBirth, motherName, motherDateOfBirth | text_22jpva/text_16qonb, text_29ktfo/text_17jgp, text_14makd, text_15hwwm | | DATA E ASSINATURA DO REQUERENTE | dateOfRequest | printed 'Data: ___/___/___' line (no widget) |

documents[]: identificationDocumentsPresented (the form's own "Documentos de Identificação Civil"/"Documento de Viagem" illustrated panel), requerentePresence (the form's own verbatim "Obs:" note requiring the applicant's personal, in-person appearance regardless of age).

Judgment calls

1. Modelled under Portugal's National ID vertical, not Passport, even though the source form's requestModality field includes a passport-only option. Cartão de Cidadão is the form's first-listed, primary modality and the form's own structure conditions the passport-only option on already holding a valid CC/BI — a National-ID-centric document, not a passport-specific application. See "Candidate screening" §3 above; this leaves Portugal's Passport vertical open.
2. Scoped to this one consular post's own published PDF, not a claimed unified national standard. Three different Portuguese consulates examined this cycle (Rio de Janeiro, and São Paulo's own two generations of the form) each publish a differently structured document for what is nominally the same underlying process, and Rio's carries no AcroForm at all. This document's id, authority, and top-level description are explicit that it models São Paulo's specific implementation, not a claimed MNE-wide template.
3. Several fields (cpf, rgOrRne, postalCode/CEP, neighborhood/Bairro) are Brazil-specific address/identity data points, present because this consulate's applicant base is resident in Brazil. A consulate in another country would publish a differently localized version of this form (as Rio de Janeiro's own, non-AcroForm req_cc.pdf already demonstrates, which asks for CPF but not RG/RNE, and structures the address block differently). This is disclosed in the top-level description rather than presented as a jurisdiction-wide Portuguese standard.
4. dateOfRequest is modelled despite carrying no AcroForm widget. Every other field in this document corresponds to a real Widget annotation; the closing "Data: ___/___/___" line is a plain printed blank (confirmed via both the annotation-layer dump and the rendered image), the only such gap in an otherwise fully-fillable form. It is included because it is a clearly designated, self-documenting field on the form's own face, and because pt/imt/requerimento-carta-de-conducao's own dateOfRequest equivalent (there, a genuine widget) plays the same closing role — this task's own instructions permit a "clean, numbered, self-documenting field structure" as an acceptable source shape alongside a strict AcroForm layer.
5. No requiredWhen dependency is asserted between the "born in Portugal" fields (civilParishOfBirth/municipalityOfBirth/districtOfBirth/ dateOfEntryToCountry) and the "born abroad" field (placeOfBirthAbroad), even though the form visually presents them as alternatives under "Se nasceu em Portugal:" / "Se nasceu no Exterior:" headers. The form carries no checkbox or radio control selecting between the two — only section headers — so asserting a structural requiredWhen/exclusivityGroups rule here would fabricate a dependency the source does not itself encode as a checkable condition, the same discipline pt/imt/requerimento-carta-de-conducao's own VERIFICATION.md applied to medicalRestrictionCodes and the currentlyHolds* fields (see its judgment calls 7-8), and the same class of bug flagged in project memory (notequals-empty-string-absent-field-bug).
6. No fee/payment documents[] entry. A search this cycle located the consulate's own monthly "Tabela de Emolumentos" fee schedule (.../images/emolumentos/2026/tabela_de_emolumentos_janeiro_2026.pdf, confirmed live via web search, dated January 2026), but it could not be directly fetched (same network block described above) and has no Wayback snapshot as of this cycle, so this schema does not assert a specific fee amount or payment method it could not independently confirm — omitted rather than fabricated, consistent with this registry's standing discipline after the GOV-1760/GOV-1763 fabricated-sourcing incidents.
7. height ("Altura") is left required: false, correcting an initial drafting error. A sibling consulate's equivalent form (Rio de Janeiro's req_cc.pdf) marks its own "Altura" field "( item obrigatório)" (mandatory item) — this schema's first draft mistakenly attributed that marker to the São Paulo cc_e_pep_formulario.pdf source document itself, an artifact of cross-referencing both PDFs' extracted text side by side during authoring. Re-checking specifically: cc_e_pep_formulario.pdf's own extractable text (both the AcroForm-adjacent text-content extraction and a targeted, zoomed Chromium render of the "Altura:" field region) carries no "obrigatório" or equivalent mandatory-marker text anywhere near it. Caught and fixed before finalizing this document; disclosed here as the kind of same-document cross-contamination error this registry's own verify-sources tooling and review-gate process exist to catch (see gov-1763-verify-sources-ci-gate and gov1760-pt-aima-review-gate in project memory).
8. No field in this document is marked required: true on an explicit in-document mandatory-marker — none of cc_e_pep_formulario.pdf's own extractable text or its rendered page carries an "obrigatório" (or equivalent) annotation next to any field, unlike the Rio de Janeiro sibling form's "Altura" field. Every required: true field (requestModality, maritalStatus, fullName, dateOfBirth, fatherName, motherName, dateOfRequest) is instead inferred from its role as a structurally necessary identity/parentage/closing field consistent with Lei n.º 7/2007's Cartão de Cidadão data model — a softer basis than an explicit in-form marker, disclosed here rather than implied. identityCardNumber, email, height, and the address block are all left optional for the same reason plus the additional, source-stated fact that a first-time CC applicant would have no prior CC/BI number to give; confirmSameDeliveryAddress and the address fields are plausibly conditionally required only for the "URGENTE"/mail-delivery option, but the form does not encode that as a checkable field-level condition (it is prose in the surrounding instructions, not a control on the confirmSameDeliveryAddress checkbox), so no requiredWhen rule is asserted here.
9. No live submission was attempted. Submitting this form at a real consular appointment triggers a real fee, a real biometric appointment, and a real change to the applicant's legal identity record — not a safe or reversible action to simulate against a live government process, consistent with this registry's standing discipline.

Validation

``` $ node tools/validate.mjs registry/pt/mne/requerimento-cartao-cidadao-passaporte-consular/1.0.0/schema.json ok registry/pt/mne/requerimento-cartao-cidadao-passaporte-consular/1.0.0/schema.json

1/1 document(s) passed.

$ node tools/validate-ajv.mjs registry/pt/mne/requerimento-cartao-cidadao-passaporte-consular/1.0.0/schema.json ok registry/pt/mne/requerimento-cartao-cidadao-passaporte-consular/1.0.0/schema.json [v0.3]

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

$ node tools/verify-sources.mjs registry/pt/mne/requerimento-cartao-cidadao-passaporte-consular/1.0.0 verify-sources: checking 1 schema version directory...

pt/mne/requerimento-cartao-cidadao-passaporte-consular/1.0.0 (4 URLs) [WARN] https://saopaulo.consuladoportugal.mne.gov.pt/ transient failure after 3 attempt(s) (ECONNRESET) — tolerated, re-check manually if this persists [WARN] https://saopaulo.consuladoportugal.mne.gov.pt/images/cc_e_pep_formulario.pdf transient failure after 3 attempt(s) (ECONNRESET) — tolerated, re-check manually if this persists [WARN] https://riodejaneiro.consuladoportugal.mne.gov.pt/images/req_cc.pdf transient failure after 3 attempt(s) (ECONNRESET) — tolerated, re-check manually if this persists

verify-sources: 1 directory, 4 URLs checked, 3 warning(s), 0 allowlisted, all clear. ```

Both WARNs are expected given the environment-level TLS block documented above under "Access notes," not evidence of a dead or fabricated source.