SocialHub.AI

Developer Center · Engineering reference

Consumer World Model

The model layer under the Decide node: a per-brand Behavior Model (an event-sequence model of how each member behaves) plus a Digital Twin layer that runs it forward (counterfactual simulation and the synthetic research panel). This page covers what an integrator can actually touch: the events that feed it, the gate that decides whether it serves, the surfaces its outputs land on, and the MCP tools that drive the panel.

Use the governed read-only REST endpoints or MCP tools below for one member prediction. Next-behavior results and personal purchase windows share a response, with explicit availability and permission checks. Events still enter through the normal integration surfaces; additional outputs surface in segments, member profiles, lookalike, send-time optimization and the synthetic panel.

Next behaviors, purchase windows and demand context

One member prediction returns next behaviors and personal purchase windows, combining consumer signals with brand demand context when the tenant fusion head is ready.

Interactive example

One consumer. One prediction response.

All states and numbers are synthetic examples, not live predictions or workspace readiness. No customer data is sent.

Choose an example state
Partial result

Behavior predictions remain available. Purchase windows stay unavailable until the brand's fusion head is trained and validated.

What could happen next?

One final distribution over this example's four supported events. Next-event probabilities are uncalibrated.

Next eventProbability
Purchase37%
Portal visit28%
Email click21%
Coupon redemption14%
Why is an event missing?

Email sent is an input context event, not a prediction target. Its probability is null. Other unsupported or uncovered events also stay unavailable.

Will they buy within…?

Personal CWM signals + TimesFM brand demand context.

7 days
Unavailable
30 days
Unavailable
90 days
Unavailable

Chance of at least one purchase. These windows are cumulative; do not add them together or to the event distribution.

Use the same result in your workflow

One member request returns distribution and purchaseWindows together.

Explore API / MCP calls
curl --request GET \
  "https://YOUR_API_HOST/api/v2/cwm/members/YOUR_MEMBER_UUID/next-behaviors" \
  --header "Authorization: Bearer YOUR_API_KEY"

Replace the API host, member UUID and API key with your workspace values.

Required access · predictions:read returns behaviors. Also grant metrics:read (or *) to enable purchase windows when the model is ready.

View response excerpt

Synthetic excerpt only. Brand-model responses also include the full event catalog and coverage metadata; public-prior references use a separate six-class vocabulary.

{
  "predictionKind": "next_event",
  "unit": "probability_0_1",
  "status": "degraded",
  "distribution": {
    "status": "ok",
    "vocabulary": "member_event",
    "normalization": "conditional_on_supported_events",
    "calibrated": false,
    "rows": [
      {
        "key": "purchase.completed",
        "label": "Purchase",
        "probability": 0.37,
        "rank": 1,
        "availability": "predicted"
      },
      {
        "key": "portal.visited",
        "label": "Portal visit",
        "probability": 0.28,
        "rank": 2,
        "availability": "predicted"
      },
      {
        "key": "email.clicked",
        "label": "Email clicked",
        "probability": 0.21,
        "rank": 3,
        "availability": "predicted"
      },
      {
        "key": "coupon.redeemed",
        "label": "Coupon redeemed",
        "probability": 0.14,
        "rank": 4,
        "availability": "predicted"
      },
      {
        "key": "email.sent",
        "label": "Email sent",
        "probability": null,
        "rank": null,
        "availability": "context_only"
      }
    ]
  },
  "purchaseWindows": {
    "unit": "probability_0_1",
    "probabilities": {
      "7": null,
      "30": null,
      "90": null
    },
    "calibrated": false,
    "envelope": {
      "status": "unavailable",
      "backend": "cwm-timesfm-2.5",
      "reasonCodes": [
        "fusion_not_trained"
      ]
    }
  },
  "reasonCodes": [
    "fusion_not_trained"
  ]
}

Synthetic data · TimesFM 2.5

Explore daily demand trends

An example forecast from 128 days of synthetic history. Compare the recent pattern with future daily demand and its quantiles.

Forecast horizon

Synthetic demand units

Recent daily average
20.0
Forecast daily average
20.1
Forecast total
604.3
History · recent 28 daysPoint forecast
Historical demand and future point forecasts with q10–q90 quantilesThe navy line shows 28 days of history. The green line shows the selected forecast horizon. Shading shows the q10–q90 quantile range. Use the day slider to inspect each forecast.
Day 1 · 2026-10-05
Point forecast
22.9
q10
22.8
q90
23.0
View daily forecast data
Date (UTC)Point forecastq10–q90
2026-10-0522.922.8–23.0
2026-10-0621.321.2–21.4
2026-10-0718.718.6–18.8
2026-10-0817.117.0–17.1
2026-10-0917.717.6–17.7
2026-10-1020.020.0–20.1
2026-10-1122.322.3–22.4
2026-10-1222.922.9–22.9
2026-10-1321.321.2–21.3
2026-10-1418.718.6–18.7
2026-10-1517.117.0–17.2
2026-10-1617.717.6–17.7
2026-10-1720.019.9–20.1
2026-10-1822.422.3–22.4
2026-10-1922.922.8–23.0
2026-10-2021.321.2–21.4
2026-10-2118.718.6–18.7
2026-10-2217.117.0–17.1
2026-10-2317.717.6–17.7
2026-10-2420.019.9–20.0
2026-10-2522.322.3–22.4
2026-10-2622.922.8–22.9
2026-10-2721.321.2–21.3
2026-10-2818.718.6–18.7
2026-10-2917.117.0–17.2
2026-10-3017.717.6–17.7
2026-10-3120.020.0–20.1
2026-11-0122.422.3–22.4
2026-11-0222.922.8–22.9
2026-11-0321.321.2–21.3
Download example data (JSON) ↓

Synthetic example, generated with TimesFM 2.5 weights. The forecast starts on 2026-10-05 (UTC); dates are fixed for the demo. Quantile coverage is uncalibrated. Values do not represent a customer's demand or individual purchase probabilities.

One complete next-behavior distribution

Receive one final probability distribution and ranking. The evaluated brand model takes priority, with up to 23 covered targets. When it is unavailable, internal public-prior models form a single six-class reference. Unsupported and context-only events remain unavailable.

7 / 30 / 90-day purchase windows

Included automatically in the same member response: a tenant-private lightweight head combines CWM signals with TimesFM brand trends. Ready heads serve directly; missing training or evaluation leaves only the purchase windows unavailable.

Daily brand and category forecasts

Where the TimesFM 2.5 service is configured and daily history is complete, forecast revenue, orders or units sold for up to 90 days, with point estimates and nine quantiles.

How to read these results

Next-event probabilities sum to 100% over supported candidates and are uncalibrated. Purchase windows separately estimate at least one purchase within 7/30/90 days and are cumulative, never normalized with event classes. Elapsed silence is not conditioned in the event vector. The public-prior reference has not earned workspace validation.

Demand quantiles describe aggregate uncertainty; they are not individual purchase intervals and have not been calibrated. Missing data remain unavailable. No accuracy lift is asserted before your own evaluation.

Integration details and availability
# Bearer API key; predictions:read
GET /api/v2/cwm/capabilities
GET /api/v2/cwm/members/{id}/next-behaviors

# metrics:read additionally enables purchaseWindows in next-behaviors
# predictions:read AND metrics:read for standalone trend/windows
GET /api/v2/cwm/trends?metric=gmv&horizon_days=30
GET /api/v2/cwm/members/{id}/purchase-windows

# Read-only MCP equivalents
cwm_get_forecast_capabilities
cwm_predict_next_behaviors
cwm_forecast_aggregate_trend
cwm_predict_purchase_windows

Purchase probabilities use 0–1 units and cumulative, monotonic windows. Until trained and validated, the response contains probabilities: {"7":null,"30":null,"90":null} and calibrated: false. Existing CWM 0–100 mass scores keep their meaning. Aggregate forecasts return one point and q10..q90 per complete UTC day; missing daily buckets are not filled with zero. Category names require catalog_gmv or units_sold; draft input metrics are disclosed. Tenant and member authorization remain server-side. Readiness distinguishes service_unavailable, awaiting_training, awaiting_validation and ready. TimesFM 2.5 weights use Apache 2.0.

Next-behavior responses use predictionKind: next_event and unit: probability_0_1. One response includes distribution and purchaseWindows; individual expert results are internal. Purchase fusion is invoked automatically when metrics access permits. A validated tenant head serves cumulative 7/30/90-day probabilities; missing permission, training, validation or inputs leaves all windows null with an explicit reason. Available behavior predictions remain readable. These windows are not summed with the next-event distribution. The brand model's rows include all 48 standard events: 26 are consumer behaviors, 39 enter the sequence vocabulary, and 23 is the prediction-target ceiling. Only covered candidates supported by the active, evaluated generation receive probabilities; all other rows have probability: null and an explicit availability. Legacy input-frequency coverage is weaker corpus-presence evidence and cannot certify provenance-masked tag targets. New snapshots use positive targets from optimizer training windows, excluding validation members and masked rows. The final distribution includes rank, entropyBits, retainedModelMass, coverageBasis, modelVersion and calibrated: false. An available, evaluated brand model is used directly without requesting alternate expert outputs. Otherwise, valid public-prior distributions are equally averaged internally into one degraded pv / fav / cart / buy / rmcart / buy_disc reference. aggregation distinguishes single_tenant_model from uniform_valid_experts; vocabulary identifies the candidate key space. The two vocabularies are never blended. The uniform reference is not a learned multiclass gate and is not tenant-validated; public class-training coverage is unverified. Rounded zero mass does not prove absent class training. This endpoint needs predictions:read; purchaseWindows additionally needs metrics:read or *. Without metrics permission, the purchase component reports metrics_scope_required and makes no metric or fusion call. Status is ok only when both earned components serve, degraded for partial/reference results, and unavailable when neither serves. Store access and live processing eligibility are rechecked before personal external processing; insufficient evidence remains unavailable. One request shares its live CWM fingerprint internally across the behavior and purchase heads.

1 · What feeds it

The model trains on the member event stream your integrations already produce — REST API v2 (orders, members), web & portal tracking, POS/receipt capture, loyalty and coupon activity. Events pass a governed catalog with a policy firewall before they can enter training; the firewall is enforced in the pipeline, not by convention.

Admitted: behavioral events

Purchases, receipts, points earned/redeemed, tier changes, coupon claims/redemptions, email opens/clicks, push opens, portal visits/clicks, store check-ins. Every event type is explicitly admitted to the catalog — new event types don't train silently.

Barred: feedback & content

Anything the model itself writes back (its own tags and scores) is excluded — a model must not learn from its own output. Message content and free text never enter training: the model learns that a member clicked, never what the message said.

Barred: restricted members

Members under a processing restriction (GDPR Art. 18) are excluded from training end-to-end, and an erased member's data — including their embedding — is removed as part of the deletion machinery itself.

Practical consequence for integrators: the richer and cleaner your event feed (correct member identity resolution, honest timestamps), the better the model — there is no separate “training upload.” See REST API and Web Tracking.

2 · The honesty gate & serving predicate

A brand's model is trained per tenant, deterministically (same data ⇒ same model, versioned), and it only serves after beating a transparent baseline on that brand's own held-out data. Downstream consumers never read the model directly — they go through a single serving predicate:

serve = verified_win ∧ not_paused ∧ not_stale

If any leg fails — the model hasn't earned its place yet, the brand paused scoring, or the model has gone stale — every consumer falls back to the glass-box predictive models (or an honest empty state, in lookalike's case). Nothing is ever zero-filled and nothing pretends: a member without an embedding is served by the fallback path, never padded into the model's.

Lifecycle a brand sees

Accumulating data

not enough history to train honestly — nothing serves

Comparing weekly

trained, being tested against the baseline on held-out reality

Active

beat the baseline — embeddings & predictions serve

Paused / stale

scoring stops or the model ages out — automatic fallback

3 · Outputs and where they surface

Three existing output families are available in the member and segment surfaces below. Use the governed REST or MCP prediction interface above for the unified next-event distribution and purchase windows.

Member embeddings

A behavioral fingerprint per member, learned from their whole event sequence. Powers nearest-neighbor similarity: every member with behavior has one — no tags required.

Next-event probabilities

Per-member purchase imminence and churn imminence (0–100), refreshed as behavior lands. Exposed as segment conditions — e.g. "Purchase Imminence (predicted next-event, 0-100)" — and on the member profile.

Per-member timing

Each member's expected next-purchase window and engaged hour of day, from their own rhythm.

4 · Driving the synthetic panel over MCP

Your AI agents can operate the Digital Twin's research panel through the governed MCP server. Four panel tools, verbatim from the live manifest, alongside the read-only prediction tools above:

list_synthetic_scenarios

((none))

List the synthetic-panel simulation scenarios with each one's honest usability boundary, confidence ceiling, and input fields. Call first to pick a kind. Requires metrics:read.

run_synthetic_panel

(segment_id, kind, fields)

Run a synthetic panel: de-identified digital twins of a segment react to a stimulus, producing an honest directional report (never real absolute numbers). Returns a run_id to poll. Bounded by a daily run cap + ≤50 twins. Requires synthetic:write.

get_synthetic_report

(run_id)

Read the frozen honest report for a synthetic-panel run — directional read, confidence ceiling, suppression flags, themes — or a blockReason if not ready. Requires metrics:read.

get_synthetic_calibration

((none))

The brand's synthetic-panel calibration (hit rate of past synthetic predictions vs reality; null until backtests exist). Requires metrics:read.

Typical flow

  1. 1. list_synthetic_scenarios → pick a kind + read its usability boundary
  2. 2. run_synthetic_panel(segment_id, kind, fields) → run_id // requires synthetic:write
  3. 3. get_synthetic_report(run_id) → directional read · confidence ceiling · suppression · themes — or blockReason
  4. 4. get_synthetic_calibration() → your brand's hit rate vs. reality (null until backtests exist)

Contract to design against: runs are bounded (daily run cap, ≤50 twins per run); reports are directional, never absolute numbers; a run that fails its honesty checks (panel collapse, sycophancy, too-small sample) comes back with a blockReason or suppression flags instead of a flattering result — treat those as terminal, not retryable. The same caps and rules apply whether a human or your agent starts the run. Setup, auth and scopes: MCP Integration Guide.

5 · Guarantees you can build on

Per-brand isolation

One model per tenant, trained on that tenant's members only. Nothing pools across brands — in either direction.

Deterministic & versioned

Same data produces the same model, bit for bit; every score is traceable to the model version that produced it.

Erasure-complete

Member erasure deletes their training data and embedding as part of the deletion transaction — not on a cleanup schedule.

Staleness-purged

Embeddings that outlive their freshness window are purged on schedule, and a stale model stops serving automatically.