Custom Import

Custom import is not an escape hatch — it is the same code path the built-in adapters use. An adapter implements the `ImportAdapter` interface (`parse(bytes: Uint8Array, opts: ImportOptions): MetaModel`) and registers itself with the ingestion pipeline via a versioned module identifier.

Once registered, the custom format appears alongside built-in formats in the import workflow UI, in the API enumeration, and in the per-format SEO surface. There is no second-class path: every custom adapter ingest writes a `SchemaIngested` entry with the same fields and the same hash chain participation as Avro or JDBC.

The adapter contract is versioned. An adapter declares the contract version it targets (`ImportAdapter@2.x`); incompatible contract versions are rejected at registration, and a `ImporterModuleRegistered` ledger entry records which adapter version handled which ingest. A reviewer can prove that a historical schema ingest was performed by a specific adapter build.

Adapter authors are expected to produce canonical bytes for hashing — the SHA-256 stamped into the `SchemaIngested` entry must be reproducible from the source artifact. The framework provides a `canonicalize()` helper for the common case (sorted keys, normalized whitespace, trailing newline) so most adapters get this for free.

Custom adapters inherit Magellan's unified MetaModel semantics, which means downstream features — Predictive Mapping, Automated Lineage, Impact Analysis, Visual Rules for Targets — work against custom-imported schemas without per-format integration work.

Adapter source is loaded from a versioned package. When a deployment upgrades an adapter, the prior version is retained and ingests pin the version they were processed under. Re-validating an old ingest against the adapter version recorded in its `ImporterModuleRegistered` entry is a one-command operation, which is what makes long-lived `SchemaIngested` entries defensible under SOX §404 retention.