population law: zero-copy projections and ARM/SPOFC evidence convergence

[AdaWorldAPI]

Summary

This PR closes two related population-law questions:

1. when a population operation is a zero-copy projection rather than a materialization boundary; and
2. how the real-data population statistics already exercised by the ANOVA witness map onto ARM / SPOFC evidence.

No production code changes are required for these results.

Population law

The physical model is:

resident data + reference register
              ↓
             FOLD
              ↓
      zero-copy projection

PIVOT = rotate the reference register
WRITE = materialization boundary

The resident population does not move when another view is needed.

A fold is the projection itself. A pivot changes the reference geometry used to read the resident population. Materialization begins only when a result is explicitly written as new state.

This removes the earlier assumption that a grouped result or a change of projection necessarily implies an intermediate population.

Bounded presence example

For the academic vocabulary population:

• O = 20,845 source observations
• I = 20,842 (spelling, PoS) identities
• S = 18,559 spellings
• PoS has a bounded 16-value domain

The question "how many PoS identities occur for each spelling?" therefore does not require materializing I and then regrouping it into S.

It can be expressed directly over O:

resident O
   +
reference = spelling
   +
16-bit PoS presence fold state
   ↓
spelling projection

The missing capability is fold state, not an intermediate population.

The same real-data witness also covers:

• pair grouping without a composite-key column;
• population-wide pair/co-occurrence statistics;
• PowerSums / moments;
• direct Pair → spelling projection from O.

ARM / SPOFC evidence

The same population algebra reaches the evidence required by association-rule discovery.

For one rule X → Y, the required evidence is:

|X|       antecedent count
|X ∧ Y|   co-occurrence count
n         observation window

ARM uses:

support = |X ∧ Y| / n

and the existing truth projection uses:

f = |X ∧ Y| / |X|
c = |X ∧ Y| / (|X ∧ Y| + k)

which yields {s,p,o,f,c}.

Two physical count engines, one evidence semantics

There are intentionally two execution paths.

Resident Lance hot path

When the evidence already resides in the population:

resident population
    + reference geometry
    ↓
Quack filter
    ↓
mask-risc Terminal::Count
    ↓
scalar count

For one ARM candidate:

X       -> Count -> |X|
X ∧ Y   -> Count -> |X ∧ Y|

These are scalar folds. No intermediate population, histogram or grouped K-slot result is required.

Tabular / external ARM path

lance-graph-arm-discovery remains an independent tabular engine:

Dataset
    ↓
RowMasks
    ↓
support_count / and_count
    ↓
|X| / |X ∧ Y|

This path deliberately remains usable without the resident lance-graph execution substrate.

The two engines converge at the evidence boundary, not by sharing their physical count implementation.

Boundaries established by this PR

• CausalEdge64 is downstream of evidence calculation and does not store raw population counts.
• Witness-register counts are local fixed-register reductions, not another population statistics engine.
• DeepNSM-v2 recounts remain independent scientific/oracle checks rather than a third production count engine.
• The separate cognitive-shader path that writes resonance-derived f/c into CausalEdge64 is recorded as an open semantic seam; this PR does not change it.
• No Count/result-as-operand machinery or intermediate analytics population is introduced.

Result

The resulting execution model is:

population evidence

        tabular                     resident
   Dataset / RowMasks          Quack / mask-risc
          │                         │
          └──── |X|, |X∧Y|, n ──────┘
                       │
                  ARM / SPOFC
                       │
                {s,p,o,f,c}

The important distinction is now explicit: projection is cheap and stays over resident state; writing new state is the materialization boundary.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Eo5eHGADmeKNE3xYhgdK76

[coderabbitai]

Navigate logical layers of code changes, visualize relationships, and explore their blast radius.

Note

Currently processing new changes in this PR. This may take a few minutes, please wait...

⚙️ Run configuration

• Configuration used: Organization UI
• Review profile: CHILL
• Plan: Essentials
• Run ID: 89817a4d-92ee-4121-8ec9-845ac2e46c88

📥 Commits

Reviewing files that changed from the base of the PR and between fe35059 and 136d810.

📒 Files selected for processing (3)

• .claude/board/STATUS_BOARD.md
• .claude/board/entries/2026-10-03-population-law-crosscheck.md
• .claude/plans/population-law-crosscheck-v1.md

 __________________________________________________________________
< Series-B funding secured. Now, I can afford to review your code. >
 ------------------------------------------------------------------
  \
   \   \
        \ /\
        ( )
      .( o ).

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Warning

Billing warning: we have not been able to collect payment for this subscription for more than 72 hours. Please update the payment method or pay any pending invoices in Billing to avoid service interruption.

---

_{Comment @coderabbitai help to get the list of available commands.}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 136d810bac

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[coderabbitai]

Autopilot could not be updated. Open Coding to check access and billing.