# APAC — Execution Status & Divergence from Plan

**Landed repo (source of truth for running code):**
[`pingcap-inc/pingcap-support/apac_lambda_tasks`](https://github.com/pingcap-inc/pingcap-support/tree/main/apac_lambda_tasks) —
scoring/priority rules doc:
[`APAC-Tenant-Scoring-and-Priority.html`](https://github.com/pingcap-inc/pingcap-support/blob/main/apac_lambda_tasks/APAC-Tenant-Scoring-and-Priority.html)

This folder doesn't duplicate that code or design. It exists so that anyone opening `/apac` here lands
on the current truth instead of stopping at the v1 planning docs, which the build has since partially
superseded.

## Status (checked 2026-07-21)

- Engineering owner: Yujie. Repo: `pingcap-inc/pingcap-support`, dir `apac_lambda_tasks/`.
- Five Python 3.12 Lambdas (SAM stack `apac-tenant-monitoring`, AWS account `552185537300`, `us-west-2`)
  are **deployed** (`CREATE_COMPLETE` as of 2026-07-14): Dispatcher → SQS → Worker → SQS → Scoring, plus
  daily Summary and weekly Metrics sending Feishu cards.
- Live DB `regional_support` had, per the 2026-07-15 post-migration snapshot: `apac_active_tenants`
  1,034 (P0 33 / P1 29 / P2 972) and `apac_sales_owned_tenants` 161 (P0 26 / P1 15 / P2 120).
- **Not yet fully live:** per `HANDOFF.md`, the Summary and Weekly Metrics EventBridge schedules are
  `DISABLED`; only Dispatcher runs on an (undocumented-in-template) drifted schedule. Code and infra
  are built and have executed against production data, but the automated daily/weekly cadence isn't
  switched on end-to-end yet.
- Scoring/priority rules doc last updated 2026-07-20; `HANDOFF.md` last updated 2026-07-15 — treat the
  HTML doc as the freshest single source for "how scoring works today."

## What changed vs. our v1 planning (this repo)

| Dimension | Our plan (`../apac-pql-v1-model.md`, `../apac-stakeholder-asks.md`) | What actually landed |
|---|---|---|
| Market scope | India + APAC-Others, **excludes CN and JP** | **CN is included**, JP excluded (`country NOT IN ('JP')`) — a live decision, not yet reflected as a confirmed answer in our stakeholder ASKs doc |
| Fit axis | Blocked: `company_ai_category` 0% populated in the BQ view → **P0 = 0** until enrichment lands | **Solved, via a different path**: a dedicated `domain_intelligence` table (cached + OpenAI web search classification) feeds a 7-tier Fit scale (core AI 30 → individual 0). This is the exact mechanism our `apac-data-inventory.md` flagged as EMEA's approach — it landed for APAC too, just outside the BQ pipeline |
| Data source | BigQuery `vw_pql_candidate_facts` (global warehouse view, `gcp-martech-infra`) | Own Postgres DB `regional_support`, populated directly by the Lambda pipeline from DevOps/Billing/Clinic/HubSpot — doesn't depend on the BQ view being enriched at all |
| Signal model | Fit × Signal matrix: Commercial (import/card/spending-limit) + Workload (QPS/first-DDL/logs) + Activation, weighted and capped, banded into Strong/Moderate/Early | `Activity(40) + Fit(30) + Urgency(30) = 0–100`, but **priority is rule-based override, not score bands** — e.g. `cluster_count ≥ 50` alone forces P0 even at score 33 |
| Import / first-DDL signal | Import = strongest live signal (~1.4k); first-DDL blocked on O11Y | **Neither is used.** Activity axis is QPS + cluster count + card only — no import, no DDL, no log volume, no active-days |
| Deployment form | Recommended **bot** (Feishu/Slack daily+weekly digest → CRM tasks) as the fastest path | Built a full **AWS SAM stack** (Dispatcher/Worker/Scoring/Summary/Weekly, SQS + DLQs + EventBridge) — heavier than the bot recommendation, though the visible output (Feishu digest) matches what was asked for |
| HubSpot direction | Both directions planned: read Target list `19544` for P0 override, **and** write P0/P1/P2 back to a Contact property (see [`../bot-to-hubspot-writeback/bot-to-hubspot-writeback.md`](../bot-to-hubspot-writeback/bot-to-hubspot-writeback.md), which is now byte-identical in both repos as of 2026-07-20) | **Both directions are live.** Read: Target list `19544` match forces final P0 (last sync 2026-08-26, 286 accounts). Write: Scoring PATCHes `apac_pql_priority_tier` on the email-matched HubSpot contact — **deployed to production 2026-07-21, token configured**; Active tenants only, sales-owned log `sales_owned_skipped`. *(Corrected 2026-08-26 — this row previously said the write half had no code, which was true only for the few hours before the 2026-07-21 deploy.)* |
| Sales ownership | Not modeled in our v1 | New concept not in our plan: `apac_sales_owned_tenants` — tenants owned by a configured APAC Sales rep list are scored normally but **excluded entirely** from Summary/Weekly reporting |

## Reconciliation needed (open, not yet resolved)

- **CN in/out** — `apac-stakeholder-asks.md` §2 still asks GTM to confirm the market list; the landed
  pipeline already made the call (CN in, JP out). This needs an explicit recorded decision, not silent
  drift between what we asked and what shipped.
- **Fit-enrichment blocker** — `apac-data-inventory.md` marks this "blocked" against the BQ view. It
  should be reframed as "resolved via a separate pipeline, not via the BQ view" so nobody re-chases the
  same enrichment ask that's already been solved a different way.
- **HubSpot write-back** — ~~not yet built~~ **resolved: live in production since 2026-07-21** (see
  the table row above). This bullet was stale for a month; corrected 2026-08-26. The *remaining*
  write-back gap is the other direction — follow-up state never returns to the database
  (`track_step` = 0 for all 7,788 rows, `track_update_time` never written). See
  [`../apac-operating-mechanism-2026-08-26.md`](../apac-operating-mechanism-2026-08-26.md) §1.
- **Two-layer reality** — scoring runs in `apac_lambda_tasks`, but the prioritisation SDRs actually
  act on (🆕 new-tenant channel, dormancy compression, blacklist, R22/R22b dedupe) lives only in
  Yan's agent. Those rules should be promoted into the official spec rather than staying in an
  unofficial build.

## Update — 2026-08-26 (operating review)

The 2026-07-21 status above still describes the build. What it does **not** describe is how APAC is
operated day to day, which is a second layer on top of this stack. Full picture, plus the live
numbers behind the dormant-P0, fast-riser, self-pay and signal-outage questions raised in the APAC
monthly review:
[`../apac-operating-mechanism-2026-08-26.md`](../apac-operating-mechanism-2026-08-26.md).

Headline facts verified against the live DB on 2026-08-26 (7,788 active tenants, P0 43 / P1 110 /
P2 7,635; 168 sales-owned):

- **29 of 43 P0 have held P0 every day since snapshots began (2026-07-13).** Only 7 of 43 show any
  live QPS. 61% of all tenants were last rescored 15+ days ago.
- **`apac_tenant_events` is empty (0 rows)** — EMEA's event-silence decay patch does not port to APAC.
- **Snapshots cover ~12.6% of tenants per day** (rotating scan, not a census); a 7-day score delta is
  computable for only 814 tenants, and they are the already-visible core.
- **`has_credit_card` is NULL for 91.3% of tenants**; of the 231 known card holders, 208 are P2.
- **New signups ran normally 08-11 → 08-21** (~1,685 tenants) — the 9.6-day outage was in the digest
  feed, not in ingestion. Recoverable by backfill.

## Indicator — where to look for current truth

For scoring/priority logic and live deployment state, check the landed repo first, not the docs in the
rest of `/apac`:

**https://github.com/pingcap-inc/pingcap-support/blob/main/apac_lambda_tasks/APAC-Tenant-Scoring-and-Priority.html**
— a snapshot as of 2026-07-15 is mirrored here for reference:
[`reference/APAC-Tenant-Scoring-and-Priority-20260715-snapshot.html`](reference/APAC-Tenant-Scoring-and-Priority-20260715-snapshot.html).

Operational detail lives alongside it in the same directory: `HANDOFF.md` (engineering handoff, session
state), `README.md` (architecture/ops), `HUBSPOT-SALES-ROUTING-DESIGN.md` (routing design).

**Do not treat [`yybaroq/plg-notification`](https://github.com/yybaroq/plg-notification) (a separate,
unofficial APAC notification shadow build) as a source of truth for anything engineering** — its
scoring formula has drifted from the doc above in confirmed ways, and its delivery mechanics are the
same layer where that drift happened. See
[`apac-scoring-model-divergence-note.md`](apac-scoring-model-divergence-note.md). The only thing worth
taking from that build is its business/GTM thinking (account categorization, routing judgments) — not
any of its code or schema.

The rest of `/apac` in this repo (model spec, data inventory, stakeholder asks) remains the **v1
planning record** — still useful for the "why" behind the scope and the open GTM decisions, but
increasingly superseded for "what's actually running" by the link above.