Transform verification

Extraction is always verbatim. A returned value that differs from its verified quote has a separate transform step. Changing the graph shape does not make that step certain: confidence says only what was measured.

Trust model

OpenParser chooses a validator from trusted request intent only:

1. An explicit x-openparser-transform plan on the request field selects that operation and its parameters.
2. If there is no extension, standard JSON Schema format: date, date-time, or time selects the date/time validator as trusted output intent (kind and targetFormat only; locale en-US, zone policy civil for dates and preserve for date-times/times).
3. A model transform_claim never selects a validator and never copies source_format into trusted parameters. It cannot independently authorize verified or a derived score of 1.0.

Description prose never grants machine authority. A hostile or mistaken claim cannot change target format, locale, timezone policy, unit/currency policy, add or narrow source formats, or select an unrelated validator. Invalid extension parameters fail request admission before a model call.

{
  "type": "string",
  "format": "date",
  "x-openparser-transform": {
    "operation": "date_time_format",
    "parameters": {
      "sourceFormats": ["d MMMM yyyy", "MMMM d, yyyy"],
      "locale": "en-US",
      "zonePolicy": "civil"
    }
  }
}

For a standard date format, OpenParser supplies the trusted target yyyy-MM-dd. An explicit plan must declare every accepted sourceFormats entry; those caller-supplied formats are trusted policy and may yield verified.

Format-only fields (JSON Schema format without x-openparser-transform) use the versioned built-in catalog openparser.transform.date-source-catalog v1 as trusted validator policy. v1 is a small, principled allowlist: ISO 8601 calendar dates and the matching offset-bearing ISO date-time/time forms, unambiguous year-first numeric dates, and explicit English civil date families (day-first and US month-first, full or abbreviated month names, and N day of Month Year). Locale-ambiguous numeric day/month orders such as MM/dd/yyyy and dd/MM/yyyy are omitted, so 05/06/2025 cannot verify regardless of a claim that names one of those formats. A claim source_format may only prioritize a candidate that is already in that catalog; the service still parses the quote against every applicable catalog member and requires a strict full round-trip plus unique semantic convergence. The claim cannot add a format or shrink the candidate set. Serialized proofs name the catalog id/version and the matched catalog format; they never label a model hint as trusted.

The extension is retained in the stored schema and compiled intent, but removed from the structured-output schema sent to providers.

What a score of 1 means

1.0 is reserved for a versioned deterministic proof of one narrowly declared transformation under trusted intent. It does not mean the field, citation, or document interpretation is correct end to end.

Model-reported low, medium, and high remain ordinal coordinates 0.25, 0.5, and 0.75 on a 0–1 display scale. They are kind: reported, calibrated: false, and method: model_ordinal; they are not probabilities.

If a permitted deterministic validator returns contradicted, OpenParser does not emit model_ordinal even when the model reported high. The transform stays unscored, the proof stays on the derivation, and composite output confidence is unknown. The Studio badge says the deterministic check contradicted the output.

not_applicable (or no trusted intent) may still retain a reported ordinal. A required transform with no measurement also makes composite output confidence unknown rather than disappearing from a minimum over the measured steps.

Proof classes

• Safe equivalence proves two representations carry the same narrowly defined value.
• Exact conversion proves a declared conversion using exact arithmetic.
• Policy application proves the output follows a trusted mapping policy. It does not prove that policy describes the real world.

For example, 5 month(s) → 5 can verify magnitude stripping when month(s) is allowlisted. 5 years → duration_months: 5 is contradicted; an explicit year-to-month conversion must produce 60.

USD 8,646 or an allowlisted US dollars token can verify USD. Bare $8,646 cannot. If trusted intent explicitly maps a standalone $ to USD, the result is a verified policy application, not proof that the document's currency is USD. $ inside C$, A$, NZ$, HK$, or S$ is not that standalone token. Cost is $5 (CAD) is ambiguous and is not applied: OpenParser will not verify USD.

Strict dates and times

Date/time verification uses explicit Luxon formats only. It consumes the whole quote, rejects invalid or defaulted fields and trailing text, requires an exact source round trip, and requires every matching source format to converge on one civil value or instant. It then renders the trusted target format, round-trips the target, and requires exact output equality.

Both source and target formats must preserve every required semantic component for the declared kind. Two-digit years (yy) are rejected because they invent a century. A date transform cannot target only yyyy. A date-time or time transform cannot silently add or drop milliseconds, offset, or zone; there is no conversion proof class for those changes yet. Prefer a false negative over a false proof.

Date-only values remain civil dates: OpenParser does not invent midnight or UTC. Named-zone date-times reject ambiguous DST folds. Locale, zone policy, Node, ICU, Luxon version, and round-trip checks are recorded in proof metadata. Natural-language date parsers are not part of deterministic proof.

Proof metadata

New runs store a bounded openparser:transformProof object on the transform derivation's transformation attributes. It contains:

• stable method ID and descriptor version
• verified, contradicted, or not_applicable
• proof class and narrowly proven scope
• trusted parameters and bounded canonical operands or hashes
• named checks and round-trip flags
• implementation library/version and relevant runtime, locale, and zone
• limitations and this documentation link

The constructor and schema cap the serialized proof at 2 KiB. Newly admitted intent parameters are bounded so a complete, replayable trusted policy fits in that cap. A verified proof must retain those trusted parameters; replacing them with { bounded: true } or a hash-only summary is not sufficient for verified. If a direct or historical input still overflows, OpenParser downgrades the result to not_applicable, stores a bounded SHA-256 proof_too_large digest, and does not emit derived confidence.

Operands never duplicate raw quote or source text: they store canonical scalars, unit or currency tokens, or sha256 digests. Runtime and library metadata describe the execution; they are not part of proof identity. Historical proofs that omit checks or proofClass, or that carry an untrusted docsHref, are shown as generic transform steps in Studio rather than crashing. Documentation links are taken from the registry allowlist, not from stored URLs.

The confidence assertion stays on the produced entity; detailed proof belongs to the derivation that performed it.

Historical method IDs such as deterministic_date_equivalence remain readable as generic legacy proof in Studio. New runs emit only versioned openparser.transform.*.v1 IDs; there is no duplicate legacy producer path.

Validator catalog

This catalog is rendered directly from the static OpenParser profile registry, so method IDs, proof classes, libraries, and limitations stay aligned with the runtime.