Miami-Dade County Clerk of the Courts Online Marriage License Pre-Application

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

This is GovSchema's first county/municipal-level schema — the first to use the us/<subdivision>/<locality>/<authority>/<process> id shape and the jurisdiction.locality member, both landed by GSP-0021 (GOV-667). It models the Miami-Dade County Clerk of the Courts and Comptroller's online marriage-license pre-application — the data-collection step both prospective spouses complete online before appearing together, in person, at a Clerk's office to sign, pay, and receive the actual Florida marriage license (Florida law does not permit fully remote issuance; see "Access notes").

Access notes

• The live pre-application form, https://www2.miamidadeclerk.gov/mlsweb/PreApplication, was fetched directly (plain HTTP GET, no login, no session/cookie, no bot-block or WAF challenge — HTTP 200). It is a server-rendered ASP.NET Core Razor/Blazor page (MLSWebMVC8), so the full field set is present in the initial HTML response with no client-side rendering step needed to read it.
• The entire form's HTML was read directly: every <input>/<select>/radio group's name attribute, its <label>/<strong> visible text, placeholder text, and its jQuery-unobtrusive-validation attributes (data-val-required, data-val-regex/data-val-regex-pattern, data-val-length/data-val-length-max, data-val-range-min/-max, data-val-equalto/-other) were extracted verbatim from the raw response body, not inferred or summarized by an intermediate tool. Each field's sourceRef in schema.json quotes the specific name attribute and the validation attribute(s) that back its type/required/validation claims.
• The three-card structure (Spouse's Info for the Online Pre-Application ×2, then General Information) and the exact field ordering within each card were read directly from the DOM order, not reconstructed from a screenshot or description.
• The form was not submitted (no POST performed). This was a deliberate choice to avoid creating any real record in the Clerk's system, consistent with this registry's convention of never transacting against a live government system as part of authoring a schema. Consequently:
  • The content of whatever screen the form's own "Next" button leads to (very likely a review/confirmation step and then a handoff to the separate appointment-scheduling flow at www2.miamidadeclerk.gov/mlsweb/ApptApplication, per the site's own navigation) was not observed.
  • Any server-side validation beyond the client-side data-val-* attributes captured above (e.g., a real-time lookup, similar to how South Africa's IEC VoterPortal rejects a syntactically-valid-but-unregistered ID number — see za/iec/voter-registration's VERIFICATION.md) was not tested, since testing it would require submitting the form.
• The Clerk's own informational page, https://www.miamidadeclerk.gov/clerk/marriage-licenses.page ("Marriage Licenses"), was fetched directly (HTTP 200) as a second live source. It supplied the context the pre-application form itself does not restate inline: the accepted-ID-document list, the SSN/alien-registration substitution rule, the previous-marriage disclosure requirement, the 3-day waiting-period and premarital-course fee schedule ($86 standard / $61 with a completed course), the in-person joint-appearance requirement, and accepted payment methods. These are cited in documents[].sourceRef and in several fields' description/sourceRef.
• Florida Statutes ss. 741.04 ("Issuance of marriage license") and 741.0305 ("Marriage fee reduction for completion of premarital preparation course") were checked directly at leg.state.fl.us to confirm the statutory basis for the SSN-affidavit requirement, the 3-day waiting period (waivable for a completed premarital course, for non-residents, or for good cause/hardship), and the $32.50 fee reduction tied to the course certificate. These statutes are cited in field/document descriptions as context, not modelled as their own fields — the pre-application form itself does not ask the applicant to select a waiting-period-waiver reason; it only records spouse1TakenPremaritalClass/spouse2TakenPremaritalClass (Yes/No) and leaves any waiver/hardship determination to the in-person Clerk's-office step.
• The www2.miamidadeclerk.gov/mlsweb/LicenseSearch, .../ApptApplication, .../CerAppt, and .../ProviderList endpoints were identified (linked from the Clerk's informational page) but not modelled — they are distinct transactions (searching existing recorded licenses, scheduling the in-person application/ceremony appointment, and browsing premarital-course providers), out of scope for a schema of the pre-application's own data collection, per this schema's description.

Sources examined

• Document (id, version): us/fl/miami-dade/clerk/marriage-license-preapplication / 1.0.0
• Spec version: GovSchema 0.3.0
• Authority: Miami-Dade County Clerk of the Courts and Comptroller
• Primary source (live, directly reached, no block, full field/validation extraction): https://www2.miamidadeclerk.gov/mlsweb/PreApplication
• Secondary source (live, directly reached, no block): https://www.miamidadeclerk.gov/clerk/marriage-licenses.page
• Cross-check (directly retrieved via leg.state.fl.us): Florida Statutes s. 741.04, "Issuance of marriage license"
• Cross-check (directly retrieved via leg.state.fl.us): Florida Statutes s. 741.0305, "Marriage fee reduction for completion of premarital preparation course"
• Retrieved / reviewed: 2026-07-06
• Reviewer: GovSchema Engineering (initial authoring source-review)

What was confirmed against the source

| Source element | Field(s) | |---|---| | Live PreApplication form, First Spouse's Info card — name/suffix/maiden-surname inputs and their data-val-* attributes | spouse1FirstName, spouse1MiddleName, spouse1LastName, spouse1Suffix, spouse1MaidenSurname | | Live PreApplication form — DOB input, mm/dd/yyyy regex | spouse1DateOfBirth | | Live PreApplication form — State/Country of Birth dropdown | spouse1BirthPlace | | Live PreApplication form — "Do you have a U.S. Social Security Number?" radio group + tooltip | spouse1HasSocialSecurityNumber | | Live PreApplication form — Residence City/County/State inputs + tooltips | spouse1ResidenceCity, spouse1ResidenceCounty, spouse1ResidenceState | | Live PreApplication form — Identification Type/Number/Verify Number, data-val-equalto | spouse1IdentificationType, spouse1IdentificationNumber, spouse1IdentificationNumberConfirmation | | Live PreApplication form — Number of this Marriage input, range 1–99 | spouse1MarriageNumber | | Live PreApplication form — "How did the Spouse's Last Marriage End" dropdown + "only required if ≥2" tooltip | spouse1PreviousMarriageEndedType | | Live PreApplication form — Date Marriage Ended input | spouse1PreviousMarriageEndedDate | | Live PreApplication form — "Have you taken a premarital Class" radio group + tooltip | spouse1TakenPremaritalClass | | Live PreApplication form — Gender radio group (Male/Female) | spouse1Gender | | Live PreApplication form, Second Spouse's Info card (identical structure/attributes to First Spouse's) | all spouse2* fields (mirror of the spouse1* set above) | | Live PreApplication form, General Information card — Mailing Address/City/State-or-Country/Zip inputs | mailingAddress, mailingCity, mailingStateOrCountry, mailingZipOrPostalCode | | Live PreApplication form — US Phone Number input (no data-val-required present, unlike every other General Information field) | mailingPhoneNumber | | Live PreApplication form — Email Address/Email Confirmation inputs, data-val-equalto | mailingEmail, mailingEmailConfirmation | | Clerk 'Marriage Licenses' page — accepted photo-ID list | spouse1PhotoIdDocument, spouse2PhotoIdDocument | | Clerk 'Marriage Licenses' page — premarital-course fee reduction and provider directory; s. 741.0305 | premaritalCourseCertificate | | Clerk 'Marriage Licenses' page — fee schedule ($86/$61) and accepted payment methods | feePayment |

What is NOT yet independently verified

• Anything past the "Next" button. The pre-application's own multi-step continuation (a review/confirmation screen, appointment-scheduling handoff, or both) was not observed, since the form was never submitted. If a real submission surfaces additional fields, a different validation rule, or a different flow than the three cards modelled here, that is a new schema version, not a correction to this one.
• **Whether any server-side check beyond the client-side data-val-* attributes exists** — e.g., whether spouse1IdentificationNumber is checked against a real SSA/DHS/passport lookup the way South Africa's IEC VoterPortal checks its ID number in real time (za/iec/voter-registration). This pre-application's client-side validation was read directly and modelled faithfully; no claim is made about server-side behavior beyond it.
• Whether the in-person appearance, fee payment, and photo-ID check are exactly as described on the Clerk's informational page — documents[] in this schema (photo ID ×2, premarital-course certificate, fee payment) is sourced entirely from the Clerk's static "Marriage Licenses" page, not observed at an in-person counter (which, by definition, cannot be reached by an automated review).
• The exact wording and mechanics of the statutory 3-day-waiting-period waiver for non-residents/hardship/good-cause (s. 741.04) — the pre-application form itself does not ask about residency status or hardship as a distinct field; only Florida residency (inferable from spouse1ResidenceState/spouse2ResidenceState being "Florida," which this form does not distinguish from residency-for-waiting-period purposes) and premarital-course completion are captured. Documented as a known under-modelled nuance in spouse1ResidenceState's description, rather than inventing a waiver-reason field with no direct source.
• Whether spouse1BirthPlace/spouse1ResidenceState/mailingStateOrCountry's dropdown option lists are identical to one another — all three were observed to be long (~250-option) US-states-then-countries dropdowns with matching visible option text where sampled, but a full byte-for-byte diff of all three <select> option lists was not performed.
• Whether a genuinely disqualifying answer (e.g., both applicants being close relatives, or an applicant under 18 without parental consent per s. 741.0405) is asked anywhere in this online flow. No such question appears on the pre-application form itself; Florida's relationship/age restrictions appear to be enforced only at the in-person stage per the sources examined. Not modelled as a fabricated field.

Path to a verified claim (next step)

To advance to status: verified, a reviewer applies manual-source-review-v1 (Procedure step 2) by completing an actual end-to-end submission with two genuinely fabricated (non-real) applicants — confirming the "Next" screen's content, any server-side validation, and whatever flow follows — then resolves any discrepancy from this version's fields by shipping a new schema version (immutability — VERSIONING §3, practice Procedure step 5), and records the outcome here plus sets status: verified with a current verification.lastVerifiedAt/nextReviewBy.

Test run

A mock pre-application packet (conformance/us/fl/miami-dade/clerk/marriage-license-preapplication/1.0.0/application-packet.json) models two fabricated applicants — one on a second marriage (exercising the spouse1MarriageNumber/spouse1PreviousMarriageEndedType/spouse1PreviousMarriageEndedDate conditional fields and the premaritalCourseCertificate conditional document) and one on a first marriage, both without a Social Security Number (exercising the alien-registration identification path). Independently checked with a from-scratch field-by-field validator (required/requiredWhen presence, validation.pattern/minLength/maxLength/minimum/maximum/enum, crossFieldValidation equality checks): all required fields collected, all three crossFieldValidation rules (spouse1IdentificationNumberMatchesConfirmation, spouse2IdentificationNumberMatchesConfirmation, mailingEmailMatchesConfirmation) satisfied, 0 violations. A mutation test confirmed the checker actually discriminates: setting spouse2IdentificationNumberConfirmation to a mismatched value is correctly flagged by the spouse2IdentificationNumberMatchesConfirmation rule, and dropping spouse1PreviousMarriageEndedType while spouse1MarriageNumber is 2 is correctly flagged as a missing conditionally-required field.

Re-verification

Per the practice's Cadence, nextReviewBy is set to 2027-01-06 (6 months). Re-check the sources on or before that date and on any source.url change, and sooner if the Clerk's office publishes a fee-schedule change (fees are set by the Clerk and periodically adjusted) or a redesigned pre-application form.