Turning a Spreadsheet of Field Definitions Into an OpenAPI Spec on One Key: Validate the Result With a Second Backend

Why use two backends for one spec

Generating an OpenAPI document from a spreadsheet of field definitions is a translation task: rows of names, types, and constraints become JSON Schema and paths. A single model can do this well, but it tends to be internally consistent with its own assumptions. A second model, given the same source rows and the drafted spec, acts as an independent reviewer. It has no loyalty to the first draft, so it is more likely to flag contradictions instead of rationalizing them.

This walkthrough keeps the two roles separate: a drafter and a validator. You can pick any suitable models for each role through the same API key.

Prepare the CSV as the single source of truth

Before prompting anything, tighten the spreadsheet so both models see the same facts.

• One row per field, with columns for entity or resource, field name, type, required flag, format, allowed values, and a short description.
• Use a consistent type vocabulary (for example string, integer, boolean, array, object) and keep formats in a separate column.
• Record constraints as structured text, such as min/max, pattern, or enum values, rather than free-form prose.
• Note relationships explicitly, such as foreign keys or nested objects, so they can be expressed as $ref or inline schemas.

If the CSV is ambiguous, both models will guess differently and the validation step will produce noise rather than signal.

Draft the spec with the first backend

Send the CSV, plus a short set of house rules, to your drafter model.

• State the OpenAPI version you target and whether you want components and $ref usage.
• Ask for JSON Schema constraints derived from the CSV columns, not invented ones.
• Require that every field row maps to exactly one schema property, and that nothing is added beyond the CSV except structural boilerplate.
• Ask the model to return only the spec, so it is easy to parse and diff.

Keep the prompt deterministic: same CSV and same rules should produce a comparable draft each run. Save the raw draft before any manual edits so the validator reviews what the drafter actually produced.

Validate with a second backend

The validator's job is contradiction hunting, not rewriting. Give it the CSV and the draft spec, and ask for a structured report.

• Ask it to check that each CSV row appears exactly once, with matching type, required flag, and constraints.
• Ask it to find internal contradictions, such as a field marked required in one schema and optional in another, or an enum that conflicts with a pattern.
• Ask it to flag dangling $ref targets, duplicate property names, and paths that reference schemas that do not exist.
• Require findings as a list with the field name, the conflicting locations, and a short explanation.

Instruct the validator to report only, not to silently fix. Silent fixes hide the disagreement between the two models, which is exactly the signal you want.

Reconcile the findings

Treat validator output as a review checklist, not as ground truth.

• For each finding, go back to the CSV row. If the CSV is wrong, fix the spreadsheet and re-run both steps.
• If the drafter misread a row, correct the draft or refine the drafter prompt.
• If the validator is mistaken, note why. Repeated false positives usually mean the CSV vocabulary is underspecified.

A short loop of draft, validate, reconcile converges quickly because both models work from the same rows.

Run structural checks as a final gate

Model review complements, but does not replace, mechanical validation. Parse the spec with an OpenAPI-aware linter or validator in your own pipeline. Schema-level tools catch malformed structures, unresolved references, and version-specific issues that a language model may overlook. Use the second backend for semantic contradictions and the linter for syntax and structure.

Keep the workflow economical

Both passes are ordinary API calls, so they fit the same key and billing model as any other request. Keep the CSV compact, send only the relevant rows if the sheet is large, and cache intermediate drafts. When you iterate, re-run the validator only on changed sections rather than the whole document.

A note on independent review

Using two different models reduces the chance that a single model's blind spots pass through unnoticed. It does not guarantee correctness. The spreadsheet remains the authority, and human review of reconciled findings is still the step that decides what ships.