Jev applies the subset criteria well — it never calls a sound dependency broken, and it finds 85% of the bad ones

{
  "state": {
    "product": "Blog or news website",
    "dependency": "Post uses Comment",
    "useful_subsets_shipped": [
      "A publishing-only build with no comment system",
      "A read-only archive mirror that shows posts and hides comments"
    ],
    "code": "// comment.ts  (B)\nexport class Comment {\n  constructor(private readonly author: string, private readonly body: string) {}\n}\n\n// post.ts  (A)\nimport { Comment } from './comment';\nexport class Post {\n  private comments: Comment[];\n  constructor(private readonly id: number, private content: string,\n              private readonly author: string, comments: Comment[]) {\n    this.comments = [...comments];\n  }\n  getComments(): Comment[] { return [...this.comments]; }\n  addComment(c: Comment): void { this.comments.push(c); }\n}",
    "notes": "`code` sketches only the parts of each module that matter for the dependency. Imports name the direction of use. Assume both modules are otherwise complete and correct."
  },
  "model": "jev-latest",
  "questions": {
    "verdict": {
      "type": "choice",
      "instructions": "`dependency` names one dependency in `code`: module A uses module B. Judge that dependency against Parnas' subset criteria. All four must hold: (1) A is essentially simpler because it uses B; (2) B is not substantially more complex because it may not use A; (3) a useful subset of the system contains B but not A; (4) no conceivably useful subset contains A but not B. `product` says what the system is, and `useful_subsets_shipped` lists real subsets when it is present. Name the single criterion that fails most clearly, or `sound` if all four hold. Judge only the named dependency; ignore unrelated faults in the code.",
      "criteria": {
        "sound": {
          "what": "All four criteria hold: B knows nothing of A, B is useful in subsets without A, A is genuinely simpler for using B, and A cannot work without B.",
          "not_for": "Code that merely looks clean; check each of the four criteria in turn."
        },
        "no_simplification": {
          "what": "Criterion 1 fails: using B does not make A essentially simpler. A translates in and out of B's shapes, repeats B's work, or bypasses B where it matters.",
          "not_for": "A that is genuinely shorter or clearer for the call, even if the call site is verbose.",
          "examples": [
            "A validates every field again by hand after calling the validator",
            "An interface with one implementation reached through a large options bag at the only call site"
          ]
        },
        "b_contorted": {
          "what": "Criterion 2 fails: B is substantially more complex because it is not allowed to call A. B carries a duplicate of A's knowledge, a mirrored copy of A's state, or a parameter bag that exists only to avoid the call.",
          "not_for": "B that is simply large on its own terms, with no duplication of A.",
          "examples": [
            "A parser carrying its own name resolver because layering forbids calling the resolver",
            "Two files holding the same table with a 'keep in sync' comment"
          ]
        },
        "b_not_reusable": {
          "what": "Criterion 3 fails: no useful subset ships B without A. B takes A's types, is keyed by A's identifiers, or branches on A's internal phases. A general name hides that B is a piece of A in another file.",
          "not_for": "B that happens to have one caller today but is written in terms of its own concepts.",
          "examples": [
            "A module named StringUtils exporting truncateForProductCard(p: Product)",
            "A message table keyed by one form's field ids"
          ]
        },
        "a_useful_without_b": {
          "what": "Criterion 4 fails: a useful subset contains A but not B, so the general module must not reference the specific one. The dependency points from general to specific and should be inverted or held by id.",
          "not_for": "A that genuinely cannot do its job without B.",
          "examples": [
            "Post holding a list of Comment when a publishing-only build has no comments",
            "Logger taking an HttpRequest when the batch importer logs and serves no HTTP"
          ]
        }
      }
    },
    "not_simpler": {
      "type": "noul",
      "instructions": "For the dependency named in `dependency`: Does using B fail to make A essentially simpler?",
      "criteria": {
        "true": "Yes, clearly: A is no simpler for using B is the situation here.",
        "false": "No: A is no simpler for using B does not apply to this dependency."
      }
    },
    "b_contorted": {
      "type": "noul",
      "instructions": "For the dependency named in `dependency`: Is B substantially more complex because it is not allowed to use A?",
      "criteria": {
        "true": "Yes, clearly: B is bloated by the ban on calling A is the situation here.",
        "false": "No: B is bloated by the ban on calling A does not apply to this dependency."
      }
    },
    "b_not_reusable": {
      "type": "noul",
      "instructions": "For the dependency named in `dependency`: Is there no useful subset of the system containing B but not A?",
      "criteria": {
        "true": "Yes, clearly: B ships nowhere without A is the situation here.",
        "false": "No: B ships nowhere without A does not apply to this dependency."
      }
    },
    "a_alone": {
      "type": "noul",
      "instructions": "For the dependency named in `dependency`: Is there a conceivably useful subset of the system containing A but not B?",
      "criteria": {
        "true": "Yes, clearly: a useful subset has A but not B is the situation here.",
        "false": "No: a useful subset has A but not B does not apply to this dependency."
      }
    }
  }
}

{
  "model": "jev-1.13.0",
  "answers": {
    "verdict": {
      "type": "choice",
      "choice": "a_useful_without_b",
      "confidence": 0.99,
      "probabilities": {
        "a_useful_without_b": 1.0,
        "b_contorted": 0.0,
        "b_not_reusable": 0.0,
        "no_simplification": 0.0,
        "sound": 0.0
      }
    },
    "not_simpler": {
      "type": "noul",
      "noul": 0.58
    },
    "b_contorted": {
      "type": "noul",
      "noul": 0.13
    },
    "b_not_reusable": {
      "type": "noul",
      "noul": 0.66
    },
    "a_alone": {
      "type": "noul",
      "noul": 0.94
    }
  },
  "usage": {
    "input_tokens": 1549,
    "output_tokens": 149
  }
}

Paired by case: both right 53, right only without the reference 0, right only with it 2, both wrong 5. Unlike the MIRO test, the flips here go one way.

The gain is concentrated in the blind condition (87 → 93%), where the model has to imagine the subsets itself and the reference supplies the worked examples. With the subsets listed, the reference changes nothing. Two flips on 60 pairs is weak evidence; treat the direction, not the size.

THE PARNAS SUBSET CRITERIA (David Parnas, "Designing Software for Ease of
Extension and Contraction", 1979).

A software system is not one program but a family of programs. Good structure is judged by
which useful subsets and extensions you can build without rewriting. That turns "should
module A use module B?" into four testable questions.

Say A uses B. The dependency is acceptable only when all four hold:

  1. SIMPLER  A is essentially simpler because it uses B.
  2. FREE     B is not substantially more complex because it is not allowed to use A.
  3. B ALONE  There is a useful subset of the system containing B but not A.
  4. NOT A ALONE  There is no conceivably useful subset containing A but not B.

The slogan: do not let the general depend on the specific. The general module is the one
that appears in more subsets.

WHEN CRITERION 1 FAILS (A is not simpler for using B)
  A translates in and out of B's shapes, re-does B's work, or bypasses B on the paths that
  matter. Examples: a service that maps 100 lines to and from a client and then calls raw
  HTTP for two of three outcomes; a handler that calls a schema validator and then
  re-validates every field by hand; an interface with exactly one implementation reached
  through a seven-field options bag at the only call site.

WHEN CRITERION 2 FAILS (B is contorted by the ban)
  The layering rule forbids B from calling A, so B grows a second copy of A's knowledge.
  Look for duplicated tables with "keep in sync" comments, a mirrored cache of another
  module's state, a parser carrying its own name resolver, a layout engine carrying its own
  font metrics. Removing the ban would delete most of B.

WHEN CRITERION 3 FAILS (B is not reusable)
  B exists only to serve A. Its parameters are A's view model, its keys are A's field ids,
  it branches on A's internal phases, it imports A's types. A general-sounding name
  (StringUtils, Geometry, CacheKeys, RetryPolicy) hides that no subset can ship B alone.
  B is a piece of A that moved to another file.

WHEN CRITERION 4 FAILS (A is useful without B)
  The general module references the specific one. A useful subset has A and no B at all.
  Examples: Post holding a list of Comment, when a publishing-only build has no comments;
  Money with a formatForInvoiceLine method, when payroll needs money and no invoices; Logger
  taking an HttpRequest, when the batch importer logs and serves no HTTP; Vector2 with a
  drawDebug(SpriteRenderer), when the headless physics build has no renderer. The fix is to
  invert the reference, hold an id instead of the object, or move the operation to the
  specific side.

SOUND DEPENDENCIES LOOK LIKE THIS
  InvoicePdf uses Money. HttpServer uses Router. SpellChecker uses Trie. Comment holds a
  PostId. In each case the depended-on module knows nothing of its caller, ships in subsets
  that have no caller, and saves the caller real work.

Judging: name the single criterion that fails most clearly. A dependency that satisfies all
four is sound even if the code has other faults.