Verify by DSEO Marketing
EN ES
Terminal

For the technical user: structured results, offline.

A small local CLI. No global install, no account, no network call. Two commands look similar and are not: `demo` reads a stored answer, `kernel-evaluate` runs the kernel now. Every response says which one happened.

Recorded or live — never blurred

demo
RECORDED_REPLAY · kernel_invoked: false · works without the snapshot
kernel-evaluate
LIVE_REFERENCE_KERNEL · kernel_invoked: true · fails closed if the kernel is unavailable

Exit codes: 0 the record was interpretable · 2 not interpretable, or the request was refused · 3 the kernel identity chain failed · 1 usage error. Exit 0 does not mean the assessment was favourable — read security_assessment_status.

Implementedworks today, local, offline
01 Install

No global install

# 1. the CLI itself has no runtime dependencies
      node cli/bin/verify.mjs --help
      node cli/bin/verify.mjs demo --scenario VALID      # works right away

      # 2. live evaluation additionally needs the Master Front NextGen source,
      #    which this release deliberately does not redistribute. Supply your
      #    authorised copy once:
      python3 scripts/init_snapshot.py --zip path/to/DSEO-MASTER-FRONT-NEXTGEN.zip

      # 3. confirm what your environment can actually do
      node cli/bin/verify.mjs doctor
      node cli/bin/verify.mjs kernel-evaluate --scenario VALID

Nothing is fetched from the network at any point. The initialiser checks both digests before extracting, refuses unsafe archive members, never executes anything from the archive, and is idempotent on a snapshot that is already correct.

02 Commands

verify hash <file>

Real SHA-256 of a real file on your machine.

$ verify hash ./release.tar.gz
      {
  "file": "./release.tar.gz",
  "bytes": 40412,
  "sha256": "9f2c…a41b"
}

verify inspect <file>

Hash plus basic structural facts about the file.

$ verify inspect ./bundle.json
      {
  "file": "./bundle.json",
  "bytes": 1822,
  "sha256": "4a01…9e3f",
  "json_parses": true
}

verify kernel-evaluate --scenario <id>

RUNS the kernel now, on that scenario’s versioned inputs. If the kernel is unavailable this fails — it never falls back to a recording.

$ verify kernel-evaluate --scenario TAMPERED_ARTIFACT --json
      {
  "envelope": {
    "execution_mode": "LIVE_REFERENCE_KERNEL",
    "kernel_invoked": true,
    "candidate_sha256": "55187fd8…",
    "input_bundle_digest": "…",
    "snapshot_membership_unchanged": true
  },
  "result": {
    "record_valid": false,
    "security_assessment_status": "NO_CONSTA",
    "release_authority": false,
    "errors": [{ "code": "BUNDLE_PIN_MISMATCH", "...": "..." }]
  }
}

verify demo --scenario <id>

READS a recorded answer. No kernel runs. Works with no snapshot installed, and says so on every line of output.

$ verify demo --scenario STALE_EVIDENCE
      === RECORDED_REPLAY — this is a stored answer, not a measurement ===
execution_mode: RECORDED_REPLAY   kernel_invoked: false
scenario: STALE_EVIDENCE
recorded_fixture_digest: 0aa98a6a…

record_valid: true
security_assessment_status: NO_CONSTA
release_authority: false

To evaluate this now instead of reading it back:
  verify kernel-evaluate --scenario STALE_EVIDENCE

verify explain <result.json>

Turns any structured Verify result into a plain-language paragraph.

$ verify explain ./result.json
      record_valid=true, security_assessment_status=FAIL.
This record is well formed and interpretable. Its answer is
unfavourable. release_authority is false, as it always is: this
result is not permission to act.

verify doctor

Checks your local environment: Node version, whether the AC7 snapshot is present and byte-matches.

$ verify doctor
      node: v24.18.0 (ok)
AC7 snapshot: present
AC7 content_root: matches pinned value
kernel import: ok
03 The kernel adapter

What kernel-evaluate actually does

Runs the actual Master Front NextGen reference assurance kernel over a bundle on your machine. Before importing anything it walks a single integrity chain — upstream archive digest, accredited manifest, the metrics file proven to be a manifest member, three-way digest agreement on every core file, exact membership — and refuses to run if any link breaks.

04 The mechanism

What happens when you run an evaluation.

How this works

  1. 01

    The adapter re-derives the core’s identity

    Before importing anything it re-hashes every file of the deciding core and checks each one against the accredited manifest, the archive digest and the pinned content root — 43 links in one chain.

  2. 02

    It refuses, or it imports

    If a single byte differs, or an unaccredited file is present, nothing runs. There is no repair step and no partial mode.

  3. 03

    Your record and pins are parsed strictly

    Duplicate keys, floats and non-finite values are rejected by the contract’s own parser, not quietly accepted the way ordinary JSON parsing would.

  4. 04

    The core evaluates and returns an envelope

    You get the result plus execution_mode, kernel_invoked, the digest of the input consumed, and whether the snapshot changed during the run.

05 Step by step

Your first five commands.

Step by step

Five commands, in order. The first three work before anything is prepared; the last two need the engine.

  1. Open a terminal in the product folder and type: node cli/bin/verify.mjs --help

    You will see a list of commands, with recorded and live ones described separately.

    That means the CLI is working. Nothing has been installed and nothing has contacted the network.

  2. Type: node cli/bin/verify.mjs demo --scenario VALID

    You will see a block beginning "RECORDED_REPLAY — this is a stored answer, not a measurement".

    That means you are reading an answer recorded earlier. Useful to learn from, but it did not just happen.

  3. Prepare the engine once: python3 scripts/init_snapshot.py

    You will see two digests printed, then "snapshot ready".

    That means the source it needs was already inside this folder. Nothing was downloaded.

  4. Now type: node cli/bin/verify.mjs kernel-evaluate --scenario VALID

    You will see a block beginning "execution_mode: LIVE_REFERENCE_KERNEL".

    That means this one ran just now, on your machine. Compare the first line with step B and you can always tell the two apart.

  5. Read the line that says release_authority.

    You will see false — on every result, including the favourable ones.

    That means the engine never grants permission to act. Whatever decides to ship, deploy or approve is a separate thing, and that is on purpose.

If it does not work If a command ends with "NEEDS_SOURCE", the engine is not prepared yet — run step C. If it ends with "INTEGRITY_FAIL", something in the copy was altered, and it refuses to run rather than guess. Neither is a crash; both print a code that says what to do.