BIR-JSON Record Schema by Op-Family — the 110-Op Catalog

All addresses on this page apply to neuronx_cc 2.24.5133.0+58f8de22, the cp310 build of libBIR.so (md5 12bb979f7ca41248252abb0f16b2da98, 9.5 MB). VA == file offset for .text (0x1820c0…) and .rodata (0x708000…); cp311/cp312 carry the identical ABI but the virtual addresses drift. Key strings and this-relative field offsets are version-stable.

Abstract

This is the authoritative per-op field reference for the BIR-on-disk JSON wire. Every bir::Instruction subclass serializes through three generated methods — a 49-byte createFromJson factory stub, a readFieldsFromJson reader, and a toJson writer — and the key set those two move is the op's record schema. The page catalogs all 110 InstructionType ordinals (0–109) grouped by op-family, and for every op gives its op-specific key set: the JSON key string, the C++ this-relative field offset it (de)serializes to, the deserializer type (from_json<Enum>, MaybeAffine<T>, SerializableFloat, QuasiAffineExpr, a vector, or a nested object), and the ctor default.

Two facts shape the whole catalog. First, every record is two layers. A shared bir::Instruction base header (opcode, engine, ins/outs/indirection_ins, dependencies, sync_info, debug, …) is emitted by bir::Instruction::toJson (0x2e2ea0) for every op and parsed by bir::Instruction::createFromJsonHelper (0x2e01b0); the per-op readFieldsFromJson/toJson add only the op-specific keys tabulated here. That base header is owned by the bir::Instruction base-struct page, not repeated per-op. Second, the per-op layer is astonishingly thin. Of the 110 ops, a large fraction carry zero op-specific keys — their readFieldsFromJson is a single ICF-folded ret and they emit a header-only record; their entire semantics rides on the operand tensors (ins/outs) and the opcode discriminator. The richest single op is InstBIRKernel with ~16 keys; the matmul base carries 13; InstActivation 11; most ops carry 0–4.

This is the JSON record layer. The L1≠L3 wire encoding (how the field values are packed for silicon, the comparison reorder, the runtime-byte form) is a separate concern owned by the AluOpType + mode-enum and front-end wire pages — cross-referenced here, never duplicated. The schema is recovered entirely from libBIR.so: libBIRParserDumper.so defines a textual pretty-printer (bir::Dumper::visit*) used here as a cross-check, but holds zero readFieldsFromJson/toJson — the JSON schema lives exclusively in libBIR.so.

For reimplementation, the contract is:

• The two-layer record model: shared base header (owned elsewhere) plus the op-specific key set per ordinal, tabulated below.
• For each op: the exact key spelling, field offset, type, default, and required-vs-optional emit/parse discipline.
• The non-obvious per-family structure: the three independent DMA class trees, the control-flow EventSemaphore-base thunk chain, the kernel-op key sets, and the operand-nested indirect-AP keys that are not per-op keys.

The record model & method dispatch

Two key-sets per record

Every wire record is the union of two disjoint key sets:

{ BIR JSON record for op X }
  = COMMON HEADER  (bir::Instruction::toJson @0x2e2ea0 — emitted for EVERY op)
      opcode · engine · engine_id · ins · outs · indirection_ins · predicates
      order · origin · dependencies · loop_carried_dependencies
      unroll_dependencies · optin_passes · loopnest · sync_info
      scheduled_start · scheduled_end · debug
      dma_trigger_debug_update_semaphore_id   (DMA-guarded)
  ⊎ OP-SPECIFIC keys  (Inst<X>::toJson — only the rows in this page's tables)

The common header is anchored verbatim to the .rodata refs inside Instruction::toJson (0x2e2ea0) and is the subject of the base-struct page; it is listed here once and never repeated. The op-specific keys are the catalog.

NOTE — the common header does not carry target / on_true / queue / arguments. Those are op-emitted (a BasicBlock* or operand reference serialized as the block/object name string), even though the corresponding object is linked later by the common createFromJsonHelper successor/operand resolver, not by the op's own reader. So a control-flow op's reader key set can omit target while its writer emits it — see § Control-flow family.

Read vs write mechanics

The (de)serializers are generated against nlohmann::json_abi_v3_11_3. The reader/writer idiom is uniform across all 110 ops:

// reader: Inst<X>::readFieldsFromJson(self, j)
//   per op-specific key:
if (REQUIRED)                                  // json.at<char const(&)[N]>("key")
    from_json(j.at("key"),  self->field);      //   throws type_error if absent
else /* OPTIONAL */                            // find-guard: j.find("key") != j.end()
    if (j.find("key") != j.end())              //   std::string::compare lookup loop
        from_json(j["key"], self->field);      //   else field keeps its ctor default

// writer: Inst<X>::toJson(j) const
//   j["key"] = field;   via MaybeAffine<T>::writeIntoJson / bir::to_json(enum)
//                       / adl_serializer<T>::to_json
//   MaybeAffine + skip-default fields are emitted ONLY when non-default

Two discriminators a reimplementer must get right:

• Required vs optional. A key read with json.at<char[N]> is required (throws if absent). A key reached through a find(key) != end() guard is optional — a missing key leaves the field at its ctor default. The [N] template argument equals strlen(key)+1 and is itself a spelling check (e.g. "op"→at[3], "reduce_cmd"→at[11], "is_first_reduce"→at[16]).
• Skip-default emission. MaybeAffine<T> fields and most enum scalars are emitted by toJson only when the value is non-default (the guard is value != 0 or affine-flag set), so an omitted key on the wire means "default". SerializableFloat and the unconditional-at() enums are always emitted. The writer's skip-default discipline is the subject of the JSON-writer page; the default column in every table below is what the field reads as when the key is absent.

QUIRK — MaybeAffine<T> (0x28 B) is a tagged union {value : T, affine-flag, QuasiAffineExpr} — the wrapper that lets a field be a compile-time constant or a runtime dynamic-shape affine expression. On the wire a MaybeAffine value is a scalar or an affine-expr object under the same key. The value lives at field+0; the active-tag byte sits at a class-specific offset (field+0x20 within the 0x28-B slot, e.g. IndirectLoad value +0x128 / flag +0x148). Reader → MaybeAffine<T>::readFromJson / QuasiAffineExpr::createFromJson; writer → MaybeAffine<T>::writeIntoJson. Full byte-layout is owned by the value model page.

The two-VA-frame artifact

Every (de)serializer symbol appears twice in the IDA sidecars: a real body in the 0x40xxxx–0x43xxxx (or 0x2dxxxx/0x25xxxx) text band, and a 5–6-byte alias/PLT thunk in the 0x17xxxx–0x18xxxx band that tail-jumps to it (verified e.g. InstActivation body 0x417f00 vs thunk 0x1816f0; InstDMA::toJson body 0x4363d0 vs thunk frame 0x17ffb0). Every address on this page is a real body. Do not read a thunk frame as the function — it is the same code reached via a different VA frame.

The factory stub

createFromJson is a 49-byte stub identical in shape for all ops:

Inst<X>* Inst<X>::createFromJson(string& name, BasicBlock* bb, const json& j):   // 49 B
    inst = NamedObjectContainer<BasicBlock,Instruction>::insertElement<Inst<X>>(bb, name);
    Inst<X>::readFieldsFromJson(*inst, j);     // the op-specific keys
    return inst;

Dispatch is purely static per opcode: a subclass's createFromJson calls its own readFieldsFromJson, so there is no virtual fan-out inside the factory. The opcode→createFromJson routing is done once by createFromJsonHelper keyed on the opcode string (InstructionType2string, 0x2d5bf0).

Matmul / MX family (6 ops)

InstMatmultBase is an abstract base that owns the entire matmul/MX op-specific payload in one shared 13-key body. Matmult and MatmultMx are pure JMP thunks to it (zero own keys); MatmultSparse adds exactly one key; QuantizeMx and ReadActivationAccumulator carry zero op-specific keys.

Instruction
 └─ InstMatmultBase   (abstract; the shared 13-key reader/writer)
     ├─ InstMatmult         (no own keys; readFields/toJson = 5-B jmp → base)
     ├─ InstMatmultMx       (no own keys; readFields/toJson = 5-B jmp → base)
     └─ InstMatmultSparse   (base keys + compress_ratio)
 ├─ InstQuantizeMx                 (empty readFields; header+operands only)
 └─ InstReadActivationAccumulator  (empty readFields; header+operands only)

InstMatmultBase — the shared 13-key body

readFieldsFromJson 0x41f600 (4373 B) / toJson 0x4358b0 (1359 B). Verified: the writer references exactly these 13 key literals and no others. Offsets are from the Instruction this. MaybeAffine<T> codes: h=u8, b=bool, i=i32, j=u32.

The 13 fields lie on a regular 0x28-byte stride from +0xF0 (counting tile_size/tile_position as two slots each = 13 MaybeAffine slots), then perf_mode (4-B enum + 4-B pad) at +0x2D0, then the two quant offsets; the base-specific region ends at +0x328. perf_mode → MatmultPerfMode {0 None, 1 DoubleRow, 2 DoubleColumn, 3 DoublePixel, 4 DoubleRowSwInterleave}; ctor default 0/None is set by 0x402fa4 (mov dword[rbx+2D0h], 0).

QUIRK — MaybeAffine fields are always emitted in the matmul body (no skip-default gate on toJson 0x4358b0), so all 13 base keys are present in any valid Matmult record. This differs from the tensor-op family, whose MaybeAffine keys are skip-default. The catalog's default column is the ctor value, not "absent".

The other five

MatmultSparse's one extra key: compress_ratio → std::variant<int, QuasiAffineExpr> (payload +0x328, variant tag +0x348; tag 0=int arm, 1=affine arm). The remaining schema = the 13 base keys.

GOTCHA — the "MX-ness" of MatmultMx/QuantizeMx (FP8/E8M0 packed weights, block scaling) is not in any JSON scalar field. It is carried by (a) the operand tensors' dtype (the FP4/FP8/E8M0 Dtype ordinals — see the dtype tables) and (b) an extra scale-tensor operand in ins. The MX block_size=32 is an HLO backend_config baked at codegen — it is absent from BIR-JSON. A reimplementer searching for a block_size/scale/scale_method key will find none; they do not exist in libBIR.

CORRECTION (E05-C1) — the seed key quant_kernel is not a matmul/MX field. It belongs to InstBIRKernel (readFields 0x433d40, key at +0x250; see § Kernel family).

Activation / reduce / pool family (16 ops)

A mixed family: a handful of rich ops (Activation, TensorReduce, Pool, RangeSelect, MatchReplace) and many header-only ops. The wire key func is overloaded: on Activation it is ActivationFunctionType at +0x120; on Pool it is PoolFunctionType at +0xF0 — same string, different enum and offset, different struct.

InstActivation (IT 4) — 11 keys

readFields 0x417f00 / toJson 0x435450. Engine = Activation ("Scalar"). Verified: the writer references exactly these 11 keys (op0/op1 are the aCompareOp0+8/aCompareOp1+8 rodata substrings — confirmed at the lea sites 0x43571f/0x4356df). This op's 11-key count is the reference shared with the cross-language parity page.

The rest of the family

GOTCHA — the wire key reduce_cmd deserializes to bir::EngineAccumulationType ({0 Idle, 1 Zero, 2 Accumulate, 3 ZeroAccumulate, 4 AddAccumulate, 5 LoadAccumulate}), not bir::ReduceCmdType. ReduceCmdType is dormant — no JSON consumer references it. InstTensorReduce has no reduce_cmd key at all; its reduce selector is the single enum axis (AxisListType, value+1 = innermost dims collapsed). See the AluOpType + mode-enum page.

NOTE — reduce_axes (Tonga, a JSON array of axis indices) and axis (TensorReduce, an AxisListType enum) are two distinct keys with different wire shapes. Do not conflate them.

Copy / tensor-scalar / tensor-tensor family (18 ops)

The common base object is 240 bytes (0xF0); every subclass's first own field is at +0xF0. The tensor-scalar group shares a layout (op0 +0xF0, reverse0 +0xF8, op1 +0x120, reverse1 +0x128) but each op re-implements its own reader — layout-inheritance by convention, not a shared reader function.

Copy ops

NOTE — InstAbstractCopy (IT 3) appears in this family and in the DMA family because it is a copy-like op whose only key is dma_qos. Its parent is InstEventSemaphore, not InstDMA — see § DMA family. Its dma_qos at +0xF0 is in the InstGeneric tree, offset-coincident-but-semantically-distinct from InstDMA+0xF0 (a DMAQueue* pointer).

Tensor-scalar group

QUIRK — InstTensorScalarPtr (the "Ptr" variant) carries no const0/const1 — the scalar is a pointer/tensor operand, not an immediate. Its is_tensor_scalar_addr / is_scalar_tensor_tensor / is_tensor_tensor_scan flag triple selects which datapath variant a single op maps to.

Tensor-tensor / select / address-gen / fill / shuffle

NOTE — Iota and TensorScalarAffineSelect share the {base, pattern, channel_multiplier} affine-address-generator sub-layout at identical offsets (+0xF0/+0x118/+0x168). The Memset fill key is constant (MA<uint>), not fill_value — fill_value is the TensorScalarAffineSelect SerFloat at +0x194. The seed helper keys predicates/value_array/value_list/update_mode are base-header / sub-object helper keys, not members of any of these op records.

DMA family — three class trees

The decisive structural result: the "DMA family" is not one inheritance tree. Three independent roots descend from Instruction, and they do not share the DMA base fields. This is verified at the binary: InstDMA::toJson (0x4363d0) emits queue and chains Instruction::toJson; InstDMADescriptor::toJson (0x43c3e0) emits num_tiling_dimensions and also chains Instruction::toJson directly — proving the descriptor subtree is not under InstDMA.

TREE 1  Instruction → InstDMA → { DMACopy, Load(→Save), DMATrigger, TensorLoad, TensorSave }
         InstDMA owns the shared DMA fields: queue / dge_type / duplicate.

TREE 2  Instruction → InstDMADescriptor → { Copy, CCE, Transpose, Replicate }
         InstDMADescriptor ctor calls Instruction DIRECTLY (NOT InstDMA).
         No dge_type/queue/dma_qos — only num_tiling_dimensions.

TREE 3  Instruction → InstGeneric → InstEventSemaphore → InstAbstractCopy
         AbstractCopy (IT3): copy-like Generic op, NOT an InstDMA. Only key = dma_qos.

Tree 1 — InstDMA base and its subclasses

InstDMA base: readFields 0x4173c0 / toJson 0x4363d0 / ctor 0x405260. The base object's own additions on top of the header are queue, dge_type, duplicate:

GOTCHA — InstDMA+0xF0 is a DMAQueue* pointer, not a scalar QoS source. toJson (0x4363e5) dereferences it and emits the queue name (the string at queue+0x68) under key queue. readFields reads only dge_type + duplicate; the queue field is written null and bound later by createFromJsonRecursivelyPass2 (queue name → DMAQueue*; "Queue does not exist!" assert). The InstDMA scalar QoS lives on the subclasses (Load/Save +0x150, DMACopy +0x1D8, AbstractCopy +0xF0), per getDMAQoSClass (0x30fc60).

The DMACopy subclass starts its own block at +0x128 (the InstDMA base block ends at the +0x120 queue-present gate):

* TensorLoad/TensorSave are catalogued under both the copy family (their natural home) and Tree 1 by name/RTTI; they carry zero DMA additions.

Tree 2 — InstDMADescriptor and its subclasses

InstDMADescriptor base: readFields 0x41f0c0 / toJson 0x43c3e0 / ctor 0x40b7e0 (calls Instruction directly). Sole base key:

Tree 3 + structured-control DMA

CORRECTION (E07-C1) — of the nine "dma/dge" seed keys, only dge_type is an InstDMA field; dma_qos is per-subclass; dma_blocks is BasicBlock-level (createFromJsonRecursivelyPass2, sub_273300); dma_trigger is an InstDMABlock sub-block; num_dma_engines belongs to the DMAQueue record (DMAQueue::toJson 0x257160), and eng_dma to ModuleArtifactInfo — neither is an instruction field. use_gpsimd_dma is an InstDMACopy field (+0x1DC).

NOTE — InstDMACopy uses remote_notification (singular); InstDMABlock uses remote_notifications (plural). Two distinct keys — do not conflate.

Collective / BatchNorm / RNG family (18 ops)

Three structural classes here. Rich ops parse named keys; degenerate ops have a bare-ret reader and no toJson override (header-only); and InstCollective (IT 47) is an abstract base whose readFields is ret but whose toJson (0x438ea0) emits one inherited collective key queue that Send/Recv/Compute all chain.

Collective ops

InstCollectiveCompute (IT 48) multiplexes all 11 CollectiveKinds; it is the only collective carrying the seed keys cc_dim/cc_type_hint. readFields 0x432110 (6466 B) / toJson 0x438fe0.

CORRECTION (E09-C1) — neff_collective_has_offset is not a literal libBIR readFields key — no such operand string appears in 0x432110. It is a paraphrase; the real offset-bearing keys are recv_from_rank / send_to_rank / src_target_pairs. The literal top-level CollectiveCompute key set is exactly the table above plus the inherited queue.

BatchNorm ops

Only three BN JSON fields exist across the whole family; BNStatsAggregate and BNGradients are header-only (operand-only) records.

RNG ops

Only Rand and SetRandState carry keys; the other five RNG opcodes are header-only.

NOTE — SetRandState's rng_engine is bir::EngineType ({0 Unassigned, 1 Pool, 2 Activation, 3 PE, 4 DMA, 5 DVE, 6 SP, 7 ALL}) — it names the engine whose RNG state is restored — not a Random enum. The Gen-2 (V4) RNG ops Rand2/RandGetState/RandSetState carry no keys; only the Gen-1 Rand and SetRandState are keyed.

Indirect / gather family (8 ops)

The fine-grained indirect access-pattern descriptors are operand-object keys, nested under the common-header ins/indirection_ins arrays — not per-op top-level keys.

IndirectDim wire enum: {W=0, Z1, Y2, X3} (IndirectDim2string 0x4021a0).

CORRECTION (E10-C3) — the seed indirect-AP keys — indirect_dim, indirect_dim_max_index, num_tensor_indirect_indices, offset_expr, tensor_indirect_arg_id, reg_ap_offset, num_indirect_args — are operand-object keys nested under ins/indirection_ins, owned by bir::DynamicAPINFO::toJson (0x268c00), bir::SymbolicAccessPattern::toJson, bir::Argument::createFromJson, and getIndirectArgumentById. The only per-op top-level indirect key is indirect_dims (on GenericIndirectLoad/GenericIndirectSave). The seed keys indirect_loadsave / is_regloc_offset / const_ap_offset have no xref in libBIR at all.

Control-flow family (13 ops)

The control hierarchy is recovered from the toJson tail-call chains. InstEventSemaphore (IT 13) is the concrete base whose toJson (a thunk → Instruction::toJson) the five structural terminators inherit.

Instruction
 └─ InstEventSemaphore           (toJson = thunk → Instruction::toJson; NO own keys)
      ├─ Return / Exit / Break    (thunk → EventSemaphore::toJson; NO keys)
      ├─ UnconditionalBranch      (+ target)
      ├─ CompareAndBranch         (+ comp_op, on_true, on_false)
      └─ BranchHint               (+ hint, associate_branch)   [excluded from the thunk chain]

CORRECTION (E10-C4) — the loop-bound keys are lb/ub/stride and name. The seed keys loop_count/trip_count/branch_target do not appear in libBIR. BranchHint (80) has its own keys but is excluded from the EventSemaphore thunk chain (consistent with byte_7858CE[3]=0). The Loop/DynamicForLoop/DoWhile container fields are parsed inline in createFromJson (0x3243b0/0x325380/0x25e8e0), not a flat readFieldsFromJson; their offsets are read from toJson only (HIGH).

Queue / sync family (9 ops)

EventSemaphoreClearMode is carried by exactly one op (GroupResetSemaphores).

CORRECTION (E10-C2) — the seed sync keys num_semaphores/user_event/wait_mode are not libBIR-JSON keys (rodata literals with zero xref to any (de)serializer). The real per-op sync keys are exactly the table above. runtime_semaphore_wait_value (the Indirect{Load,Save} key) is distinct from runtime_semaphore (the CoreBarrier key).

Kernel / custom-op family (4 ops)

The kernel ops are the richest records in BIR-JSON. Non-MaybeAffine vector/string offsets are marked HIGH (their field↔key pairing is by lea/operator[] adjacency); the MaybeAffine members are CERTAIN.

CORRECTION (E10-C5) — the kernel ops are not keyed function_name/lib_file_name/kernel_text/opaque (no xref). They use opFunctionName/opLibFile (CustomOp) and func/klir_binary (NKI*). quant_kernel lives here (BIRKernel +0x250), confirming it is not a matmul key. NKIKernel/NKIKLIRKernel/Call assert "Not Implemented" only in sameInst (structural equality) — they have full JSON (de)serializers regardless.

Misc family (6 ops)

The 110-op coverage tally

Every InstructionType ordinal 0–109 is covered exactly once by one of the families above. The partition is cross-checked against the 110-case InstructionType2string (0x2d5bf0) — see the 110-opcode enum, which also reconciles the 104/105 "concrete-leaf" count denominators. The catalog has no gaps and no overlaps.

NOTE — the family rows total more than 110 because a few ops are legitimately catalogued under two families (e.g. AbstractCopy IT 3 appears under both copy and DMA Tree 3; IndirectCopy IT 26 under both copy and indirect; TensorLoad/TensorSave IT 75/76 under both copy and DMA Tree 1; DMA IT 18 is the InstDMA abstract base). The distinct ordinal set is exactly 0–109, 110 ops, dense and gap-free, matching the InstructionType enum.

The dominant shape of the catalog: a large fraction of ops carry zero op-specific keys. Across the indirect/control/queue/sync/kernel/misc set alone, 10 ops have a ret-only reader (NoOp, EventSemaphore, AllEngineBarrier, Halt, GPSIMDSB2SB, GetSequenceBounds, RegisterMove, Terminator, Gather, Generic) and 6 are 5-byte JMP thunks to a base reader. A reimplementer should expect most records to be header-only and reserve the rich path for matmul, activation, the tensor-scalar group, the collectives, and the kernel ops.

Confidence & re-verification

The strongest claims on this page were re-verified against libBIR.so cp310 directly, not only against the source reports:

• InstMatmultBase::toJson (0x4358b0) references exactly the 13 key literals tabulated, no more — confirmed by enumerating the lea …, a<Key> sites. CERTAIN.
• InstActivation::toJson (0x435450) references exactly 11 keys; op0/op1 resolve via the rodata substrings aCompareOp0+8/aCompareOp1+8 at 0x43571f/0x4356df. CERTAIN.
• The DMA tree split: InstDMADescriptor::toJson (0x43c3e0) chains Instruction::toJson and emits num_tiling_dimensions, while InstDMA::toJson (0x4363d0) emits queue and chains Instruction::toJson — the descriptor subtree is provably not under InstDMA. CERTAIN.
• InstAbstractCopy::readFieldsFromJson (0x416b30) reads dma_qos into [r12+0F0h] via from_json<DMAQoSClass> (jmp 0x416ca8). CERTAIN.
• The 110-op partition is cross-checked against the 110-case InstructionType2string (0x2d5bf0), verified in the opcode-enum page. CERTAIN.

Honest ceiling on the rest: families fully covered at CERTAIN for their primary keys are matmul/MX, activation/reduce/pool, copy/tensor-scalar/tensor-tensor, the three DMA trees, BN, RNG, and the control-flow/queue/sync core. Sampled/HIGH (offset-precise but not every member byte-pinned): the deep CollectiveCompute field block below cc_type_hint (pipe_id/recv_from_rank/permute_chain/src1_bitmap/unique_tensors), the kernel-op non-MaybeAffine vector/string offsets (srcsShape/sb_buf_shape/func_outs/kernel_attrs/lower_bound), and the structured-control container offsets (Loop/DynamicForLoop/DoWhile, read from toJson only). The MaybeAffine<T> per-field ctor defaults (beyond perf_mode=None and the bool-false sentinels) are the uniform 0x28-B zero/identity init and are marked "ctor", not byte-traced per field. No NEFF/BIR-JSON fixture round-trip byte-diff was performed.

Cross-References

• The bir::Instruction Base Struct — the shared base header keys (opcode/engine/ins/outs/…) that every record carries; the single-spec *OpGen contract
• InstructionType: the 110-Opcode Enum — the ordinal→name roster and the 104/105 concrete-leaf count reconciliation this catalog partitions
• Cross-Language Wire-Key Consistency & the *Gen Bases — the Python↔C++ parity proof for the same InstActivation (11) / InstMatmultBase (13) key sets; the instruction-count denominators
• Argument / AccessPattern / Immediate / Register Value Model — the MaybeAffine<T> / QuasiAffineExpr / SerializableFloat / APPair wrappers and the operand-nested indirect-AP keys (DynamicAPINFO)
• AluOpType + the Mode Enums & the L1≠L3 Comparison Reorder — AluOpType, TSCMode, MemsetMode, and why reduce_cmd is EngineAccumulationType not ReduceCmdType
• Engine / Arch / Accumulation / Axis / Indirect / Transpose Enums — EngineType, AxisListType, IndirectDim, TransposeOps, EngineAccumulationType
• Op-Family Enums & the L1/L2/L3 Crosswalk — CollectiveKind/CollectiveDimension, MatmultPerfMode, PoolFunctionType, the kernel/branch structural enums
• Dtype Tables & Wire-Tag / Stride / Alignment LUTs — the FP4/FP8/E8M0 Dtype ordinals that carry "MX-ness" in operand tensors, absent from the matmul scalar fields
• JSON Writer — toJson, Skip-Default Emission & Always-v2 — the writer side: skip-default gates, ICF-merged bodies, the always-v2 schema version (planned)
• JSON Loader — createFromJson & the Recursive Pass-2 Linker — the reader side: the opcode→factory dispatch and the queue/successor resolution this catalog defers to (planned)