Pipeline

ox build <dir> searches upward from <dir> for the nearest ox.toml and treats that directory as the package (oxc-workspace::find_nearest_package_dir), the same cargo-style discovery ox check and ox lsp use. Module resolution then handles real nested package layouts — pkg::, super::, self:: path roots and pub use re-exports (see Modules and packages; not repeated here).

Output location. Build products never sit next to sources — cargo-style, the artifact is written under a target/ directory: <root>/target/<name>.oxbin, where <root> is the package directory (the one holding ox.toml) and <name> is the resolved entry’s file stem (so a package whose entry is root.ar yields target/root.oxbin). For a standalone .ar file with no enclosing manifest, target/ is created beside the file. target/ is created on demand and is git-ignored. -o/--out overrides the path entirely. The artifact-loading commands (ox query, ox derive, ox run, ox run-scenario, and ox runtime serve --oxbin) accept a package directory or source .ar and resolve the same default target/ location, or an explicit .oxbin path.

The pipeline has a sharp boundary: oxc is the per-package compiler; ox is the workspace orchestrator. Every cross-package concern lives in ox.

per-package source
      ↓ oxc elaborate              ← oxc owns (sync; salsa-cached)
per-package CoreIR
      ↓ oxc instantiate            ← oxc owns; consumes wiring
per-package .oxc cache
      ↓                            ─┐
(workspace metadata + lockfile)     │  ox owns:
      ↓ ox build                    │  • compute wiring diagram
      ↓                             │  • compose standpoint lattice
      ↓                             │  • check tier cap
      ↓                            ─┘  • merge .oxc → .oxbin
workspace .oxbin
      ↓ runtime backend (Runtime contract)
answers / docs / mutations / …

Three artifacts, three typed transitions:

• Source — the .ar surface text plus the per-package manifest.
• .oxc cache — one file per package: the elaborated, instantiated serialization of that package’s contribution relative to this composition. Same section model as Section model, smaller scope.
• .oxbin — the workspace artifact: one file per ox build, content-addressed, consumed by a runtime backend (Runtime contract).

oxc never sees the workspace. It elaborates a single package against a wiring diagram ox supplies; it cannot resolve cross-package references, merge standpoint lattices, check tier consistency across packages, or emit the workspace .oxbin. ox is the only command modelers invoke directly (ox build, ox run, ox query, ox check, ox test, ox doc, ox inspect, ox runtime serve, per reserved keywords); oxc instantiate / oxc emit core-ir / oxc dump are tooling-internal.

Build scope (RFD 0030). ox build produces a single, monolithic .oxbin per invocation covering the entry’s dependency closure: each [dependencies] path dependency’s modules are loaded and folded into the consumer’s workspace (exactly as the embedded stdlib is folded), elaborated into the same event stream, and embedded in the one artifact — so a dependency’s content participates in the artifact’s content hashes (Content-addressing). Cross-package references across a path dependency resolve at build time. The registry/git dependency surface (a bare version requirement, the version/git/branch/tag/rev/registry keys, ox.lock) is out of scope (Out of scope) and refuses with OE1240. The separate per-package .oxc cache and workspace-merge orchestrator below (Composition signature) describe the composition model the registry story realizes.