Reincarnation — plain-language explainer

Reincarnation is an adaptive survey engine: it picks the most informative questions to ask next, scores the construct underneath them, and continuously retires weak items while promoting strong ones.

A People Analytics Toolbox component. Built to the portfolio Explainer Standard v1.0. Every claim below is grounded in the spoke's own code and contracts (src/spokes/reincarnation/, contract 1.2.0); anything not yet built is marked (TBD).

1. What is it?

Reincarnation is an adaptive psychometric diagnostic engine: you give it a measurement target (a galaxy — one construct, like "engagement" or "respect at work"), its bank of candidate survey items, and a stream of respondent answers, and it does two jobs at once. First, for each respondent it selects the next batch of items that will tell you the most — spending questions where they buy the most information instead of asking everyone everything. Second, as answers arrive it scores the construct (reliability, item quality, trend) and uses that telemetry to move items through a pool lifecycle — promoting items that discriminate well, quarantining items that don't.

The name is the mechanic: items earn their way up or get sent back to be reborn. An item bank is never static; it is continuously re-graded against real responses.

Visual — Tier B (in-repo reference). The pool lifecycle, named in the contract enum (src/spokes/reincarnation/contracts/types.ts, pool enum): an item lives in one of six pools — D → C → B → A (the active, promotable ladder, A being the proven "champion" tier), plus PURGATORY (under review) and INFINITY (the exploration reserve). Active selection draws exploit items from A–D and exploration items from INFINITY/PURGATORY.

2. What problem does it solve — and why is it different?

The pain it removes: fixed survey instruments waste respondents. A static questionnaire asks everyone the same 40 items regardless of whether item 12 has ever discriminated between high and low scorers, and it has no mechanism to retire a dead item mid-program or to surface a promising new one. The construct stays noisy where you have too few good items, and respondent attention is burned on items that carry almost no signal.

The difference, stated as a shift:

  • FROM a frozen item list, asked uniformly, with item quality assessed (if ever) in a one-off offline analysis after the survey closes.
  • TO a live bank where every item carries its own information-gain weight, the next batch is chosen to maximize that weight per respondent, and reliability is recomputed as a feed every cycle.

How it differs from the obvious substitutes:

  • vs. a spreadsheet item inventory — a spreadsheet cannot promote a winning item or quarantine a weak one with reproducible telemetry; Reincarnation does it as a governed pool transition keyed on observed IRT and virtue stats.
  • vs. a generic survey tool (Qualtrics/Forms) — those deliver items; they do not compute Cronbach's alpha, item-total correlations, or "alpha-if-deleted" per item and then act on them. Reincarnation is the measurement science, not the form renderer.

Visual — Tier B (FROM→TO typographic block). The shift above is the visual; a rendered comparison block is a follow-up (FU-A).

3. How does it work?

Inputs → method → outputs, concretely:

  • Inputs: a registered galaxy (one construct) holding universal items (RIDs — the canonical item text, shared across studies) and study items (SIDs — a per-study instance of an RID carrying that study's pool, virtue, and IRT stats), plus a stream of respondent answers (1–5 Likert values, ResponseIngestItemSchema).
  • Method — selection. runAdaptiveSelection (core/adaptive-selection.ts) scores every active candidate SID with an information-gain weight and an exploit/explore split:
    • informationGain = virtue·0.4 + irtDiscrimination·0.3 + uncertaintyBonus·0.3, where the uncertainty bonus rewards items with thin response history (sampleSize < 10) so new items get a look.
    • It sorts descending, takes the top items as the exploit set, and reserves a small exploration budget (default 0.05) drawn from the INFINITY/PURGATORY pools — the explore/exploit tradeoff, same idea as multi-armed bandit selection.
  • Method — scoring. computeCronbachAlpha (core/psychometrics.ts) computes internal-consistency reliability (the k/(k−1)·(1 − Σσ²ᵢ/σ²_total) form), handles reverse-coded items (6 − value), computes item-total correlations and alpha-if-deleted per item, and emits human recommendations ("removing N item(s) could improve reliability").
  • Outputs: a ranked selected/exploration item set (AdaptiveSelectionResponse), an ingest receipt (ResponseIngestResponse), and a per-galaxy psychometric feed (PsychometricFeedResponse — alpha, reliability band, construct score + confidence interval, trend, pool distribution).

The science backing. This is classical test theory plus item response theory: Cronbach's alpha with the standard reliability bands (≥0.9 excellent, ≥0.8 good, ≥0.7 acceptable, else poor), IRT difficulty/discrimination stored per item, and information-gain item selection. It is Mike West's IP and the single canonical source for it across the portfolio — Performix and vela consume this engine rather than re-implementing psychometrics.

Differentiation beat: the practitioner's real question is not "what's the score" — it's "am I asking the right questions, and can I trust the number?" Reincarnation answers both in one loop: the selection step is which items, the scoring step is how trustworthy, and the pool lifecycle closes the loop so the bank gets better every cycle.

Visual — Tier A (real computed output). See the worked example in §below — a real run of the information-gain formula over the in-repo seed galaxy.

4. What does it enable?

Concrete uses a practitioner would recognize:

  • Run a shorter, sharper survey — adaptive selection means each respondent answers the items that discriminate, so you measure the same construct with fewer questions and less fatigue.
  • Catch a dead item before the program ends — the psychometric feed flags low item-total correlation and "alpha-if-deleted" gains, so a weak item is identified mid-flight, not in a post-mortem.
  • Stand up a new construct without a SQL seed — a consumer app self-registers its own galaxy + items idempotently (POST /galaxies), pinning its item bank at deploy time.
  • Track a construct's reliability and trend over time — the feed carries a per-galaxy Cronbach alpha, a construct score with confidence interval, and a trend direction (improving | declining | stable | insufficient_data).
  • Feed downstream analytics a clean measurement — the construct score and its CI flow to forecasting / metric surfaces as a vetted input rather than a raw item average.
  • Accumulate item evidence centrally — each computed psychometric can be emitted back to Principia as DeploymentEvidence, so the canonical item library learns from every production administration.

Visual — Tier B (step flow). register galaxy → administer adaptive batch → ingest answers → recompute psychometrics → promote/quarantine items → feed score downstream.

5. How it fits in the toolbox

Data flow:

  • Consumes — respondent answers from survey-delivery consumers (Performix, vela) and, for new constructs, galaxy/item definitions those consumers self-register. RIDs are intentionally global (a shared universal item library); galaxies, study items, and responses are tenant-scoped (tenantId required on every write, contract 1.2.0).
  • Emits — five contracts (DATA_CONTRACTS in contracts/types.ts): adaptive-selection, response-ingest, psychometric-feed, diagnostic-export, and metric-cards (standardized cards for the Metric Market surface). Consumers vendor src/spokes/reincarnation/contracts/types.ts.
  • Feeds — preference-modeler (selection + ingest), people-analyst forecasting (psychometric feed), metric-market + data-anonymizer (diagnostic export / cards), and Principia upstream via the DeploymentEvidence round-trip (core/principia-emit.ts, fail-soft, retry-on-5xx).
  • Boundary — consumers call the HTTP/MCP API and vendor the contract; they never import the spoke's core/. Writes require a service key (x-toolbox-service-key or Authorization: Bearer).

Visual — Tier B (typographic data-flow). Performix / vela survey delivery → Reincarnation { adaptive-selection · responses/ingest · psychometric-feed } → { preference-modeler · forecasting · metric-market } ↘ Principia DeploymentEvidence.

6. Commercialization / packaging

Reincarnation is a service engine, not a standalone product — it is the measurement core that consumer products (Performix's CAMS instrument, vela, future diagnostics) compose. It sits behind buyer-facing survey/diagnostic surfaces rather than being sold on its own.

  • IP posture: this is Mike West's psychometric IP and the canonical implementation — the explicit rule is that consumers consume the API, they do not fork the algorithm into their own repos.
  • Data-license posture: the engine ships no proprietary item content of its own; item banks are owned and registered per consumer/tenant, and the universal RID library is the shared canonical layer. Tenant scoping (contract 1.2.0) is the isolation boundary.
  • Anything about pricing tiers or packaged offerings is (TBD) — not earned yet, so not stated.

Visual — (TBD — product-tier placement diagram).

7. The vision

A measurement layer where no respondent is wasted and no item is trusted on faith — every question earns its place from observed information gain, and every score arrives with its reliability attached.

The direction is the closing of the full loop with Principia: Reincarnation administers items, computes psychometrics, and emits that evidence back to the canonical store (the round-trip already exists, fail-soft, in core/principia-emit.ts); the next links are a richer connector with cache + MCP (referenced in-code as the PAT-114 / TB-PRINCIPIA-04 follow-up) so the universal item library and the production telemetry converge. Read-path tenant-filtering hardening is the paired follow-up to the 1.2.0 multi-tenant scoping (PAT-39-FU-A-FU).

Visual — (TBD — the Principia round-trip loop as a closed-cycle diagram).

8. Current status

Grounded in the real code state (status: "live" in src/lib/contracts/registry.ts, contract 1.2.0, src/spokes/reincarnation/):

  • Shipped: information-gain adaptive selection with exploit/explore (core/adaptive-selection.ts); response ingest; Cronbach-alpha psychometric scoring with item-total correlation + alpha-if-deleted + recommendations (core/psychometrics.ts); the psychometric feed; idempotent consumer galaxy registration + item append (DP-133); the six-pool lifecycle taxonomy; tenant scoping with service-key-gated writes (PAT-39-FU-A); the Principia DeploymentEvidence emit (PAT-118, fail-soft + retry); MCP tools registered (reincarnation.adaptive-selection, .responses-ingest, .psychometric-feed, .galaxies.register, .galaxies.items-append, .emit-insight-cards, .health). Live HTTP routes under /api/spokes/reincarnation/* + /health. A deterministic demo seed (pat2-galaxy-seed) ships in migration 0001 so adaptive selection returns non-empty results on a fresh migrate.
  • In flight / planned: the richer Principia connector with cache + MCP (PAT-114 / TB-PRINCIPIA-04); read-path tenant-filtering refactor (PAT-39-FU-A-FU); Performix consumer wiring (PFX-7, in-progress) and vela (planned), per the registry consumers list.

Visual — Tier A (live capture). GET /api/spokes/reincarnation/health and GET /api/spokes/reincarnation/psychometric-feed report the real shipped state at request time.

Worked example (load-bearing, real computed output)

Using the in-repo demo galaxy pat2-galaxy-seed exactly as seeded in migration drizzle/0001_small_silver_sable.sql (five study items, "Seed Construct"), run the real runAdaptiveSelection scoring formula:

informationGain = virtue·0.4 + irtDiscrimination·0.3 + uncertaintyBonus·0.3
   (uncertaintyBonus = 0 for all five — every seeded sampleSize is ≥ 12)

  pat2-sid-4  virtue 0.91  disc 1.30  →  0.754   (pool A)
  pat2-sid-1  virtue 0.85  disc 1.10  →  0.670   (pool D)
  pat2-sid-5  virtue 0.72  disc 1.00  →  0.588   (pool D)
  pat2-sid-2  virtue 0.62  disc 0.90  →  0.518   (pool C)
  pat2-sid-3  virtue 0.41  disc 0.75  →  0.389   (pool B)

  informationGainEstimate (mean of top items) = 0.584

(These five values are computed directly from the seeded virtue / irt_discrimination / sample_size columns in migration 0001 run through the exact formula in core/adaptive-selection.ts. No figure is invented.)

What a practitioner does with it: if this respondent has an item budget below five, Reincarnation serves sid-4 and sid-1 first — the items that discriminate hardest — and holds the low-gain sid-3 back. As answers accumulate, computeCronbachAlpha recomputes the construct's reliability and flags whether sid-3 (the weakest by information gain) is also dragging internal consistency down, which is the signal to quarantine it into PURGATORY. That is the full select → score → re-grade loop on real seed data.