| type | policy |
|---|---|
| scope | all dancinlab projects + future repos |
| principle | verify against REAL limits (math · physics · engineering), not self-imposed convenient numbers |
| ssot | sidecar/hooks/commons/LATTICE_POLICY.md (this file) — referenced by commons.tape g25 + g26 |
One line: a project's ceiling is set by real mathematical / physical / engineering limits, NOT by the n=6 lattice. The lattice is a tool, not a constraint. Verify against real limits.
| Usage | Verdict |
|---|---|
Native invariant — the project uses n=6 as an explicit design invariant (e.g. isa_n6, hexa1, npu_n6) |
Valid — lattice is core to the spec |
| Self-imposed ceiling — the project uses "must be n=6-compatible" as a constraint | Invalid — artificial bottleneck |
Self-imposed-ceiling anti-patterns (all dishonest):
- "this analysis fits n=6, therefore correct" → fit-to-convenient-number
- "the capacity limit is J₂=24" → arithmetic disguised as physical limit
- "data satisfies σ·φ=24, therefore PASS" → tautology (always passes → zero verification power)
- "external entity X also follows n=6 (χ² test)" → over-claim
Shannon entropy H = −Σ p log p · Kolmogorov complexity lower bound · computability (Halting/Rice) · Bekenstein bound S ≤ 2πkRE/ℏc · statistical power β = f(α,n,effect) · PAC-learning ~ VC/ε².
speed of light c · Planck ℏ · Boltzmann k (Landauer) · Stefan-Boltzmann P = σεAT⁴ · Carnot η ≤ 1 − T_c/T_h · Bremermann 10⁵⁰ ops/s/kg · Margolus-Levitin n ≤ 2E/πℏ · Bekenstein-Hawking S = A/4ℓ_P².
fab throughput envelopes · grid capacity · launch cost per kg · permit envelopes · funding ceilings · labor-pool ramp · patent thicket — each from the entity's OWN published data.
- No lattice anchor alone — never place a lattice tautology (
σ·φ=24,1/2+1/3+1/6=1) as a sole HARD check. Self-consistency aid is OK; never apply to external domains. - Real-limit anchor first — every verify uses ≥1 limit from §2.
- Falsifiers on real thresholds — judge by physical/industry threshold exceedance, not χ²-fit to the lattice.
- No external over-claim — never claim an external entity "follows the lattice". Analyze external domains by their OWN invariants.
- Lattice-native — components where n=6 is an explicit spec invariant: keep using the lattice.
- Lattice-acceptor — may use the lattice as organizing vocabulary, but define their OWN limits by domain physics (bio = enzyme kinetics / membrane potential; accelerator = RF gradient / beam dynamics; matter = thermodynamics / phonon dispersion; fusion = Lawson criterion; etc.).
- External envelope — entities/companies absorbed into an analysis: NO lattice HARD check, NO χ²-to-lattice falsifier; disclose "n=6 is our framing, not 's design"; falsifiers defined only by the entity's published thresholds.
- Tautology — an always-PASS check has zero verification power.
- Over-claim — implies external systems follow a lattice they've never heard of.
- Constraining — asking "how does this fit n=6?" first narrows thinking away from the domain's real invariants.
- χ²-weakness misread — external data being weak on lattice-fit means the external system doesn't follow the lattice; misreading it as "needs reformulation" causes infinite retrofit.
- Real ceiling ignored — time spent on the artificial ceiling is time not spent on the real one.
- ❌ first question is NOT "how does this fit n=6?"
- ✅ first question IS "what is this domain's real invariant?" — find the physical constant / math limit / industry ceiling
- ✅ verification anchor = ≥1 real limit from §2
- ✅ use the lattice only if it appears naturally; otherwise omit it