docs← Back to article

Markdown for LLMs

Reviews, approvals, and records

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

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

```text
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

<details>
<summary>Toolchain, hashes, and full transcripts</summary>

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](/corpus/sources/pinning/#reproduction-details)).

</details>

## Further reading

- [LawQL reference](/lawql/)
- [A real article: source and anchor](/tutorials/real-article-source/)
- [Sources: source, edition, publication, fragment](/constructs/sources/)
- [Sources and text](/recipes/i-sources/)