Build and the artifact
Build, then run
With the tier settled and the shapes accepted, the source becomes an artifact. The shape mirrors compiling to a binary, except the artifact is a database rather than machine code:
$ ox build examples/temporal_promotion
$ ox query examples/temporal_promotion ...
ox build runs the compiler over a package and writes a .oxbin. A separate runtime loads that file the way a database server loads a schema, then answers queries and accepts mutations. The runtime never compiles source — every parse, check, and elaboration step happened at build time — which keeps it small and embeddable. ox is the driver that orchestrates compilation across a package and writes the artifact; oxc is the compiler-only subset it drives.
The build pipeline is a fixed sequence of phases:
lex -> tokens
parse -> a lossless syntax tree
expand -> macros run to a fixed point (below)
resolve -> every path bound to a definition
check -> type inference, then the runtime-evaluability gate
elaborate-> one axiom event per declaration
encode -> the .oxbin
The decisive step is elaboration. It turns every declaration — a concept, a relation, a rule, a fact — into an axiom event: a tagged record with a body. By the time the artifact exists, the whole program is a list of events, which is also the storage model the runtime turns on. The check phase before it is the evaluability gate: it runs the static checks and refuses the unsupported shapes, so a .oxbin that exists is one that passed.
Macros run before the program is a program
The expand phase is where the fifth atom lives. A pub macro is compile-time code generation — a vocabulary library grows the surface syntax without a compiler change, which is what the ontology-neutral design depends on. A macro expands to surface syntax that is re-parsed and flows through the same resolve, check, and elaborate path as hand-written source; it never emits an axiom event directly. Expansion runs to a fixed point, bounded by a fuel cap that errors on exhaustion rather than looping.
Two consequences make macros safe to trust. Because the classifier runs after expansion, on the lowered events, a macro lands the program on its true tier — a macro that emits a recursive rule is classified exactly as if the rule were written by hand, and cannot smuggle a program across a tier boundary. And because the declarative layer is strongly normalizing, has no input or output, and emits in a canonical order, expansion is a deterministic function of its input: the same source yields a byte-identical artifact, with no author discipline required.
The declarative engine — pattern-to-template pub macro with hygiene, repetition, and cross-module import — runs today. A procedural layer, #[procmacro] pub fn computing over reflected syntax, ships its first slice: token pasting, quotation, and light declaration reflection, enough to re-home the #[irreflexive] and #[asymmetric] directives from compiler builtins into genuine library macros. The remaining procedural surface is staged. The reference fixes the macro surface, the hygiene model, and the current status under the macro atom.
The artifact
The .oxbin opens with a fixed-size preamble and a directory of sections. Two properties govern how it is consumed.
It carries four independent version numbers rather than one — the section layout, the set of axiom kinds, the decidability ladder, and the runtime contract — because these evolve at different rates. A consumer accepts a future minor bump on any axis and rejects a major one: strict producers, liberal consumers.
It is content-addressed and deterministic. A composition signature hashes the wiring, the standpoint lattice, and the contract versions, and the artifact hash builds on that. Because the encoding and section order are canonical, the same source always produces a byte-identical .oxbin — reproducible builds for a knowledge base. The reference fixes the artifact layout under the .oxbin section model.