Short answer: treat a structured summary as a billable accounting event, not as a string returned by a model. In a Node.js catalog-enrichment worker, require a versioned JSON Schema, attach a tenant-scoped usage record, validate before persistence, and retain the original input reference for reconciliation. The useful unit is a summary that can be explained later: which description produced it, which schema accepted it, and which tenant owns the work.

That framing changes the implementation. A malformed field is a rejected event; an absent cost attribution is an audit gap; a retry is a second delivery attempt, not permission to charge twice.

What must a structured summary prove?

The output contract should answer four questions without interpreting prose: what was summarized, what facts were extracted, which schema version was used, and what accounting identity owns the operation. Keep those concerns separate. The summary is domain data. The usage record is operational data.…