Isolated execution sandboxes, as a library with no host-application concepts.

ex_sandbox is a composition and evidence layer over operating-system facilities, not a new isolation mechanism. Nothing here invents containment: the primitives are the OS's (cgroup v2, namespaces, bubblewrap, sandbox-exec, Job Objects). What this library adds is a uniform behaviour over them, a capability report that is honest about what the host cannot do, and a conformance suite that establishes claims by observing breaches being stopped rather than by confirming a limiter was invoked.

It depends on Elixir/OTP and nothing else — no Ash, no web framework, no host application (FR-001).

Public interface

These modules are public. A breaking change to any of them is a major version (FR-015):

• ExSandbox — this module; the top-level API
• ExSandbox.Mechanism — the behaviour every isolation mechanism implements
• ExSandbox.Sandbox — the struct passed to every mechanism callback
• ExSandbox.Capability — the host capability report (FR-016)
• ExSandbox.Hardening — the OS-level enforcement seam
• ExSandbox.Conformance — the conformance suite, included via use
• ExSandbox.Proxy — forwards a request to a running sandbox's address
• ExSandbox.Telemetry — the events both libraries emit, and their metadata
• ExSandbox.Conformance.{Lifecycle, Isolation, ResourceLimits, Execution, Helpers, Group} — public by consequence: use ExSandbox.Conformance expands into calls on them inside the consumer's own module, so they are part of the compiled surface whether or not anyone intended it

Everything else is private

A module not listed above is private, whether or not it is namespaced Internal (FR-014). The ExSandbox.Internal.* namespace makes the common case obvious from the module name, but the list above is what defines the boundary — a module that merely lacks the Internal prefix has not thereby become public.

There is no compatibility promise for private modules. Calling one from a consuming application is the coupling FR-004 forbids, and a consumer can check for it mechanically rather than by review: this table also ships as priv/boundary.md inside the package, resolvable at runtime through Application.app_dir(:ex_sandbox, "priv/boundary.md"). A consumer's own test reads the installed copy instead of restating it, so the check cannot drift from the list it is checking against.

What a consumer must supply

A consumer supplying nothing beyond a mechanism gets a working sandbox.

Capability honesty

Every entry point below refuses to start a sandbox when a required capability is unavailable, rather than starting it unconfined (FR-016; 005 R9). A mechanism that cannot isolate must say so — reporting less than it does rather than more is the discipline that makes a cross-platform floor mean anything.