PMU Visa of Competence — Cross-Lattice Interlock Protocol

1. The compatibility check — when two lattices CAN compose

Two lattices A and B are compatible iff:

1. Same canonical axes at every depth. The 12 length-1/2 axes (A,B,C,A1,A2,A3,B1,B2,B3,C1,C2,C3) are non-negotiable — they're the patent v20 §16 ShortLex backbone. Any deeper expansion (depth 3+) uses the position-parity rule: length-N axes match by canonical ID, not by per-problem-space label.
2. Same address-shape branching factor at every depth. Both lattices use the demo-default 3 letters / 3 digits, OR both use the same alternative branching factor (architecture supports arbitrary).
3. Optional but desirable: each lattice publishes its per-axis mass (gzip-compressed bytes of axis tile dump). The match score can be mass-weighted; without mass, fall back to uniform-weight hamming.

2. Lit-cell pattern — what a worker publishes

A worker (agent or human) runs the decomposition pipeline on their own corpus (resume, portfolio, work history). The output is a 144-cell binary pattern: which cells are COMPETENT (lit) given their intent (what they offer) vs reality (what they've demonstrably done).

{
  "lattice_fingerprint": "sha256 of canonical axes + branching factor",
  "publisher": "did:agent:0xA1B2…",
  "issued_at": "2026-05-24T22:00:00Z",
  "lit_cells": {
    "A1:A1": 1, "A1:B2": 1, "B2:B2": 1, "B2:C3": 1, …
  },
  "per_cell_mass": {
    "A1:A1": 8242,  // gzip-bytes of the cell's intent text
    …
  },
  "signature": "ECDSA signature over lit_cells + per_cell_mass"
}

3. Needed-cell pattern — what a job publishes

A job posting (or any task) decomposes the same way. The output is a needed-cell pattern with an explicit threshold per cell: "the worker MUST have this cell lit" (hard) vs "it would help" (soft), and a global tolerance radius.

{
  "lattice_fingerprint": "must match worker's fingerprint",
  "issuer": "did:org:0xC3D4…",
  "issued_at": "2026-05-24T22:00:00Z",
  "needed_cells": {
    "A1:A1": "hard",    // must be lit
    "A1:B2": "hard",
    "B2:B2": "soft",    // adds match score but not gating
    "B2:C3": "soft",
    "C3:C3": "soft"
  },
  "tolerance_radius": 0.20,  // see Goldilocks section below
  "signature": "ECDSA signature over needed_cells + tolerance"
}

4. The Goldilocks question — answered explicitly

The user flagged this as the "one hidden trap": "If a job requires 15 specific cells to be lit, does the worker need a 100% bitwise match, or is an 80% overlap sufficient for a Visa?"

4.1 Hard cells — exact lock, no tolerance

Every cell marked "hard" in needed_cells MUST be lit on the worker's pattern. Zero tolerance. If any hard cell is unlit, the match returns { visa: false, reason: "hard cell unlit", missing: ["A1:A1"] } regardless of how high the soft score is.

4.2 Soft cells — mass-weighted overlap, tolerance radius

For cells marked "soft", the match score is the mass-weighted fraction of soft cells that are lit on the worker's pattern:

soft_score = Σ (worker_lit[c] · max(worker_mass[c], 1))  for c in soft cells
              ─────────────────────────────────────────
             Σ max(needed_mass[c], 1)                    for c in soft cells

The worker passes iff (1 - soft_score) ≤ tolerance_radius. A tolerance_radius of 0.00 demands 100% overlap; 0.20 allows up to 20% missing weight; 0.50 allows half.

4.3 Why mass-weighted, not bit-counted

A cell with 8 KiB of gzip-compressed mass carries more semantic payload than one with 800 bytes. A worker missing the 800-byte cell is a lighter miss than missing the 8 KiB one. Mass-weighted overlap prices the semantic loss proportionally — same principle as risk-weighted assets in the underwriter spec.

4.4 Issuer-set, not protocol-set

Both the hard/soft labels AND the tolerance_radius are set by the issuer, not by the protocol. The bridge does not enforce a fixed threshold; different jobs in different markets pick different tolerances. The Goldilocks zone is the issuer's calibration, not the spec's prescription.

5. The match function — one constant-time call

function matchVisa(worker_pattern, job_pattern):
  if worker_pattern.lattice_fingerprint != job_pattern.lattice_fingerprint:
    return { visa: false, reason: "incompatible lattice" }

  for c in job_pattern.needed_cells where label == "hard":
    if not worker_pattern.lit_cells[c]:
      return { visa: false, reason: "hard cell unlit", missing: [c] }

  soft_cells   = [c for c in job_pattern.needed_cells where label == "soft"]
  weighted_hit = Σ (lit_cells[c] · max(per_cell_mass[c], 1)) for c in soft_cells
  weighted_max = Σ max(per_cell_mass[c], 1)                   for c in soft_cells
  soft_score   = weighted_hit / weighted_max  (or 1 if soft_cells empty)

  if (1 - soft_score) > job_pattern.tolerance_radius:
    return { visa: false, reason: "soft tolerance exceeded",
             soft_score, tolerance: job_pattern.tolerance_radius }

  return { visa: true, soft_score, hard_passed: true }

Constant-time per (worker, job) pair: O(|needed_cells|), bounded by 144 at depth 2, by 9N² at recursive depth N. AC⁰ on the verifier because there is no model, no nearest-neighbor search, no embedding distance — just bit lookup + multiply-accumulate.

6. Cloud bridge state ≡ local lattice state

The user's load-bearing question: "how to compare the cloud map state to the local map state?" Answer: they ARE the same state.

• Local lattice: a 144-cell binary array on the deployer's chip, produced by decompose.mjs.
• Cloud lattice: the SAME 144-cell binary array transmitted via bridge-receive.mjs to the cloud.
• The bridge does not RE-DERIVE the lattice. It RECEIVES the already-derived array + the canonical-fingerprint + the signature.
• Equality check is byte-equality on the lit_cells map + fingerprint verification + signature verification. No SimHash recomputation needed; that already happened locally.

7. Iteration risk assessment

The user asked: "is this going to work… without many iterations?" Honest scorecard:

8. What this spec doesn't cover (yet)

• Revocation. If a worker's lit_cells go DRIFT in a later re-derive (their corpus changed), the old signature is still valid for the old pattern. Need a sliding-window CRL or freshness deadline per signature. Iterate post-funding.
• Multi-lattice workers. A worker might publish lit-patterns for both EU-AI-Act-insurability AND US-AI-EO. The visa decision per job is per-lattice, but a marketplace can prefer workers with patterns in multiple compatible spaces.
• Asymmetry pricing. The asymmetryGrid (Option E) measures whether direction matters per cell. Future: jobs could require not just lit-cell match but also low-asymmetry on key cells (direction-locked competence).