TorchLean API

NN.Backend.Types

Backend Types #

Small vocabulary for backend selection and trust boundaries.

TorchLean owns the spec, graph, and proof-facing contracts. Backends are execution providers for parts of that graph: a Lean reference path, the TorchLean runtime, native CUDA kernels, or LibTorch. This file deliberately contains only data. It should stay cheap to import from specs, runtime wrappers, docs generators, and tests.

Hardware or execution target visible to the planner.

Instances For
    @[instance_reducible]

    Stable spelling used in profile names, reports, and CLI bridges.

    Instances For

      Parse an explicit backend device name. CLI layers may resolve policy names such as auto before calling this function.

      Instances For

        Parse an explicit backend device name or return a diagnostic suitable for command-line use.

        Instances For

          Concrete provider family used to execute a kernel capsule.

          Instances For
            @[instance_reducible]

            Stable operation vocabulary used by backend capsules, graph planning, and runtime guards.

            This is deliberately a closed vocabulary. New backend-visible operations should be added here and then wired through the IR adapter and capsule registry. Runtime tape/debug labels may still be strings, but the backend planner should not accept arbitrary stringly-typed operation names.

            Instances For
              @[instance_reducible]
              @[instance_reducible]

              Stable spelling used in reports, capsule names, and CLI diagnostics.

              Instances For

                Whether training through this operation requires a registered local VJP.

                Random sources create values but are not themselves differentiated. Every other backend-visible operation must provide a compatible VJP whenever gradient tracking is requested.

                Instances For

                  How much TorchLean knows about an implementation.

                  trustedExternal is allowed, but it is intentionally loud: the contract names the boundary instead of silently treating an industrial kernel as though Lean had verified its source.

                  Instances For
                    @[instance_reducible]

                    Which trust boundaries a kernel plan may cross.

                    The same record decides both which capsules the planner may select (by trust level) and which contract evidence the selected capsules may rely on (by evidence kind). Keeping the decision in one place prevents a profile from selecting a capsule under one policy and checking it under another.

                    • allowTrustedExternal : Bool

                      Whether capsules and evidence that delegate to an external implementation are admitted.

                    Instances For

                      Maintained TorchLean runtime policy.

                      Checked implementations backed by runtime guards and regression evidence are accepted; trusted external implementations are not.

                      Instances For

                        Explicit external-provider policy.

                        This is the policy used when a caller deliberately delegates a numerical kernel to LibTorch or another external implementation. The selected boundary remains visible in the execution audit.

                        Instances For

                          Whether the policy admits a capsule with the given implementation trust level.

                          Instances For

                            How a backend capsule treats gradients.

                            Instances For
                              @[instance_reducible]

                              Provider preference used when selecting an implementation for an operation.

                              Instances For

                                Policy used to select kernel capsules for a device and assurance boundary.

                                Instances For