peopleanalyst

research / principia / audience tiers

Product implications

What the registry tells us to build next — on the People Analytics Platform, on Vela, in the toolbox/hub. Which constructs unlock which platform features once their rows exist.

By Mike West

Principia·Audience tiers·Product implications·source: people-analyst/principia/docs/research/reviews/product-implications.md

Principia: product implications

What the registry tells us to build next — on the People Analytics Platform, on Vela, in the toolbox/hub. Each implication traced to a specific construct family, a specific instrument, or a specific registry artifact.

This document is written for a product builder reading the Principia registry as a forward-leaning input — what does this thing let us build that we could not build before? The question is more constrained than "what is Principia for"; it is "what does Principia, as it stands and as it accumulates, hand to the rest of the portfolio."

The honest framing first. Principia is early. The engagement family is the proof-of-method; the rest of the construct-family roadmap is sequenced behind it. Several of the implications below pre-suppose registry rows that are not yet live (the engagement-survey at docs/research/reports/engagement-survey.md is in draft; the organizational-commitment survey is queued behind engagement; the psychological-safety corpus is sparse). The implications still matter, because the product decisions that follow from them are decisions that need to be in place before the registry rows land, not after. A toolbox feature that wants to subscribe to canonical engagement measurement is a feature whose data contract is the registry's CanonicalSurveyItem shape — and that contract is set today, regardless of how many rows are populated against it.

Each implication below traces to a specific registry artifact. None of them is a generic product wish.

1. Engagement-survey rows unlock Calculus's engagement-metric coverage

The proof-of-method case. When the engagement-family survey at docs/research/reports/engagement-survey.md flips from draft to live (gated on the engagement family's effect-size table populating to the threshold in methodology.md §2 — ≥ 8 load-bearing EffectSize rows for headline relationships, ≥ 1 A-grade meta-analysis for engagement → performance, novelty verification on every promoted row), Calculus can stop reinventing engagement metrics per customer.

What changes in Calculus:

  • Subscribe to Construct.work_engagement and the top-graded instruments in the family: UWES-9 (the nine-item Utrecht Work Engagement Scale; Schaufeli, Bakker & Salanova 2006), UWES-17 (the original three-factor instrument; Schaufeli, Salanova, González-Romá & Bakker 2002), Gallup Q12 (the meta-analytically validated business-unit-level engagement instrument; Harter, Schmidt & Hayes 2002), JES (Job Engagement Scale; Rich, LePine & Crawford). The instrument inventory carries item-level schemas, scoring rules, reliability evidence per population, and cross-cultural adaptations.
  • Stop maintaining the customer-by-customer engagement-question library that today every people-analytics tool maintains in some form. Instead, instantiate from the registry: a customer who wants to deploy engagement measurement gets the canonical UWES-9 with the canonical scoring and the canonical normative bands (where the registry has them — currently [FILL: pending verification] for several specific norm references; the engagement survey will land them).
  • Compute defensible engagement statistics against the canonical instruments rather than against a per-customer scale that has no validation literature. The customer's engagement score is interpretable against the field's prior, not just against the customer's last quarter.

Specific dependencies in the registry: construct.work_engagement populated with the Kahn (1990) theoretical lineage in the construct definition; instrument.uwes_9, instrument.uwes_17, instrument.gallup_q12 each with item-level schemas; the CanonicalPrior rows at /api/v1/priors/construct.work_engagement/predicts/construct.task_performance and the corresponding turnover-intention and job-satisfaction tuples synthesized from the engagement-family effect-size table.

2. Organizational-commitment rows unlock AnyComp's tenure-modeling improvements

The Allen & Meyer (1990) tripartite Three-Component Model of organizational commitment — affective commitment (emotional attachment), continuance commitment (cost-based attachment), normative commitment (obligation-based attachment) — is the canonical measurement structure for organizational commitment. Meyer & Herscovitch (2001) is the canonical theoretical refinement. The commitment-family survey is in the Tier-1 queue behind engagement and job satisfaction.

What changes in AnyComp when commitment rows land:

  • AnyComp's voluntary-turnover prediction today rests primarily on demographic and compensation features. The literature is unambiguous that organizational commitment (affective in particular) is a measurement-graded predictor of voluntary turnover beyond demographic baselines — Riketta (2002), Attitudinal Organizational Commitment and Job Performance, is one of the canonical meta-analytic anchors, and the broader Allen-and-Meyer lineage carries the predictive-validity evidence.
  • A customer's commitment measurement, deployed via the registry's canonical instruments, becomes a queryable predictor that AnyComp's tenure model can consume — not as a free-text feature but as a measurement-graded one, where the prior strength is documented per instrument and per population.
  • Cross-customer comparisons of commitment-attached turnover prediction become defensible. Two customers using the same canonical Allen & Meyer instrument have measurements that pool meaningfully; two customers using ad-hoc commitment-questions do not.

Specific dependencies in the registry: construct.organizational_commitment_affective, construct.organizational_commitment_continuance, construct.organizational_commitment_normative (the tripartite distinction must be preserved in the registry — they are not the same construct); instrument.allen_meyer_tcm with its item-level schema; CanonicalPrior rows for the predicts-turnover tuples from the commitment family.

3. CanonicalTheoreticalModel unlocks model-first analytics

The PRN-037 work shipped a load-bearing piece of infrastructure: theoretical models as queryable data. Eight seed theories landed — Job Demands-Resources (Bakker & Demerouti); Job Characteristics Model (Hackman & Oldham); Conservation of Resources (Hobfoll); Self-Determination Theory (Deci & Ryan); Affective Events Theory (Weiss & Cropanzano); Goal-Setting Theory (Locke & Latham); Equity Theory (Adams); Two-Factor Theory (Herzberg). Each carries its canonical constructs, its canonical relations (with central flags separating load-bearing from boundary claims), and its foundational citations.

What changes when theoretical models are queryable:

  • The recommendation endpoint (PRN-036; POST /api/v1/recommend) can answer the directed question "I want to predict turnover — what should I measure, and which canonical instruments are best?" by traversing from the outcome construct, through EffectSize rows pointing at it, ranked by |value| × quality-grade weight × prior informativeness. The response is a ranked predictor set with the top-graded instrument per predictor, plus administer-via-toolbox hooks.
  • Theory-first analytics in customer-facing products becomes possible. A customer who says "we want to apply JD-R to our workforce health initiative" can be served the JD-R theoretical-model card from the registry — canonical constructs (job demands, job resources, personal resources, engagement, burnout, outcomes) — and the toolbox can administer the canonical instruments for each construct in one round-trip.
  • Model lineage becomes traceable. A per-study Model row produced by an extraction pipeline can carry descends_from_theoretical_model: "theory.jd_r", which means the registry knows which canonical theory the study is instantiating. Two studies that instantiate the same theory pool meaningfully; two studies that look superficially similar but instantiate different theories produce evidence the registry presents as such.

Specific dependencies in the registry: the eight seed theoretical-model rows landed in apps/web/data/store/theoretical_model.json and reachable at /api/v1/theoretical-models[/{id}|/search]. The cross-reference from per-study Model rows to CanonicalTheoreticalModel is in place via Model.descends_from_theoretical_model?; the ingest pass that backfills the linkage on existing per-study models is PRN-040 territory.

4. Bayesian priors unlock Stan / PyMC integrations

The CanonicalPrior layer (PRN-021 + PRN-022) is the part of Principia that has no direct precedent in the existing infrastructure. The pooled distribution is queryable, returned with its provenance attached (contributing_effect_size_ids[], k_studies, n_total, synthesis_method, last_updated), and consumable by researcher tooling as informed-prior input.

What changes for researcher tooling:

  • A graduate student running a structural equation model on engagement antecedents in a small-N organizational sample stops choosing between flat prior (ignores 40 years of evidence), cite a single meta-analysis (better, but frozen at the meta-analysis's search-end date), or hand-construct one (correct, but a research project in itself). The registry returns a prior at /api/v1/priors/{from}/{predicate}/{to} that the student plugs into Stan / PyMC / brms / R / NumPy directly. The PRN-038c code-copy widget on the prior viewer renders the snippet in the researcher's tooling of choice.
  • Toolbox features that ship measurement-graded effects (rather than ad-hoc statistics) get a defensible prior layer. A toolbox-side function that predicts an engagement-attached outcome carries a Bayesian prior derived from the field's literature, not a heuristic constant.
  • The methodology becomes auditable. A reviewer who asks "where does this prior come from" gets back a list of contributing effect-size IDs that trace to study-level rows that trace to DOIs. The synthesis is reproducible from the registry rows + the BibTeX; no consumer has to trust the synthesis author.

Specific dependencies in the registry: CanonicalPrior rows synthesized via PRN-021's random-effects engine; the public API at /api/v1/priors/{from}/{predicate}/{to}; the public prior viewer at peopleprincipia.com/registry/priors/{from}/{predicate}/{to} with its inline-SVG distribution plot and code-copy snippets per PRN-038c.

5. CanonicalSurveyItem ↔ Reincarnation RID linkage unlocks expected-score queries

SPEC §5 Delta 5 declares CanonicalSurveyItem.canonical_item_id as 1:1 with the toolbox's Reincarnation engine's RID (the response-item identifier in Reincarnation's adaptive-measurement infrastructure). PRN-011 shipped the type; PRN-039 shipped the principia-side write surface at POST /api/v1/deployment-evidence and the round-trip contract at docs/specification/reincarnation-roundtrip.md. The toolbox-side emitter (filed as PAT-NNN-reincarnation-emit) is the cross-repo follow-on that closes the loop.

What changes when the round-trip is closed:

  • A toolbox-side feature can ask "what is an organization's expected score on UWES-9, given its industry, region, and role mix?" — and the registry can answer with a measurement-graded expectation, derived from accumulated DeploymentEvidence rows, rather than a fabricated benchmark. The expected-score query is the kind of question every people-analytics vendor pretends to answer; the registry is the data structure that lets it be answered with provenance.
  • Reincarnation's adaptive-measurement work feeds back into the registry. Every administration of a canonical item via Reincarnation produces a DeploymentEvidence row keyed to canonical_item_id; the rows accumulate; the per-context expected score becomes a queryable derived statistic.
  • The toolbox's customer-facing comparisons (this organization's engagement vs. industry peers; this team's psychological-safety vs. a matched-cohort baseline) get a measurement-graded foundation. The comparison is against measured deployments of the same canonical item, not against vendor-marketed benchmark composites of unspecified construction.

Specific dependencies in the registry: CanonicalSurveyItem rows for the engagement family's canonical instruments (UWES items first, Q12 items second); the DeploymentEvidence ingest path live at /api/v1/deployment-evidence; the toolbox-side emitter shipping. Until the toolbox-side ships, the round-trip is half-built: principia accepts writes, toolbox does not yet emit them.

6. MethodologyCritique unlocks instrument-diagnostic surfaces

The PRN-044 proposed entity — MethodologyCritique — makes methodology critiques first-class data rather than markdown footnotes. The proposed schema includes subject_type (instrument | construct | model | effect_size | citation), critique_type (construct_validity | method_bias | sampling | scoring | reliability | applicability | factor_structure | other), severity (minor | moderate | major | fatal), citation_ids[] for the critics, and rebuttal_citation_ids[] for where the critique was addressed.

What changes when critiques are queryable:

  • When the toolbox detects that a customer is measuring engagement with Q12 and getting unexpected results, the toolbox can surface the published critiques of Q12's single-item-per-domain coverage — Macey & Schneider (2008) on the construct-validity question; the broader literature on whether Q12 measures engagement or measures something adjacent (satisfaction-engagement hybrid). The customer sees the critique inline, with the citations attached, with severity coded. This is a diagnostic surface no existing measurement catalog offers — they present instruments as good-or-bad-or-uncited; the registry presents them with their structured critiques and lets consumers weight accordingly.
  • A toolbox feature recommending instrument selection can rank candidates with critique severity as a weight. A B-grade instrument with a fatal critique against the use case is not the right pick for that use case, even if it is more popular than a B-grade instrument with no documented critiques in scope.
  • Researcher-facing surfaces can answer "what's wrong with the JDI for measuring job satisfaction in service-industry contexts?" with the actual literature attached, not with a generic "consider validity" disclaimer.

Specific dependencies in the registry: the MethodologyCritique schema landed in @people-analyst/measurement-core; ≥ 3 engagement-family critiques seeded (Q12 single-item-per-facet; UWES factor-structure debate; common-method bias on self-report engagement); the curator-promote path mirroring PRN-030's D4 discipline. The PRN-044 ticket is PROPOSED as of the time of this writing; the dependency on it is the dependency on a not-yet-shipped piece of infrastructure.

7. Cross-cultural moderation as queryable unlocks defensible global comparisons

The PRN-045 proposed work — culture-conditioned sub-priors when sample data permits — augments CanonicalPrior to carry culture-cluster sub-priors keyed by CulturalAdaptation rows. When 3+ contributing EffectSize rows share a cultural adaptation, the synthesis engine produces a culture-specific sub-prior.

What changes for global products:

  • A customer running engagement measurement across European, North American, and East Asian operations stops applying a single global prior to all three. The registry returns culture-conditioned priors where available, with the culture_unavailable_note field surfacing the absence where the sample data isn't sufficient.
  • Calculus's cross-region comparisons gain a measurement-graded basis. The engagement-attached productivity comparison between the customer's Tokyo and Berlin offices uses sub-priors derived from culturally-matched validation samples, not a single global pool that smuggles in unspecified moderation.
  • The honesty discipline holds: when the sub-prior data is thin, the API returns the global prior with a note, not a fabricated sub-prior. The product surface inherits the same discipline; a customer sees the global comparison with the cultural-moderation caveat surfaced explicitly.

Specific dependencies in the registry: CulturalAdaptation rows ingested at scale (the schema exists in @people-analyst/measurement-core; the population pipeline is gated on the construct-family surveys landing); the PRN-045 synthesis enhancement; the query-parameter API at GET /api/v1/priors/{from}/{predicate}/{to}?sample_culture=....

8. Intervention library bridges measurement to applied work

The PRN-047 proposed work — the Intervention entity — bridges the registry from measurement to applied organizational-development literature. The proposed schema includes targets_constructs[], mechanism_summary, typical_duration_weeks, typical_cost_band, delivery_modality[], citation_ids[], meta_analytic_effect_size_ids[] (where intervention efficacy has been meta-analyzed), fidelity_notes, contraindications.

What changes when interventions are queryable:

  • The registry stops being a description-of-state and starts being a description-of-action. "Engagement → performance is r=.37" is interesting; "engagement-improving interventions in this delivery modality show effect sizes of [FILL: pending verification]" is actionable.
  • The toolbox's customer-facing analytics gain a "what next" surface. A customer whose engagement-attached productivity is below the registry's culture-matched prior gets a list of interventions from the registry with their meta-analytic efficacy attached, their typical cost band, their fidelity notes, and the citations a customer's HR team can read directly.
  • The bridge to consulting becomes data-backed. A consulting engagement that proposes a specific intervention does so with the registry's evidence attached; the customer can evaluate the proposal against the registry rather than against the consultant's pitch deck.

Specific dependencies in the registry: the Intervention schema landed in @people-analyst/measurement-core; the ingest pipeline from applied literature (similar pattern to PRN-012; engagement-interventions first); the bridge in the PRN-038 reader UI surfacing per-construct intervention links.

What this tells the portfolio to do now

Reading the eight implications together, the product-strategy posture is this: the People Analytics Platform apps (Calculus, AnyComp, Reincarnation) and the toolbox/hub features that consume them should be designed against the registry's data contracts today, even where the registry rows are not yet populated. The contracts are stable; the rows are sequenced. A toolbox feature that ships against the canonical UWES-9 schema in 2026 keeps working when the engagement-family survey lands in live status in 2027; a toolbox feature that ships against a vendor-bespoke engagement schema has to be rewritten when the registry coverage forces the switch.

The order of the rest of the work, derived from the eight implications:

  1. Engagement-family survey to live is the gating dependency for Calculus's engagement-metric coverage (#1), the Bayesian-prior consumables (#4), the Reincarnation round-trip's first usable canonical items (#5), and the first engagement-family methodology critiques (#6). The proof-of-method on engagement unlocks the largest block of downstream product capability.
  2. Organizational-commitment-family survey unlocks AnyComp's tenure-modeling improvements (#2) and the second block of Tier-1 Bayesian-prior consumables.
  3. Theoretical-model layer ingest expansion (beyond the eight seed theories) unlocks broader model-first analytics (#3) and the per-study Model linkage backfill.
  4. Cross-cultural moderation rollout (#7) and the Intervention library (#8) are the long-tail product capabilities that turn the registry from a measurement reference into a decision-support tool.

Each of these is a piece of registry work, not a piece of toolbox work. The toolbox features that consume them are ready as soon as the registry contracts are. The registry is the rate-limiter; the product capability is the downstream consumable.

That is what Principia tells the portfolio to build next. Not generic measurement-graded analytics — specific construct families, in a specific order, against specific instruments, with specific Bayesian priors, gated on specific verification. The registry's discipline is contagious in the right direction: every product capability that subscribes to it inherits the source-grading, the snapshot-versioning, and the provenance-to-DOI traceability that the registry itself carries. The portfolio gets to be measurement-graded in a way no individual product team would have the bandwidth to build alone.

That is the bet.