Namespace Guide

Use zeroproofml as the canonical public namespace for package names, documentation, and new import examples. Keep zeroproof working as a compatibility namespace for existing code.

Short rule

  • New docs, notebooks, and user-facing examples should prefer zeroproofml.*.
  • Existing integrations that already import zeroproof.* do not need an immediate rename.
  • Within one file or example, pick one namespace family and stay consistent.

Canonical imports for new code

from zeroproofml.inference import InferenceConfig, strict_inference
from zeroproofml.training import SCMTrainer
from zeroproofml.metrics import tau_infer_sweep_from_q_abs

Compatibility imports remain supported:

from zeroproof.inference import InferenceConfig, strict_inference
from zeroproof.training import SCMTrainer

Both forms resolve to the same underlying SCM implementation modules.

When zeroproofml.* is required

Some product-level surfaces live only under zeroproofml.* and should be documented that way:

  • zeroproofml.benchmarks
  • zeroproofml.report
  • zeroproofml.reference_robotics_deployment

Those modules do not have a legacy zeroproof.* counterpart.

Maintainer rule for new modules

When adding future SCM implementation modules:

  • put the implementation under zeroproof.*
  • expose it through zeroproofml.* for public imports and docs
  • reserve zeroproofml.*-only packages for product-level entry points

That keeps the public package name aligned with the published docs while preserving compatibility for the pre-existing import tree.