Schema Formats
JSON Schema
JSON Schema drafts 4, 6, 7, 2019-09, and 2020-12 are parsed into the MetaModel preserving `$ref`, `oneOf`/`anyOf`/`allOf`, conditional `if`/`then`/`else`, and `$defs` — with full keyword resolution and a SchemaIngested entry per ingest.
The JSON Schema adapter supports drafts 4, 6, 7, 2019-09, and 2020-12. Schema composition keywords (`allOf`, `anyOf`, `oneOf`, `not`) and conditional keywords (`if`/`then`/`else`, `dependentSchemas`) are preserved as first-class composition nodes in the MetaModel rather than being flattened into a single shape.
References (`$ref`) are resolved transitively across `$defs`, external files, and HTTP(S) URIs (when allowlisted by the deployment). Each external resolution writes its own `SchemaIngested` entry, so the `$ref` graph between an OpenAPI components bundle and its downstream MetaModel state is reconstructable from the ledger.
Format keywords (`date-time`, `email`, `uri`, `uuid`, `ipv4`, `ipv6`) and validation keywords (`pattern`, `minLength`, `maxItems`, `multipleOf`) become annotations on the corresponding MetaModel attribute. Ambiguous formats — for example `uuid` vs. our ULID requirement — are flagged for review at ingest time, not at runtime.
Every ingest writes a `SchemaIngested` entry with the importer module identifier (`JsonSchemaImporter@x.y.z`), the SHA-256 of the canonical JSON bytes (computed against a stable key ordering, not the on-disk ordering), and the assigned schema ULID. A reviewer can prove that two ingests of the same schema text produced the same hash even when the editors who saved them used different key orders.
JSON Schema is the format Magellan uses internally to publish OpenAPI definitions for the Semantic Match API and the export endpoints. The adapter is therefore exercised on every release — there is no path through CI/CD where the JSON Schema importer is bypassed.
When a JSON Schema is the source side of a mapping, Predictive Mapping uses the format keyword and the JSON pointer path together as Semantic Match context, so `/patient/identifier` is preferred over `/order/identifier` even when both resolve to the same `string` type with the same `pattern`.
Audit ledger entries written by this capability
Each action in this capability appends one of the following entry types to the ULID‑keyed, SHA‑256 hash‑chained audit ledger. A reviewer can replay the chain to reconstruct exactly what happened, when, and under which role.
SchemaIngestedSchemaParsedExternalRefResolvedSee json schema demonstrated against your data
Pick a sample dataset or bring your own. We will walk the ledger from ingest through Approver release in a single working session.
Request a demoRelated across the platform
Where this capability hands off — upstream adapters, downstream governance, and the underlying audit primitives.