Backend Registry

Registry of backend capsules known to TorchLean's planner.

Capsules are contributed by operation or provider modules and flattened into one planner catalog. Model architectures never appear here: they lower to backend operations, and the planner chooses a capsule for each operation. Optional external modules such as LibTorch are included only when the caller enables them and chooses an assurance policy that admits them.

structure NN.Backend.Registry.CapsuleModule : Type

A named, independently maintained contribution to the backend catalog.

• name : String
• capsules : Array KernelCapsule

def NN.Backend.Registry.instReprCapsuleModule.repr : CapsuleModule → Nat → Std.Format

@[instance_reducible]

instance NN.Backend.Registry.instReprCapsuleModule : Repr CapsuleModule

def NN.Backend.Registry.flatten (modules : Array CapsuleModule) : Array KernelCapsule

Flatten capsule modules while preserving module and local preference order.

def NN.Backend.Registry.firstDuplicateModuleName? (modules : Array CapsuleModule) : Option String

First repeated module name, if the registry contains two contributions with the same name.

def NN.Backend.Registry.firstDuplicateCapsuleName? (capsules : Array KernelCapsule) : Option String

First repeated capsule identity after flattening, if one exists.

def NN.Backend.Registry.validateModules (modules : Array CapsuleModule) : Except String Unit

Validate the identities that make registry ordering meaningful.

Different providers may implement the same operation. What is rejected is registering the same named module twice or repeating the same capsule name, operation, provider, and device tuple.

def NN.Backend.Registry.maintainedModules : Array CapsuleModule

Maintained operation/provider modules. A new architecture does not modify this list; only a new primitive implementation or provider does.

def NN.Backend.Registry.libTorchModule : CapsuleModule

LibTorch's independently maintained provider module. Profiles opt into it by adding this module to their catalog; provider preference is handled by the kernel policy, so module order does not encode backend selection.