Reviews, approvals, and records

Numbers say how much is formalized; reviews say whether it is right. This page covers the approval command that binds a human review to an exact result, the lint catalog that screens every package’s shape, and the per-corpus review records.

Marks follow the topic legend. Approvals and the lint catalog need a source checkout; law audit itself is available in the public release, where its form section reports not_run.

Approving an answer

law answers approve records a lawyer’s review of answer verbalizations. Requires a source checkout (I): the command is absent from the public composition, so it needs the checkout launcher ./law (see Before you start):

console

$ ./law --help
...
  law answers build|check <selection> [--from <ask catalog>]
  law answers approve <selection> --key <key> --reviewer <urn> --at <moment> [--status …] [--note …]
          answer-verbalization goldens of the selection, and approvals (DECISION-0388)

An approval is not a comment; it is a binding between a review block and two hashes — the semantic hash of the reviewed subject and the hash of its verbalization. If either side drifts afterward, the approval goes stale (LDC-E8202) instead of silently blessing a changed text. Each approval names its reviewer, its key, and its moment, with optional status and note.

Reviews climb a status ladder — draft, reviewed, verified, approved, disputed — and only approved admits a fragment to VERIFIED. The ladder is per review block, so one disputed block never blocks the approval of its neighbors.

Sixteen shape checks on every audit

In the full checkout build, every law audit run ends with a form section: the 16 LawQL lint detectors run over a fresh snapshot of the package (S). The coverage page shows two real reports from that build; both carry the detector count (detectors 16, findings 0 for a clean dictionary package, detectors 16, findings 12 for a larger source package).

The public composition pinned for the lab ships no lint catalog, so its audit reports the form section as not run — verbatim last lines, exit code 0:

Output

form (LawQL catalog lints): not_run — lint catalog not found: present --lints <corpus/ql/lints dir>
dangling premises: 0 (unsupplied by package 0, enum variants in body 0)
one-way premises: 0 of 0 rules

Read the verdict by the build that produced it:

What ran	What you may conclude
Audit from the public composition	only the checks that composition actually ships
Audit from the checkout build with the catalog	additionally the 16 named structural checks
Catalog unavailable (not_run)	the 16 checks did not run; no findings means nothing was looked for, not that nothing is wrong

The detectors live in the same named catalog as the six structural questions. Listing them requires a source checkout (I: query is absent from the public composition). This transcript is real; the catalog descriptions are stored in Russian (English gloss after the output):

console

$ ./law query --list
achievement-open-window — Обязанность достижения с открытым окном никогда не получает VIOLATED.
aggregate-head-without-key — Голова правила заполняется агрегатом, а отношение не объявляет key §45.1 — поданное делом сводное и пересчитанное значение истинны разом (DECISION-0105).
anchored-relation-without-executable — Выводимое отношение заякорено на фрагмент, на который не заякорен ни один выводящий узел — статья ANCHORED вместо EXECUTABLE в мере §33.1, право выражено, а мера этого не видит.
...
$ ./law query --list | wc -l
      22

In English, the three lines shown say: an achievement duty with an open window never becomes VIOLATED; a rule head is filled by an aggregate while its relation declares no key, so a case-supplied total and a recomputed one are both true at once; a derived relation is anchored on a fragment that no deriving node is anchored on, so the article counts as ANCHORED instead of EXECUTABLE in the measure.

Twenty-two entries: sixteen lints plus six named questions (producers, readers, anchors-of, imports-of, links-of, type-step). Each lint names one suspicious shape — a dangling reference, a priority edge with nothing to decide, a defeasible head read from across a package boundary — and each finding is either accepted with a reason or carried as debt, as the accepted 1, debt 11 split in the coverage report shows.

Review records per corpus

Some corpora keep their own review records as team convention, enforced by dedicated full-profile checks (G):

• a clause-review registry tracks which clauses were reviewed, which still need review, and which were explicitly allowed to stay unreviewed for now;
• a constitution review record tracks the review state of the constitutional text;
• text and classification checks cover the scriptural corpora that need them.

The pattern is the same everywhere: the record is data beside the package, the check compares the record against the package, and any row the record cannot explain fails the run.

Reproduction details

Toolchain, hashes, and full transcripts

Commands on this page were run against law 0.1.1, semantics law.core/0.2, standard library 0.2.0 (full law version blocks under Reproduction details on the pinning page).

Further reading

• LawQL reference
• A real article: source and anchor
• Sources: source, edition, publication, fragment
• Sources and text