Migration from generic knowledge modules to native MathGenesis objects

Why migrate

The current generic module shape is suitable for formulas, decision tables, examples, exceptions, and time-varying facts. MathGenesis needs stronger distinctions among axioms, definitions, theorems, proof receipts, algorithms, constructions, physical models, partitions, and epistemic states.

Phases

Phase 0 — Compatibility wrapper

• Keep the existing schema and registry.
• Put native objects inside a mathgenesis_native_bundle record in formulas.
• Validate both the wrapper and the nested native objects.

Phase 1 — Native registry

• Add knowledge/math/registry.yaml and schemas/mathgenesis/.
• Add object, source, symbol, dependency, and snapshot indexes.
• Continue emitting compatibility wrappers for old consumers.

Phase 2 — Native retrieval

• Route math, geometry, and physics packs directly to the native registry.
• Enforce partition-scoped retrieval credentials.
• Add dependency-aware and notation-aware retrieval.

Phase 3 — Discovery lifecycle

• Add staging, falsifier, validation, utility, contamination, promotion, and historian artifacts.
• Store generation snapshots and immutable lineage.

Phase 4 — Deprecate compatibility reads

• Keep wrapper exports for archival compatibility.
• Make native objects canonical.
• Publish a migration ledger and expiry policy for legacy consumers.