IMPRS V32 Engine Behavior
We're proposing a measurable definition of brand health, and a proposal is only testable if its implementation is pinned down. This document specifies how the production engine actually behaves: inputs, computation order, edge cases, and the guarantees you can build against.
01Versioning and guarantees
The production engine is IMPRS V32, a sealed, deterministic scoring function. The version number is part of the score’s meaning: every published validation figure is attached to V32, and any change to the mathematics, weights, thresholds, or normalization tables produces a new version that must be re-validated before it ships (section 10).
The engine makes four hard guarantees:
- Determinism. Identical inputs produce the identical score. No randomness, no A/B variation, no learned components that drift between calls.
- No generative AI in the calculation. Language models explain scores and recommend actions strictly downstream of the number. They cannot read from or write to the scoring path.
- No manual adjustment. There is no override surface. Scores change only when inputs change or a new sealed version ships.
- Structural fairness. The split between the two metric families is fixed by design rather than by data richness, so an account on API-generous platforms cannot outscore an equally healthy account on stingier ones by coverage alone. Missing data shrinks toward neutral; it never fabricates signal.
02The scoring pipeline
There is exactly one canonical scoring path in production: the audit pipeline. Every surface that displays a score, the dashboard, audits, agency portfolios, share cards, public badges, reads a persisted audit produced by that pipeline. No surface computes its own variant of the score, which is what makes the number consistent everywhere it appears.
The pipeline stages are:
- Collect. Platform connectors pull organic metrics from the account’s connected platforms; ad connectors pull paid metrics; the financial collector reads connected revenue integrations. All inputs are snapshotted for the audit.
- Score. The V32 function maps the snapshot to pillar scores, the composite, and the 350-900 display score, with the full pillar decomposition and per-pillar confidence retained.
- Persist. The audit row stores the scores, the pillar breakdown, metric coverage, and the engine version, forming an append-only score history. Deltas are derived by diffing consecutive audits.
- Explain. Downstream of the persisted number, the explanation layer generates plain-language analysis and recommendations. This stage cannot alter the score.
Scheduled re-audits run through the same pipeline via fan-out: a daily dispatcher selects the day’s cohort and emits one audit request per user, and the pipeline worker executes each with per-user idempotency and concurrency controls. On-demand audits triggered from the product enter the identical path.
03Input assumptions per platform
Organic platforms are Instagram, Facebook, TikTok, YouTube, and Twitter/X. Ad platforms are Meta Ads, Google Ads, TikTok Ads, and X Ads. Revenue integrations are Stripe, Shopify, Xero, and QuickBooks. Per-platform expectations:
| Source | Representative inputs | Notes |
|---|---|---|
| Save rate, story exits, carousel completion, reach breakdown, profile actions | Richest depth-of-impression surface; benchmarked per audience tier | |
| Reaction split, share-to-reach ratio, page engagement | Reactions scored as a 3-way split; ambiguous reactions never counted positive | |
| TikTok | Sound reuse, duet rate, profile click-through, completion | Discovery-weighted; entry-point signals feed Reach |
| YouTube | Retention checkpoints (30s, 60s), end-screen CTR, traffic source mix | Traffic source diversity scored via normalized Shannon entropy |
| Twitter/X | Quote volume, list adds, link expansion rate | Conversation-depth signals feed Impact |
| Ad platforms | Paid impressions, cost efficiency, ad-to-organic correlation | Correlation metrics gate on a hard minimum sample of n at least 10 |
| Revenue integrations | Repeat purchase rate, refund rate, churn | Activates Mode-2 Sentiment (section 05); the only path by which Sentiment scores |
Each metric normalizes against tier and platform benchmarks keyed by audience size (tiny through Fortune 500, plus an agency profile), so inputs are always interpreted relative to what an account of that scale on that platform should achieve. Connecting a platform adds its metrics to pillar coverage; the engine never penalizes a platform for fields the account’s API tier does not expose beyond the neutral shrinkage described next.
04Computation order
The engine computes in a fixed order. Pillar order follows the acronym: Impact, Momentum, Presence, Reach, Sentiment.
- 1. Metric normalization. Raw inputs score 0-100 against tier and platform benchmarks.
- 2. Pillar aggregation. Each pillar aggregates its available metrics into a raw 0-100 pillar score.
- 3. Coverage shrinkage. Each pillar is pulled toward neutral 50 in proportion to missing metric coverage: shrunk = raw x coverage + 50 x (1 - coverage).
- 4. BHI. Presence, Reach, and Impact combine under segment-validated shares, discounted by the maturity modifier (a bounded penalty, floor 0.85, when high Presence coexists with low Momentum).
- 5. GMS. Momentum (mode-resolved: delta, year-1 neutral, lagged blend, or absolute) blends with Impact under the segment’s momentum share.
- 6. Composite. Mode 1: blend of BHI and GMS. Mode 2: 0.80 x (BHI/GMS blend) + 0.20 x shrunk Sentiment.
- 7. Bonuses. Stability, acceleration, and cross-platform credits, capped at the distance to 90 so bonuses alone can never reach the elite band.
- 8. Display transform. display = round(350 + clamp(raw, 0, 100) / 100 x 550). This function is the single source of truth for the 350-900 mapping; grade bands (Critical 350-499, Developing 500-649, Moderate 650-749, Strong 750-849, Elite 850-900) derive from it.
Consumers must treat the internal 0-100 score as private and render only display-scale values obtained from the engine’s own transform. Re-implementing the mapping, or hardcoding band edges elsewhere, is a defect class we have specifically engineered against: every surface derives from the canonical constants.
05Sentiment modes
The Sentiment pillar resolves to exactly one of four modes per audit, in priority order:
| Mode | Trigger | Scoring effect |
|---|---|---|
| financial | Any of repeat purchase / refund / churn present from a revenue integration | Mode 2: additive pillar at weight 0.20; partial coverage shrinks the score toward 50, never the weight |
| nlp_primary | Comment classification validated | Gated off in V32; activates only under a pre-committed validation criterion |
| nlp_fallback | No financial data; 30 or more reliably classified comments | Display-only preview at weight 0, shown with a connect-a-revenue-source CTA |
| proxy_only | No financial data, no reliable classification | Unscored: pillar neutral, weight 0 |
The invariant behind the table: comments never move the score. Only revealed-preference financial behavior scores, through the single Mode-2 additive channel. The legacy sentiment multiplier is retired; the engine still reports a sentiment factor field for API compatibility, permanently pinned to 1.0.
06Edge cases
Missing platforms and partial data
A disconnected platform simply contributes no metrics, and the affected pillars shrink toward neutral in proportion to lost coverage. The audit reports per-pillar confidence and an overall data-quality block, and an account is scoreable when at least three of the five pillars have data. Reported audit confidence steps with integration depth (65 to 95 across the confidence levels), so consumers can distinguish a thin score from a rich one.
No revenue source connected
The account scores in Mode 1. Sentiment carries weight 0 and resolves to proxy_only (unscored) or, with enough classified comments, to the display-only nlp_fallback preview. Connecting a revenue integration switches the next audit to Mode 2, where Sentiment becomes a real additive pillar at 0.20.
New accounts
A first-year creator has no prior-year momentum, so the engine substitutes neutral momentum (50) and anchors the score on Impact; the product surfaces this as establishing baseline, and the forecast layer treats such accounts conservatively. From year two, momentum switches to the year-over-year delta, which is the validated creator signal. Non-creator accounts with sparse history score under normal coverage shrinkage: valid, low-confidence, converging as data accumulates.
Missing lagged snapshots
The lagged momentum blend requires 7- and 14-day snapshots alongside financial data; when absent, momentum falls back to the standard current-window computation with no penalty.
Degenerate weight configurations
If a segment’s BHI weight vector sums to zero on the legacy path, the engine falls back to a defined pillar rather than dividing by zero; segment share overrides make this path effectively unreachable in V32, but the fallback is specified so behavior is never undefined.
07Data freshness and re-audit cadence
Every account with an active platform connection is re-audited weekly through the canonical pipeline. The scheduler runs daily and audits the cohort whose stable user-id hash maps to that day of the week, so one seventh of accounts refresh each day and no account can time the scan (an anti-gaming property: audit day is a deterministic function of the account, not a published schedule). Deactivated and demo accounts are excluded.
Score freshness is a first-class, displayed state derived from the last audit date:
| State | Age | Meaning |
|---|---|---|
| fresh | 7 days or less | Current; within one full re-audit cycle |
| stale | 8 to 21 days | Aging; typically a paused or failing connection |
| expired | more than 21 days | Outdated; the score should not drive decisions until re-audited |
| none | no audit | Never scored |
Consumers should treat display scores as valid as of their audit timestamp, not as live values, and surface the freshness state alongside the number.
08The forecast layer (application, not measurement)
Directional forecasting is built on top of the score and is governed separately, because its evidence is separate. The engine emits a directional call (up, flat, or down) from five weighted signals: score level versus the segment median, score velocity, regime zone, level-velocity consistency, and momentum-level confirmation. All five weights, and the gates below, are calibrated per segment against the validation panel.
- Abstention is structural. A call is issued only when the move is material for the tier (a per-segment conviction threshold), agrees with the account’s level position, and clears a data-confidence gate. Everything else returns flat, and flat means the signal did not clear the validated bar, not that nothing is happening.
- Creator down-calls are suppressed outright. Down-calls inverted for creators on the validation panel, so the engine never emits one for a creator account, including creator clients on agency rosters, which inherit the creator guard rather than the agency configuration. This holds until the live panel re-tests the claim.
- Macro regime guard. In detected rate-compression regimes, confidence intervals widen and directional calls are suppressed, with a disclaimer attached to the result.
- Prospective logging. Every issued call is timestamped and stored before its outcome is known and is never edited afterward. Where the accuracy of these calls is discussed, it is reported as precision on the called subset with skill over the base rate, per the standards on the research hub; raw direction accuracy is never the claim.
09Reproducibility guarantee
The reproducibility contract, stated as an interface:
Given the same input snapshot, the same engine version returns the same overall score, the same pillar scores, the same display score, and the same grade, exactly. The engine achieves this by construction: pure functions over the snapshot, no wall-clock reads inside scoring, no network calls, no sampling, and no model inference. Audits persist their inputs alongside their outputs, so any historical score can be recomputed and checked against the stored value.
This is the property that makes the score auditable by third parties: replication requires only the input snapshot and the versioned formula, not our infrastructure.
10Change control
The formula is sealed under a re-seal gate. Any change to weights, thresholds, normalization tables, metric definitions, or composite structure requires: a new version number; a re-run of the full simulation and validation suite against the sealed panel; publication of the new version’s evidence separately from prior versions; and no retroactive merging of results. Validation evidence is permanently attached to the version that produced it. V32 is always V32; V33 earns its own.
Pre-committed gates inside V32 follow the same discipline: the comment-classification gate opens only on a validation criterion fixed before the data exists, and the Mode-2 sentiment weight rises only with production outcome data. Neither is a runtime configuration; both are version events.
For the mathematical treatment behind this specification, see the Technical Paper. For the plain-language case and the validation narrative, see the Whitepaper. The live validation record is on the research hub.