MAX and Mojo (Modular)

Recorded as a compiler, not an engine, on the strength of the two facts that make it one: MAX compiles model graphs down across three hardware families from one package, and Mojo is a frontend onto MLIR rather than a closed DSL. The inline-MLIR escape hatch is the part most likely to matter to a kernel author and the part easiest to miss - Mojo's documented answer to 'this operation is not exposed' is 'write the MLIR op yourself', which makes it a Python-shaped MLIR frontend rather than a language with its own dialect design. PRODUCTION_READY IS FALSE, DELIBERATELY, and this is the one production_ready value in this batch that is a negative claim rather than an omission. Modular sells hosted inference and demos to enterprises, and a less careful pass would have recorded 'yes' on the strength of that; but production_ready in this schema means used in production INFERENCE ENGINES, and no third-party engine deployment or independent measurement is documented in any source reachable here. A vendor product page is not production evidence, and recording it as such would be the exact vendor-claim-as-fact error AGENTS.md's contract exists to prevent. If a third-party production deployment appears, this flips to true with the source named. output_artifacts carries mlir-ir, which is NOT in this schema's documented enum (ptx, amdgcn, spirv, air, metal, c, llvm-ir, triton-ir, cubin, plan) - flagged here as enum debt rather than presented as a listed value, because Mojo genuinely does emit MLIR and the enum genuinely does not describe it. validate.py does not enforce item enums on arrays, which is why it passes; that is a validator gap, not a licence to invent. compile_time_seconds is null: no primary source publishes a per-kernel compile time. confidence is 0.8 for the mechanism and materially lower for the performance story, which rests entirely on vendor claims.