Package boundaries: what the corpus answers

A package boundary is three things at once: the artifact edge (the whole versioned package, pinned by content hash), the visibility edge (which declarations other packages may name), and the behaviour the team promises to keep. This page describes the import surface that crosses those edges, the questions the corpus answers well, and the ones it refuses to answer and why.

Marks on this page follow the topic legend.

The import surface

An example from the lab first. labparcels.fees imports labparcels.registry at version 0.1.0 and writes labparcels.registry::registered(p) in its rules. The reference works for two reasons: registered is marked pub in the registry, and the registry is part of the fees world.

In general, one package names another package to use it. The world link step then joins the compiled packages by name and refuses collisions and second versions. Inside a package, one use self block per file records the intra-package references, in the mode the manifest declares. Both are Available in the public release (S).

Three levels divide what crosses the boundary, from bytes to promises:

• Artifact and hash. The unit of reuse and transfer is the whole versioned package: the lock pins each dependency to one version with the content hash of its compiled bytes, and the downloaded bytes are verified against that hash before anything trusts them.
• Visible and internal names. A declaration is internal unless marked pub; only pub names are reachable from another package, written with the package prefix, and reaching for anything else is refused with a diagnostic. The prefix alone is not enough — the neighbor package must also stand in the linked world.
• Public contract. A team-kept vocabulary contract lists the names and shapes consumers may rely on; anything unlisted may change without notice. The engine never reads this document — it records stability promises, not a package format.

The first two levels are tool surface, Available in the public release (S). The contract is a Team convention (T): no tool checks it. The language side of the middle level — pub marking, package-prefixed references, and the refusal for hidden names — is introduced on the Language pages.

The authoring side — explicit mode, per-package repair of the use self blocks, and the shared-tree discipline — lives on the Team workflow: conventions and check profiles page of this topic.

What the corpus answers

Case questions over pinned worlds

Given a case package — facts plus expected results — the corpus evaluates the question over the locked, linked world and returns the result with its provenance. Asking and scenario testing share one path — link the locked world, then evaluate — while serving evaluates over already-linked world bytes. Either way, anything the question needs must be inside the closure; nothing is fetched or guessed at question time. (S)

The recipe book for this path is N. Package, context, snapshots, case, result, and test; the command surface is Packages and cases.

Structural questions over the formalization itself

Separate from case questions, the structural query surface asks about the canon as written: which rules derive a predicate, which literals read it, which anchors support a node, which packages import which. The surface offers fourteen relations and nine functions, plus a catalog of six named questions and sixteen lint checks — twenty-two entries in the live listing, quoted verbatim on Catalogs and discovery. The structural layer answers equality and membership only; every row carries the identity of the compiled node it came from. (S)

The audit-oriented tour continues on Audit surface: relations, functions, questions, lints, and the full reference is the LawQL reference.

Discovery before asking

Package listing with signatures, meaning-based search across predicates, rules, and source fragments, and paged structural queries form the discovery path. Search returns addresses — what to ask next — never answers; similarity of wording never settles applicability of a norm. (S)

Start at Catalogs and discovery.

What the corpus does not answer

• Unformalized law. If no rule expresses the norm, the answer is that nothing is established — with the candidate rules and their unsatisfied premises shown — never a guess from general knowledge.
• Cross-closure merges. One version per closure, one semantics line per world. Questions spanning language lines or competing pins are separate questions over separate worlds; see Compatibility: versions and language lines.
• Hosted services. Discovery and asking run against local checkouts, registries, and lockfiles. Anything beyond the directory registry and the local commands is Unconfirmed (U).
• World building as a standalone step. Linking a new root’s locked world happens inside asking, testing, and packing — there is no separate assembly command, by design. Serving and replaying are the other operation: they execute already-linked world bytes without linking again. See Packages, cases, and worlds.
• Legal amendment synthesis from the repair command. The amendment search on the command surface is minimal code repair over sources, not the enactment of a legal amendment; the legal lifecycle — editions, applicability, and revision operations — is covered on Editions and updates.

Where to go next

• Packages, cases, and worlds — the architecture this page draws boundaries around.
• Dependencies, locks, and registries — how the closed world the questions run in is built.
• Catalogs and discovery — the discovery surfaces in full.