Confirmatory Factor Analysis (CFA)
Analyze → Dimension Reduction → Confirmatory Factor. Tests a hypothesized measurement structure: you say which observed indicators belong to which latent factors, and CFA tells you how well that structure fits your data. It is the confirmatory complement of Factor, which finds a structure — use Factor to explore, CFA to test what you (or the literature) already claim.
Typical uses: validating a questionnaire's subscales, checking that a published factor structure holds in your sample, or testing a measurement theory before building on it.
The dialog
Build the model factor by factor:
- Add factor creates a factor; give each a meaningful name (the names appear throughout the output).
- Tick each factor's indicators in its checklist. An indicator can belong to one factor only — once ticked in one factor it disappears from the others' lists. A factor needs at least two indicators (three when the model has only one factor).
- Each factor's first indicator sets its scale: its loading is fixed at 1, so it is the yardstick the factor is measured in. Pick a good, central indicator first per factor.
- Orthogonal factors (visible with two or more factors) forces the factor correlations to zero. Leave it off in most applications — real constructs correlate, and the correlated model reports how much.
Reading the output
- CFA Model Fit — the headline table. The χ² test asks whether the model reproduces the observed covariances exactly (a significant result says it does not — but with large samples χ² flags even trivial misfit, which is why the descriptive indices beside it matter). Conventional rules of thumb, guides not laws: CFI/TLI ≥ 0.95 good, ≥ 0.90 acceptable; RMSEA ≤ 0.06 good, ≤ 0.08 acceptable (read its 90% CI, not just the point value); SRMR ≤ 0.08. Judge the set together and against your field's standards, not any single index against a cliff. The note beneath records how the model was estimated and how many iterations it took.
- CFA Loadings — each indicator's loading on its factor, with a standard error, z and significance for the free ones (the reference indicator shows its fixed 1 and dashes — it was not estimated). The Standardized column is the completely standardized solution: roughly, the indicator-factor correlation. Standardized loadings around 0.7+ mean the factor explains about half the indicator's variance; clearly weak loadings suggest the indicator does not measure that factor.
- CFA Factor Correlations — how strongly the latent factors correlate (only with two or more correlated factors). Correlations near ±1 are a warning: two "factors" may really be one.
- CFA Variances — the factor variances and each indicator's residual (unique) variance, with standard errors.
When something is wrong, it says so
CFA is an iterative estimation, and this dialog treats its failure modes as information, never as silent numbers:
- Identification errors stop the analysis with a message naming the offending factor (too few indicators, an impossible parameter count). Fix the model rather than the data.
- A Heywood case — a residual variance driven to its lower bound — is flagged by name in the notes. It usually signals a misspecified model, a weak factor, or too small a sample.
- Non-convergence and suspected local optima are reported in the Model Fit note. Treat the estimates with caution and simplify the model or check the indicators.
- A singular information matrix (the model is empirically underidentified for these data) is stated plainly, and standard errors are withheld rather than printed as nonsense.
Reproducibility
A run journals a compact syntax command, e.g.:
cfa model="Verbal: v1 v2 v3; Speed: v4 v5 v6"
with orthogonal=true recorded when set — re-running reproduces the same
tables. The same tool is available to the AI assistant, MCP and batch
scripts.
Scope (v1): single-group models with continuous indicators, maximum likelihood only, simple structure (one factor per indicator). Ordinal (WLSMV) estimation, multi-group invariance testing, modification indices and regression paths between factors (SEM territory) are recorded follow-ups, not implied promises. Validated against reference implementations on the classic Holzinger–Swineford example — see the validation suite.