Cejel

cejel

Evidence about a repository that anyone can rerun. Cejel reads a repository's own evidence (tests that really assert something, committed secrets, CI gating) and writes a certificate pinned to one commit. Whoever receives it, a customer, a buyer or an acquirer, can run the same Cejel version on the same commit themselves, offline, and get the same result. No LLM, no signup.

Add it to a workflow; the result is posted to the job summary:

on: [pull_request]

jobs: cejel: runs-on: ubuntu-latest steps:

• uses: actions/checkout@v4 with: fetch-depth: 0 # full history: A2 and B2 read commit history
• uses: BargLabs/cejel/action@v1

Keep fetch-depth: 0. actions/checkout makes a shallow clone by default, and a shallow clone is "Unrated: shallow clone", with no score and no verdict, under every rubric, the default included, until the full history is checked out. A directory with no .git (an uploaded snapshot or an archive) is "Unrated: no git history" under every rubric.

Or run it once from a shell: npx @cejel/cejel@latest . More on the Action under GitHub Action. To read what comes out, see Reading the result.

Cejel (*"SEH-jel"*) — a trust certificate for your codebase.

Free, offline, no-signup CLI that scores the engineering signals that tell you whether to trust a repo — tests, secrets, isolation, claim-vs-reality, CI/audit discipline — and prints a trust certificate + badge. Especially valuable when AI wrote a lot of the code: that's exactly when you can't eyeball trust. Built on a deterministic, no-LLM scoring core — the free path makes zero network calls and requires no account.

Claim boundary: Cejel scores engineering-trust signals; it does not claim to detect software defects or prove that code is safe. Defect and vulnerability scanners remain evidence producers that Cejel can aggregate into a trust certificate.

Cejel is not another point scanner competing with the one you already run — it's the open, portable, offline trust certificate that aggregates them. Pipe in SARIF-compatible output (MunaTrust, Snyk, Semgrep, CodeQL, Codex) plus OpenSSF Scorecard, and get one shareable certificate + badge over all of them. See "Aggregate your scanners" below.

Cejel is used on Barg Labs’ own code. The public board

labels publisher-owned snapshots separately from the ranked public repositories.

Rubric calibration policy

The public CLI default is witan-rubric-v17-2026-07-24, the last rubric to clear Cejel's preregistered 200-repository untouched holdout. Published calibration figures apply only to that exact rubric and frozen evaluation population. Later rubrics—including the current v18 through v23 prospective series—are available only to explicit evaluation harnesses. Prospective rubrics inherit none of v17's calibration figures; a bounded paired repair or corpus-delta result can validate its stated construction without transferring precision, recall, or false-positive-rate claims. Promoting a prospective rubric to the public default requires a fresh authenticated untouched holdout, every preregistered gate to pass, and a separately recorded promotion decision.

Measured recall (bounded)

Measured recall (bounded). Cejel publishes one cohort-level in-scope detection-recall

figure, for the prospective v22 rubric, in docs/calibration/v22-detection-recall/; no general

figure exists, and the three quantities called recall are set side by side on

cejel.dev/methodology. On a frozen,

preregistered, in-scope held-out fixture set of 30 named defects, the released public default

(v17, tree a857f0b3) cited 16/30, two-sided 95% Wilson interval [36.1%, 69.8%]; the

prospective v22 detector (commit 8a289ea, tree 10960a03) cited 24/30, two-sided 95%

Wilson interval [62.7%, 90.5%]. Same fixtures, same partition, same controls in both runs.

v22 is prospective and not the shipped default. Full preregistrations and results:

docs/experiments/in-scope-detection-recall-v3-result-2026-08-09.md and

docs/experiments/in-scope-detection-recall-v4-result-2026-08-11.md.

The defect-class census publishes the coverage-breadth boundary—which defect classes any shipped rule targets—and is explicitly not a recall claim.

Reading the result

The first page of certificate.html (and the block printed after the verdict in the terminal) answers four questions in plain words, built only from report.json:

• What holds: the measured areas the report labels Verified, or Info (one label below, listed as "Partly holds"), each with its score out of 4 and the strongest measurement it saw, for example "Rated Verified, at 1.0 out of 4". Only a score of 4.0 is called the top score. A label and a score are set separately, so a Verified area can have a low score; each area's card in the certificate compares the two. An area Cejel did not examine, or examined with no measurement, is never listed here. When the list is empty, one sentence says why: no overall result, no area labelled Verified or Info, or both.
• What is wrong: every critical and warning-level finding, most serious first, naming the file or area and what is wrong, and every area labelled Critical or Warning that has no critical or warning finding of its own, with its score ("Scored 2.2 out of 4, with no single finding of its own"). A score made up of several measurements is given with its number and level, for example "give 3.1 out of 4, which Cejel counts as a warning".
• What is not known: what the report records it could not establish, from these fields: an overall result it withheld, with its reason restated from a fixed table (a reason the table does not know reads "Cejel could not rate the source here; see the certificate below"); areas that do not apply, have no measurement, or have no score while a finding stands; areas Cejel could not fully read (named in the report's skipped-content summary or by a scan or history limitation), listed as "not read" with the cause the report ties to that area: files that could not be read, Git LFS pointers, files left out under Cejel's size limit or rules, a scan limitation, or a shallow clone; each scan and history limitation, reworded into plain words; files it did not read; a label moved by imported evidence; and each limit a check recorded on what it examined. Anything the report does not record is not listed, so an empty list does not mean nothing is unknown.
• What to check next: one line for each wrong or not-known item, taken from a fixed table of reviewed sentences. The line for an area not read, and for a scan limitation, follows its own cause: git lfs pull for Git LFS pointers, making files readable only where they could not be read, and no fix for a size limit or rule. An item with no table entry points to the section of the certificate that holds it.

The first page also says what the result does not cover: Cejel reads files and history and does not run the code or its tests. Under a prospective rubric such as witan-rubric-v27-prospective-2026-10-19, the first page opens, above the verdict line, with the same notice the certificate's header carries: the rubric is not calibrated, and its results carry no precision or recall claim. Every line links to its source further down; the certificate below the first page holds the evidence, unchanged apart from the anchors those links point to. summary.json carries the same lists under plainSummary.

Install

No account, no key, no signup.

Single-file binary. One file. No Node, no npm, no node_modules, nothing installed.

set -eu

asset="cejel-$(uname -s)-$(uname -m)" curl -fsSL "https://github.com/BargLabs/cejel/releases/latest/download/$asset" -o "$asset" curl -fsSL https://github.com/BargLabs/cejel/releases/latest/download/SHA256SUMS -o SHA256SUMS checksum_entry_count="$(awk -v asset="$asset" '$2 == asset { count++ } END { print count + 0 }' SHA256SUMS)" if [ "$checksum_entry_count" -ne 1 ]; then echo "Expected exactly one SHA256SUMS entry for $asset; found $checksum_entry_count" >&2 exit 1 fi if command -v sha256sum >/dev/null; then grep " $asset$" SHA256SUMS | sha256sum -c - else grep " $asset$" SHA256SUMS | shasum -a 256 -c - fi mv "$asset" cejel chmod +x cejel ./cejel .

Windows x86_64 (PowerShell).

$asset = "cejel-Windows-x86_64.exe"

Invoke-WebRequest "https://github.com/BargLabs/cejel/releases/latest/download/$asset" -OutFile $asset Invoke-WebRequest "https://github.com/BargLabs/cejel/releases/latest/download/SHA256SUMS" -OutFile SHA256SUMS $expected = ((Select-String -Path SHA256SUMS -Pattern " $([regex]::Escape($asset))$").Line -split "\s+")[0] $actual = (Get-FileHash -Algorithm SHA256 $asset).Hash.ToLowerInvariant() if (-not $expected -or $actual -ne $expected.ToLowerInvariant()) { throw "SHA-256 verification failed for $asset" } .\cejel-Windows-x86_64.exe .

Windows signing status: cejel-Windows-x86_64.exe is intentionally unsigned in

0.6.11 and may trigger Microsoft SmartScreen. The release build removes Node's inherited

signature before SEA injection and fails unless Windows reports the result as NotSigned;

it does not ship an invalid signature. Before running it, verify SHA256SUMS and the

GitHub build-provenance attestation. Each binary also has an attached SPDX SBOM (the packages

bundled into it, listed from the build, and the Node.js runtime it embeds; from the release after

0.6.0 it is attested to the binary) and an own-platform verification receipt covering --version, --help, a real scan,

source/binary parity, and a network-denied scan. If your policy requires Authenticode,

use the npm package or the OCI image until a human-approved signing path is available.

Don't take the offline claim on trust — check it. Turn your network off, then run the binary. It will score your repository and write you a certificate anyway. That is the whole product, and you can falsify it in ten seconds:

# with Wi-Fi off, or:

docker run --rm --network=none -v "$PWD:/w" -w /w -v "$PWD/cejel:/cejel:ro" debian:stable-slim /cejel .

npm.

npx @cejel/cejel@latest .

Distribution note: Cejel 0.6.11 is the coordinated release version for npm,

standalone binaries, Docker/OCI, GitHub Action, Homebrew, and MCP Registry. On GitLab, use the

CI/CD Catalog component gitlab.com/barglabs/cejel/cejel@0.6.11; it, the include template and

the Code Quality export are documented in docs/gitlab-ci.md.

npx can reuse a stale cached package. Force the current npm release with the @latest specifier above, and check the version that will run before comparing certificates:

npx @cejel/cejel@latest --version

If a root package.json still carries a template name, override only the certificate display name while keeping the repository-derived stable slug:

npx @cejel/cejel@latest . --name "Customer Portal"

From 0.4.5, use --product-name when two checkout directories must emit the same identity fields. The supplied value sets both the display name and its slugified stable ID:

npx @cejel/cejel@latest . --product-name "Customer Portal"

Product identity is caller context, not scored repository evidence, and is excluded from certificate byte-comparison claims.

The npm package is scoped as @cejel/cejel; its executable remains the short command cejel.

GitHub Action — s