JSON Schema Manual

JSON Schema Manual renders a confirmed canonical field list as a draft 2020-12 schema for validation, API contracts, imports, exports, form generation or documentation. It is a helper rather than a new business table: the active module supplies the property names and types used across its CSV, SQL, spreadsheet and Notion artifacts.

The workflow types each property, applies requiredness the manual supports, and provides the schema as a contract. It does not compute, decide or imply business rules. If the owning field list is missing or ambiguous, the workflow asks which table the contract describes and stops rather than constructing its own definition.

Use it when agreed fields need a machine-readable contract or a payload needs structural validation. It reuses property names, options, dates, currency fields, calculated fields, statuses and IDs already confirmed. The remaining question is whether unknown properties should be rejected or allowed, when that choice affects the schema.

Do not use it to impose validation that the business has not requested. A required field or invented enumeration can reject valid data. It cannot confirm database records, check that a related client exists, repair an unconfirmed field list or enforce cross-field rules such as a due date following an invoice date.

The output is one object schema with one property per confirmed field, preserving names and order. Text, titles and phone values map to strings; numbers, money and percentages to numbers; checkboxes to booleans; and multi-select values to arrays of strings. Dates and datetimes use string format annotations, while URL and email fields use their corresponding formats. IDs and relations use strings or integers matching the manual keys. Files use an array or string only when the confirmed field model defines that structure.

A required entry needs support from the parent field list or explicit confirmation. Unknown requiredness means optional. Enumeration values represent a confirmed taxonomy; open options stay strings. Strict additional-property rejection applies only to a closed contract. Null is allowed only when the parent model explicitly distinguishes null from missing; otherwise optional unknown data is omitted.

A confirmed status enumeration has this shape:

{
  "Status": {
    "type": "string",
    "enum": ["Draft", "Filed", "Paid"]
  }
}

Calculated fields carry their data types, without a calculation. Descriptions stay within supported field meanings, and example values are omitted unless requested, then clearly synthetic. Prose and material limitations stay outside machine-readable schema data.

The consuming system supplies versioning, publication, registry and CI wiring. A relation is only a reference key, not a nested target schema or an existence check. Date and email formats may be advisory to a validator. The contract remains unverified until a real payload has been validated against it.