Canonical Architecture Strategy

Status (noted): CANONICAL for the methodology computation effort as architected during the engine-arc. The engine arc closed — see session-close-003-engine-arc-consolidation.md (the current canonical resume doc). The architecture documented below remains the canonical record of the engine's design; this doc is no longer the live operational anchor (that role moved to the session-close docs and, currently, to architecture-catchup.md for the broader paper-team resync). Cross-reference; do not update in place.

Purpose: Establish the unified architectural picture, the analytical discipline that keeps it coherent, the project layout that makes it maintainable, and the forward plan for getting it built. Written as a re-grounding after a session in which the compute prototype drifted from the methodology because the methodology's analytical control layer (Layer 4) was never explicitly applied.

Scope of this document: Architecture and discipline only. Concrete implementation details belong in the targeted strategy docs (computation-chain-strategy.md, probability-walk-design.md, sagemath-*.md, lean-*.md). Operational state belongs in project-tracking.md.

Part 1 — Diagnosis: Why the prototype drifted

1.1 The recurring failure mode

Recent sessions produced compute infrastructure, JSON domains, and visualizations that didn't connect to the methodology in interpretable ways. The diagnosis in session-status.md correctly identified flat domain structure, performance issues, and disconnected visualizations as symptoms — but those are downstream of a deeper failure:

The methodology's analytical control layer (Layer 4) was never invoked. Every artifact in the prototype is missing labels for Fw (which arrangement?), Sc (at what scope?), Mn (whose manifestation, if any?), Cx (what context?), Ls (what landscape?). Without those labels, you cannot tell what an artifact means — even if it computes something correct.

This is what gives rise to:

• Conflated arrangements. Biology and entity-system primitives appearing in the same domain JSON or on the same diagram, because there is no Fw label saying "these belong to different arrangements."
• Conflated scopes. Topology results (Sc1) plotted as if they were temporal (Sc2), or treated as predictions about specific systems (Sc3).
• Conflated cross-domain semantics. Bridge constraints implemented as flat dependency union rather than as separate domains connected through a bridge domain.
• Visualizations of derived statistics with no lattice grounding. Plotting "corridor width by rank" when neither the lattice topology nor the unified manifestation at each rank is visible.
• Computation outputs no one can interpret. A 537M-position search finishes; what does "104,694 coherent positions" mean for the question we're asking? Without Sc/Mn, it doesn't mean anything yet.

1.2 The root cause: cognitive distractions filling structural holes

Working through the methodology informally, the gaps in formal scaffolding get filled by intuition and analogy in the moment. This works for one-off insights. It does not work for generating and analyzing landscapes consistently across many domains — every gap-fill is a new ad-hoc decision, the decisions don't compose, and the outputs become incomparable.

The methodology already has the formal scaffolding to prevent this. We just have to use it.

1.3 What we are NOT discarding

The prototype proved several things worth keeping:

• BFS-based reachability scales where full enumeration does not.
• Forward + backward reachability intersection (the corridor) is the right structural primitive for walks.
• Bottleneck identification on the corridor is informative and computable.
• Multi-domain composition is needed (the prototype tried it; the implementation was wrong, but the requirement is right).

These belong to the new architecture. The data model, the chain treatment, the visualization design, and the absence of L4 labels do not.

Part 2 — The unified architecture

2.1 Layer overview

The methodology has four layers (defined in detail in methodology.md). For computation purposes, the relevant separation of concerns is:

L4 is the layer that was missing. It is not an analysis target — it is the labelling system for analysis itself. Every JSON, plot, claim, and computation result must carry L4 labels to be interpretable.

2.2 The scope ladder (the central dial)

Sc is the most important L4 primitive for our purposes because it controls which kind of question is being asked.

Three discipline rules follow directly:

• Time only enters at Sc2 and below. rank ≠ time at Sc1. Any temporal claim made from a topological computation is a scope violation.
• Probability only enters at Sc2 and below. Sc1 corridors are combinatorially possible paths; their probability requires rates.
• Specific real systems are Sc3 evidence. They condition the Sc2 distribution; they do not exist at Sc1.

2.3 Realization chains and arrangements

An arrangement is a chain of domains connected by bridge domains, plus a context root. The methodology identifies several:

• Biology arrangement. Physics → Chemistry → Biology substrate → Organism architecture → (Cognitive substrate → Cognitive architecture →) Cultural ecosystem → Environment ecosystem context. The cognitive segment is part of the biology realization chain (brains are organism architecture; minds run on brains; cultures run on minds).
• Entity arrangement. Physics → Hardware → Digital computing → Entity substrate → Application architecture → Digital ecosystem → Digital context.
• Methodology arrangement. L1 → L2 → L3 → L4, treated as its own chain (the methodology analyzing itself).
• Mathematics arrangement. Information theory → Computational complexity → Dynamical systems → Network theory → Statistical mechanics (only IT analyzed canonically; rest are gaps).
• Speculative AI cognition extension. Entity substrate → Kd3/Kd4 type systems → Artificial cognitive architectures. Real but not yet analyzed.

Every arrangement has these structural facts:

• Each domain is a separate lattice with its own primitives, partial levels, dependencies.
• Bridge domains are themselves domains. They have primitives, partial levels, phase transitions. They are not edges or constraint sets.
• Each arrangement has a context root — a domain that provides the boundary conditions for the chain but is not in the chain itself (Environment for biology, Digital Context for entity).
• Arrangements share abstract structure at L3 (six-primitive substrates, evaluator role, ~12-mechanism developmental bridge, nine-primitive surface). Sharing structure does not mean sharing primitives — entity-system E,I,T,M,X,P are not biology G,T,R,P,Reg,Mem even though both occupy the substrate role.

Discipline rule: Arrangements are analyzed in isolation at Sc1. Cross-arrangement claims are L3 (abstract structure) or coupling (Sc3+, see §2.5).

Arrangements vs X-genesis questions. The X-genesis family (abiogenesis, ontogenesis, phylogenesis, technogenesis, sociogenesis, civilizational) are NOT separate arrangements. They are Sc=3 trajectory questions asked of an existing arrangement, typically asking how a specific manifestation (or class of manifestations) reached its current position. Abiogenesis lives within the biology arrangement (it is the Sc=3 trajectory through biology's chemistry → chemistry-to-biology-bridge → biology-substrate sub-segment, asking how the first cells emerged). Ontogenesis lives within biology (organism developmental trajectory) or cognition (cognitive ontogenesis). Civilizational trajectory lives within cognition (cultural-ecosystem evolution). Technogenesis lives within entity. Etc. Discipline rule (corollary): when a trajectory is rendered or analyzed, name the underlying arrangement explicitly; never treat the X-genesis label as itself implying an arrangement. Files in data/arrangements/ named after X-genesis questions (e.g., abiogenesis.v1.json) are SCOPED COMPUTE VARIANTS — sub-resolution or context-specialized views of the underlying arrangement — and must be documented as such, not as parallel arrangements.

2.4 Shared-physics convergence at Sc4

This is the structural fact that makes all of the above hang together physically.

At Sc0–Sc1, arrangements look like independent chains. At Sc4 — the level of a specific instantiated event — they collapse onto a single shared physical substrate, because every arrangement bottoms out in physics.

Worked example. A developer pressing a key on a keyboard is a single Sc4 event that simultaneously occupies positions in:

• The biology arrangement (the developer's body, neural state, motor action)
• The cognitive segment (intent, attention, internal model of the system being typed into)
• The cultural / digital ecosystem layer (the social role this work plays)
• The entity arrangement (the keyboard firmware, OS input pipeline, application receiving the event)
• The hardware sub-chain of the entity arrangement (the actual electrons in the key matrix, the bus, the CPU)

These are not five separate events. They are one event, viewed through five arrangement frames. The arrangement frames are analytical decompositions; the underlying physics is one substrate.

This produces three concepts that the framework needs to support:

• Within-arrangement unified manifestation. A specific entity's position across all domains in one arrangement. (Git, Postgres, Bitcoin, Instagram analyses are these.)
• Cross-arrangement unified manifestation. A specific Sc4 instance's positions across all coupled arrangements. The developer-pressing-key event is one of these.
• Physical convergence. The fact that as Sc → 4, arrangement separation dissolves into shared physics. This is what makes coupling (Cpl) physically real and not just an analytical move.

Discipline rule: When working at Sc4 or describing a real interaction, identify all the arrangements that share the event. When working at Sc1, do exactly the opposite — keep arrangements strictly separate.

2.5 Mn, Ls, Tj, Cpl — keeping the population concepts distinct

These four L4 primitives are the most-conflated set in informal discussion. The distinctions:

Walks (the corridor) are an Sc1 structural object. They are not trajectories. A trajectory requires time, which requires rates, which requires Sc2.

The landscape is not a single point or a single chain — it is the cloud of co-existing instances, with their relative density, coupling, and dynamics. Plotting "Git, Postgres, Nostr, AT Protocol" against entity-system primitives is a Sc2 landscape view (potential population) or Sc3 landscape view (actual population), depending on whether we're claiming "these are the only ones" or "these are some of them."

Mn-kind heterogeneity within an arrangement (added). A single arrangement can host Mns of structurally-distinct kinds — Mns that populate different chain-level subsets and aren't directly comparable on the same fingerprint grid. The cognition arrangement is the canonical case: it contains organism-cognition Mns (populate neural-hardware + cognitive-substrate + cognitive-architecture; zero on cultural-ecosystem), civilization Mns (populate all 7 levels), cultural-artifact Mns (populate cognitive-architecture + cultural-ecosystem; zero on neural-hardware), and research-ecosystem Mns (populate cognitive-architecture + bridge + cultural-ecosystem). Each Mn-kind populates a different chain-level subset.

A zero on neural-hardware for git-cultural-artifact does NOT mean "git lacks brains." It means neural-hardware isn't a structurally-differentiating primitive of cultural artifacts as a kind — the biological substrate is presupposed, not part of the artifact's characterization. The encoding semantic of zero is therefore context-dependent across kinds:

1. "Lacks this primitive entirely" (cross-domain — e.g., chemistry Mn has zero on neural primitives)
2. "Presupposes this primitive but doesn't differentiate on it" (cultural artifacts on neural-hardware)
3. "Different chain level entirely / not part of this Mn's characterization"

Implication for analysis. Structural-fingerprint comparison (cosine distance on per-Mn fingerprint vectors) works correctly within an Mn-kind because members populate similar chain-level subsets. It produces meaningless cross-kind adjacency when comparing Mns from different kinds — disjoint-populated-region pairs collapse to d≈1.0 under cosine and get placed adjacent to whatever the MDS projection happens to put at the extremes. The right move when an arrangement has Mn-kind heterogeneity is to partition by kind and compare within-kind. Cross-kind analysis is RELATIONAL (e.g., "cultural artifacts are produced-by cognitive-architecture activation," "research-ecosystems realize methodologies in cognition") not COMPARATIVE.

The boundary between kinds is question-dependent, not fixed. Most of the time (the "generic human" assumption) neural-hardware is presupposed for cultural-artifact analysis. But there are real questions — what is the cognitive load required to interpret this artifact, and how does it interact with neural-impairment distributions in the population? — where neural-hardware IS load-bearing for cultural-artifact analysis. In those cases, the comparison frame should include neural-hardware. The L4 control layer needs to support specifying the comparison frame per question rather than baking it into Mn authoring.

Entity / biology / methodology arrangements don't have this Mn-kind heterogeneity at the same level — their Mns populate roughly homogeneous chain-level subsets, so full-arrangement fingerprint comparison is fine. The compute library currently assumes the homogeneous case; making Mn-kind / comparison-frame a first-class concept is an open methodological development.

2.6 The Bayesian probability framework

The probability framework already drafted in probability-walk-design.md slots into the scope ladder cleanly:

• Prior = the coherent sub-lattice (the topological possibility space). Sc1 product.
• Likelihood = physics rates per transition (kinetic / thermodynamic). Sc2 input.
• Evidence = empirical observations or locked manifestations. Sc3 input.
• Posterior = probability distribution over walk positions. Sc2 (without evidence) or Sc3 (with evidence) output.

The operations described informally — "set what we know," "generate distributions given that," "lock down a unified manifestation," "detect feedback cycles and impose time" — all map directly:

• "Set what we know" = condition on evidence (lock a position, lock a manifestation, lock a chain level). Bayesian conditioning.
• "Generate distributions" = forward + backward reachability under the priors and likelihoods, intersected at fixed points.
• "Detect feedback cycles" = identify SSA topology (when active, how coupled). The cycles become the dynamical operator at Sc2.
• "Impose time and iterate" = roll the Sc2 dynamical process forward at chosen granularity (granularity is set by Sc).

Discipline rule: Every probability claim must specify its prior (which sub-lattice), its likelihood source (which rate model or "uniform"), and its evidence set (which observations conditioned on). Unlabeled probabilities are scope violations.

2.7 Time, feedback, and the SSA

Time is not part of the lattice. Time enters as the parameterization of dynamics applied to the lattice at Sc2.

The SSA topology (7 roles: En, Vr, Mc, Sf, Cx, Cm, Se) gives the structure of the feedback cycles. Pre-genesis the SSA is fused (En = Vr); at the genesis transition it separates; post-genesis the three SSA cycles run simultaneously. This is what makes time meaningful in a given arrangement — without active feedback cycles, the lattice can be traversed but doesn't do anything in finite time.

Concrete consequence for computation: The R0→R2 walk in biology and the X0→X2 walk in entity systems are both genesis transitions — they cross the boundary where SSA fuses become SSA separates. Before that boundary, time is dominated by stochastic chemistry (or stochastic protocol invention); after it, time is dominated by directed evaluation (ribosome dispatch, runtime dispatch). This is exactly the regime change that physics rates need to model.

2.8 The unified analytical view (the frame of reference)

Every analytical use case in Part 4 produces a result rendered — mentally, in computation, or in visualization — into a single conceptual structure: the unified analytical view. This is the frame of reference that ties Mn, Ls, Sc, Tj, Cpl together into one navigable space the analyst can iterate on. Without this unification, each analytical question would require its own bespoke framing; with it, analysis becomes a matter of turning dials on a shared structure.

The view has five orthogonal dimensions, each controlled by one L4 setting:

Iterating on the view = changing one or more L4 settings and re-rendering. The Bayesian framework provides the recompute: the prior (lattice topology) usually persists; the likelihood (rate model) may swap; the evidence (Ls or Mn focus) often does. The view redraws against the new settings.

Concrete iteration patterns the analyst should be able to perform without rebuilding anything:

• Re-scope. Toggle Sc1↔Sc2↔Sc3 to add/remove rates/specific systems on the same lattice geometry.
• Re-context. Change Cx (different environment, different historical period). Same lattice, different background; positions and trajectories may shift.
• Re-populate. Add or remove Mns from Ls (focus on Git+GitHub vs. all VCS systems vs. all distributed information systems).
• Re-time. Move from snapshot to trajectory animation; toggle which Mns are tracked over time vs. shown statically.
• Re-frame. Switch Fw to a parallel arrangement (entity ↔ biology) and ask whether the L3 abstraction holds — same view, different arrangement.
• Re-bridge. At Sc4, add or remove arrangements from Cpl to see how a cross-arrangement event decomposes.

Discipline implication: When designing computation outputs and (eventually) visualizations, design them to take L4 settings as parameters, not to bake one setting in. A landscape plot is not "the entity-system landscape" — it is render(Fw=entity, Sc=3, Ls=[...], tj_mode=null). Changing settings should re-render the same machinery. This is what makes the view a frame of reference rather than a collection of separate diagrams.

Connection to the constructs already in the framework: §2.2 (scope ladder) supplies the Sc dial. §2.3 (chains and arrangements) supplies the Fw dimension. §2.5 (Mn/Ls/Tj/Cpl distinctions) supplies the population/time/coupling dials. §2.6 (Bayesian framework) supplies the recompute mechanism. §2.7 (time and feedback) supplies the dynamics underneath the time dial. The unified analytical view is what those sections add up to in practice — it is not new machinery, it is the integrated frame that the existing machinery composes into.

2.9 Rate-model taxonomy and schema boundary

The Bayesian framework (§2.6) admits any rate model in principle, but the data-side schema constrains which rate models can be encoded statically versus which require stochastic simulation to compute their distributions. The relevant boundary is the rate_table schema: it keys on (chain_level, primitive_id, from_level, to_level) — the moving primitive's own transition only. There is no slot for other primitives' levels at the current state. This produces a three-category taxonomy of rate models that the framework needs to keep distinct:

• (a) rate_table-expressible. Rate depends only on the moving primitive's transition. Encodable as a static rate_table; analytical forward × backward weighted-mass propagation produces the same distribution as stochastic simulation within Monte Carlo noise. Examples: uniform rates; per-transition rate constants; primitive-self-autocatalytic rates of the form (1 + current(P))^k.
• (b) Position-Markov but rate_table-inexpressible. Rate depends on the current state (other primitives' levels at this position) but not on path history. Cannot be encoded in the rate_table schema. The stochastic simulator is necessary to compute the resulting distribution within the existing schema. Canonical example: partner-primitive autocatalysis where rate(+P1) ∝ (1 + current(P2))^k. Empirically verified: under coupled Cd × Cat autocatalysis, no rate_table-encodable approximation gets within L1 ≈ 0.6 of the simulator distribution.
• (c) Path-history-dependent. Rate depends on the path taken to reach the current state, not just the current state. True non-Markov dynamics. No rate models in this category are currently implemented; if added, iteration would be essential by construction (the analytical reduction available for category (a) is unavailable).

Two operational consequences follow. First, claims about a simulator ensemble's informational content must specify which category the rate model falls into — a category-(a) ensemble carries no information beyond the static analysis of the same model, while a category-(b) ensemble does. Second, the rate_table schema is a real expressiveness boundary, not an implementation accident: extending it to encode category-(b) rates would require keying on position (whole-state) rather than per-primitive transition.

Two limitations of the current simulator follow from the current data model and should be flagged in any analysis using it:

1. Trajectories always reach destination by construction. Unlimited simulation steps + a structurally reachable corridor mean every simulated trajectory in our test cases (500/500, 2000/2000) reaches the destination. We are not modeling success/failure dynamics — "of N attempts in time τ, how many reach destination?" The methodology supports this via population_context (population size, time available) and realized_probability (per-trial probability × population × time), but the simulator has not been wired into them. Status: partially addressed via the calibration evaluator — see "Calibration extension layer" below.
2. No physical-time scaling. Each simulator step is one cycle of the loop; there is no notion of "this transition takes microseconds, this one takes millennia." The time_available field in population_context is unused at the simulator boundary. Status: partially addressed via the calibration evaluator — see "Calibration extension layer" below.

Calibration extension layer (added)

A pluggable extension layer attaches wall-time interpretation to rate models without modifying the existing static-equivalent or simulator paths. Three additive components:

• rate.v1.schema.json extension. An optional calibration block: {method, step_duration, anchor_milestones, scaling_factor, uncertainty, model_parameters}. When absent, rate files behave exactly as before (dimensionless relative weights, used by static and simulator analyses unchanged). When present, the rate file carries wall-time semantics. Methods enumerated: uniform-step (each rate-1 step = step_duration wall time), milestone-anchored (step_duration solved against an empirical anchor), eyring (Eyring activation energy in model_parameters), mutation-rate (per-replication rates), fitted (multi-anchor numerical fit), custom (method-specific via model_parameters).

• compute/lib/calibration.py library. Pure functions consuming a (trajectory, rate_file, [population_context...]) triple and producing calibration_analysis.v1 output: per-snapshot expected wall times, anchor-milestone validation (residual log10, within-empirical-range bool), and cumulative-success-probability curves under N parallel attempts via 1 - exp(-Nλt). Falls back to dimensionless step counts (method='none' in the output) when the rate file lacks a calibration block, recording the fallback in fallback_notes.

• compute/scripts/analyze_calibration.py driver + compute/scripts/plot_calibration_comparison.py figure. Standalone, opt-in. Don't modify the simulator interface or existing analysis paths.

Pluggability properties: (a) Existing rate files validate unchanged. (b) Multiple calibrated rate files can be authored alongside placeholders for the same arrangement (e.g., abiogenesis-placeholder.v1.json + abiogenesis-calibrated.v1.json + future abiogenesis-eyring.v1.json); downstream analysis selects via path. (c) The RateModel callable interface in feedback_simulator.py is untouched — calibration is a layer over the existing rate corridor, not a replacement. (d) Falls back gracefully when calibration is absent; the same analysis driver works for both placeholder and calibrated rate files. (e) Different method values produce the same output schema; downstream consumers don't need to switch on method.

Worked example: abiogenesis calibration anchored against LUCA at ~3.7-3.8 Gya. step_duration = 3 My/baseline-step solves the slowest-corridor wall-time to ~855 My — within the empirical [500M, 1Gy] window (residual log10 = +0.082). Under population_context size N=10⁶-10⁹ Hadean pores, cumulative success probability reaches ~1 at the anchor wall-time, indicating the rate-corridor's structural bottlenecks dominate over population effects at this scale. See output/figures/calibration-comparison-abiogenesis.png and output/results/abiogenesis-calibration-analysis.v1.json.

Discipline rule (added): Every calibration_analysis output must declare its calibration_method (including the explicit none value for fallback). Anchor-milestone checks must report residual_log10 and within_empirical_range to make calibration drift detectable. When uncertainty bands are propagated, they must be propagated explicitly via uncertainty_band rather than implicitly via the central estimate.

Discipline rule: When reporting rate-model results, label which category (a/b/c) the model belongs to, and whether the result comes from static analysis (category (a), equivalent to simulator) or the stochastic simulator (category (b), necessary). Do not frame category-(a) simulator output as "iteration revealing what static analysis cannot show" — it does not. The information content of a simulator run is exactly the rate-model category permits.

Part 3 — Applied discipline (the rules)

These are the rules that prevent the failure mode in §1. They are mechanical; follow them and the cognitive-distraction problem largely goes away.

Rule 1: Every artifact carries an L4 header

Every JSON, every plot, every notes file, every computation output. Header format:

Fw:       <arrangement name, e.g. "biology" or "entity">
Sc:       <0|1|2|3|4>
Mn:       <none | specific manifestation ID>
Cx:       <context, often the context-root domain>
Ls:       <landscape under consideration, if applicable>
Question: <one sentence: what does this artifact answer?>

For data files this lives in a meta field. For plots, in the title or caption. For notes, in YAML frontmatter or a top-of-file block. If you can't write the header, don't make the artifact.

Rule 2: Arrangements are isolated at Sc0–Sc1

No biology and entity-system primitives in the same domain JSON. No cross-arrangement primitives on the same diagram without explicit role labels. The L3 isomorphism between arrangements is a meta-claim about structure; it is not permission to overlay the lattices.

Cross-arrangement work happens at L3 (abstract pattern extraction) or at Sc3+ (coupling through shared instances). Not at Sc1.

Rule 3: Walk the scope ladder in order

Get Sc1 (topology) right and stable for an arrangement before adding Sc2 (rates). Get Sc2 right before conditioning on Sc3 (instances). Get Sc3 right before describing Sc4 (specific events). Do not try to do all four at once — the previous prototype tried to and produced indeterminate outputs.

Rule 4: Bridges are domains, not constraints

Bridge primitives have their own lattices, their own partial levels, their own phase transitions. They sit on edges between substantive domains and connect them through shared variables, but they are not edges. The data model must reflect this.

Rule 5: Compute by BFS, never by enumeration

Forward and backward reachability with on-the-fly coherence checking. Never enumerate full product spaces. The 537M-position case completes in seconds with BFS; that is the only viable approach as chains scale.

Rule 6: Visualizations follow questions, not data

Before building a visualization: write the question it answers. Then write what would have to be true of the underlying computation for that question to be answerable. Then check the question is at the right scope and the artifact carries L4 labels. Only then build the plot.

Rule 7: Track decisions

Architectural and methodological decisions go in project-tracking.md with date, decision, alternatives considered, and rationale. This prevents quietly drifting back into prior failure modes.

Rule 8: Mn-kind discipline and consistent chain-level encoding (added)

An arrangement can host Mns of multiple structurally-distinct kinds — Mns that populate different chain-level subsets and aren't comparable on the same fingerprint grid. Per §2.5: the cognition arrangement is the canonical heterogeneous case (organism-cognition + social-band + civilization + cultural-artifact + research-ecosystem are all valid cognition Mns but cannot be cross-compared structurally).

The rules:

1. Within an Mn-kind, encoding must be uniform. Every member of the same Mn-kind must populate the same chain levels with the same primitives present (even if some are at explicit-zero). Mixed-population within-kind produces asymmetric-zero-vector artifacts under cosine distance and silently distorts comparison.

2. Use explicit zeros over absent keys when a primitive doesn't apply. A primitive at 0 is different from a primitive absent from the JSON: the first is "this Mn explicitly doesn't engage this primitive at any level"; the second is "we never authored this." If the kind populates the chain level and this specific Mn doesn't use the primitive, encode as 0. Reserve key-absence for "this chain level isn't part of this Mn-kind's characterization at all."

3. Don't conflate scales in a single Mn. Individual cognition belongs in an individual-cognition Mn; band-scale social structure belongs in a band-scale Mn; civilization-scale belongs in a civilization Mn. If a Mn looks like it has positions at multiple scales (e.g., individual organism + band social-structure), split it into separate Mns of separate kinds.

4. Tag explicit mn_kind for any Mn in a heterogeneous arrangement. When an arrangement contains multiple kinds, every Mn should declare its mn_kind in the JSON. Naming-pattern fallback (in compute/scripts/plot_structural_fingerprint_landscape.py::infer_mn_kind) is for legacy Mns; new Mns get explicit tags.

5. Cross-kind analysis is RELATIONAL, not comparative. A cultural-artifact Mn is not "more" or "less" than an organism-cognition Mn — they live in different chain-level scopes. Cross-kind relationships are encoded via couples_with (Sc=3 sustained) or positions_by_arrangement (Sc=4 single events), not via structural-distance comparison.

6. Audit chain-level coverage when adding a Mn. Before merging a new Mn, check that its chain-level coverage matches other Mns of the same kind. The compute already supports this — plot_structural_fingerprint_landscape.py prints "Chain-level coverage audit" + flags asymmetries when --filter-kind is set. Run it.

**Concrete cases as of **

Why this matters. Failing to maintain consistent encoding within a Mn-kind produces silent comparison artifacts (cognition organism-cognition example: human-adult-cognition appeared structurally distant from chimp because chimp had small social-band positions that human didn't, even though they're both individual cognition Mns and that wasn't supposed to be the comparison axis). The compute can paper over this with strict-all auto-scope, but the right fix is data-side discipline. Documenting these rules so future authoring doesn't repeat the inconsistency.

Rule 9: Selective corpus expansion before anchor authoring (added)

When an analytical cluster appears to be a structural class but is supported by N=1-2 Mns, AUTHOR 1-2 STRUCTURAL COMPARABLES before committing the cluster as an anchor. Selective corpus expansion is the empirical sharpening step between cluster identification and anchor authoring.

The rules:

1. A cluster of N=1-2 may be an artifact of corpus undersampling. Before authoring an anchor for a small cluster, add 1-2 Mns that test the cluster boundary: pick structurally-comparable candidates and see whether they join the cluster (confirming the class) or land elsewhere (refining the boundary or disconfirming).

2. Add Mns ONE-PER-CANDIDATE-CLUSTER per Wave; rerun meta-stability between Waves. This is faster than batch-authoring and gives early signal on which clusters confirm and which refine. The empirical arc used 3 Waves of 3-5 Mns each, with cluster sweep between each, to reshape the anchor inventory iteratively.

3. A disconfirmed cluster is a finding, not a failure. When the structurally-comparable candidates fail to cluster (memcached + redis = 4/12; couchdb + mongodb = 6/12), the cluster boundary IS the structural distinction. Don't anchor disconfirmed clusters; the singleton members remain individual structural attractors.

4. A confirmed cluster grows. When candidates DO cluster (consul + couchdb both join etcd + zookeeper), the cluster's N grows and the anchor authoring uses the refined membership.

5. Stop Waves when new additions produce diminishing differentiation. The signal "we're not learning new boundaries" indicates the corpus has reached a useful density for the current analysis. Remaining singletons can be flagged for future Waves if/when new structural questions arise.

Empirical reference: the entity-arrangement arc went from 35 instance Mns + 2 declarative anchors → 47 instance Mns + 2 scenario projections + 10 anchors (8 inductive + 2 refined declarative) across 3 Waves. This pattern is recommended for future arrangement-level anchor identification.

Rule 10: Mn-pair-similarity vs anchor-candidacy (added)

The cluster_meta_stability.py co-cluster count is a measure of STRUCTURAL SIMILARITY between Mn-pairs across (chain-level × signature) configurations. The cluster_stability min_stable_size (default 3, per Plan §5.1) gates ANCHOR CANDIDACY. These are distinct concepts; the original §5.1 conflation produced a bug (git+mercurial co-clustered at 10/12 but appeared as 4/12 because the 2-pair fell below min_stable_size).

The rules:

1. For pair-similarity analysis: count ALL method-agreement clusters regardless of size (including small_groups of size 2). This identifies all structurally-similar Mn-pairs.

2. For anchor candidacy: require either (a) N≥3 cluster member count, or (b) N=2 with 10+/12 stability + corpus-expansion plan to grow N. The original plan §5.1 N≥3 minimum applies to inductive anchors derived from clustering; explicit N=2 pair-anchors should carry a notes field documenting their pair-status and growth path.

3. The cluster_meta_stability.co_cluster_pairs_from_stability default behavior is now include_small=True per this rule.

4. N=2 anchors authored in Phase 1C: relational-server-dbms (mysql + postgres), editor-tools-pair (claude-code + obsidian). Both at 10-12/12 stability. Anchor JSONs flag the pair-status in notes.

Part 4 — Use case taxonomy

The same lattice machinery supports many different analytical use cases. They differ only in L4 settings (Fw, Sc, Mn, Cx, Ls, Tj, Cpl) and the question being asked. This part catalogs the use cases so that any new analytical need can be located in the framework rather than re-invented ad hoc.

The catalog is grouped by scope. Within each scope, use cases share the same kind of output structure but differ in arrangement, manifestation, and question.

4.1 Sc1 — Static structural analyses (no time, no probability)

Lattice analysis. Coherent sub-lattice of one domain. Output: which positions exist, dependency structure, filter stringency. Fw=<one>, Sc=1, Mn=none. Question: "What positions are structurally possible in this domain?"

Walk corridor analysis. Forward + backward reachability intersection between two pinned positions in one arrangement, with bottleneck identification. Fw=<one>, Sc=1, Mn=none (origin and destination act as bounding positions, not specific manifestations). Question: "What are the structurally possible paths from origin to destination, and where does the corridor narrow?"

Cross-arrangement abstraction. L3 pattern extraction across multiple arrangements (the methodology's L3 work). Fw=<multiple>, Sc=0. Question: "What L3 patterns appear across these arrangements (substrate-evaluator-surface, six-primitive substrates, twelve-mechanism developmental bridges, etc.)?"

Bridge domain analysis (first-class). A bridge between two chain levels has its own lattice — primitives, partial levels, dependencies, phase transitions — and is analyzed as a domain in its own right (per discipline Rule 4). Fw=<arrangement>, Sc=1, Mn=none, focus=bridge-domain. Question: "What is the structure of this bridge as a domain, and how do its cross-lattice constraints connect the source and destination chain levels?" Particularly important for ontogenetic analysis (which traverses the biology→organism-architecture bridge with its 12 developmental mechanisms) and for any cross-domain coupling work.

4.2 Sc2 — Weighted dynamic analyses (rates, populations, probability)

Genesis transition analysis. Phase-transition dynamics at a specific position in the lattice (R0→R2 in biology, X0→X2 in entity). Includes pre-transition fused-SSA dynamics and post-transition separated-SSA dynamics. Fw=<one>, Sc=2, Mn=null, tj_mode=null (this is a Sc2 dynamics analysis at a specific transition; trajectory framing only enters at Sc3 with a specific Mn). Question: "What are the rate-weighted bottlenecks at this phase transition, and what is the time scale?"

Population analysis. Expected number of parallel experiments at each step of a corridor, given physics rates and search-space sizes. Fw=<one>, Sc=2, Ls=potential. Question: "How many parallel experiments exist at each corridor position, and what does that imply for outcome probability?"

Probabilistic landscape. Probability distribution over endpoint manifestations given priors and likelihoods. Fw=<one>, Sc=2, Ls=potential. Question: "Given the priors (sub-lattice) and the rates (likelihoods), what is the probability distribution over endpoint manifestations?"

4.3 Sc3 — Trajectory analyses (the "X-genesis" family)

These use cases share a single analytical pattern — a specific manifestation (or class of manifestations) moving through arrangement positions over time, with bottlenecks, phase transitions, attractors, and feedback cycles operating throughout. Abiogenesis, ontogeny, phylogeny, and technological evolution are all instances of this pattern; they differ only in which arrangement, which manifestation, and which time scale.

For all of these, Sc=3, tj_mode is single (one Mn) or multi (many Mns being compared/co-tracked), tj_type discriminates among the variants below, and the analysis output is a sequence of unified manifestations through time (or a probability distribution over such sequences if conditioned partially). L4 settings are written Fw=..., Sc=..., Mn=..., Cx=..., tj_mode=..., tj_type=... matching the schema fields in compute/schemas/_l4_header.v1.schema.json.

Abiogenesis analysis. The trajectory from prebiotic chemistry to first life. Fw=biology, Sc=3, Mn=first-life-on-earth, Cx=environment-prebiotic, tj_mode=single, tj_type=historical. Question: "What was the specific trajectory of life's origin, where do empirical constraints narrow the corridor, and what cross-domain bridges (chemistry→biology) gate the transition?" Note: at Sc1 this is the corridor of all possible origin trajectories; at Sc2 it is rate-weighted; at Sc3 it conditions on what actually happened on Earth.

Ontogenetic analysis. The trajectory of a single organism from fertilized egg to adult. Fw=biology, Sc=3, Mn=<specific organism or species developmental program>, Cx=maternal-environment, tj_mode=single, tj_type=developmental. Question: "What positions does this organism occupy through its development, what bottlenecks and branch points define the trajectory, what feedback cycles canalize it?" The trajectory primarily traverses the biology→organism-architecture bridge (the 12 developmental mechanisms), so the bridge-as-domain treatment is essential. The unified manifestation evolves through the trajectory (egg, embryo, larva, adult are different UMs) rather than being fixed at the endpoint as in abiogenesis. Sub-level resolution captures molecular → cellular → tissue → organ scales.

Phylogenetic analysis. The evolutionary trajectory of a species or clade over evolutionary time. Fw=biology, Sc=3, Mn=<species or clade>, Cx=ecological-pressures, tj_mode=single, tj_type=evolutionary. Question: "What positions did this lineage occupy across evolutionary time, what selection events drove transitions between them, where did major novelties emerge?" Differs from ontogeny in time scale (millions of years vs. weeks-years) and in dominant feedback cycle (selection vs. development).

Technogenetic analysis. The evolutionary trajectory of a technology or technology lineage through entity-arrangement positions. Fw=entity, Sc=3, Mn=<technology lineage, e.g. www, distributed-databases>, Cx=socioeconomic-pressures, tj_mode=single, tj_type=evolutionary. Question: "What positions did this technology lineage occupy, what social/economic/technical events drove transitions, where are attractors and walls?" Direct analog to phylogeny in the entity arrangement.

Sociogenetic analysis. Trajectory of cultural or institutional structures through cultural-ecosystem positions. Fw=biology, Sc=3, Mn=<institution, movement, language>, Cx=historical-context, tj_mode=single, tj_type=cultural. Question: same shape as phylogenesis at the cultural level.

Individual lifecycle analysis. A single specific instance through its lifetime. Generalizes ontogeny to non-biological arrangements (one specific Postgres database from creation through retirement, one specific Bitcoin wallet from generation to last spend). Fw=<any>, Sc=3, Mn=<specific instance>, tj_mode=single, tj_type=lifetime. Question: "What positions did this instance occupy through its lifetime, when and why did transitions occur?"

Counterfactual trajectory analysis. What trajectory would have occurred under different conditions. Fw=<arrangement>, Sc=3, Mn=<hypothetical-Mn-id>, Cx=<varied>, tj_mode=single, tj_type=counterfactual. Question: "What trajectory would have occurred had X been different?" Useful for design analysis (what if the entity system had been built without P? what if the genetic code had a different mapping?) and for necessity-vs-contingency reasoning.

Trajectory backwards inference. Given an observed manifestation as it exists now, infer the trajectory that produced it. Fw=<arrangement>, Sc=3, Mn=<observed-instance>, tj_mode=single, tj_type=inferred-backwards. Question: "Given this manifestation as it exists now, what trajectory most likely produced it?" Load-bearing for paper writing — most papers describe systems that already exist (Git, Postgres, Bitcoin, biological organisms, cognitive architectures) and reason backwards about their genesis. Without this use case, the framework cannot produce most of the planned papers.

Trajectory comparison. Compare multiple trajectories. Fw=<arrangement>, Sc=3, Mn=[<multiple>], tj_mode=multi, tj_type=comparison. Question: "How do these trajectories differ, where do they branch, and what selects between them?" Examples: ontogenesis across species at homologous developmental stages; technogenesis of competing technology lineages (Holochain vs Urbit vs AT Protocol vs Nostr).

Common analytical machinery for all of §4.3. All trajectory analyses produce: (a) a position sequence (or distribution over sequences) through the relevant arrangement, (b) identification of bottlenecks where the trajectory could branch but didn't (or did), (c) identification of phase transitions and the SSA cycle activity that drove them, (d) identification of attractors that the trajectory was drawn toward, (e) cross-arrangement coupling events where the trajectory was shaped by interactions with other arrangements (e.g., ontogeny shaped by environment, technogenesis shaped by user behavior). The lattice computation is the same; the interpretive frame differs by use case.

4.4 Sc3 — Landscape views and evolution (populations of manifestations)

These use cases are about populations rather than single instances. Some are static snapshots; others track how the landscape itself evolves.

Landscape positioning (snapshot). Specific real systems mapped to arrangement positions (Git, Nix, Postgres, Bitcoin, Instagram, Linux, Minecraft positioned in the entity arrangement). Fw=entity, Sc=3, Mn=null, Ls=[git, nix, postgres, ...], tj_mode=null. Question: "Where do specific real systems sit in the arrangement lattice, and what does their distribution tell us about attractors, gaps, and convergence?" This is the use case Paper 0 and Paper 6 need. Visualization-wise it is the unified analytical view (§2.8) with the time dial off — a single frame.

Landscape evolution / ecosystem accretion analysis. Multi-Mn co-evolution over time. The landscape itself is the trajectory subject — not a single Mn moving through positions, but the whole population of Mns shifting, accreting, and reorganizing across time. Fw=<one>, Sc=3, Mn=[<specific systems>], Ls=[<evolving population>], Cx=<broader-environment>, tj_mode=multi, tj_type=evolutionary. Question: "How does the landscape of co-existing manifestations evolve, where do new entrants appear, what stays stable, and what aggregate structures form from accretion?"

The landscape evolution analysis tracks several distinct phenomena simultaneously:

• Stable Mns. Manifestations whose lattice position barely moves over the time window of interest. Git is the canonical example: the software itself sits at a stable lattice position (content-addressed store, very limited primitive coverage) for nearly two decades.
• Trajectory Mns. Manifestations whose own position evolves non-trivially. These are the targets of §4.3 trajectory analyses. In the landscape view they appear as moving dots.
• New entrants. Manifestations that were not in the landscape at earlier times and appear later. GitHub appearing alongside Git is the canonical example. New entrants often fill in primitives that nearby existing Mns lack.
• Departures and displacements. Manifestations that fade, are absorbed, or are displaced by competitors.
• Aggregate structures. Constellations of Mns that, viewed collectively, occupy a higher-primitive lattice region than any individual member does.

Notable observation: aggregates can masquerade as higher-primitive systems. Some aggregate structures formed by ecosystem accretion approximate higher-primitive configurations that no individual Mn achieves. The Git ecosystem (Git the software + GitHub + GitLab + Bitbucket + dependent CI/CD + package registries + dependency managers + ...) collectively approximates a partial entity system, even though Git itself only realizes a small fraction of the entity-arrangement primitives. The aggregate "masquerades" as the higher structure — but it is a degenerate form, because the cohesion is social/ecosystem (multiple parties, multiple substrates, accreted bridges) rather than architectural (one substrate with composable primitives).

This is a real structural observation worth capturing. It connects to attractor analysis and the layering trap from Paper 6: when no single system finds the full primitive set, the ecosystem around partial systems fills in the missing primitives via accretion, producing degenerate approximations of the full thing. Analyzing landscapes over time without recognizing the aggregate-as-degenerate-higher-primitive phenomenon will mislead you about what the landscape is actually doing.

Comparative landscape (cross-arrangement). Same kind of analysis across multiple arrangements simultaneously, looking for L3 abstractions. Fw=[<multiple>], Sc=3, Mn=null, Ls=[<multiple landscapes>]. Question: "Do landscape patterns in entity systems mirror landscape patterns in biology (e.g., are there structural attractors in both at homologous positions; do both produce ecosystem-level aggregate structures)?" This is Paper 11 territory.

Multi-arrangement coupling at Sc3 (ongoing structural). Sustained coupling between separate arrangements through shared instances over time — distinct from Sc4 single events (§4.5). Fw=[biology, cognition, entity], Sc=3, Mn=[<shared instances>], Cpl=[biology, cognition, entity], tj_mode=multi. Question: "How are instances in two arrangements ongoingly coupled (not just at a single moment)?" Example: an organization of biological developers building entity-arrangement instances is a sustained Sc3 coupling between biology, cognition, and entity arrangements. The cognition-arrangement instances depend on biology-arrangement instances (the developers are alive); the entity-arrangement instances depend on cognition-arrangement instances (someone has to think them up); and there are bidirectional feedback loops over time.

Sc3 sustained coupling — paired-manifestation form (added). A specific structural form of multi-arrangement coupling at Sc=3: each instance has TWO structurally coordinated positions — one in its primary arrangement (analytical structure) and one in the cognition arrangement (cultural artifact in collective use). Authoring convention: paired manifestations <artifact> (in primary arrangement) and <artifact>-cultural-artifact (in cognition arrangement, positioning the artifact in cultural-ecosystem + cognitive-architecture chain levels). Question: "What is the relationship between the artifact's analytical depth and its cultural-ecosystem reach, and what does that relationship reveal about the arrangement's depth-cost mechanism?" This is the layering-trap-for-X analytical pattern. Worked examples: methodology-arrangement landscape (13 strategic-analysis methodologies, Pearson r = −0.710 inverse correlation between depth and adoption) and entity-arrangement landscape (9 systems, r = −0.250). Analytically, the comparison surfaces three structural zones (mass-adoption, specialized, depth-over-reach) and distinguishes gradient-mechanism arrangements (smooth inverse) from walls-mechanism arrangements (bimodal). Methodological guide: how-to-apply-cross-arrangement-coupling.md.

Discipline rule (added for paired-manifestation Sc=3 coupling). The pairing convention is canonical. Don't mix analytical-structure positions and cultural-artifact positions in the same Mn — two arrangements → two Mns. Each cultural-artifact Mn must declare its ls (landscape) field with the family name (e.g. ["strategic-analysis-methodologies-cultural-artifacts"]). Each level claim in the cultural-artifact Mn must carry ~1-3 sentences of evidence (citation, deployment count, certification body, training-program enrollment). When reporting cross-landscape comparisons, report Pearson AND Spearman correlations — Pearson is sensitive to outliers, Spearman is rank-only. When correlations differ across arrangements, look for mechanism difference rather than papering with combined-landscape statistics.

Aggregate-as-degenerate-higher-primitive analysis (use case form). Specifically targets the aggregate phenomenon documented above. Fw=<arrangement>, Sc=3, Mn=[<aggregate members>], Ls=[<aggregate members>]. Question: "Does this aggregate masquerade as a higher-primitive system; if so, what is its degeneracy character (architectural cohesion vs. social/ecosystem cohesion)?" The Git ecosystem is the canonical example. This use case treats aggregate-masquerading as an analytical target rather than just an observation.

Structural-fingerprint comparison (added). A landscape-positioning use case that goes beyond scalar substrate-rank to preserve the per-Mn pair-realization and composition-realization shape. Fw=<arrangement>, Sc=3, Ls=[<Mns>], Cpl=fingerprint-projection. Per Mn, build a fingerprint vector with three slot types per relevant chain level: (a) raw partial-level positions per primitive, (b) pair-realizations (min(level_a, level_b) × intensity_weight per documented pair, heavy=3 / medium=2 / light=1), (c) composition-realizations (min(member_level) × member_count per documented composition). Pairwise cosine distance + classical MDS produces a 2D projection where structurally-similar Mns cluster regardless of their absolute substrate-rank. Compute: compute/scripts/plot_structural_fingerprint_landscape.py. Per-Mn comprehensive card view: compute/scripts/plot_mn_comprehensive.py (fuses combinatorial circle + heatmap fingerprint + evidence). Question: "Which Mns share structural shape vs differ in shape, and what structural classes emerge that scalar substrate-rank cannot distinguish?" Worked examples: entity-arrangement N=35 produces three structural classes (tools/protocols, app-class, OS/runtimes); biology N=20 produces phylogenetic gradient (mammals → vertebrates → eukaryotes → prokaryotes) without phylogenetic input in the data; methodology N=21 differentiates most strongly at L3 (graph semantics) not L1 (substrate). Caveat (per §2.5 Mn-kind heterogeneity): comparison must scope to chain levels the Mn-kind actually populates; cross-kind comparison is relational, not comparative.

4.5 Sc4 — Single-event analyses (cross-arrangement, shared physics)

Cross-arrangement event analysis. A single instantiated event spanning multiple arrangements through shared physics. Fw=<multiple>, Sc=4, Mn=<the specific event>, Cpl=<arrangements involved>, Cx=shared-physics. Question: "What positions do all the involved arrangements share at this moment, and how does the event propagate through cross-arrangement coupling?" Worked example: developer pressing a key (biology + cognitive + entity + hardware arrangements).

Manifestation snapshot. A unified manifestation at one specific moment in time. Fw=<one>, Sc=4 (or Sc=3 averaged over recent time), Mn=<specific>. Question: "What is this entity's full position right now across all chain levels of its arrangement?" Existing Git/Postgres/Bitcoin/Instagram analyses are this type.

4.6 Hybrid and meta analyses

Multi-scope analysis. Working at multiple Sc levels simultaneously to trace how patterns at one scope propagate to behavior at another. Each scope's view is its own artifact; the multi-scope analysis composes them via an inquiry (per L5 synthesis). Fw=<one>, Mn=<varied per scope>. Question: "How do strategic-level decisions (Sc0/Sc1) propagate to operational behavior (Sc3/Sc4), and where does the propagation chain break or amplify?" Currently flagged as open in methodology-advanced-topics.md; will become tractable as the unified analytical view (§2.8) supports view composition across scopes.

Causal attribution. Distinguish necessary, sufficient, contributing, and incidental causes of a transition in a trajectory. Fw=<one>, Sc=3, Mn=<trajectory-id>. Question: "Which mechanisms caused this transition; which were necessary; which were sufficient; which were merely correlated?" Standard analytical move; not yet formalized as a workflow but recurring across trajectory analyses.

Framework gap detection. Methodology applied to itself to check coverage. Fw=methodology, Sc=1, Mn=null. Question: "What use cases or analytical needs are not covered by current primitives, and is the gap real or just a missing catalog entry?" The Phase 0 use case coverage exploration is one instance. (Fw=methodology treats the methodology itself as an arrangement; standard Sc values apply.)

Methodology evolution analysis. Tracking how the methodology itself changes over versions. Fw=methodology, Sc=3, Mn=<methodology-vN>, tj_mode=single, tj_type=evolutionary. Question: "How has the methodology evolved (v1 → v2 → ...), what drove version transitions, what's converging and what's still open?" Currently informal in tracking docs; could become a formal trajectory analysis with the methodology as the Mn.

Methodology applied to itself. Treating L1, L2, L3, L4 (and the resolved L5 question) as their own domains. Done in methdology_domain_analysis/; the L5 synthesis (analysis-using-the-methodology.md) is the most recent instance.

4.7 Production / pedagogical use cases (non-analytical)

These are use cases of the framework that aren't framework-internal analyses but are how the framework gets applied to produce things outside itself. Listed for completeness; the catalog should not pretend they don't exist.

Paper writing. Render analytical results as academic prose. The 14 papers of this project are this use case. Outputs go into papers/NN/content/paper.md (existing format, not in the analytical format catalog).

New domain analysis (L1 12-step workflow). The L1 process applied to a new domain to produce a domain.v1 JSON. The recurring meta-workflow for building the framework's content. Documented in methodology.md.

Pedagogical exposition. Explaining the framework to a new analyst (human or AI). The methodology docs are artifacts of this; future onboarding documents would be too.

Tooling and infrastructure design. Building compute, building visualization, building data pipelines. Phase 1+ work is this use case.

4.8 What this taxonomy enables

When picking up new analytical work, identify which use case it is, set L4 controls accordingly, and build artifacts that answer the corresponding question. If the work doesn't fit any cataloged use case, that is a signal of either:

• A genuinely new use case that should be added to this catalog (rare; the framework is fairly complete), or
• A poorly-formed question that needs to be sharpened before any artifacts are produced (common; this is the failure mode that produced "random pictures with no meaning" in the prior session).

The catalog also makes it explicit that abiogenesis, ontogenesis, phylogenesis, and technogenesis are the same kind of analysis with different L4 settings. Code, data structures, and visualization templates built for one of them should be reusable for the others. Special-casing one use case is a sign the framework was applied incompletely.

Part 5 — Project layout

4.1 Documents

  methodology.md                          -- canonical methodology (L1-L4)
  methodology-advanced-topics.md          -- canonical advanced topics
  review-canonical-inventory.md           -- inventory of canonical docs
  methodology_strategy/
    canonical-architecture-strategy.md    -- THIS DOC (senior strategy)
    project-tracking.md                   -- operational state, decisions log
    computation-chain-strategy.md         -- chain-aware computation design
    probability-walk-design.md            -- Bayesian framework
    sagemath-computation-strategy.md      -- SageMath roadmap
    sagemath-implementation-plan.md       -- SageMath execution plan
    lean-formalization-strategy.md        -- Lean formalization roadmap
    lean-physics-feasibility-analysis.md  -- physics-in-Lean feasibility
  abstract_info_domain_analysis/          -- canonical abstract domains
  biology_domain_analysis/                -- partial canonical (abiogenesis only)
  entity_domain_analysis/                 -- v1 canonical (extraction needed for chain levels)
  physics_domain_analysis/                -- canonical
  cognitive_substrate_domain_analysis/    -- empty (extract from v1_revision)
  math_information_domain_analysis/       -- IT canonical, others gaps
  implementation_architecture_domain_analysis/  -- exploratory
  methdology_domain_analysis/             -- canonical
  v1_revision/                            -- prior-version source for extraction

4.2 Compute

The current compute/ will be moved to compute-legacy/ (preserving learnings: BFS reachability, corridor logic, coupling sketch). A new compute/ will be built with chain-aware data model and L4-labelled outputs from the start. Migration handled as a discrete step in §6.

compute/                  -- to-be-built, chain-aware, L4-labelled
compute-legacy/           -- prior prototype, kept for reference
data/
  domains/                -- per-domain JSONs (one lattice each)
  bridges/                -- per-bridge JSONs (also lattices)
  arrangements/           -- chain definitions referencing domains + bridges
  manifestations/         -- specific Mn analyses (Git, Postgres, etc.)
  landscapes/             -- landscape definitions (which Mns under consideration)
  rates/                  -- physics-rate models for Sc2 weighting
  walks/                  -- walk specifications and computation results
output/
  results/                -- JSONs from computation runs (with L4 headers)
  figures/                -- plots (with L4 captions)

4.3 Tracking

project-tracking.md is the operational doc. Updated each working session. Contains:

• Current phase
• Current sprint goal (what we're trying to ship now)
• Decisions log (date, decision, rationale)
• Gap inventory (what's known to be missing, ranked)
• Validation checklist (what has been verified against source)

Part 6 — Forward plan

Phase 0 — Documentation and discipline (this session)

• Write canonical architecture strategy (this doc). DONE.
• Write project tracking doc. DONE.
• Save corresponding memories. DONE.
• Decision pending: when to migrate compute/ → compute-legacy/.

Phase 1 — Entity arrangement Sc1 (next)

Why entity first: the user's mental model of the entity arrangement is more developed; the source documents in entity_domain_analysis/ are more complete; fewer chain levels (Hardware, Computing, Substrate, App, Ecosystem vs. biology's Chemistry, Biology, Organism, Cognitive, Cultural, Environment); already have one validated domain JSON (entity-system.json).

Deliverables:

1. Arrangement definition for entity, with all chain levels, bridges, and context root explicitly listed. Stored as data/arrangements/entity.json.
2. Per-domain lattice JSONs for hardware, digital computing, computing→entity bridge, entity substrate (already done), entity→app bridge, application architecture, app→ecosystem bridge, digital ecosystem, digital context. Each carries an L4 header.
3. Validation pass of each JSON against its source document in entity_domain_analysis/.
4. Sc1 computation infrastructure (new compute/) that takes an arrangement definition, BFS-explores reachability per-domain, applies bridge constraints between adjacent domains, and reports per-domain corridors with L4-labelled output.
5. First end-to-end run producing per-domain corridors and bottlenecks for the entity arrangement, with each output carrying L4 labels.

Validation criterion: every output answers a stated question at a stated scope, with a stated arrangement, and is interpretable by a reader who has only read this document and the methodology.

Phase 2 — Biology arrangement Sc1

Repeat Phase 1 structure for biology. More work because the chain is longer and more domain JSONs need extraction from v1_revision/. The abiogenesis sub-level analysis is already canonical and feeds in here.

Phase 3 — Sc1 → Sc2 weighting

Add the rate-model layer. rates/ directory populated. Bayesian framework from probability-walk-design.md operationalized. Corridor probabilities, expected populations, expected times become computable. Verify on biology (we have empirical milestones to validate against) before claiming entity-arrangement timing.

Phase 4 — Sc3 conditioning, landscape views, trajectory analyses

Three workstreams sharing the same Sc3 machinery:

1. Landscape positioning (snapshots). Use the existing unified manifestation analyses (Git, Nix, Postgres, Bitcoin, Instagram, Linux, Minecraft) as Sc3 evidence to condition the Sc2 entity-arrangement distribution. Produce landscape views showing where each canonical system sits in the entity-arrangement lattice. Connects to Papers 0 and 6.
2. Landscape evolution (multi-Mn co-evolution). Render the unified analytical view (§2.8) with the time dial active: how the population of co-existing manifestations shifts over historical time, where new entrants appear (the Git+GitHub+ecosystem-accretion pattern), and where aggregate-as-degenerate-higher-primitive structures form. Connects to Papers 6 and 11.
3. Trajectory analyses (X-genesis family). Abiogenesis (biology arrangement, requires Phase 2), ontogenesis (biology, developmental bridge), phylogenesis (biology, evolutionary), technogenesis (entity, evolutionary). Same machinery as the landscape evolution workstream — every X-genesis is a single-Mn (or Mn-class) projection of the broader landscape evolution view. Connects to Papers 11, 12.

Common requirement: the unified analytical view must take L4 settings as parameters from the start. Outputs are not "the entity landscape plot" — they are render(Fw, Sc, Mn, Cx, Ls, tj_mode, tj_type, Cpl). Re-running with different settings re-renders without rebuilding.

Phase 5 — Cross-arrangement coupling at Sc4

Work the developer-pressing-key example end-to-end. Identify all arrangements involved, their positions, and the shared physical substrate at the convergence point. This is the deliverable that connects to Papers 8, 11, 12, 13.

Phase 6 — Cognition and AI cognition extension

Extract cognitive chain from v1_revision/. Speculative AI cognition chain (entity substrate → Kd3/Kd4 type systems → artificial cognitive architectures) drafted as new analysis. Long-tail.

Part 7 — Relationship to existing documents

This document is the senior strategy. The other strategy docs operate within the framework here:

• methodology.md and methodology-advanced-topics.md define the framework. This doc is downstream of them and applies them.
• computation-chain-strategy.md — chain-aware data model. Still valid; this doc adds the L4 discipline that was implicit there.
• probability-walk-design.md — Bayesian framework. Still valid; this doc places it explicitly at Sc2/Sc3 in the scope ladder.
• sagemath-computation-strategy.md and sagemath-implementation-plan.md — implementation roadmaps. Operate within this architecture; some details may need revision once Phase 1 lands.
• lean-formalization-strategy.md and lean-physics-feasibility-analysis.md — long-horizon formal verification. Independent of this doc but informed by the same scope ladder.
• session-status.md — preserved as the diagnostic of the prior failure. The "what needs to happen" section there is partially superseded by this doc and §6 here.

Future strategy docs in this directory should reference this document and identify where they fit in the architecture.

Appendix A — Quick reference: L4 primitive definitions

For rapid lookup when writing artifact headers:

• Fw — Framework. Which arrangement we are working in. E.g. biology, entity, methodology. Cross-arrangement work labels both: entity × biology for coupling work.
• Mn — Manifestation. A specific entity's full position across an arrangement. E.g. git, postgres. none if working at Sc0–Sc2 without specific instance in view.
• Sc — Scope. Integer 0–4. See §2.2.
• Cx — Context. Boundary conditions. Usually the context-root domain (environment-prebiotic, digital-context) but can be more specific.
• Ls — Landscape. Set of manifestations under joint consideration. E.g. {git, postgres, bitcoin, instagram} for software landscape work.
• Cpl — Coupling. Cross-arrangement connection through shared instances. Active at Sc3+.
• Tj — Trajectory. A manifestation's path through arrangement positions over time. Active at Sc2+. Schema-side, split into two fields: tj_mode (null/single/multi — how many Mns are tracked) and tj_type (historical/developmental/evolutionary/cultural/lifetime/counterfactual/comparison/inferred-backwards — what kind of trajectory). The conceptual primitive Tj is unchanged; the schema split is to keep mode and type as orthogonal dimensions.

Appendix B — Quick reference: artifact tagging examples

These are schema-valid meta blocks per compute/schemas/_l4_header.v1.schema.json. JSON form shown; YAML inputs convert to the same structure.

Authored domain JSON (Sc1 topology):

{
  "meta": {
    "schema": "domain",
    "version": 1,
    "fw": "entity",
    "sc": 1,
    "mn": null,
    "cx": "digital-context",
    "ls": null,
    "tj_mode": null,
    "tj_type": null,
    "cpl": null,
    "question": "What is the coherent sub-lattice of the entity substrate domain?",
    "produced_at": "",
    "produced_by": "author"
  }
}

Walk computation output (Sc1 corridor):

{
  "meta": {
    "schema": "corridor",
    "version": 1,
    "fw": "biology",
    "sc": 1,
    "mn": null,
    "cx": "environment-prebiotic",
    "ls": null,
    "tj_mode": null,
    "tj_type": null,
    "cpl": null,
    "question": "What is the structural corridor of the R0->R2 walk through the biology arrangement?",
    "produced_at": "",
    "produced_by": "bfs_corridor@v1",
    "provenance": {
      "inputs": [
        { "path": "data/arrangements/biology.v1.json", "content_hash": "sha256:0000000000000000000000000000000000000000000000000000000000000000" },
        { "path": "data/walks/r0-to-r2.v1.json",       "content_hash": "sha256:1111111111111111111111111111111111111111111111111111111111111111" }
      ],
      "procedure": "bfs_corridor@v1",
      "parameters": { "max_depth": null }
    }
  }
}

Landscape positioning snapshot (Sc3 conditioning, no trajectory):

{
  "meta": {
    "schema": "view_render",
    "version": 1,
    "fw": "entity",
    "sc": 3,
    "mn": null,
    "cx": "digital-context",
    "ls": ["git", "postgres", "bitcoin", "instagram", "linux", "minecraft"],
    "tj_mode": null,
    "tj_type": null,
    "cpl": null,
    "question": "Where do canonical software systems sit in the entity-arrangement lattice?",
    "produced_at": "",
    "produced_by": "landscape_render@v1",
    "provenance": {
      "inputs": [{ "path": "data/landscapes/canonical-software.v1.json", "content_hash": "sha256:2222222222222222222222222222222222222222222222222222222222222222" }],
      "procedure": "landscape_render@v1"
    }
  }
}

Cross-arrangement event (Sc4 with full-stack coupling):

{
  "meta": {
    "schema": "coupling_analysis",
    "version": 1,
    "fw": ["biology", "cognition", "entity", "hardware"],
    "sc": 4,
    "mn": "developer-keypress-event--001",
    "cx": "shared-physics",
    "ls": null,
    "tj_mode": null,
    "tj_type": null,
    "cpl": ["biology", "cognition", "entity", "hardware"],
    "question": "What are the simultaneous positions of a single keypress event across all arrangements it participates in?",
    "produced_at": "",
    "produced_by": "coupling_analyze@v1",
    "provenance": {
      "inputs": [{ "path": "data/events/keypress-001.v1.json", "content_hash": "sha256:3333333333333333333333333333333333333333333333333333333333333333" }],
      "procedure": "coupling_analyze@v1"
    }
  }
}

Trajectory analysis (ontogenesis, Sc3, single-Mn developmental):

{
  "meta": {
    "schema": "trajectory_analysis",
    "version": 1,
    "fw": "biology",
    "sc": 3,
    "mn": "drosophila-melanogaster-developmental-program",
    "cx": "maternal-environment",
    "ls": null,
    "tj_mode": "single",
    "tj_type": "developmental",
    "cpl": null,
    "question": "What positions does Drosophila melanogaster occupy through its development, and where do canalization branch points occur?",
    "produced_at": "",
    "produced_by": "trajectory_analyze@v1",
    "provenance": {
      "inputs": [{ "path": "data/trajectories/drosophila-ontogeny.v1.json", "content_hash": "sha256:4444444444444444444444444444444444444444444444444444444444444444" }],
      "procedure": "trajectory_analyze@v1"
    }
  }
}

Referenced by the model

Cited as a source by 14 model records (browse the model census):

• entity — arrangement entity/sc1
• developer-keypress-event — manifestation biology+cognition+entity/sc4/developer-keypress-event
• entity-system-cultural-artifact — manifestation cognition/sc3/entity-system-cultural-artifact
• entity-system-maximal-adoption — manifestation entity/sc3/entity-system-maximal-adoption
• entity-system-modest-adoption — manifestation entity/sc3/entity-system-modest-adoption
• entity-system — manifestation entity/sc3/entity-system
• spoken-utterance-event — manifestation biology+cognition/sc4/spoken-utterance-event
• structural-primitive-analysis — manifestation methodology/sc3/structural-primitive-analysis
• abiogenesis-calibrated — rate abiogenesis/sc2
• abiogenesis — topology abiogenesis/sc1
• cross-arrangement-substrate — topology cross-arrangement-substrate/sc1
• entity — topology entity/sc1
• methodology — topology methodology/sc1
• paired-coupling — topology paired-coupling/sc3