docs← Back to article

Markdown for LLMs

Package boundaries: what the corpus answers

The source Markdown for this article. Copy it into your assistant or download it as a text file.

Download this articlePlain text ↗
# 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](/corpus/#how-this-topic-marks-confidence).

## 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](/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**](/corpus/team-workflow/) 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](/recipes/n-package/); the command surface is
[Packages and cases](/cli/packages-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**](/corpus/catalog/). 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**](/corpus/vocabulary/audit/), and the full
reference is the [LawQL reference](/lawql/).

### 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**](/corpus/catalog/).

## 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**](/corpus/releases/compatibility/).
- **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**](/corpus/model/).
- **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**](/corpus/sources/editions-and-updates/).

## Where to go next

- [**Packages, cases, and worlds**](/corpus/model/) — the architecture this
  page draws boundaries around.
- [**Dependencies, locks, and registries**](/corpus/dependencies/) — how the
  closed world the questions run in is built.
- [**Catalogs and discovery**](/corpus/catalog/) — the discovery surfaces in
  full.