The analysis

06 — What is still unverified, and the method

Scope: the verification chain drawn end to end, the revision this package documents, the largest hole in the chain, the licence terms that were quoted rather than read, the complete NOT VERIFIED register, the term table, and the method by which this package was produced.

Source root: as 01-premise-and-reaim.md §0.

1. The verification chain, drawn

  Magieva monorepo (private)
  internal/contentstudio/cinematography*.go
            │
            │  ◄── LINK 1: NOT AUDITED
            │      A temporary Go harness was compiled inside the module and run.
            │      Its output was captured to verification/go-reference-dump.json.
            │      The harness source is preserved. It was never re-run by anyone
            │      outside the Magieva checkout, and the checkout is not in this package.
            ▼
  verification/go-reference-dump.json          (3,003 lines, frozen)
            │
            │  ◄── LINK 2: MECHANICALLY CHECKED
            │      python verification/differential_check.py → 289 checks, 0 disagreements
            │      Tolerance 1e-6. Reproduced by this package.
            ▼
  app/cinematographer/*.py                     (1,342 lines, pure stdlib)
            │
            ├─── LINK 3a: MECHANICALLY CHECKED
            │    app/tests/ → 69 tests, hand-computed expectations
            │    Reproduced by this package.
            │
            │  ◄── LINK 3b: MECHANICALLY CHECKED
            │      python app/web/parity_check.py → 28 fixtures, 0 mismatches
            │      Three-way: JS↔fixtures, Python↔fixtures, Python↔JS live.
            │      sha256 staleness guard over the six engine modules.
            │      Reproduced by this package.
            ▼
  app/web/cinematographer.js                   (843 lines, JS mirror)
            │
            │  ◄── LINK 4: NOT CHECKED
            │      The panel renders these numbers. No browser test asserts that
            │      what is on screen equals what the engine computed.
            ▼
  app/web/index.html + app.js                  (the director's panel)

  ─────────────────────────────────────────────────────────────────────────

  app/workflows/*.json                         (2 graphs, 60 nodes, 82 links)
            │
            │  ◄── LINK 5: STRUCTURALLY CHECKED ONLY
            │      python app/workflows/validate_graphs.py → PASS both
            │      Checks: JSON parses, class_type present, slot counts, links
            │      resolve, acyclic, reachable from SaveVideo.
            │      Does NOT check: that ComfyUI accepts the prompt, that the
            │      node packs and weights are installed, that it runs, or that
            │      it produces a clip.
            ▼
  ComfyUI                                      ◄── NEVER EXECUTED

  ─────────────────────────────────────────────────────────────────────────

  app/cinematographer/nodes.py                 (698 lines, 6 nodes)
            │
            │  ◄── LINK 6: BROKEN, THEN PARTIALLY FIXED
            │      ComfyUI's loader requires <pack_root>/__init__.py and does not
            │      recurse. The documented clone puts the pack root at the repo
            │      root, which has no __init__.py. A shim now exists at
            │      app/__init__.py; the documented path is still broken.
            ▼
  ComfyUI custom_nodes/                        ◄── NEVER LOADED

Two links are mechanically checked end to end. Four are not.

2. The revision this package documents

The entry is not a git checkout (git status → fatal: not a git repository). Revision pinning was therefore done by sha256 manifest.

2.1 The manifest

A manifest over the 44 source files (.py, .js, .mjs, .json, .md, .html, .css, .toml, .txt, LICENSE), excluding __pycache__ and .pytest_cache:

$ find . -type f \( -name '*.py' -o -name '*.js' -o -name '*.mjs' -o -name '*.json' \
    -o -name '*.md' -o -name '*.html' -o -name '*.css' -o -name '*.toml' -o -name '*.txt' \
    -o -name 'LICENSE' \) -not -path '*/.pytest_cache/*' -not -path '*__pycache__*' \
  | sort | xargs shasum -a 256 > /tmp/cine-manifest.txt
$ wc -l < /tmp/cine-manifest.txt
44
$ shasum -a 256 /tmp/cine-manifest.txt
58d27eab06da1631333d6d5793de6205ca29c6bde3e15a340512d770dafe133c  /tmp/cine-manifest.txt

Manifest hash: 58d27eab06da1631333d6d5793de6205ca29c6bde3e15a340512d770dafe133c (44 files, observed 2026-10-29 17:38 PT)

2.2 The engine hash

The parity fixtures record their own hash over the six engine modules, constructed as sha256(Σ name ‖ \0 ‖ content ‖ \0) (app/web/parity_check.py:223-237):

engine_hash_sha256 = 24621deb23c66c8ffb501b97e8350f1d67c93c39626f8936a1805fcd1d67bd93

— app/web/parity_fixtures.json meta.engine_hash_sha256

The parity check recomputes it and reports "matches live engine" (parity_check.py:260-262), so the fixtures are not stale.

A second, independent aggregate over the same six modules:

$ find app/cinematographer -name '*.py' -not -path '*__pycache__*' | sort | xargs shasum -a 256 | shasum -a 256
cf24e2ba1eeadfd9e7b317fafc2c114710865c91f67b806e2d55fe337fb523fe  -

Engine aggregate: cf24e2ba1eeadfd9e7b317fafc2c114710865c91f67b806e2d55fe337fb523fe

Per-module:

2.3 The concurrency caveat

The source tree was being edited by another lane while this package was written. Three files changed during the writing of 05-adversarial-review.md:

The engine modules did not change (the aggregate hash is stable), so every claim in this package about engine behaviour is pinned. Every claim about the three edited files is timestamped in 05-adversarial-review.md §10.

A reader re-running the manifest will get a different hash if further edits have landed. That is expected; the manifest's purpose is to say what was read, not to freeze the tree.

3. The largest hole: the Go dump's provenance

The adversarial review named it, and it is the single most important caveat in this package:

"No Magieva Go checkout. I could not re-run go-harness/zz-cine-dump.go. I verified the Python side against the frozen go-reference-dump.json only. The dump's own provenance is unverifiable from here — if it were fabricated or stale, none of my claim-A work would detect it. This is the single largest hole in the verification chain, and it is inherent to the setup." — verification/ADVERSARIAL-REVIEW.md:673-676

3.1 What this means precisely

The entry's strongest claim is:

"289 differential checks, zero disagreements — the Python port reproduces the original Go cinematography implementation." — verification/README.md:15

Stated precisely, the evidence supports:

The Python port agrees with verification/go-reference-dump.json on 289 comparisons.

The step from there to "agrees with the Go implementation" requires a fact this package cannot establish: that the JSON was produced by the Go code it claims to have been produced by.

3.2 What makes it auditable but not audited

The harness source is preserved at verification/go-harness/zz-cine-dump.go, and the README gives the exact reproduction commands:

# verification/README.md:26-32
cp verification/go-harness/zz-cine-dump.go cmd/zz-cine-dump/main.go
GOWORK=off go run ./cmd/zz-cine-dump > /tmp/go-cine-dump.json
rm -rf cmd/zz-cine-dump
python verification/differential_check.py /tmp/go-cine-dump.json

So the claim is auditable: anyone with the Magieva checkout can re-run it in about a minute. It was not audited, because the checkout is not in this package and the reviewer did not have it.

3.3 The three ways the dump could be wrong

The third is the subtle one. A harness that called the Go functions with the port's own defaults would produce a dump that the port trivially matches. Nothing in the package rules this out.

3.4 What would close it

1. Re-run the harness in the Magieva checkout and diff the output against the frozen dump. If they match byte-for-byte, link 1 is closed.
2. Record the Go source revision (commit sha) alongside the dump.
3. Record the harness's own sha256 in the dump's metadata.

None of the three was done.

4. The licence terms were quoted, not read

The licence argument in 02-licence-trap.md is the entry's second-strongest claim after the differential check. The review did not verify it:

"I did not read the LTX-2.x Community licence, the Wan 2.2 licence, or the MoGe-2 licence to confirm the revenue caps and territory exclusions quoted in the README." — verification/ADVERSARIAL-REVIEW.md §13 (What I could not verify)

What was verified is narrower and different:

"F — Licence-clean / no trademark — CONFIRMED. No Higgsfield in filenames or app strings; no MiniMax H3, no closed API, no partner nodes, no network calls in the engine." — verification/ADVERSARIAL-REVIEW.md:38

4.1 The distinction

The licence reasoning is in 02-licence-trap.md, which cites the recon's inventory. The recon read the licence texts; this package did not, and the review did not.

4.2 Why the distinction matters here

The entry's licence position is "we chose Wan 2.2 because it is Apache-2.0 with zero caveats." That is a claim about a licence text. If the text says something else, the entry's central open-weights argument weakens.

The practical consequence is small — the entry ships no weights and no model code, so it is not distributing anything under those licences. But the argument is load-bearing for the "open-weights-only" property, and the argument rests on quotes.

5. The complete NOT VERIFIED register

Consolidated from verification/README.md:117-126, 03-SUBMISSION.md, the workflow _READMEs, and the adversarial review's §13.

5.1 Never executed

5.2 Never measured

5.3 Never checked

5.4 Never obtained

5.5 Never read

6. The term table

The terms used throughout this package, defined for this subject.

The two inapplicable terms are stated rather than dropped, because their absence is itself the finding: this entry has no live surface. Every claim about it is a claim about source code, a harness, or a JSON file. Nothing was observed running.

6.1 The term distribution

Zero measured claims. That is the honest headline of this package, and it is why the entry's own honesty ledger (03-SUBMISSION.md:133-145) is the right artefact to lead with.

7. The method

7.1 How this package was produced

7.2 The rules this package followed

7.3 What this package did not do

7.4 The one thing this package added that the entry did not have

Three findings, each surfaced by re-deriving rather than re-reading:

1. The gating-rule arithmetic (03 §6.4). Only four rules can ever fail a frame, and headroom — the demo's headline example — gates only in a close-up. The demo shows a rule-level FAIL that does not change the frame's verdict.
2. The 289 decomposition (04 §3.3). 243 of the 289 are per-rule field comparisons; 46 are whole-object or invariant checks. The units are not homogeneous.
3. The rule-surface vs gating-rule distinction (03 §6.5). Of 14 rules, 4 never fail and 8 more cannot fail the frame in at least one shot type. "14 rules" is the right number for the rule surface and the wrong number for the rules that can fail a frame.

All three are arithmetic consequences of constants the entry already published. None required running anything.

8. The timeline

Reconstructed from file mtimes and the documents' own statements.

The gap between the review landing and the deadline is roughly 15 hours. The CRITICAL defect was still open at the snapshot.

9. What a reader should do to close the gaps

In priority order, with effort estimates.

Items 1 and 2 are the two that matter. Item 1 is the difference between an installable pack and an empty category. Item 2 is the difference between a verification story that survives a curious judge and one that does not.

10. Evidence index for this file