This manual walks you through the Everythingist Research Dashboard from the analyst's seat — what each tab is for, what each visualization is showing, what each metric means in plain English, and what decisions the tool can and cannot support. It is written for psychological scientists who are comfortable reading a correlation matrix and running a paired t-test, but who have not specialized in self-complexity research and have not read the original AST formulation. Where we use jargon (Welch's correction, Mann–Whitney U, Louvain modularity), we define it the first time it appears.

The dashboard ingests JSON files exported from the Everythingist Self-Space app — a browser-based tool in which participants build a map of their self-aspects (the “hats” they wear: parent, athlete, professor, partner) and the attributes that describe each one. The dashboard then produces individual-level deep dives, cohort-level summaries, and multi-cohort comparisons across self-complexity, identity strength, and longitudinal change. It runs entirely in your browser as a single HTML file. No data leaves your machine. There is no server, no database, and no upload step beyond drag-and-drop into the page.

This manual is current as of dashboard version v0.17.1 (Phase 5E.2 complete). Features marked [PLANNED] are described in the dashboard specification but are not yet shipping; we will flag them as we go.

The Everythingist Research Dashboard is a client-side analytics application: open the HTML file in a recent browser, drop in your JSON files, and the dashboard builds an in-memory data store of participants and journeys. It then exposes that data through six tabs — Upload, Identity Space, Metrics, Cohort Comparison, Export, and Publication — that together cover ingestion and quality control, individual deep dives, cohort-level summaries, multi-cohort statistical comparison, and manuscript-ready output. Everything is computed in JavaScript at the moment you ask for it; nothing persists between sessions other than a few UI preferences in localStorage. Closing the tab clears the data.

The dashboard expects one JSON file per journey — that is, per snapshot of a participant's self-map at a single point in time. A participant who completed the app three times produces three JSON files. Within each file is the participant's mapping across three temporal periods (past, present, future), where each period contains an array of self-aspects, each aspect contains an array of attributes, and each aspect and attribute has ratings on importance, certainty, descriptiveness, valence, and (for aspects) visibility. The dashboard groups files by participant automatically using a four-level priority chain — explicit participantKey, then a structured title parse like Alice_P001, then the raw title, then a stable hash of the journey ID — so you can mix research-grade exports with anonymous-mode exports in the same analysis without losing the longitudinal links you have or fabricating ones you don't.

A useful mental model: the app is what your participants used to build their self-spaces; the dashboard is what you use to analyze the structural products. The app's terminology (“self-aspects,” “Self-Space”) is preserved at the user-facing layer; the dashboard often switches to “identity space” and “aspects” because the audience is researchers, not participants.

The Upload tab is your first stop. There are three things to do here, in order: drop your files, read the Data Quality panel, and triage the issues it surfaces. The dashboard will not stop you from skipping straight to analysis, but you should not.

§ 2.1 Drag, drop, parse

Drag one or more JSON files onto the Upload zone, or use the file picker. Files larger than 5 MB are rejected at parse time — this protects against accidentally dropping a malformed export or a non-Self-Space document. Each file flows through a strict ingestion sequence: parse, normalize (fill in missing fields with sensible defaults), record schema-version metadata, resolve a participantKey for grouping, validate, recompute all metrics from the raw data, and store. The dashboard pointedly never trusts client-provided metric values — every metric you see was recomputed inside the dashboard from the raw self-map. The original client-computed metrics are preserved as clientMetrics in the full JSON export for audit purposes only.

A “Load Synthetic Demo Cohort” button generates 20 participants with 40 journeys (every fixture has at least two journeys) through the same ingestion pipeline. This is the fastest way to explore the dashboard's behavior before pointing it at real data.

Screenshot · FIG 2.A Upload tab with drag-and-drop zone, integrity panel, and Data Quality scanner output visible after a synthetic-cohort load.

§ 2.2 The Data Quality Scanner

After ingestion, the DataQualityScanner runs automatically. It performs two kinds of checks. Per-journey checks flag placeholder aspect names ("Click to edit", "Self-Aspect 3", empty strings); empty attribute names; all-default ratings (importance/certainty/descriptiveness all at midpoint with neutral valence — likely an unrated aspect); rapid completion (export time minus creation time under 60 seconds, suggesting a speed-through); aspect-count extremes (zero aspects in any period, or more than 15); missing participant identity fields; and the source app's dataQuality.exportClean flag when it came in as false. Cross-journey checks group files by participant and look for likely duplicates within 30 minutes, accidental re-exports, and same-anonId-different-journeyId patterns. The scanner is schema-aware: as of schema 1.6.0 the rating midpoint shifted from 5 to 6, so the all-default check accommodates both possibilities depending on the file's declared schemaVersion.

Each issue lands in the Quality Panel as a card with severity (warning or info), participant label, source filename, and a row of action buttons: Exclude from aggregates, Keep anyway, Keep all (longitudinal), Keep latest only, Add to contact list, or Assign ID manually. The default is conservative: warning-severity issues auto-exclude the journey from aggregate analytics, and you have to click Keep anyway to bring it back. Info-severity issues do not auto-exclude. Every journey carries a _qualityStatus field that takes one of pending, clean, flagged, or excluded; only clean (and flagged ones explicitly kept) flow into aggregates.

Two CSV exports — Quality Report and Contact List — are produced from this panel; we discuss them in the Exports section.

§ 2.3 Reading the Integrity Panel

Above the Quality Panel you'll find an Integrity panel that summarizes ingestion at the file level: how many files arrived, how many normalized cleanly, what schema versions are in the mix, and (since schema 1.7.0) a Session Integrity subsection that breaks the cohort down by session-cleanliness state. Those states matter enough that they deserve their own section.

Screenshot · FIG 2.B Data Quality panel showing a mix of warnings and info cards with the action-button row visible, plus the Integrity panel above it.

Schema 1.7.0 of the Self-Space app added a sessionIntegrity block to every export. This block records what happened during the session that produced the journey: how long the participant was actively on-task versus idle, how many idle warnings fired (at the 30-minute, 2-hour, and 12-hour thresholds), whether the participant confirmed a contamination review, and what the app's overall verdict was. That verdict — sessionCleanliness — takes one of five values:

• clean: No idle warnings, no contamination flags. The participant did the task in one continuous session.
• review-confirmed: An idle warning fired, the participant returned, reviewed their map, and explicitly confirmed everything was still theirs. Equivalent to a clean session with a check-in.
• review-pruned: Same as above, but the participant removed one or more aspects during the review. The remaining aspects are theirs; the pruned ones aren't in the export.
• previously-contaminated: A contamination event happened earlier in the session and was not adequately reviewed.
• unknown: Pre-1.7.0 imports that don't have session data. The dashboard synthesizes this placeholder during normalization so downstream code has a value to dispatch on.

The dashboard exposes a single filter — the Integrity Filter — in the header that controls which journeys flow into every cohort-aggregate calculation. There are three modes:

Your choice is sticky — it persists across page reloads via localStorage. The filter is applied at every aggregation point in the system: cohort means, longitudinal trajectories, identity-space co-occurrence graphs, per-snapshot trajectories, and the cohort-comparison statistical pipeline. Pre-1.7.0 imports (those unknown placeholders) are excluded under both clean-only and review-confirmed-and-clean modes; they appear only when the filter is set to all.

When you switch to all mode and the cohort actually contains contaminated sessions, a banner appears at the top of the dashboard reminding you that some metrics may be unreliable. The banner is gated to fire only when contamination is genuinely present — a 100%-clean cohort viewed in all mode does not trigger it.

The exports do not respect the filter — they always emit all clean (non-excluded) journeys with the per-journey sessionCleanliness value carried as a column, so that downstream filtering in R or SPSS is explicit and traceable. This is intentional: the on-screen filter governs what you see; the export carries the full population so you can document your inclusion decisions in your manuscript.

Screenshot · FIG 3.A Header bar showing the Integrity Filter selector and the Session Integrity subsection of the Integrity panel with per-state counts.

A cohort in this dashboard is a labeled group of participants. The dashboard supports up to four cohorts simultaneously, distinguished by user-editable label and color. One cohort is always the primary — its data lives in the main DataStore and drives the legacy single-cohort tabs (Identity Space cohort scope, Metrics cohort scope, Export, Publication). The other cohorts (up to three additional) live in the CohortRegistry as snapshots and are accessed through the Cohort Comparison tab.

The first time you upload, your files land in the primary cohort. This is the workflow most users want: a single group of participants, drop the files, analyze. If this is your situation, you can ignore the cohort machinery entirely.

If you want to compare two or more groups — treatment vs. control, semester A vs. semester B, classroom 1 vs. classroom 2 — open the Cohort Comparison tab. The Cohort Manager at the top of that tab lets you click + Add Cohort, give it a label and a color, and drop files directly into the new cohort.

Behind the scenes, the dashboard uses a transient-write pattern: it temporarily swaps your new cohort's storage into place as if it were primary, runs all the canonical pipeline modules (validator, scanner, metrics engine, etc.) on it, then swaps the original primary back. The user-facing consequence is the one that matters: every cohort gets the same quality scrutiny and the same metric computations as the first one, and cohorts stay completely isolated from one another. Nothing bleeds across.

You can rename, recolor, designate a different primary, or delete cohorts at any time. Cohort data does not survive page reloads (you re-upload each session, just as you would for a single-cohort workflow) but cohort labels and colors do, so your “Treatment” cohort comes back orange even after a refresh. Each cohort row also carries an “Activate for comparison” checkbox; the comparison panels render only for cohorts that are checked, with a maximum of four active.

Screenshot · FIG 4.A Cohort Comparison tab Cohort Manager with three cohorts loaded, showing label-edit, color swatch, primary radio, activate checkbox, and N counts.

The Identity Space tab is the dashboard's primary visual concept. Its underlying premise is that researchers think about identity structure as the same kind of thing at different scales: a cohort's identity space is the aggregation of the individual identity spaces inside it. Treating these as separate tabs would reinforce a false hierarchy. Treating them as one tab with a scope toggle (Cohort | Individual) exposes the unity.

§ 5.1 Cohort scope: the co-occurrence network

In cohort scope, the Identity Space tab renders a force-directed network where nodes are unique aspect labels (e.g., “runner,” “mother,” “musician”) and edges connect aspects that co-occur within the same participant's journey. Edge weight is the number of participants who hold both aspects. Node size encodes overall frequency in the cohort. Node color encodes whichever attribute you select in the control bar — physical-identity tier, dominant valence, or raw frequency.

This is exploratory, not statistical. Click a node and a side panel slides in from the right showing the aspect's frequency, participant count, dominant valence, physical-identity tier, the aspects most commonly co-occurring with it, and a list of the participants who hold it. Clicking a participant in that list drills into the individual scope of the same tab with that participant pre-selected — so the tab acts as both a panoramic view and a navigation surface into the cohort.

§ 5.2 Individual scope: the per-participant map

Switch to individual scope and the tab becomes the Individual Identity Space — a researcher-grade rendering of one participant's self-map. The default view is a three-column layout (Past | Present | Future), with aspects listed in salience-rank order within each column. Each aspect card encodes:

• Salience rank as a numeric prefix (1 = the participant's first-created aspect for that period, which is treated as a proxy for top-of-mind salience).
• Valence as the fill color (green for positive, gray for neutral, red for negative).
• Physical-identity tier as a colored ring around the card (Tier 1 Embodied = orange; Tier 2 Role = violet; Tier 3 Value = green).
• Cohort frequency as a small caption (“8 / 20 participants”) that appears when the participant belongs to a cohort with at least two members.

Hover or focus an aspect for a tooltip showing its full name, importance/certainty/descriptiveness/visibility ratings, attribute count, tier label, and cohort frequency.

A second layout option, Force-Directed, places all aspects from all three periods on a single d3 force simulation with charge, link, center, and collision forces. Cross-period same-name pairs (e.g., “runner” in past and present) link with strength 0.6 to cluster recurring identities. Period is encoded by HSL modulation of the valence color: past is desaturated and darkened (sepia-feeling), present is the canonical valence color, future is brighter. The force-directed layout disables itself with an inline note when a participant has more than 50 aspects, both for legibility and for simulation performance. If your participant prefers reduced motion, the simulation runs synchronously to convergence before render — no animation at all.

A third dimension, view mode (Single Snapshot vs. Across Snapshots), is orthogonal to layout. Single Snapshot shows one journey at a time, navigable via Prev/Next arrows, a search-by-Study-ID input, and a snapshot timeline strip below the dropdown. Across Snapshots renders a horizontal sequence of compressed three-column panels, one per journey, with explicit visual encoding of how aspects evolve. Aspects emerging in a snapshot get a glow; disappearing aspects from the prior snapshot appear with a strikethrough; expanding/contracting aspects show an attribute-count badge (+2, −1); persisting aspects render solid; salience-rank shifts are annotated with arrows whose emphasis scales with the size of the shift. Below the panel sequence, a change-summary block per transition lists counts (emerged, disappeared, expanded, contracted, persisting) with cohort-comparison annotations like “Above cohort median for emergence in this period.”

§ 5.3 What the Identity Space view teaches you that a metric table cannot

Two participants with identical Scott H values can have very different identity shapes. One might have eight tightly-bounded, well-separated aspects; another might have eight aspects that all share the same five attributes. The metric numbers can look similar; the picture is not. Likewise, two cohorts with the same mean self-complexity score can produce different co-occurrence networks — one might cluster around physical/embodied identities, the other around social/role identities. The Identity Space view exists to surface this kind of structure, which the metric panel will not.

Screenshot · FIG 5.A Identity Space individual scope, participant P012, three-column layout showing past/present/future with cohort-frequency annotations and a tier ring around one aspect.

Screenshot · FIG 5.B Identity Space cohort scope, force-directed co-occurrence network with the side panel open on a clicked aspect node.

The Metrics tab is the analytic heart of the dashboard. It shares the same Cohort | Individual scope toggle as the Identity Space tab, and its content is gated by your scope choice.

§ 6.1 Aggregate (Cohort) scope

In cohort scope, the Metrics tab is reorganized into three sections (introduced in Phase 5D):

1. Longitudinal Cohort Trajectories. For any selected metric, the dashboard plots per-snapshot cohort means — the average value at journey 1, journey 2, journey 3, and so on — with ±1 SEM bands and snapshot-N annotations. The mechanics: for each snapshot index i, the dashboard collects every multi-journey participant's i-th journey, drops the participant if they lack one, computes the mean and SEM of the metric at that index, and plots. This is not the same as a longitudinal linear mixed model — there is no participant random effect and no slope estimation. It is a description of how the cohort's average looked at the first measurement, the second, the third. Treat it as a visual aid for spotting trends, not as inference.
2. Distributions. Single-cohort histograms and box summaries for the present period. Self-complexity (expSC) gets a histogram; the other primary metrics get descriptive cards (M, SD, min, max, N).
3. Cross-Sectional Comparisons. Period-by-period mean tables (mean ± SD for each metric across past, present, and future), plus the Cohort Profile card and Cohort Interpretation card from earlier phases. The Cohort Profile assigns a categorical label like “Expanding” or “Consolidating” with a confidence rating and a “Why this label?” expandable rationale. The interpretation block surfaces dominant patterns and structural emphases. These are heuristic — useful for first looks and grant figure captions, not for hypothesis testing.

The cohort scope also surfaces an ISI radar — a six-axis Chart.js radar of the cohort-mean Identity Strength Index (described below) — as well as physical-identity tier prevalence, valence distribution, and longitudinal change-pattern distribution.

§ 6.2 Individual scope

In individual scope, the Metrics tab renders the per-participant view: a participant selector dropdown with longitudinal and trajectory-classification badges, then for each journey:

• Trajectory chart (when the participant has ≥ 2 journeys): a Chart.js line plot of any selectable metric across the participant's journeys, with separate series for past, present, and future periods.
• Per-journey metric cards with delta from the previous entry.
• Aspect summary tables showing aspect name, attribute count, importance/certainty/descriptiveness, valence, and physical-identity tier.
• Longitudinal summary: a first-vs-latest comparison surfacing emerged aspects, disappeared aspects, expanded aspects (with attribute-count delta), contracted aspects, strengthened aspects (composite rating delta ≥ 2 across importance + certainty + descriptiveness), and weakened aspects (composite delta ≤ −2). A trajectory classification badge — Expanding, Stable, Consolidating, or Fragmenting — sits in the participant header.
• ISI radar for the selected journey, with a longitudinal overlay option that shows the radar at first and latest journeys on the same axes.
• Per-participant integrity badge with a hover tooltip showing active dwell, idle warnings by tier, aspects removed during review, and contamination event count.

§ 6.3 The metric inventory, with plain-language interpretations

The dashboard computes 21 self-complexity metrics organized into eight sections, plus the six ISI dimensions. Below is a quick tour. The mathematics live in the Self-Complexity Measurement Specification (v2.2); we focus here on what each metric means. Where a metric was developed by Sean P. Mullen for this project, we mark it as (novel).

A. Legacy metrics

NSA (nsa) is just the count of self-aspects — how many “hats” the participant wears. Scott H (scottH) measures how differently the participant's traits are sorted across roles. If every role uses the same traits, H is low; if each role draws from its own unique mix, H is high. Note: this is the original Scott (1969) formula; the field often calls it “Linville's H” because Linville (1985, 1987) adopted it, but the math is Scott's. H is psychometrically limited because it confounds the number of aspects with their overlap. Reportable, but never interpreted alone.

B. Component metrics

Overlap (OL) (overlapOL) measures how much the participant's roles recycle the same traits — directionally, following Tversky's (1977) asymmetry argument that similarity is not a symmetric relation. High OL = lots of recycling; low OL = each role has distinctive content. Mean Jaccard (meanJaccard) is the symmetric counterpart, useful for visualization and as the default weight for the network metrics.

C. Composite

Sakaki SC (sakakiSC) is the ratio NSA/OL — many unique roles ÷ how much they overlap. Many roles with little recycling = high SC; few similar roles = low SC. The dashboard returns null rather than a stabilized value when OL = 0 (every role uses entirely unique traits). Standard practice is to exclude these participants from SC analysis. The dashboard does not silently substitute an ε-stabilized value; what you see is the mathematically honest answer, even when it's “undefined.”

D. Spatial / AST metrics

These follow the spirit of Schleicher & McConnell (2005) and treat each aspect as a centroid in trait-coordinate space. Between-Aspect Separation B (betweenSeparation) is the total distance between role pairs; Mean Separation B̄ (meanSeparation) is the per-pair average, comparable across people with different aspect counts. Within-Aspect Spread W (withinSpread) is how diverse the traits within a single role are, averaged across roles.

AST SC (astSC) and normalized AST SC (astSCnorm) are the signal-to-noise interpretations: how far apart are roles relative to how spread out each one is internally? Both return null when W is null (i.e., when every aspect is a singleton).

E. Derived structural metrics (novel)

These extend the spatial intuition. Crystallization (crystallization) is 1/(W + ε) — high values mean tightly defined, internally coherent roles; low values mean diffuse, loosely organized ones. Distributedness (distributedness) is K · B̄ — the total identity “real estate” the participant occupies. Isolation Ratio (isolationRatio) is B̄/(W + ε) — how independent the roles feel from one another. Identity Rigidity Index (IRI) (rigidityIndex) measures how locked-in each role's trait profile is. All four return null when W = null.

F. Connectivity metrics (novel)

Mean Bridge Load (meanBridgeLoad) is the average number of roles that each trait connects — a high value means there are many cross-aspect connectors. Proportion Shared (propShared) is the fraction of traits that appear in more than one role.

G. Network metrics

Spillover Risk Index (SRI) (spilloverRisk, novel) captures the likelihood that a difficulty in one role bleeds into others — driven by overlap and spatial proximity. High SRI means high spillover risk; low SRI means buffered, compartmentalized structure. Modularity Q (modularity) is Newman's (2006) modularity computed over a Louvain (Blondel et al., 2008) partition of the aspect graph. Louvain modularity, briefly, is a community-detection algorithm that greedily merges nodes into clusters that maximize the within-cluster edge density relative to a null model. High Q means well-separated identity modules (a “work cluster,” a “home cluster”); low Q means everything tangles together.

H. Distributional metrics

Identity Entropy (identityEntropy, Shannon, 1948) and its normalized variant (identityEntropyNorm) measure whether roles are evenly weighted or one dominates. Balance Index (balanceIndex, novel) — already normalized — is the same intuition expressed via the standard deviation of role weights. High balance means evenly weighted roles; low balance means one or a few dominate.

§ 6.4 The Identity Strength Index (ISI)

The Identity Strength Index, developed by Sean P. Mullen, summarizes the structural health of a person's identity system across six dimensions. The conceptual framework draws on Linville (1985, 1987), McConnell (2011), Campbell et al. (1996), Donahue et al. (1993), and Rafaeli-Mor & Steinberg (2002). Critically, ISI is not a single scalar — it is a profile.

Two design choices matter for interpretation. First, Integration uses Gaussian-peak functions for prop-shared and modularity, because both extremes are undesirable: zero sharing means isolated silos, excessive sharing means an enmeshed identity. The optimal values (PS_OPTIMAL = 0.25, Q_OPTIMAL = 0.20) are theoretical first estimates and should be empirically calibrated — the dashboard ships them as defaults, not as established norms. Second, the dashboard does compute an _overallMean field as the arithmetic mean of non-null dimensions, but this is provided for sorting and screening only. Profile shape matters more than the average. Two participants with identical means can have very different profiles (one strong-on-DIF/weak-on-INT, another flat across all six), and the substantive interpretation depends on the shape.

ISI tracks longitudinally as well. The detectChangePattern() function classifies cross-journey changes into Strengthening (3+ dimensions up), Weakening (3+ down), Rebalancing (mixed), Crystallizing (coherence + commitment up, differentiation stable), Fragmenting (differentiation and integration both down), or Stable (default). Use these as descriptive labels, not as diagnostic categories — they are first-pass heuristics and will benefit from empirical refinement.

Screenshot · FIG 6.A Metrics tab individual scope showing the per-journey metric cards, ISI radar with longitudinal overlay, and the longitudinal summary block with emerged/disappeared/expanded/contracted/strengthened aspects.

The Cohort Comparison tab is the methodologist's home. Its job is to take the 2–4 cohorts you've activated, compute distributional summaries for each, run an appropriate statistical test, report effect sizes and confidence intervals, and surface the result alongside identity-space side-by-sides and aspect-overlap visualizations. It rests on a substantial in-house statistics library (CohortStatistics) that ships its own distribution functions — error function, regularized incomplete beta and gamma, t and F and χ² CDFs, studentized range — built on textbook approximations (Abramowitz & Stegun for erf, Lanczos for log-gamma, Lentz continued fractions for incomplete beta). These are sufficient for screening-grade p-values; methodologists wanting extreme-tail asymptotic results or exact ptukey values should re-run in R.

The tab follows an empty-state cascade: with no cohorts loaded, you get an upload prompt; with cohorts loaded but fewer than two activated, you get an “activate at least two cohorts” message with quick-action buttons; with two active you get boxplot comparisons; with three or four active you get violin plots.

§ 7.1 Distribution comparisons (boxplots and violins)

The dashboard renders comparisons for four primary metrics at the present period: experimental self-complexity (expSC), positivity ratio, average certainty, and average importance. With two cohorts active, each metric gets a side-by-side boxplot built from a Tukey-style summary (whiskers extend to the most extreme datum within 1.5×IQR; beyond that is an outlier, plotted as a discrete point). Raw points are jittered over the boxes when N ≤ 60. With three or four cohorts active, the boxplots become violin plots — kernel-density-estimate plots (Gaussian kernel, Silverman's rule of thumb for bandwidth) with median and quartile lines overlaid, again with raw points when N is small enough.

§ 7.2 Statistical dispatch (compareTwo and compareMany)

The dashboard's two-cohort dispatcher (compareTwo) follows a small, defensible decision tree. With n < 3 in either group, it refuses to test and says so explicitly. Otherwise it runs Shapiro–Wilk on each group (a normality screen valid for 4 ≤ n ≤ 5000, using Royston's 1982/1992 normal approximation to the W statistic) and Levene's test — specifically the Brown–Forsythe variant, which centers deviations on the median rather than the mean and is more robust to non-normality.

When the parametric branch fires, the dashboard runs Welch's t-test (Welch, 1947), which is robust to unequal variances by construction — no pre-screening with Levene is needed in the two-sample case. (Levene is reported for transparency but does not gate dispatch in compareTwo.) When the non-parametric branch fires, the dashboard runs Mann–Whitney U (Mann & Whitney, 1947), which is a rank-based test of whether one of two random variables is stochastically larger than the other. For very small samples (n₁ + n₂ < 16) with no ties, the dispatcher automatically swaps to an exact Mann–Whitney routine that enumerates all U-statistic arrangements via dynamic programming — this matches R's wilcox.test(exact = TRUE) to the published precision and resolves a known small-sample over-conservatism in the asymptotic version.

The three-or-more-cohort dispatcher (compareMany) uses the same OR rule for parametric vs. non-parametric, but additionally consults Levene's: if the parametric path fires and Levene rejects equal variances, the dispatcher runs Welch's ANOVA (Welch, 1951) instead of classic ANOVA — same logic as Welch's t, scaled up to k groups. A Force classic ANOVA checkbox lets you override this when you have good reason. The non-parametric three-plus path is Kruskal–Wallis with tie correction (Kruskal & Wallis, 1952). Post-hoc tests dispatch automatically when omnibus p < 0.05: Tukey HSD (Tukey, 1949) for the parametric path, Dunn (Dunn, 1964) for the non-parametric path. Dunn's adjustment method is exposed as a dropdown — the default is Bonferroni–Holm (Holm, 1979), with options for plain Bonferroni or Benjamini–Hochberg FDR (Benjamini & Hochberg, 1995). The adjustment method is named explicitly in the table caption when post-hoc results render.

§ 7.3 Effect sizes and confidence intervals

For two-cohort comparisons, the dashboard always reports both Cohen's d (with the classic sign-preserving formula and Cohen 1988 magnitude thresholds) and Hedges' g (Hedges, 1981 small-sample correction), alongside rank-biserial r computed via the algebraic identity r = 1 − 2U/(n₁n₂), which falls naturally out of the U statistic. Rank-biserial r substitutes for Cliff's δ in this build; both convey the same magnitude/direction information at the same interpretation thresholds. Reporting both Cohen's d and rank-biserial r regardless of which test fired is intentional: it lets a reviewer see both magnitudes side by side.

Confidence intervals follow the path. The parametric branch reports a closed-form 95% CI on the mean difference using the Welch–Satterthwaite degrees of freedom. The non-parametric branch reports a BCa bootstrap 95% CI on the mean difference (Efron, 1987 — bias-corrected and accelerated, with jackknife-derived acceleration). Default is 1000 resamples; a “More precise (5000)” toggle exposes the slower, tighter version. When BCa cannot compute the bias correction (a degenerate case where 0% or 100% of bootstrap replicates fall below the observed statistic), it falls back to a percentile CI with an explanatory warning so you don't see a silent quality drop.

For three-plus comparisons, ANOVA reports both partial η² and ω² with Cohen-style thresholds; Welch's ANOVA reports the same; Kruskal–Wallis reports ε² with Tomczak & Tomczak (2014) thresholds.

§ 7.4 Identity Space side-by-side and aspect overlap

Below the distribution comparisons, the tab renders the active cohorts' identity-space networks tiled side-by-side (horizontal flex for 2–3 cohorts, 2×2 grid for 4). Each tile gets its own period selector and minimum-frequency slider. Aspects whose label appears in two or more active cohorts get a thicker accent stroke; hovering or clicking such a node triggers a brief outline pulse on every matching aspect across all rendered tiles, so you can visually trace shared identities across groups.

Beneath the side-by-side, the dashboard shows an aspect-overlap visualization that scales with cohort count: a Venn diagram for two cohorts, a three-circle Euler diagram for three, and an UpSet-style matrix for four. Clicking an aspect anywhere in these surfaces opens a small inline detail card with per-cohort frequency.

§ 7.5 Longitudinal trajectory comparison

When two or more active cohorts each have at least two multi-journey participants, the tab adds an overlay line chart — one line per cohort, color-coded — showing per-snapshot cohort means with ±1 SEM bands. Cohorts that lack longitudinal data are excluded with a footer note (“Cohort B excluded: no multi-journey participants”). Trajectory length mismatch is handled per-cohort: if cohort A has 4 snapshots and cohort B has 3, each plots to its own length and the footer notes the per-cohort snapshot counts. There is no time-warping or imputation; what you see is what each cohort actually has.

§ 7.6 The pre-registration disclaimer

A persistent card at the bottom of the comparison body carries that line. This is not a courtesy — it is the methodologically honest framing. The Cohort Comparison tab is engineered to give you fast, well-instrumented cross-cohort summaries with sensible default tests and proper effect sizes. It is not engineered to replace a pre-specified analysis plan, because it cannot. Selection of cohorts, selection of metrics, selection of post-hoc adjustment method, selection of integrity-filter mode — all of these are researcher degrees of freedom. Use the tab to look around, generate hypotheses, and produce screening-grade evidence; pre-register the confirmatory analysis you are actually going to run; and run that confirmatory analysis in R or your statistics package of choice.

Screenshot · FIG 7.A Cohort Comparison tab with three cohorts active, violin plot of astSCnorm with the test result panel showing Kruskal–Wallis omnibus and Dunn post-hoc table, plus the small-N warning visible above the violin.

Screenshot · FIG 7.B Cohort Comparison tab longitudinal trajectory comparison with three overlaid lines, ±1 SEM bands, and the per-cohort snapshot-length footer.

The Publication tab generates manuscript-ready output from the same data the rest of the dashboard is showing. The intent is that you can finish a cohort analysis, switch to this tab, click Generate Publication Package, and walk away with a ZIP file containing APA-styled tables, SVG figures, supplemental CSVs, and a Methods paragraph that you can edit and drop into your manuscript.

§ 8.1 APA tables

Six tables are available:

• Table 1 — Sample descriptives: N participants, journeys per participant (M/SD/range), aspects per journey (present period), attributes per journey, period coverage.
• Table 2 — SC metrics by period: All 21 self-complexity metrics organized into the eight sections of the measurement spec, one row per metric, columns M (SD) per period. Attaches a small-sample warning when N < 5.
• Table 3 — Correlation matrix: Pearson r among researcher-selected metrics on participants' latest-journey present period, with two-tailed p-values. Refuses below N = 5.
• Table 4 — Longitudinal change: First-vs-latest paired t and Cohen's d on multi-journey participants for an extensive metric set including ISI dimensions. Refuses below N = 2 multi-journey participants.
• Table 5 — ISI profiles: Two panels. (A) ISI dimensions × period, M/SD/n. (B) Cohort change-pattern distribution from the longitudinal analyzer's isiPattern output.
• Table 6 — Cohort comparison: Phase 5E.2. APA-formatted descriptive statistics by cohort (one row per metric × cohort, columns N/M/SD/Mdn/IQR) plus pairwise test results sourced from CohortStatistics. Requires at least 2 active cohorts in the Cohort Comparison tab; refuses with an explanatory note otherwise.

Each table returns an APA-styled HTML form for in-browser preview and PDF inclusion, plus a tab-delimited plain form for copy-paste into Word.

§ 8.2 SVG figures

Six figures, each returned as a self-contained SVG with inline fonts and no external dependencies — they survive being copy-pasted into LaTeX or Word:

1. SC metric radar (8-axis cohort-mean radar at the present period).
2. Trajectory distribution (bar chart of trajectory-type counts).
3. Sparklines of per-participant longitudinal trajectories grouped by trajectory type, for a researcher-selected metric.
4. ISI radar (6-dimension cohort-mean radar at the present period).
5. Physical-identity tier prevalence (stacked bar across PI-detected participants).
6. Correlation heatmap (Table 3 rendered as a diverging-color heatmap with cell labels).

§ 8.3 Supplemental CSVs

Four supplemental tables intended for re-analysis in R or SPSS:

• S1: One row per participant, latest-journey present-period values for every SC metric and ISI dimension, plus identity counts and PI tier.
• S2: One row per journey × period, all core + SC + ISI metrics.
• S3: Per-participant physical-identity summary (detection, strongest tier, matched terms, temporal change classification).
• S4: Per-participant network primitives (aspect count, attribute count, bridge load, modularity Q, community count).

§ 8.4 Methods text

A generateMethodsText(sections) generator emits an APA-style Methods paragraph with citations matching the in-module references. Toggle which content blocks to include — descriptives, SC, longitudinal, ISI, physical identity, cohort comparison — and the generator builds a paragraph you can paste in and edit.

§ 8.5 ZIP packaging

The Generate Publication Package button bundles the lot via JSZip into a single download. The resulting archive has a fixed top-level layout so collaborators always know where to look for what:

A note on Phase 5E.2 outputs: Table 6 is shipped, but a dedicated Pub-tab UI panel surfacing it alongside the other tables, plus an SVG identity-space side-by-side and inclusion of the long-format CSV in the ZIP, are all targeted for the [PLANNED] Phase 5I refresh.

Screenshot · FIG 8.A Publication tab showing the table preview pane with Table 2 (SC metrics by period), the figure preview showing Figure 4 (ISI radar), and the Generate Publication Package button visible.

Beyond the publication package, the Export tab provides eight current export formats. Each one has a different downstream purpose; choose by what you want to do with the data after it leaves the dashboard. The table below summarizes the inventory; the rules of thumb that follow narrow it down to the right pick for the typical analytic workflow.

§ 9.1 Rules of thumb

A few defaults worth committing to memory. Use the Aggregate CSV when you want one row of summary statistics for the whole cohort. Use the Journey CSV when you want one row per journey × period for downstream modeling — this is the right default for most R/SPSS work. Use the Aspect-Attribute CSV when you want to model attributes themselves, or when you want to construct your own networks. Use the Full JSON when you want a perfect record of the analyzed dataset to share with collaborators or to deposit alongside the manuscript.

§ 9.2 The integrity filter does not reach the exports

A second rule, important enough that the dashboard doesn't bury it: the Phase 4.5 Integrity Filter is not applied to exports. All exports flow through the _qualityStatus !== 'excluded' gate and emit every clean journey, regardless of your on-screen filter. The per-journey sessionCleanliness value is carried in the Journey CSV and the Full JSON as a column you can filter on downstream.

§ 9.3 The Phase 5E.2 long-format CSV

The Phase 5E.2 long-format cohort-comparison CSV is a separate export available from the Cohort Comparison tab itself, with one row per (cohort, participant, journey, period, metric) for the four primary metrics across all three periods, scoped to currently-active cohorts. It is additional to the eight listed above — nine total, if you count it; eight, if you treat it as a comparison-tab artifact rather than a general export.

Screenshot · FIG 9.A Export tab showing the eight export buttons with brief descriptions and the Aggregate CSV currently selected.

It is worth being explicit about the dashboard's epistemic boundary, because the affordances of the tab structure can suggest more than the analytics actually deliver. Six clarifications follow. Each of them is a statement of what the dashboard is not — and, by negation, a statement of what the surrounding analytic plan still owes the work.

§ 10.1 It is not a multilevel modeling environment

The Metrics tab's longitudinal cohort trajectories are descriptive: per-snapshot means with ±1 SEM bands. There is no participant random effect, no slope estimation, no Bayesian credible interval. The Cohort Comparison tab's tests are single-level location tests on cohorts, not nested or repeated-measures models. If your design requires a multilevel model — and most longitudinal designs with cohort effects do — fit it in lme4, brms, or your tool of choice using the Journey CSV or Aspect-Attribute CSV exports as input.

§ 10.2 It is not a confirmatory inference machine

The Cohort Comparison tab's pre-registration disclaimer is not pro-forma. Test selection is partly automated, but the choice of which cohorts to activate, which metrics to compare, which integrity-filter mode is in effect, and which post-hoc adjustment method to apply are all researcher degrees of freedom. Use the dashboard for screening, exploration, and visualization. Pre-register the confirmatory analysis. Run that analysis in software whose statistical layer is canonical-grade.

§ 10.3 It is not a substitute for expert metric interpretation

The dashboard reports 21 self-complexity metrics and a 6-dimension ISI profile. The measurement spec is explicit that these should be reported as a profile, not collapsed into a scalar. The dashboard's _overallMean field on ISI is for screening only — profile shape matters more than the average. Likewise, the AST formulation is a reconstructed operationalization of Schleicher & McConnell (2005), not a verbatim reproduction; ISI's Integration optimal values are theoretical first estimates that should be empirically calibrated; the change-pattern classifications are first-pass heuristics. Treat all of these as instruments that need interpretation, not as oracles.

§ 10.4 It is not a longitudinal modeling engine

The longitudinal summary is a first-vs-latest comparison: emerged, disappeared, expanded, contracted, strengthened, weakened. The cross-snapshot Individual Identity Space view shows pairwise transitions across the participant's whole journey arc. Neither is a sequence model. If your question is “what's the rate of change in differentiation between weeks 4 and 8 conditional on baseline?”, you'll need to fit that model yourself.

§ 10.5 It is not a server

The current build is a single HTML file that runs entirely in your browser. There is no authentication, no role-based access, no audit logging, no k-anonymity enforcement, and no persistent storage between sessions. De-identification is a binary toggle — either opaque hash keys or readable participant labels — not the tiered system contemplated for [PLANNED] Phase 5F. Closing the tab clears all loaded data.

§ 10.6 A roadmap of planned features

A few features marked [PLANNED] you should know about, in the order they're targeted:

Until those phases ship, treat the limitations above as load-bearing. They are part of the current dashboard's scope of validity.

If you have read this far, you have a working mental model of the dashboard: a single HTML file that ingests Self-Space JSON exports, normalizes and validates them, recomputes metrics from the raw data, exposes them through six tabs, applies session-integrity and quality-status filtering uniformly across cohort-aggregate computations, supports up to four cohorts in parallel for descriptive comparison, and emits manuscript-ready output via APA tables, SVG figures, supplemental CSVs, and a Methods paragraph. The metric inventory rests on a published measurement specification (v2.2) with explicit citations, plain-language interpretations, and explicit acknowledgment of where the formulas are reconstructed rather than canonical. The statistics rest on a published cohort-comparison specification (Phase 5E) with explicit decision rules, effect-size reporting, and bootstrap confidence intervals.

What the dashboard offers, in short: speed, transparency, reproducibility on a single workstation, and a clean separation between the descriptive/exploratory work it does well and the confirmatory/inferential work it leaves to you.

Use it as a microscope and a notebook, not as a replacement for the analysis plan you would write anyway.

When you find a behavior that surprises you, the dashboard specification (currently v1.21) and the measurement specification (currently v2.2) are the ground truth. Both name the version of the dashboard they describe; both call out planned versus implemented features explicitly. If something on screen disagrees with what's in this manual, the spec is right and this manual is stale — file it as a documentation issue and proceed with the spec.

Manual prepared as a companion to dashboard v0.17.1 and measurement specification v2.2. Citations for the metric formulas and statistical machinery follow those documents. The Identity Strength Index and the novel self-complexity metrics in sections E–H were developed by Sean P. Mullen, PhD, University of Illinois Urbana-Champaign.