Super Schema GitHub

Logical first. Format aware.

One model.
Many schemas.

Design the logical shape of your data. Reuse it across schemas, APIs, and events.

Get started Explore an example

Public project. Self-hosted application.

One shared definition

Illustrative example
Logical model

Customer

id
string
name
string
email?
string

email is optional

customer.schema.json
{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "Customer",
  "type": "object",
  "properties": {
    "id": {
      "type": "string"
    },
    "name": {
      "type": "string"
    },
    "email": {
      "type": "string"
    }
  },
  "required": [
    "id",
    "name"
  ]
}

Review the generated artifact, field types, and optionality before adopting an output.

Same entity, different representations. Examples illustrate the workflow; generation and validation happen in the application.

A model that travels

Target support has format-specific limits. Review the generated artifacts and diagnostics before using them.

From definition to delivery

Fewer places to define
the same thing.

Follow a Customer definition from shared meaning to a published version. Choose a step, then explore the decisions inside it.

  1. 01Model the meaningAgree on fields, descriptions, types, and ownership.
  2. 02Connect definitionsReference the same entity from related contracts.
  3. 03Generate and inspectReview physical types, optionality, and format limits.
  4. 04Publish deliberatelyCapture a version and choose what consumers reference.

01 / Model the meaning

Start with a definition people can agree on.

Interactive illustration
Product & businessMeaning and intended use
GovernanceStandards and classification
AdministrationOwnership and participation
EngineeringTypes and implementation context
Shared decisions become a logical definition
Logical entityCustomer

Select a field to inspect its intent.

FieldLogical typePresence
stringRequired
stringRequired
stringOptional
One shared definitionThree explicit fields

Field intent

Customer.email

Email address used for customer communications.

Logical type
string · optional
Classification
PII
Definition owner
Customer product team · example

Classification records governance intent. Configure the corresponding controls in downstream systems.

Logical source · illustrative TypeSpecDescriptions live beside fields
model Customer {
  @doc("Stable customer identifier.")
  id: string;
  @doc("Customer display name.")
  name: string;
  @doc("Email address used for customer communications.")
  email?: string;
}

Start visually, paste a definition, or import a supported schema. Make the meaning and logical shape clear before reviewing any physical format.

02 / Connect definitions

Give related contracts a shared vocabulary.

Conceptual reference map

An order can reference a Customer. An API can return one. An event can use one as its payload. Select a reference to see how the shared entity is used.

Shared logical entity

Customer

  • id: string
  • name: string
  • email?: string
Meaning, descriptions, and type intent
Referenced by

Reference in focus

An API response uses the Customer definition.

The response points to a Customer schema component. Its fields describe the same logical customer, rather than an independently defined shape.

OpenAPI excerpt · illustrative
responses:
  "200":
    description: Customer found
    content:
      application/json:
        schema:
          $ref: "#/components/schemas/Customer"

Reuse custom scalars, enums, and unions as well as entities. This diagram illustrates declared references; it does not discover runtime data flow or synchronize running systems.

03 / Generate and inspect

Make every physical representation a deliberate choice.

Illustrative output

The logical entity stays recognizable. The target format determines how types and optionality are expressed.

Logical → physicalJSON Schema
FieldLogical intentTarget type
idstring · requiredstring · required
namestring · requiredstring · required
emailstring · optionalstring · may be omitted

What to inspect

JSON Schema properties are optional unless named in required. Here, id and name are required; email may be omitted.

customer.schema.json
{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "Customer",
  "type": "object",
  "properties": {
    "id": { "type": "string" },
    "name": { "type": "string" },
    "email": { "type": "string" }
  },
  "required": ["id", "name"]
}
MeaningReview the output beside the shared field descriptions.
TypesReview precision, scale, nullability, and target limits.
DiagnosticsInspect the actual emitter output and validation messages.

These are static examples, not a browser-based compiler. Generate and validate real artifacts in the application. Format support differs; review each output before adopting it.

04 / Publish deliberately

Make evolution explicit. Keep references intentional.

Local publishing illustration

A draft adds an optional phone field. Publish the example, then choose which published Customer version a sample event references.

Published snapshot

Customer v1.0

  • id string
  • name string
  • email? string

This definition stays fixed.

Draft change

Customer v1.1

  • id string
  • name string
  • email? string
  • + phone? string

Review the added field before publishing.

The example starts with v1.0 published and v1.1 in draft.

Consumer reference

customer.updated payload

A version pin keeps this example tied to a chosen published definition.

Customer@1.0
  • id: string
  • name: string
  • email?: string

This consumer uses the three-field v1.0 definition.

This illustration changes only the example on this page. Real publishing requires the application, review of change impact and target diagnostics, and a deliberate choice of referenced versions.

Inside the workbench

The model, its details,
and its source. Together.

Move between the visual field editor and the TypeSpec view. Keep the definition close to the decisions that shape it.

Customer / Entity workspaceProduct view
Super Schema's Customer entity editor showing six fields and a TypeSpec preview, using synthetic test data.
A real workbench view with synthetic test data.View full image

Around the shared model

The context is
part of the definition.

Fields are a start. Relationships, contracts, and change history give the model a life beyond its first schema.

Entities

Give your models a home.

Define fields, descriptions, and constraints in a shared logical model.

Reusable types

Define it once. Reference it.

Share enums, custom scalars, and unions across your modeling workspace.

Relationships

See what connects.

Reference other entities and explore the relationships you have modeled.

Schema generation

Meet your systems where they are.

Generate supported schema and DDL artifacts, then inspect the output and diagnostics.

API contracts

Carry the model into your APIs.

Describe operations, parameters, and responses with shared definitions.

Event contracts

Put payloads in context.

Design AsyncAPI 3.0 contracts visually, using entities as message payloads.

Governance metadata

Keep meaning beside the field.

Record classification, retention, and quality rules alongside your definitions.

Published versions

Make evolution explicit.

Separate drafts from published versions and pin references to a known version.

Start with one entity

Give your model
one shared home.

Explore the workflow, then make it your own.

Read the guide Explore the project on GitHub