Status: proposed formalization, not yet part of the canonical spec.
This document exists because prior writing about Spherepop (in this
session and elsewhere in the repository) sometimes moves too quickly
between several genuinely different quantities — event count, structural
depth, constraint, entropy reduction, and assembly — as if they were
interchangeable. They are related, but they are not the same thing. This
document is deliberately not a philosophical essay (that role belongs
to prose papers such as standardgalactic/calculus's
identity_after_collapse.tex, see §11). It is meant as the precise
crosswalk that prevents the repository's different complexity claims from
drifting back together: every symbol below is given an explicit domain,
every claim is either proved from the definitions or flagged as
unverified, and every scalarization is required to name the policy under
which it was produced. Nothing here has been adopted into SPEC.md
itself, and no kernel code implements it — the four primitives'
admissibility and replay semantics are entirely untouched. §14's derived,
non-authoritative analysis functions (experiments/flat/profile.py / run_profile.py, isolated from the
main conformance suite; this remains a conceptual/notational proposal for
Phase B/C work under issue #1 with respect to the kernel and SPEC.md
themselves.
Correction to an earlier version of this document: a previous draft
stated that the extensional_view/history_view divergence discussed in
§4 was "exercised in test_spherepop.py-style fixtures." That was wrong.
test_spherepop.py belongs to the personalinks nested-sphere/quotient
lineage (see GRAMMAR.md), not the canonical SPEC.md kernel lineage this
document is built on. The canonical evidence for the canonical lineage is
the flat conformance fixtures and the three conforming implementations:
spherepop-kernel/
experiments/flat/run_python.py
compiler/tools/fixtures/
Checked directly in this session: there is no flat fixture yet that
exercises an intensional/extensional (history_view vs.
observation-under-Collapse) divergence. The closest existing fixture
pair is experiments/flat/fixtures/05a_same_snapshot_different_history_run_a.json
/ 05b_same_snapshot_different_history_run_b.json ("same snapshot,
different history"). The precise relationship is:
Fixtures 05a and 05b demonstrate that distinct histories may produce the same tested snapshot. They therefore support the general distinction between historical and extensional identity used throughout this document, but they do not implement or test the named
extensional_viewandhistory_viewinterface, which belongs to the separatepersonalinkslineage (seeGRAMMAR.md) and has no counterpart in the canonical flat fixtures.
§4 and §14 below identify the still-missing fixture (one that exercises a
named Collapse-relative view distinction, not merely snapshot equality)
as a concrete gap rather than implying it is already covered.
Before defining any complexity measure, fix the objects the rest of this document quantifies over.
A history is a finite sequence of admitted events drawn from the canonical four-primitive alphabet:
Replay produces an authoritative state:
A certified collapse rule
From
- the residual option space
$\Omega_H$ — the options not yet committed by aPopand not excluded by admissibility failure; - the refusal record
$F_H$ — the sequence or multiset ofRefuseevents and their recorded reasons; - the binding relation
$B_H \subseteq \mathrm{Obj} \times \mathrm{Obj}$ — the pairs coupled byBindevents, without asserting identity between them (this is the canonical meaning ofBind; see §7 for why it must not be silently treated as a dependency/assembly relation); - the observation record
$Q_H$ — the sequence ofCollapseevents applied and the rules$c$ they invoked.
Open question, not resolved here: whether spherepop-kernel's History/Arbiter types
(src/history.rs, src/arbiter.rs) materialize an analogous structure
directly; whether that is the only legitimate choice, or merely the
current implementation's choice, is left open. This distinction matters
for §13's comparison with the OS kernel-state tuple: spherepop-os.tex's
per-object State term rej: tags), while Bind's filter
predicate leaves no trace in
Event length is raw count:
Weighted historical cost requires an explicit, positive per-event
weight function
Append monotonicity then follows by construction, not by assumption:
Algorithmic complexity is a genuinely different quantity and must be named separately:
A previous version of this document used the symbol
Observed complexity is whatever a chosen measurement Collapse-produced observation,
Spherepop is a calculus of assembly only in the historical sense:
Spherepop is a calculus of assembly only in the historical sense. An object is not identified merely by its final configuration but by the admissible event history through which it was constructed. Assembly therefore supplies identity, not merely cost. Two extensionally identical structures may have different Spherepop identities when their histories differ, while a specified Collapse may deliberately treat them as equivalent for a chosen observation.
This connects the calculus directly to assembly theory while marking a real difference from it: a conventional assembly index asks for the shortest construction pathway permitted by a repertoire of operations and reusable components, whereas Spherepop ordinarily preserves the actual path taken, not the shortest one available.
An earlier version of this document defined minimal assembly as
silently assuming that an evaluation map
Proposition (Collapse-relative assembly complexity). Say
Reasoning:
This is one of this document's two central results (see §8 for the other): apparent minimal assembly complexity decreases as the observer is permitted to forget more distinctions. There is no observer- independent minimal assembly index unless the criterion of equivalence has already been fixed.
An earlier version of this document called all three of the following relations "partial orders." That overstated what follows from the definitions alone; each is analyzed separately below.
Causal order — a genuine partial order, provided it is defined over event occurrences in an acyclic dependency structure (which the canonical model guarantees: history is append-only and an event can only depend on events already admitted, so no cycle can form):
Assembly relation — initially only a preorder, not a partial order:
Reflexivity and transitivity are immediate from admissible extension
being reflexive and transitive. Antisymmetry does not follow: two
differently presented structures may each be constructible from the
other under different admissible continuations (e.g. via different
Collapse policies), so
Observational relation — also initially only a preorder. Define
the distinction set exposed by rule
Then:
This is a preorder (reflexive and transitive by set-inclusion) unless observational equality has already been quotiented out. On equivalence classes under
the induced relation
The general pattern: Collapse is exactly what turns a preorder into
a partial order, by supplying the equivalence Collapse-induced quotient.
These relations need not agree with one another: later does not always
mean more complex; more assembled does not always mean more
distinguishable; and Collapse can shrink
Spherepop complexity is monotone at the level of authoritative history but need not be monotone at the level of observed structure. Every admitted event increases historical information, even when its result is a simpler quotient, a smaller option space, or a more compressed view.
Using the corrected ledger from §2 (not
while for an observation
may hold. Collapse therefore does not make the past less complex — it
makes a selected observation less discriminating. See §9 for a concrete
worked witness of this claim.
Canonical Bind couples two elements without identifying them — it does
not assert that one was assembled from the other. Reading a
dependency/assembly graph out of Bind events therefore requires an
additional, explicit interpretation. This document distinguishes:
— the graph whose edges are literally the canonical Bind relation
— a derived view produced by an explicit interpretation rule Pop events) count as
construction dependencies. Different choices of Bind events, and nothing in the canonical primitive itself
distinguishes them. All assembly-graph quantities below (
Concrete evidence for exactly this gap now exists outside this document:
spherepop-os.tex's per-object causal State term (§13, Definition "State
Term, Extended") defines Pop and Refuse, which each append a tagged
entry to the history component, Bind's filter predicate
| Symbol | Meaning | Depends on |
|---|---|---|
| raw event count | — (invariant) | |
| weighted historical cost | a weight function |
|
| assembly depth (longest dependency path in |
assembly interpretation |
|
| concurrency width (maximum antichain width in |
assembly interpretation |
|
| number of distinct constructed components (vertices of |
assembly interpretation |
|
| dependency count (edges of |
assembly interpretation |
|
| refusal burden, $ | F_H | |
| $ | \Omega_H | $ |
| reuse gain (§9) | assembly interpretation |
|
| observational resolution, e.g. $ | D_c(H) |
The subscripts are not decoration:
A scalarization must declare two separate policies, not one:
Collapse does not, by itself, contain every value judgment
a scalar complexity score requires.
For an admitted event
— the last equality holds under the current canonical interpretation, in
which refusal records inadmissibility without deleting the option from
the underlying possibility space (SPEC.md; consistent with
Spherepop_Specifications.tex's conservation-of-possibility framing, §12
below).
where Bind event is not guaranteed to
move any assembly-graph coordinate at all.
but Collapse must not be declared
universally complexity-reducing; it is distinction-reducing relative to
a particular observational comparison
An earlier version of this document proposed a subtractive reuse-credit formula,
which has two defects: it can go negative, and it does not specify whether the first sum already counts a shared component once or once per use. The corrected treatment compares two different graphs built from the same history.
Let
Let
where
whenever
Counterexample 1 — equal length, different depth and width. Two
histories, each with four Pop/Bind events (
Counterexample 2 — reuse vs. reconstruction under a coarse Collapse.
—
Counterexample 3 — observational simplification through historical
growth. Let Collapse event
(
The user has proposed expanding standardgalactic/calculus's
identity_after_collapse.tex (see EXTERNAL-SPHEREPOP-REFERENCES.md —
verified in this session to define real \pop/\refuse/\bind/
\collapseop macros) with a new section, "Assembly Order and Historical
Complexity," placed after that paper's primitive calculus and before its
categorical/interpretive conclusions. That repository is outside the
scope of standardgalactic/spherepop and has not been modified from this
session; the proposal is recorded here as reference only. At a high
level, that proposed section covers the same ground as §4, §5, §7–§10
above (collapse-relative minimal assembly, the assembly preorder and its
quotient, the Bind-derived dependency graph, tree-vs-DAG reuse, and a
worked example), but is meant to carry the philosophical framing — why
this distinction matters for what "identity after collapse" means — while
this document carries the precise, checkable definitions. Anyone
picking up that proposal should treat this document as the source of
truth for the formal claims and use the paper only for the interpretive
argument built on top of them, to avoid the two documents' formalism
drifting apart.
Spherepop_Specifications.tex (verified present in this session; see
IMPLEMENTATIONS.md's "Canonical basis") states a conservation law:
This deserves its own scrutiny rather than an assumed compatibility with
§8's profile: is
for each primitive separately:
-
Pop: removes exactly one option from$\Omega$ ($\Delta|\Omega| = -1$ ) and, under the specification's own weighting$w(\mathrm{Pop}) = 1$ (Spherepop_Specifications.tex§"conservation," verified: "$w(\Pop(x))=1$"), contributes$\Delta\Pi = -1 + 1 = 0$ . Conserved, exactly, forPop. -
Refuse: per §8's$\Delta_{\mathrm{Refuse}}|\Omega| = 0$ (refusal does not shrink the option space, only records inadmissibility) and the specification's own weighting$w(\mathrm{Refuse}) = 0$ (verified: "$w(\RefuseOp)=w(\BindOp)=w(\CollapseOp)=0$"),$\Delta\Pi = 0 + 0 = 0$ . Conserved. -
Bind,Collapse: likewise weighted zero by the same specification clause, and neither changes$|\Omega|$ (§8), so$\Delta\Pi = 0$ for both.
Conclusion of this comparison: Spherepop_Specifications.tex assigns weight Pop alone and
weight Bind or
Collapse by their computational expense). Read as a claim about that
specific weight assignment, Refuse/Bind/Collapse, since those no
longer contribute zero. This resolves (rather than merely repeats) the
open question: the conservation claim holds in its own specified domain
and does not generalize to this document's more general
An earlier draft of this section proposed a tentative, coordinate-by-
coordinate correspondence between spherepop-os.tex's kernel state and
this document's causal-history quantities. That was the wrong shape of
claim to make, and it is retracted here rather than merely hedged
further. The corrected conclusion is stronger than "tentative": there
is presently no componentwise crosswalk to make, because the two tuples
live at different layers and are not populated from the same event
vocabulary.
spherepop-os.tex's kernel state (verified in this session, Definition
"Kernel State," §5.1) is
where, exactly as defined there: POP; MERGE; LINK; and spherepop-os.tex line 588). This
tuple belongs entirely to the OS operational layer.
By contrast, this document's causal-history quantities
(§1) belong to the causal option-space layer: possibility, refusal,
dependency, and observation. The letters
-
$\Omega_H \neq U$ .$U$ is a union-find map over objects that already exist (post-POP);$\Omega_H$ is the space of options that do not yet exist. These are not even subsets of the same universe. -
$F_H \neq R$ .$R$ records typed relations produced by OS operations likeLINK; it is not a refusal ledger. No top-level kernel event (POP,MERGE,LINK,UNLINK,SET_META) is itself aREFUSE, so there is no kernel-event directly analogous to causalRefuse. Refined below, however: causalRefuseis used internally inside theLINKreduction, and — per the per-object State term found in this session (see "A concrete, partial$\mathcal{I}$ ," below) — it does leave a trace, just not one that survives into$\sigma$ . -
$B_H$ /$G_H^{\mathrm{bind}}$ (§7) may be related to$R$ if some of$R$ 's typed relations happen to record causalBindevents, but this requires an explicit translation rule, not a bare identification of the two symbols. Refined below: theLINKreduction gives exactly this translation rule for one specific case.
The document therefore describes two projections from an authoritative history, rather than one shared coordinate space:
Neither is presumed recoverable from the other:
The causal calculus and the OS kernel expose different state spaces. The causal model tracks possibility, refusal, dependency, and observation. The OS model tracks object existence, identity classes, typed relations, and metadata. Although OS events may be reducible to expressions in the causal calculus, this does not imply a componentwise correspondence between their replayed states.
If a bridge between the two layers is wanted, it should be typed as an explicit interpretation, not asserted by matching field names:
together with the two independent replay functions
Even if LINK to a causal expression involving
Bind, that alone does not justify identifying REFUSE has no direct OS event, a refusal arising during reduction may
be internal to the causal derivation without surviving as a separately
queryable OS-state component under
The previous version of this document treated $\mathcal{I} :
\mathsf{History}{\mathrm{OS}} \to \mathsf{History}{\mathrm{causal}}$ as
a future obligation and flagged spherepop-os.tex line 585's reference
to a "higher-level State model...defined over an option space and a
history" as not yet located. It has now been located and read in full
(Definition "State Term, Extended," spherepop-os.tex line 907, §9.1),
and it changes §13's picture from purely negative to partially
constructive.
The per-object causal state is literally a triple
— immutable identity, admissible option space, and append-only history — with the three primitives acting exactly as this document's §1 assumed, but with one asymmetry worth recording precisely:
Bind does not append to Pop and Refuse leave a mark in the history component, tagged
sel:/rej: respectively. This sharpens §7's Bind-vs-assembly-
interpretation gap: in this concrete model, rej: tags (contrary to what the previous
paragraph's "no demonstrated storage location for refusal bookkeeping"
suggested about Bind's filter predicate Bind calls occurred, and with which predicates, requires the full
external operation sequence, not the state triple
Moreover, LINK and kernel COLLAPSE are not merely claimed reducible
to the causal calculus — they have proven reductions already in the
text:
(Definition "LINK Reduction," line 505, proven well-typed at
Proposition "LINK Well-Typedness," line 517), and kernel
This still does not rehabilitate the coordinate-by-coordinate
identification the previous section rejects, and in fact sharpens why it
must be rejected on the spherepop-os.tex line 490
states explicitly that Collapse
value "does not account for $U'$'s reassignment of every Collapse
operator's own definition are silent on identity (Proposition
"tensor-structural"), and choosing Collapse-quotient" — is now actively contradicted by the source,
not merely unconfirmed: Collapse, so Collapse-induced
Finally, note that LINK and COLLAPSE reduce over, and that would need to be
consulted to recover LINK/COLLAPSE well-typed, not retained afterward as queryable
state. So even though rej: tags), it is not recoverable from
Net conclusion, revised. No componentwise crosswalk between
LINK and kernel
COLLAPSE give two concrete, proven instances of it, expressed over
per-object causal State terms $t = (I_t, \mathrm{Opt}t, H_t)$ that are
themselves now fully located and defined (spherepop-os.tex line 907).
But those per-object histories $H_t$ are consumed only inside the
reduction's derivation; they are not retained as fields of $\sigma$, so
$F_H$, $\Omega_H$, and $B_H$ remain unrecoverable from $\sigma$ even
though they are well-defined and (for $F_H$, partially for $\Omega_H$)
recoverable from the richer per-object $H_t$ that the derivation
consults. The one specific lead that does not survive is "$U$ resembles
a Collapse-quotient" — the source states the opposite: $U$'s update is
an external policy decision the causal Collapse operator's own
definition is silent on. A state coordinate still cannot automatically
substitute for a historical measure: different histories can replay to
observationally equivalent states, so $\mathbf{A}{a,c}(H)$ is not
generally recoverable from spherepop-os.tex's per-object
A minimal implementation need not compute every entry of
Because the profile is derived, it must not affect event admission,
replay, or authoritative history — exactly the same non-interference
constraint spherepop-os.tex already states for diffs ("Diffs do not
influence kernel state and may be dropped, reordered, or ignored by
observers without affecting correctness," line 353) and that
spherepop-kernel's Collapse implementation already satisfies (a pure
function over History that never mutates state — see
IMPLEMENTATIONS.md's "Canonical basis" entry for spherepop-kernel/).
This is no longer a proposal. experiments/flat/profile.py implements
default_assembly_graph,
min_length_achieving, §4). It is kept in its own file, imports
run_python.py's Event/Arbiter/collapse-rule implementations rather
than duplicating them, and is exercised by experiments/flat/run_profile.py
against fixtures in the isolated experiments/flat/profile_fixtures/
directory — deliberately separate from experiments/flat/fixtures/ so
this non-authoritative suite cannot perturb the existing 13-fixture
conformance suite in any way. All five fixtures below pass, and the
original conformance suite (run_python.py against fixtures/) was
re-run afterward and is unaffected:
-
13_length_increases.json—$L(H \cdot e) = L(H) + 1$ for every admissible$e$ (§2), checked after each of four different event kinds (pop,bind,refuse,collapse). -
14_collapse_non_mutating.json—Collapsedoes not mutate prior history: two branches share an identical prefix and diverge only in which certified rule their finalCollapseinvokes; the prefix'soption_space,committedset, andhistory_lenare checked identical across both branches. -
15_depth_vs_width.json— Counterexample 1 (§10) instantiated exactly: a 4-object sequential chain ($D=4$ ,$W=1$ , via exact Dilworth/Mirsky-duality max-antichain computation) versus 4 independent objects with no binds ($D=1$ ,$W=4$ ), equal event/vertex count in both. -
16_reuse_tree_vs_dag.json— Counterexample 2 (§10): a history reusing one shared component ($u$ ) across three downstream assemblies gives a strictly positive$G_{\mathrm{reuse}}$ (tree cost 12.0 vs. DAG cost 7.5), contrasted in the same fixture with a fully independent reconstruction of the same shape three times over, which correctly yields a non-positive$G_{\mathrm{reuse}}$ (tree cost 12.0 vs. DAG cost 14.7) — demonstrating both the reuse-gain case §9 motivates and the documented no-reuse edge case where$G_{\mathrm{reuse}} \le 0$ is expected, not a defect. -
17_collapse_relative_minimal_assembly.json— a strict witness for §4's proposition: two candidate histories relating objects 1 and 3 through an intermediate object 2, then withdrawing the (1,2) relation. Under the coarse rule (ignores withdrawals) the shorter, length-3 candidate already achieves "1 and 3 same class"; under the fine rule (honors withdrawals) only the length-4 candidate does, giving$A_{\min}^{\mathrm{fine}}(x) = 4 > A_{\min}^{\mathrm{coarse}}(x) = 3$ — a strict inequality, not just the non-strict bound proved in §4, at the same standard already applied to the Meld schema inexperiments/flat/fixtures/08_meld.json.
Spherepop offers no single inherent "complexity." It supplies an
authoritative history from which several invariant and policy-relative
complexity measures can be derived (§8's invariant core vs. its
Collapse rule Bind/assembly-interpretation gap, §9's tree-vs-DAG reuse treatment,
§12's resolution of the possibility-functional conservation claim, §13's
separation of the OS kernel-state projection from the causal-history
projection, with two of its five kernel events now shown to have concrete
proven reductions) exists to make those two results, and any future
extension of them, precise enough to falsify. §4's monotonicity claim and
§9's tree-vs-DAG reuse gain are no longer only proved on paper: §14's
experiments/flat/profile.py/run_profile.py compute them, and all five
fixtures in experiments/flat/profile_fixtures/ — including a strict
witness for §4's proposition and both the positive- and non-positive-gain
cases for §9's reuse comparison — pass against that implementation,
without altering the existing 13-fixture kernel conformance suite.