Code review

Scope and evidence

State the target, revision, question, and review procedure. A complete script review needs the full script and its associated experiment record, including the current design and any relevant requirements. To assess a claim about an output, include the referenced data, artifacts, or provenance records. A diff review also needs its base and surrounding code: defects introduced by a change can depend on code the patch did not touch.

Evidence should be pinned to the version under review. If a needed file, record, or source is absent, the reviewer can mark the question unresolved rather than infer its contents. A code review pass evaluates the supplied evidence and does not establish that the program ran in a target environment or that an instrument responds sensitively.

Code-review procedures

The registry distinguishes these procedures by what they ask the reviewer to judge. Their names are identifiers, not interchangeable labels for one generic code review.

• review-script, whole-script review. Cold-read the complete experiment script against its experiment record. The registered scope includes design conformance, logic and statistics, artifact and reporting completeness, and provenance. This is the appropriate full-artifact question for a script, rather than a judgment about just its recent edit.
• scan-script-delta, script delta review. Judge what an edit does to a script that was previously reviewed in full. The attestation memo names that earlier reading. It covers the change against that basis, not the untouched script anew, and another delta cannot become the full-review basis. Despite the word “scan,” the registry classifies this as an audit: a clean change is a zero-finding audit outcome.
• audit-code, code audit. This is a distinct registered audit procedure for code. The registry does not define it as a substitute for reviewing an experiment script against its record. Specify the code target and the audit question so its scope is clear.
• review-change, change review. Review a grounded diff together with surrounding code. The question concerns the change, while context can reveal defects in unchanged code that the patch interacts with. This is a change-target procedure, not the script-delta procedure measured against a named full-script attestation.

A procedure is not a trigger or lifecycle position. The same procedure may be requested at different points; a trigger may bind one or more procedures. The general review guide covers independent reviewers, findings, review records, and gates.

Review lenses and fault families

A review lens is a perspective applied within a procedure, such as checking statistical reasoning, provenance, or whether an output corresponds to its claimed inputs. A lens does not define a separate registered procedure. Fault classes describe observed problems and can cross lenses: the procedure determines the scope, the lens focuses scrutiny, and the fault states what failed.

Examples of implementation faults include:

• Calculation or decision-rule mismatch: code computes a different quantity from the one specified, skips a registered condition, or treats an empty category as a pass.
• Failure reported as a result: a missing prerequisite fails open, a stale artifact is reused, or a terminated run is presented as partial success.
• Wrong or unverified inputs and outputs: analysis reads the wrong corpus, checkpoint, or artifact, or a summary repeats stored values without checking them.
• Insufficient checks: a test agrees with the implementation by construction, or a self-test bypasses the actual scoring path.

A script that tests only the average when the record requires every seed to pass has an implementation fault. If the record's rule itself cannot answer the scientific question, that is a design concern, even if a code reviewer discovers it. The Design review guide addresses that question. Which check can detect a fault, and whether a targeted run or human decision is needed, depends on the specific evidence and fault.

Fault examples are an interpretive grouping from Review fault typology: what design and script reviews find (October 8, 2026), a report covering four project ledgers. They are not an exhaustive taxonomy or measured detection rates.

Findings do not grant authority

A review can report findings, evidence, unresolved questions, and a verdict for the stated scope. A review request defaults to reporting; remediation must be separately requested and authorized. Closing a finding as repaired requires evidence that the repair landed and an independent review of the changed target. Logging and gate practices are covered in the general review guide.

An advisory review-script can inspect code without an experiment record or passing design review, but its receipt must say that design conformance was not assessed. Advisory findings do not authorize launch or completion. The repair workflow and a transition-authorizing policy require current passing design coverage as a prerequisite to script review. That coverage comes from full design review or a chosen design-delta review with a passing full review for the same record as its basis.

Neither a pass nor a reviewer's recommendation authorizes execution, spending, or a pilot. Runtime compatibility and instrument validity require execution evidence, including a positive control for instrument validity. Such a run needs its own authority and bounded scope.

Code review in the autonomous workflow

The autonomous code workflow coordinates evidence, independent review, repair, fresh review, and handoffs under a mandate. It separates review permission from permission to edit or execute, and sends scientific choices back for human judgment. Use it when delegated review and repair need those controls; the procedure taxonomy above also applies to ordinary advisory review.