Short answer: treat structured summarization as a versioned data contract, not as a prompt formatting trick. For a fintech product catalog, the useful output is the record that passes schema validation, business validation, and provenance checks in that order. A fluent summary that silently turns 12-month warranty into 12 months or invents a missing fee is a data-quality incident, even when the model call returned HTTP 200.

The operational rule is narrow: accept only a validated object, quarantine anything that fails, and make schema changes explicit. Keep the model behind an interface so the catalog pipeline does not inherit one endpoint's request shape, retry semantics, or interpretation of JSON Schema. That decision leaves room to change the inference service later, but it does not relax the contract at the database boundary.

Why does a catalog summary need a contract?

A messy description is not a trustworthy source merely because it is text.…