PolyU Alumni Data Integration — Final Synthesized Plan

Opportunity: EventBinder (Kenta Ng) pitching "Robbie" (Mr Robbie Sin, IT Manager, PolyU Alumni Affairs Office) on two named workstreams — (1) LinkedIn profile refresh / alumni-data currency, and (2) event registration data integration.

Prepared by synthesizing two independent efforts:

PA — puaa/PA (fable5 ultracode): INVESTIGATION.md, PROPOSAL-PLAN.md, PROPOSAL.md + 12 research memos with per-claim sourcing.
PB — puaa/PB (codex 5.5 xhigh + 5.6 sol ultra): V1→V4 proposal iterations, V3/V4 bid playbooks, executive proposal, cover message.

Date: 2026-07-11. Status: internal synthesis + client-ready recommendation. v2 — cross-checked against an independent, blind codex rerun (Section F); its convergence confirms the spine, and four of its risks are elevated below. v3 (2026-07-12) — delivery model set to on-prem self-host in the AAO office (client direction; Robbie green-lit) and Parking added as Pilot Zero (§C.8); see the updated hosting bullet in §C.5 and the new discovery items in §D. v4 (2026-07-12) — added §C.12 QR & Wallet identity layer and §C.13 AI-assisted data integration (self-hosted, human-in-the-loop — Robbie-requested); +2 discovery items. v5 (2026-07-12) — added §C.14 Information-architecture reference (SCAA + Alpha student platform reviewed live); the alumni portal's gap is information surfaced, not styling.

How to read this doc: Section A is the decision-comparison table (the core deliverable — every major choice with why-chosen / why-not). Section B is the evidence-confidence ledger (what is safe to say vs speculative — read before any client contact). Section C is the full final plan. Section D is open questions + immediate next actions (cover message + reconciled meeting-question shortlist).

0. The single sharpest positioning (the one decision that matters)

"You already own the systems. What you don't own is the seam. I'm proposing a paid six-week discovery that maps and proves one governed path back to your Alumni record — for LinkedIn-sourced career data and for event participation from every source (CEMS, art-mate, PFS/LimeSurvey) — not another app, event system, or QR check-in."

This fuses PA's "One Alumnus, One Record" narrative frame with PB's discipline of scope (interoperability/data-contract layer, explicitly not a product pitch, sized as a de-risking discovery). Robbie is technical and is AAO's own IT manager — the pitch must read as an integration-architecture proposal to a peer, wrapped in a memorable one-record story, never as a vendor selling a platform.

A. Decision-comparison table (PA vs PB vs Final + rationale)

#	Decision	PA's position	PB's position	FINAL	Why final / why not the alternative
A1	Core positioning	"Alumni Engagement Layer" on top of AMS/CEMS; gamification, digital card, wallet passes, engagement mechanics ("One Alumnus, One Record").	Narrow "data interoperability" layer: identity linkage + data contracts + consent/provenance + writeback. Explicitly NOT an app, event system, QR, or gamification.	PB's scope + PA's story. Sell a data-interoperability discovery, framed with PA's "one alumnus, one record, one journey" narrative. Gamification/wallet/app are a future-vision appendix slide, not the ask.	PB is correct on scope: Robbie asked for exactly two things (LinkedIn + event data), and CEMS already does QR check-in, payment, social login, attendance, analytics — pitching an app or QR layer pitches what they own and reads as a vendor upsell to a technical buyer. PA's engagement-layer framing over-scopes and invites the "why not ITS?" and "$1/head" fights. But PA's narrative is far more memorable and sellable than PB's dry "governed path," so we keep the story and drop the extra product.
A2	Scope of workstream 1 (LinkedIn)	LinkedIn is structurally dead for individual records; recommend non-renewal / downgrade to free Alumni tab; redeploy HK$300k into first-party capture. "Sign in with LinkedIn" = login only (name/email/photo). Optional vetted enrichment feed (EverTrue) after legal review.	Same first-party core, BUT adds Verified on LinkedIn (Lite/Plus) as a possible legitimate consented career-refresh route (Plus lists current position + recent education + change notifications under member OAuth). Do NOT recommend cancelling before auditing the contract.	PB's LinkedIn framing wins, with PA's redeployment logic held in reserve. Lead with: audit the contract first; test Verified-on-LinkedIn (dev/Lite) feasibility; first-party progressive profiling is the guaranteed engine; enrichment feed only post-legal-review. Do not open with "cancel the HK$300k."	PB found a product PA's research never examined. PA's "no LinkedIn product can ever deliver individual records" is overstated — it's true of Talent Insights/Recruiter/Sales Nav/public API/scraping (all well-sourced in PA), but Verified on LinkedIn Plus is a member-consented per-profile API that returns current position + education (PB sourced to Microsoft Learn docs, 11 Jul 2026). Both agree it needs written LinkedIn+PolyU approval and may require a Plus partnership. PA's "cancel it" is politically dangerous — the contract may sit with HR/Careers/Comms, not AAO, and rubbishing it before evidence attacks an internal stakeholder. PB's "judge against purchased purpose, not a predetermined cancellation result" is the wiser play.
A3	Scope of workstream 2 (events)	Unified event layer that replaces art-mate for flagships, writes registration+attendance back to AMS; CEMS keeps small events; cabi POS for on-site scan/badge.	Canonical event-participation data contract across CEMS + art-mate + PFS/LimeSurvey + future vendors; reconciliation + exception queue + writeback. CEMS is the default; external systems allowed but must return data to a standard. NO new registration/QR/scanner product.	PB's data-contract approach. The deliverable is a canonical participation contract + connectors + reconciliation, not a competing event system. CEMS stays the operational default.	PA's "replace art-mate for flagships" re-opens the exact ticketing-vs-ticketing / HK$1-per-head price fight PA's own incumbent analysis warns against, and it duplicates CEMS. PB's "make data-return mandatory, don't ban the tool" is both cheaper to sell and technically correct. PA's on-site POS/scanner build is out of scope for a discovery and competes with CEMS scanning. Keep PA's "attack the seam" line — PB operationalizes it as the data contract.
A4	Architecture	Engagement & Integration Layer (EIL): identity gateway, engagement ledger, consent ledger, profile-delta queue, connectors (CEMS/art-mate/form), rotating signed QR token. Minimal data, AMS = system of record.	Event Interoperability Service + LinkedIn connector: source adapters, schema validation, identity match (confidence tiers), consent check, provenance, exception queue, reconciliation. Profile-assertion contract + event-participation contract. "Reuse existing ITS integration bus/iPaaS/ETL first."	Merge — they are the same architecture. Use PB's naming (interoperability service, assertion/participation contracts, adapters) + PA's "minimal data, opaque join key, AMS untouched" discipline + PB's critical "reuse existing ITS middleware first" principle. Rotating-QR token = deferred (belongs to a build, not discovery; and see A11).	The two designs are ~90% identical (both: append-only engagement ledger, per-purpose consent ledger, profile-delta/assertion queue, no second master record). PB adds the discovery-critical instruction to check for an existing ITS integration bus/iPaaS before proposing a new runtime — avoids the "you're duplicating our platform" objection. PA's rotating signed QR is well-designed but is a build feature, not a discovery item, and drags the events story back toward "new QR product" (A3). Defer it.
A5	Privacy / PDPO	Deep PDPO analysis: Part VIA (donations = DM), s.35J/35K written consent for FHKPUAA provision, DPP1/DPP3, penalties, s.35D grandfathering, TPCL for lucky draws, no fingerprinting. Consent-per-purpose ledger.	Consent-per-purpose separation table, PICS matrix, "marketing consent never a condition for ticketing," data-processor obligations (destroy on termination, no subcontracting/AI without consent), PolyU PO Data Privacy Terms.	PA's depth + PB's data-processor framing. Use PA's PDPO substance (Part VIA, DPP1/DPP3, s.35D grandfathering as a budget argument) AND PB's operational rules (EventBinder = data processor under PolyU PO terms; no personal data to external AI services; destruction certificates). Correct PA's one over-reach (see A5-note).	PA researched PDPO deepest and best-sourced (PCPD Direct Marketing guidance read in full). PB contributes the data-processor legal posture that PA lacks — critical because PolyU's standard PO terms make EventBinder a processor with destruction/subcontracting/AI-tool obligations. A5-note / correction: PA's own critic flags that "sharing AAO→FHKPUAA data needs written consent" is too broad — s.35J/35K written consent applies specifically to provision for direct marketing; non-DM sharing is a DPP3 prescribed-consent question. Use the corrected version. Also: FHKPUAA is now out of primary scope (see A9), so this mostly becomes a discovery flag, not a workstream.
A6	Procurement / tender path	Small direct-award paid discovery, then pilot sized under threshold, then scale. "Ask the threshold numbers in meeting 1." No figure researched.	HKD 50k–200k = Finance Office RFQ (≥3 quotes); >HKD 200k = tender (public Dec-2024 departmental quick guide). Discovery at HKD 188k will likely need competing quotations — do NOT expect a relationship direct-award. Never split scope to dodge a threshold. COI disclosure (proposer is an alumnus with an AAO relationship).	PB's procurement realism. Expect the HKD ~188k discovery to face an RFQ with ≥3 quotes, not a direct award. Confirm the current Finance band with Robbie. Prepare COI disclosure and supplier registration early.	PB actually researched the thresholds; PA's "size it for direct award" is an unsupported assumption — PA's own critic lists procurement as un-researched gap #1, and "direct award below threshold" is likely wrong at HKD 188k (which sits in the RFQ band and near the tender line). PB's honest "you will probably compete" is safer and prevents a strategy built on a false premise. Caveat: the HKD 200k tender figure comes from a departmental quick guide (PB self-labels it "planning evidence, not the final rule") — confirm in the meeting; do not state it to the client as settled.
A7	Pilot design	Phase 1 Card+Capture pilot (~3-4mo), Phase 2 Events+Rewards (~4-6mo), ship before Homecoming 2027. Each phase separately signable.	3 controlled proofs: Pilot A LinkedIn dev-tier proof (5-10 test accounts, synthetic AMS); Pilot B event integration proof (1 CEMS + 1 external/PFS source, idempotency/matching/reconciliation); Pilot C one controlled live 100-400-person AAO event. Homecoming = retrospective case study, NOT first live test.	PB's three-proof pilot. It maps exactly to the two workstreams and de-risks with synthetic data before any production PII. Keep PA's "each phase separately signable" + "Homecoming 2027 as the ship-by milestone" framing.	PB's pilot is tighter, evidence-gated, and correctly forbids using the 6,000-person Homecoming as the first live test (a build-order discipline PA lacks). PA's "Card+Capture / Events+Rewards" phases presume the engagement-layer product rejected in A1 and include gamification/wallet not in scope. PA's 90th-anniversary deadline and land-and-expand phasing are good and retained.
A8	Commercial structure	Phase 0 fixed-fee discovery (number TBD, "small enough for direct award"); Phase 1-2 fixed-price build + annual licence; anchor annual number vs HK$300k LinkedIn + Hivebrite enterprise. IP: PolyU-branded, EventBinder retains platform IP, source escrow.	Specific numbers: discovery HKD 168k-198k, open at HKD 188k, floor HKD 158k (only w/ written scope cut). Pilot ranges: LinkedIn proof 120-220k; CEMS+1 connector 280-480k; combined production pilot 520-900k. Milestone split 25/35/30/10. Form A (bespoke, PolyU-owned infra) vs Form B (EventBinder licensed service). Background-IP carve-out; don't submit reusable source as a deliverable.	PB's commercial machinery wholesale. Open at HKD 188k discovery, floor 158k with written scope reduction, milestone-billed 25/35/30/10. Keep PA's anchor-vs-LinkedIn/Hivebrite line for the eventual build quote only, not the discovery. Prepare Form A vs Form B before hosting policy is known.	PB did the real commercial work; PA left it "TBD, refine after discovery." PB's background-IP carve-out and "quote core-code ownership as a separate buyout; don't let a discovery PO capture the platform" are essential given PolyU's broad PO IP terms. PA's Hivebrite/LinkedIn anchoring is useful but PA's own research grades that SaaS pricing as weak ([likely], search-result grade) — so use it as rhetoric in the build phase, never as a quotable fact.
A9	FHKPUAA	Treated as a live integration opportunity (unified card, NetID SSO into the new Federation portal, graduate-verification API kills transcript uploads); Phase 3. Deep research on Cambison, EGM, new portal.	Explicitly out of primary scope — "FHKPUAA is not a primary stakeholder unless AAO identifies a specific dependency. Robbie is AAO, not FHKPUAA."	PB's exclusion. Keep FHKPUAA as a discovery flag / phase-3 vision note only, not a workstream. Retain PA's research as background (eligibility-claim pattern, not a second member DB).	Robbie asked for two things; FHKPUAA is neither, and V3's evidence shows individual FHKPUAA membership already routes through the Alumni Portal — so the "bridge" PA designed is partly moot. Pulling it in bloats scope and adds the highest-PDPO-risk data-sharing question uninvited. PA's Federation research is genuinely good and stays in reserve for when AAO raises it.
A10	Handling the incumbent (art-mate / AlphaSoft)	Rich profile (§7b): 5 positioning rules — sell a different category, attack the seam not the vendor, lead with data-governance, offer year-one coexistence, let HKAAA→Glue-Up make the argument. Deep tech/company intel.	art-mate = one event source that must return data to the standard; "coexistence" via mandatory data-return contract; use Homecoming as a case study to measure real match rates. No badmouthing.	PA's positioning doctrine + PB's mechanism. Use PA's five rules (esp. "attack the seam, never the vendor" and coexistence) as the stance; use PB's canonical data-return contract as the how. Keep the incumbent intel internal.	This is PA's standout unique asset — PB never profiled the incumbent. The 5 rules are exactly right and prevent the price-anchoring trap. PB supplies the concrete deliverable (external-vendor data-return standard) that turns "coexistence" from a slogan into a contract clause. Do NOT surface the incumbent's tech weaknesses (PHP 5.6, AWS Singapore, no PICS) as an attack — PA's own critic grades several as inference, Lo is personally trusted by AAO, and it's beneath a governance pitch.
A11	Rotating QR / digital card / wallet	In-app rotating QR (CityU pattern) + Apple/Google Wallet passes; central to the "card done right" feature.	Opaque, event-scoped, revocable tokens with no PII in the QR (a security principle), but NO new QR product.	Defer to a build; keep only PB's security principle. In discovery, adopt "no personal data in QR/URLs; opaque revocable tokens" as a design rule. Do not pitch a rotating-QR card or wallet passes.	PA's card is a genuinely good product idea but (a) it's a build feature not a discovery item, (b) PA's own critic flags two unverified claims under it (iOS PWA cache/eviction misstatement; Apple Wallet has no rotating barcode, so "add to Apple Wallet at turnstiles" may not work without NFC hardware), and (c) it competes with CEMS's existing check-in. Wrong altitude for this pitch.
A12	Gamification	Tier system, streaks, stamp rally (cabi QR-art collectibles), leaderboards, NUS AlumPERKS merchant model — framed as hypothesis+measurement (CASE AEM).	Explicitly out of scope; "prove the loop before game mechanics."	PB's exclusion. Cut from the pitch entirely; retain "hypothesis + CASE-AEM measurement" framing only if AAO asks about engagement ROI.	Both efforts agree gamification lacks proven ROI (PA's critic caught PA's platforms memo overselling ASU Sun Devil Rewards against PA's own playbook). It's not one of Robbie's two asks and reads as scope-creep to a technical buyer. Kill it.
A13	Discovery deliverable & duration	Phase 0: 4-6 wks, stakeholder interviews + systems audit + tech spike (SSO + one AMS API call). Costed roadmap + KPI baseline.	6 wks, week-by-week plan, 15 deliverables, acceptance criteria requiring written sign-off from BOTH AAO and ITS, a working dev-tier LinkedIn proof + event reconciliation prototype, and an "access-dependent proof is not silently waived" clause.	PB's 6-week structured discovery with explicit acceptance criteria and the dual AAO+ITS sign-off. Fold in PA's specific spike targets (NetID SSO round-trip; one AMS write-back; one CEMS event read).	PB's discovery is dramatically more rigorous (acceptance criteria, failure-state handling, "blocked test → document dependency + smallest next action"). PA's spike targets are excellent and concrete — merge them in as the technical proof content. Dual sign-off is a PB insight that protects against AAO saying yes while ITS blocks integration.
A14	Meeting / discovery strategy	Top-5 discovery questions; credibility slide (PolyU DS grad, ex-AMA lecturer, campus WiFi, BME KOA client work); demo kit; "do NOT say" list.	90-min technical scoping session, 8 named roles, timed agenda, "then stop — let them explain," 40 prioritized questions, objection-handling scripts. Cover message drafted (WhatsApp/email, bilingual).	PB's meeting choreography + PA's credibility positioning + reconciled question set (Section D). Use PB's cover message (already Robbie-specific, bilingual) with one PA-sourced tightening.	PB's meeting mechanics are more complete (roles, timing, objection scripts, "then stop"). PA contributes the credibility narrative (Kenta is a PolyU-native target user — genuinely differentiating) and the sharp "do NOT say" guardrails (2011 not 2017; no "HKU CONNECTS"; don't assert Dynamics; don't badmouth art-mate). Merge.

A5-note, A6-caveat, A10-caution are carried into Sections B and C below.

B. Evidence-confidence ledger — read before ANY client contact

The two efforts researched different things and disagree on what is proven. This ledger reconciles them. Grade key: ✅ primary-sourced & safe to state · ⚠️ likely / inference / single-source — hedge it · ❌ unsupported or client-asserted — treat as a discovery question, never a claim.

Fact	Grade	Reconciliation notes
AMS + Alumni Portal in-house by ITS, live 2024-06-13, "free from licensing restrictions"	✅	Both efforts; PA sourced to ITS Jun-2024 eNewsletter. Anchor fact.
First 10 days: ~5,200 visits, ~4,000 records updated (<1% of base)	✅	Same eNewsletter. The problem-statement number.
CEMS: QR + card check-in, MS/Google/Apple/WeChat guest login (from 2024-12), payment, analytics	✅	Both; PA sourced to ITS CEMS service page + Nov-2024 eNewsletter. This is why "don't pitch QR" is correct.
PFS event registration = LimeSurvey	✅ (PB) / absent in PA	Key reconciliation: PB confirmed via PFS footer/page metadata (V3 evidence table, obs 12704). PA's 12 memos never mention LimeSurvey/PFS at all. Not a contradiction — PA simply didn't look at PFS; PB's sourcing is sound. Safe to state, attribute to "PolyU Form Service (PFS)".
Alumni Portal is Next.js	⚠️ (PB) / absent in PA	PB fingerprinted it (obs 12705); PA found the stack deliberately masked (strict CSP, masked x-powered-by) and framework "unknown." Treat as likely, not load-bearing — do not assert the framework to ITS.
2011 NetID split (NOT 2017)	✅	Both efforts independently corrected the "2017" premise in Kenta's brief. PA sourced to alumni FAQ. Do not repeat "2017" to the client.
90th anniversary 2027; Strategic Plan 2025/26-2030/31 names alumni engagement	✅	PA downloaded and text-extracted both. Deadline + budget hook.
Homecoming 2026: art-mate = gate admission QR only; all capacity-limited sub-activities on CEMS; ≥1 gathering on PFS; 6,000+ attendees, ~200 volunteers	✅	PA (curl-verified redirects) + PB. Use the narrow version — art-mate did only the gate; that two-system seam is PolyU's own design.
LinkedIn: Talent Insights aggregate-only; Recruiter 25/export cap, hiring-use; Sales Nav no export; public API closed 2015-05; Sign-in returns identity only; scraping legally dead (hiQ, Proxycurl, PCPD)	✅	PA's best-sourced section (LinkedIn's own docs + case law).
Verified on LinkedIn (Lite/Plus) — Plus lists current position + recent education + validation status + change notifications, member-OAuth, subject to Plus partnership + written agreement	✅ (PB) / absent in PA	The substantive LinkedIn disagreement. PB sourced to Microsoft Learn (11 Jul 2026). PA's "no product can ever deliver individual records" is therefore overstated. Both agree it needs LinkedIn+PolyU written approval and may need a Plus partnership. State it as a feasibility to test in discovery, not a promise.
HK$300k/yr LinkedIn spend	❌ client-asserted	Neither effort verified it. PA matched ≈US$38.5k to a median contract (⚠️ inference). Which product/seat/owner = discovery question #1. Never state as fact; never say "cancel it."
art-mate = AlphaSoft Design Ltd; PHP 5.6.37 (EOL); HK$1/free-reg + HK$600/event + HK$1,000/yr + 1% commission; AWS Singapore; PolyU relationship since 2014	✅ (facts) / ⚠️ (7-FTE headcount, "HK$1/head paid" extrapolation)	PA only (PB never profiled incumbent). PHP/pricing/AWS/2014 = confirmed via live curl + art-mate's own pages. 7 staff = single paywalled Ming Pao source (⚠️); HKAAA→Glue-Up migration = ⚠️ (search excerpt, page not fetched). Keep all incumbent intel INTERNAL.
PDPO: Part VIA (donations=DM), s.35C/E/F/G, s.35J/35K written consent for third-party DM provision, s.35D narrow grandfathering, DPP1 not-excessive, penalties HK$500k/3yr & HK$1M/5yr	✅	PA read PCPD Direct Marketing guidance in full. Correction: s.35J/35K applies to provision for direct marketing only; non-DM AAO↔︎FHKPUAA sharing is a DPP3 question (PA critic flagged PA's own over-broad wording).
EventBinder = data processor under PolyU PO terms: destroy PII on termination, no subcontracting/no external-AI without written consent, broad PolyU IP ownership, 12-mo warranty, breach notice	✅ (PB)	PB read the public PolyU PO Data Privacy + PO terms PDF. PA lacks this. Drives the background-IP carve-out and "no PII to AI services" rules.
Procurement: >HK$50k-200k = Finance Office RFQ ≥3 quotes; >HK$200k = tender	⚠️	PB only, from a Dec-2024 departmental quick guide (PB self-labels "planning evidence, not final rule"). PA researched nothing here (its own critic: gap #1). Confirm with Robbie; do not state as settled. Any HKD 200k figure appearing as fact in PA's PROPOSAL.md would be unsourced.
CityU rotating-QR / killed physical cards 2025-03; HKUST alumni app (Beautitag); Hivebrite/Graduway/Vaave pricing	⚠️	PA only, mostly search-result grade. HKUST app ✅ (App Store fetched). CityU ⚠️. SaaS pricing ⚠️ — never quote as fact. Only relevant if we pitch a card/build (we don't, in discovery).
FHKPUAA: Cambison third-party application host; new membership portal "in final upgrades"; 24-Oct-2025 EGM, 5 member categories; individual membership routes through Alumni Portal	✅ (mostly) / ⚠️ ("payments processed on Cambison host" = inference)	PA deep-researched. Out of primary scope (A9) — background only.
cabi (EventBinder) v2025 apps' live-traffic / production status	✅ (stack) / ⚠️ (event-mgmt) — verified 2026-07-12	Live SSH probe: cabi2025 is a real prod box (408d uptime) running dashboard + backend + analytics via Cloudflare Tunnel + Tailscale. Reusable & claimable: the operating stack + analytics. NOT present on cabi2025: event management, payments, SSO, consent ledger. falcon23 verified 2026-07-12: runs `cabi_binder_app` (event mgmt) + `cabi_qr_app` (QR check-in) via CF Tunnel → event + QR are reusable, not net-new. Still unverified: payments, SSO, consent, and real prod traffic (box freshly booted, prod+dev mixed).

Three architecture/analytics conflicts to resolve explicitly (both efforts or PA-internal):

cabi device-fingerprinting analytics (FPID+IP+TLS) is disqualifying for a public university under PCPD's posture — must be rebuilt as consented, account-based tracking, or omitted. Never show fingerprinting to PolyU. ✅ Confirmed in code 2026-07-12: cabi_binder_app uses clientjs + api/createFPID_record.ts (FPID) with zero consent framework (grep consent|privacy|gdpr|pdpo = 0). Strip or gate behind consent before any PolyU build.
Apple Wallet has no rotating barcode — so "add eCard to Apple Wallet at turnstiles" may be unusable without NFC certification. (Moot if we defer the card, per A11.)
Mainland China access: cabi is Cloudflare-first (degraded/blocked in the Mainland); 14 mainland networks + WeChat-login users. Flag as a discovery/hosting item (PB's hosting Option C boundary + WeChat channel), don't hand-wave.

C. The full final plan

C.1 What we are pitching (and explicitly not)

Pitching: A six-week, fixed-fee paid discovery that produces working proofs and canonical data contracts for the two workstreams Robbie named, plus a costed pilot SOW — an implementable blueprint AAO keeps regardless of who builds it.

Explicitly NOT pitching (say this on page one): a replacement for AMS/Alumni Portal or CEMS; a new alumni app (native or PWA); a new QR/ticketing/payment/check-in product; campus-wide gamification; LinkedIn scraping; automatic profile overwrite; an FHKPUAA redesign.

The frame: One alumnus, one record. Today one alumnus can register on art-mate for the gate, on PFS for one activity, and on CEMS for another — three sign-ups, no single person-linked record landing in AMS. Every silo works; the seams don't. The discovery maps and proves one governed path back to the record.

C.2 Positioning against the "why not ITS?" objection

ITS built AMS in-house in June 2024 specifically to escape vendor licensing — so any pitch touching the system of record dies. Position EventBinder as: an integration architect across AAO/ITS/LinkedIn/vendors; a delivery accelerator outside the ITS backlog; a vendor-neutral designer of canonical data contracts; a builder of proof connectors and exception workflows. Everything is built against ITS-owned, documented, hand-over-able interfaces (source escrow if procurement requires). Reuse any existing ITS integration bus/iPaaS/ETL first. The architecture is deliberately designed so engaging EventBinder now never locks PolyU out of insourcing later. Answer to "ITS can build it": "The discovery is useful either way — it gives ITS agreed source contracts, field semantics, privacy rules, exceptions, tests, and a working LinkedIn spike. PolyU then chooses the delivery owner."

C.3 Workstream 1 — LinkedIn data integration (honestly)

Audit first, don't cancel. Establish the exact product, contract owner (AAO? HR? Careers? Comms? ITS?), annual cost, seats, renewal/notice date, API rights, and actual usage. The ~HK$300k figure and product identity are unverified — this is discovery task #1.
Set the boundary truthfully. Talent Insights (aggregate-only), Recruiter (25/export, hiring-use), Sales Navigator (no export), public API (closed 2015), Sign-in-with-LinkedIn (identity + verified email only), and scraping (legally dead) cannot feed individual records into AMS. State this plainly — it's well-sourced and it disqualifies any competitor pitching a "LinkedIn career-data pipe."
Test the one legitimate route: Verified on LinkedIn. Plus tier lists current position, recent education, validation status, and change notifications under member OAuth — a possible consented refresh path, conditional on a Plus partnership and a written LinkedIn+PolyU agreement covering permitted fields, AMS storage, retention, refresh, revocation, deletion. Build a dev-tier proof with 5-10 approved test accounts and synthetic AMS data. Do NOT promise current-job/education fields until Plus access + permitted storage are confirmed.
The guaranteed engine is first-party progressive profiling. The only lawful, accurate, sustainable source of an alumnus's current employer/title is the alumnus. Every authenticated touchpoint asks ≤1-2 pre-filled things ("Still at [employer]?" — Yes ✓ / Update). Under DPP1, minimal per-moment collection is the compliant pattern. Target: sustained monthly confirmations at or above the ~4,000-in-10-days launch baseline. Freshness becomes a measurable last_confirmed_at SLA.
"Sign in with LinkedIn" = friction-remover, not data source (returns identity + verified email; zero job data). "Add to LinkedIn Profile" = credentials/badges flowing OUT — organic PolyU reach, permitted direction.
Optional enrichment feed (EverTrue/LiveAlumni) is a supplement, gated on legal review — ingested as a confirm-before-write suggestion queue, never silent writeback. If it fails DPO review, the first-party engine stands alone.

LinkedIn refresh policy default: "notify and confirm," never silent career-profile replacement. Missing LinkedIn fields never clear valid AMS data. If durable LinkedIn-derived storage isn't permitted, use it only as a temporary prefill and store the alumnus's independently confirmed correction as the AMS value.

C.4 Workstream 2 — event registration & data integration

CEMS is the baseline, not a competitor. It already does registration, QR/card check-in, four-provider guest login, payment, and analytics. The question is not "can EventBinder build these" — it's "why do some AAO journeys still use separate systems, and how does their data return to AMS?"
Deliver a canonical event-participation contract mapping every source (CEMS, art-mate, PFS/LimeSurvey, future vendors) to one minimum record: source system/IDs, canonical event, participant type, identity-match status, distinct registration/ticket/attendance states, check-in time, participation role, consent reference, idempotency, provenance. "Registered" is never "attended."
Identity linkage by confidence tier: high (authenticated NetID/AMS reference → auto-link); medium (verified email/mobile + matching graduate facts → proposed, review); low (name-only / art-mate-account-only / social-URL-only → never auto-link → exception queue); guest (never auto-converted to alumnus). Multi-NetID, name changes, family/group bookings represented explicitly. Low-confidence matches never merge automatically.
Reconciliation + visible exception queue: every source batch reconciles (input = accepted + rejected + duplicate + pending); no batch is "complete" while counts don't balance or exceptions are hidden. Re-running the same import never duplicates participation.
Incumbent coexistence via a mandatory data-return standard. art-mate stays the ticketing rail for cultural programming (relationship since 2014, trusted operator); what changes is that any external event vendor must return the canonical participation record (API/webhook/encrypted export + reconciliation). Optionally place a thin EIL pre-registration step in front of the gate sign-up so the alumnus arrives carrying a verified identity token — dissolving the double-registration seam without touching art-mate's system. Attack the seam, never the vendor (Section C.7).
Close the ad-hoc form silo at source: every one-off Google-Form-style sign-up becomes a PFS/EIL form behind NetID SSO with consent capture — the least-governed fragmentation channel.

C.5 Target architecture (merged)

Sources (LinkedIn OIDC/Verified APIs; CEMS; art-mate; PFS/LimeSurvey; approved CSV) → source adapters (API/webhook/scheduled export/controlled file) → Alumni Data Integration Service (identity linkage · consent + provenance · profile assertions · event-participation ledger · exception queues · reconciliation · audit/monitoring) → approved, traceable updates → AMS + Alumni Portal (official record — untouched internals) → AAO reporting (freshness, source coverage, participation, exceptions).

Design invariants (from both efforts):

AMS is the sole system of record. The integration layer keeps only an opaque join key, SSO subject, verified email, and in-transit deltas — never a second master copy (DPP1 by design).
Verified identity, not self-declared — every authenticated action rides Alumni NetID SSO (OIDC/SAML, ITS's choice).
Reuse existing ITS middleware first — identify any ITS integration bus/iPaaS/ETL/API-gateway/master-data service before proposing a new runtime; add only the missing alumni/event semantics.
Two canonical contracts: the profile-assertion contract (LinkedIn/first-party → AMS: assertion_id, ams_person_id, source, source_member_id, field_name, current_ams_value_ref, proposed_value, source_observed_at, verification_category, member_consent_id, storage_basis, raw_payload_expires_at, status[PROPOSED|CONFIRMED|REJECTED|APPLIED|SUPERSEDED]) and the event-participation contract (all event sources → AMS). Both carry a lifecycle state machine; no state disappears into a generic success message.
No PII in QR/URLs/logs — opaque, event-scoped, revocable tokens only.
Account-based, consented analytics only — no device fingerprinting.
Delivery/hosting — DECIDED (v3): on-prem self-host in the AAO office (client direction). Robbie (AAO IT, effective authority) has green-lit a tailor-made self-hosted box on PolyU premises, so alumni PII stays on campus — a compliance strength, not a risk (no off-site data export). Stack: app + Postgres in Docker on an encrypted box; Cloudflare Tunnel (outbound-only → zero inbound ports) fronting the public hostname with WAF + Cloudflare Access gating /admin; Tailscale for all ops/SSH/DB (never public). Presented openly this beats any cloud-SaaS competitor's residency story — it is "Form B" made concrete. Build-gates: (1) no single point of failure — mirrored disks + UPS + encrypted off-box backup on PolyU-controlled storage; (2) a one-paragraph written confirmation from Robbie (paper trail if staff turn over); (3) Cloudflare edge still sees traffic in transit — fine for parking, revisit before donor/financial data. Upside to probe: the box sitting inside the PolyU network may grant internal reachability to AMS/CEMS an external vendor never gets (subject to ITS segmentation). Mainland access + WeChat channel + PIPL still scoped honestly, not assumed away.

C.6 PDPO / data-governance (merged, corrected)

Data flow	PDPO handle	Approach
Event/membership/donation asks to named alumni	Part VIA direct marketing (silence ≠ consent; penalties to HK$500k/3yr, HK$1M/5yr for transfer-for-gain)	Segmentation joined to the consent ledger; first-use opt-out; withdrawals propagate to AMS
Collecting profile data	DPP1 (adequate, not excessive; fair means)	Progressive 1-2 field confirmation is the minimal-collection pattern
New purpose	DPP3 (prescribed consent)	Enumerated purposes; new purpose = new flag = new capture flow
AAO→FHKPUAA provision for DM	s.35J/35K written consent	FHKPUAA a named transferee; `fhkpuaa_provision` flag captured in-flow. (Non-DM sharing is a separate DPP3 question — corrected from PA's over-broad wording.)
Third-party enrichment	DPP1/DPP3 + PCPD anti-scraping	No scraping; vetted feed enters as confirm-before-write suggestions, post legal review
Legacy pre-2013 records	s.35D narrow grandfathering; burden on data user	Likely NOT grandfathered without proof → a large share needs fresh Part VIA consent. This is a budget argument as much as a risk.

EventBinder as data processor (PolyU PO terms): destroy PII on termination with destruction certificates; no subcontracting without written consent; no production/sample personal data into external AI services (OpenAI/Anthropic/Google/public Ollama) without written approval — use synthetic data; server-side authorization on every person/event record; encryption in transit + at rest; tamper-resistant audit; role separation (view/match/approve/export/admin). Consent is never a condition of ticketing, attendance, LinkedIn connection, or profile correction. Lucky draws (if ever) need a Trade Promotion Competition Licence (HK$1,590, ~2-wk lead, no cash prizes) — flag, don't build.

C.7 Handling the incumbent — five rules (internal doctrine)

Sell a different category — data-interoperability/governance, not a per-event ticketing tool. Never build a feature-vs-feature table (the HK$1/head anchor kills the deal).
Attack the seam, not the vendor — "In 2026 one alumnus signed up on art-mate for the gate and again on CEMS/PFS for activities. 2027 = one identity, one record, one journey." Critiques PolyU's own two-system split.
Lead with data ownership + governance — every scan feeds AAO's own record via SSO-verified identity, HK-controlled, PDPO-documented. Unanswerable by a 7-person shop; you never name them.
Offer year-one coexistence — art-mate keeps ticketing; you own the data contract, reconciliation, and writeback. Lets AAO say yes without firing anyone Lo knows.
Let the HKAAA→Glue-Up migration make the argument (⚠️ verify before quoting) — a longtime art-mate client already graduated its membership function to a dedicated platform.

Keep all incumbent tech intel (PHP 5.6, AWS Singapore, no PICS, contact details) strictly internal — several claims are inference-grade, and Lo is personally trusted by AAO.

C.8 Pilot (post-discovery, quoted separately)

Pilot Zero — Parking (the wedge; pre-discovery, near-zero cost). The live "Request for hourly parking space" MS Form (anonymous, PolyU Alumni eCard holders) forces every alum to retype 7 identity fields per request. Build a thin portal front end holding the alum's profile that generates an MS Forms prefilled link — the alum lands on the same Microsoft form fully populated and submits in ~3 taps.
- Auto-filled (7 of 10): acknowledgement (pre-tick Yes), Alumni ID, Full Name (EN), Contact number, Email, Vehicle No. (captured once → stored → prefilled = progressive profiling made real), Vehicle Type. Per-trip only: Visit Date, No. of Passenger, Purpose.
- Minimal profile fields the box must hold: alumni_id, full_name_en, contact_number, email, vehicle_no (validate: no O/I/Q), vehicle_type.
- Privacy-clean MVP: the prefilled link is built in the alum's own browser and the submission goes straight to Microsoft (AAO tenant) — no parking PII touches the office box. Ships before any data-processor conversation.
- Hard dependency: the AAO form owner runs … → Get pre-filled link once and sends the URL (yields every question's param key). Cannot be built without it.
- Sequence: prefill-link MVP → custom UI writing to the same SharePoint sink via Power Automate (now data transits the box → data-processor terms apply) → own the workflow.
- Why it's the wedge: proves "one record, prefilled everywhere" with no AMS write, delivers a real value exchange to the alum (mitigates R4), and shows fast value even if ITS could build it (mitigates R2). Use as goodwill proof to win the paid discovery.
Pilot A — LinkedIn profile-refresh proof: PolyU-controlled dev app; 5-10 approved test accounts; OAuth + retrieval + consent evidence + field comparison + user confirmation + revoke + audit; synthetic AMS first; Plus-tier gap report. Optional production extension (50-200 volunteer alumni) only after LinkedIn+PolyU approval.
Pilot B — event-participation proof: one CEMS event + one external/PFS source (a controlled Homecoming 2026 sample or a future art-mate export); adapter, schema validation, idempotent ingestion, identity matching, exception queue, AMS staging/writeback, source-count reconciliation, deletion/retention completion.
Pilot C — one controlled live 100-400-person AAO event after A+B pass; CEMS as the operational system; measure availability delay, person-link rate, exceptions, staff effort.
Homecoming 2026 = retrospective case study; Homecoming 2027 = ship-by target, NOT the first live test. Each phase separately signable (procurement sizing + AAO exit ramps).

C.9 Commercial (internal)

Discovery: open HKD 188k (range 168-198k), floor HKD 158k only with a written scope reduction (fewer workshops/prototype depth/sample sources). Milestone-billed 25 / 35 / 30 / 10 (current-state map → options+privacy+LinkedIn audit → prototype+pilot SOW → final handover). Excludes third-party licences, production hosting, legal advice. ⚠️ Price-validation flag: the HKD 188k anchor and the pilot ranges originate entirely from PB and were not independently validated by either model (the blind codex rerun adopted the same figure without challenging it). Before quoting, sanity-check against EventBinder's real cost/margin and effort estimate — this is the one number in the plan nobody cross-checked.
Pilot planning ranges (internal only): LinkedIn dev proof 120-220k; CEMS + 1 external connector 280-480k; combined controlled production pilot 520-900k.
IP: background-IP carve-out; SaaS core = term licence, not ownership; do not submit reusable EventBinder source as a discovery deliverable; quote core-code ownership as a separate buyout. Choose Form A (bespoke, PolyU-owned infra) vs Form B (EventBinder licensed service) only after hosting policy is known.
Procurement reality: expect an RFQ with ≥3 quotes (HKD 188k sits in the Finance Office RFQ band, near the tender line). Confirm the current band with Robbie; register as a supplier early; prepare COI disclosure (proposer is an alumnus with an AAO relationship); never split scope to dodge a threshold.

C.10 Measurable outcomes (baselined in discovery)

Freshness (% records confirmed in last 12mo; monthly volume vs the ~4,000-in-10-days baseline) · closed event loop (% registrations resolved to an AMS record; % attendance written back <24h — today ~0) · verified identity at events (% flagship registrations via SSO vs self-declared) · consent coverage (% contactable records with current Part VIA flags) · engagement in CASE Alumni Engagement Metrics framing (experiential/volunteer/philanthropic/communication) for peer-benchmarkable numbers. LinkedIn: connection rate, usable-profile rate, confirmed-update yield, assertion acceptance rate, refresh yield. Voluntary LinkedIn connection / optional updates are measured outcomes, not guaranteed software acceptance.

C.11 Kenta's credibility (the differentiator)

PolyU BSc (Hons) Data Science 2019 and a target user of this system (his own duplicate "EventBinder CEO" career rows are a live demo of the data-quality problem); former AMA visiting lecturer + capstone supervisor (2021-25); built PolyU campus Wi-Fi (HKT era); delivered PolyU BME KOA system infra/security. NetID, ITS working practice, campus operations = first-hand knowledge. Procurement pack (company profile, PI + cyber insurance, references — PolyU BME KOA, HKU President's Office, Veolia — support/SLA) available on request.

C.12 QR & Wallet identity layer — the events differentiator (vision, not the discovery ask)

Confirmed in cabi code (2026-07-12): branded/image QR (smartQr/qrArt + Python cabi-qr-art), GIF QR (binder type B005), dynamic QR (smartQr), and Add-to-Wallet (cabi-qr-v2025/components/wallet). Real, and a genuine step up from art-mate's plain gate QR.

Two QR jobs — never conflate:

Campus access QR (entry): PolyU's alumni access QR rotates daily — a short-lived signed security token. Leave it in PolyU's flow; do not restyle or replace it. Restyling a rotating credential is pointless + risky, and cabi "dynamic QR" (fixed code / changeable destination) ≠ a rotating security token.
General / event / info QR: cabi's playground — styled/GIF/dynamic QR for event info, profile/networking cards, check-in landing pages. "Extract their QR content → re-render in our style" works only for static content QRs (qr-art preserves error-correction/scannability), never for the rotating access token.

Wallet: ✅ for a stable alumni identity card / event ticket / networking pass. ❌ not a drop-in for the daily-rotating access token (a wallet barcode is static without live PassKit / Google-Wallet push updates — a real build, not a freebie).

FPID — hard rule: deliver the "just arrive, machine knows you" UX via a consented wallet pass or a scannable code, NOT silent device fingerprinting (FPID is PCPD-disqualifying for a university — see R1 / ledger). Same UX, no legal liability.

Positioning: keep this OUT of the discovery headline (Robbie asked for two things; a wallet product reads as upsell + steps on CEMS). Use it as the answer to "why cabi vs art-mate" and an events-phase vision: art-mate prints a gate QR; cabi gives each alum a wallet identity + styled dynamic QR that carries their verified record — "one alumnus, one record" made physical, alongside (never replacing) PolyU's secure access QR.

C.13 AI-assisted data integration — self-hosted, human-in-the-loop (client-requested)

Robbie's ask (2026-07-12): much of the integration/reconciliation work is done by humans today; he wants an AI agent to cut it, and — again citing ITS constraints — wants it self-hosted. This is client-driven, so it passes the scope test (unlike gamification/app, which we rejected as upsell).

The convergence that makes it clean: the plan's hard PDPO rule is no personal data to external AI services (OpenAI/Anthropic/Google/public Ollama) without written consent — EventBinder is a data processor under PolyU PO terms. So the AI agent must run on self-hosted local models on PolyU premises → PDPO turns Robbie's self-host wish into a requirement, and vice-versa. And it's squarely Kenta's existing capability: he already operates self-hosted LLMs (local Ollama/MLX + GPU hosts) — demonstrable, not aspirational.

Honest design:

Self-hosted local LLM (Qwen/Llama-class) on the AAO-office box or an adjacent local GPU / Apple-Silicon inference box — PII never leaves campus.
Human-in-the-loop, suggestion-only. The agent proposes; AAO staff approve. Never autonomous writes to AMS, never auto-merge (consistent with the confidence-tier + confirm-before-write rules). The AI is the engine that works the exception queue, not a replacement for the system of record.
Scoped to the real manual pain: (1) fuzzy identity resolution / entity matching across event sources (Chan Tai Man ↔︎ Tai-Man CHAN ↔︎ email variants) → ranked candidates for approval; (2) extraction/normalization of messy inputs (CSV / PDF / free-text / email) into the canonical schema; (3) dedup suggestions; (4) a natural-language query / reporting co-pilot for staff; (5) draft confirmation emails / segments.
Auditable: every suggestion logged with provenance + approver (ties to the consent/provenance ledger).

Set expectations (don't oversell): assistive + human-gated, not full automation; local-model quality is below frontier cloud models but sufficient for matching/extraction/normalization — and it's the only PDPO-compliant option; it needs inference hardware + an accuracy eval in the pilot.

Why it strengthens the bid: a specialized, PDPO-safe capability ITS's backlog won't deliver soon, it directly attacks Robbie's stated pain, and it's uniquely Kenta's. Frame it as an AI-assisted layer inside the two existing workstreams (less manual matching/entry), NOT a separate "AI product."

C.14 Information-architecture reference — what a member/alumni hub actually surfaces (SCAA + Alpha)

The problem (Robbie's instinct, confirmed live 2026-07-12): PolyU's alumni portal is information-poor — framed as "update your record," not "here's everything your membership gives you." This is about information/services surfaced, not visual styling. Two references reviewed:

SCAA — South China Athletic Association member portal (vendor AVEEGO, Ionic mobile app v17.4.1). A services hub: course + trial-class enrolment · facility/venue booking · packages/passes · shop · digital member card · locker rental (paperless + auto-renewal) · event registration · rewards/loyalty · personalized news feed · cart + online payment · join/renew membership · trilingual. Everything the membership gives you, in one place.
Alpha Institute student platform — EventBinder's own (alpha.eventbinder.app/student, Next.js under /student basePath): nav = Home · Courses · My Orders · Account; skeleton-loading, password eye-toggle, trilingual, mobile-first. Proof EventBinder already builds friendly member-hub IA — a demonstrable capability, not a promise.

Gap vs PolyU alumni portal: unified hub (vs fragmented portal + CEMS + MS-Form + eCard) · self-service + payment · facility bookings · rewards · personalized notifications/renewals · a functional digital card · personalized news.

Discipline (reconcile with the anti-over-scope rule, A1/E): this is the IA reference / roadmap vision for the Alumni Hub — NOT "build all of SCAA's features" for the discovery. Near-term wedge stays parking (§C.8); the hub grows around the one record. Differentiation is the governed data layer underneath (integration + on-prem + AI + one-record), NOT competing with an off-the-shelf member app like AVEEGO on features — PolyU could buy AVEEGO; they can't buy the governed alumni record we build.

D. Still unknown / needs discovery + immediate next actions

D.1 The genuine unknowns (all become discovery questions, never claims)

Which LinkedIn product/seat/owner is the ~HK$300k? (product identity + figure both unverified) — and does PolyU have/qualify for Verified on LinkedIn Plus?
Does CEMS already write participation to AMS? (if yes, scope narrows to non-CEMS sources) — and what supported AMS write interface exists (API / staging table / batch / none)?
Does ITS operate an existing integration bus / iPaaS / ETL / master-data service the design must reuse?
Why art-mate for Homecoming, and what data came back? Can 6,000 registrations be reconciled against alumni records? What's exportable (fields, stable IDs, scan data)?
Current Finance procurement band (confirm the >HK$200k tender / HK$50-200k RFQ guide is live policy) + supplier-registration timeline + is Director-of-ITS approval required + is it classed consultancy/IT/software?
Consent state: what share of records has current Part VIA consent? Which pre-2013 records lack demonstrable grandfathering (s.35D)?
Hosting/residency ITS will accept + mainland-alumni network topology (WeChat channel, Cloudflare-in-Mainland limits).
Portal framework/vendor (Next.js is ⚠️, masked) — and the "Alumni ID vs Alumni NetID" string in the portal JS.
Turnstile/reader capability (only if a card/token is ever scoped).
cabi v2025 live-traffic/production status — verify before any capability claim (honesty item; see Risk R1).
Who actually holds the budget? AAO vs Development / Foundation / Advancement. Alumni-data + donor-solicitation work is often funded by Advancement, not the Alumni Affairs Office — Robbie may not be the budget owner. (codex-surfaced; potentially the most important commercial unknown — map this stakeholder early.)
Payments scope. Does AAO need paid events / memberships / donations / refunds? CEMS claims payment; art-mate has PayMe/Alipay/WeChat rails; cabi has none. If yes, this pulls in finance + PSP integration scope — keep it explicitly out of the discovery unless AAO raises it.
PIPL / cross-border for mainland alumni. Beyond access/latency (item 7), a Cloudflare-first or non-Mainland-hosted stack raises PIPL cross-border transfer obligations for mainland-resident alumni, not only PDPO. Ask hosting + mainland-channel + data-residency questions together.
Real match-rate ceiling. Family/group bookings, guests, name changes, multiple NetIDs, shared emails, walk-ins — the exception queue is the main workload, not an edge case. Ask for a representative messy sample to estimate the true auto-link rate before promising numbers.
Internal-network adjacency. Does the AAO-office box, on the PolyU network, get internal reachability to AMS/CEMS APIs (subject to ITS segmentation)? If yes, integration is far easier than a public-API path — confirm early.
Form-owner access for the parking prefill. Who owns the "Request for hourly parking space" MS Form? Need them to generate one Get pre-filled link — this unblocks Pilot Zero (§C.8).
Quantify the manual work (Robbie's AI driver). Which reconciliation/data-entry tasks are done by hand, how many staff-hours/week, on what volume — so the AI agent's value (§C.13) is sized against real numbers, not "save time."
Local-inference hardware. What can sit in the AAO office (GPU / Apple-Silicon box) for on-prem LLM inference, and its power / cooling / space / noise limits.

D.2 Immediate next actions

Send Robbie the cover message + executive V4 proposal (below), attach the detailed technical appendix (the V4 interoperability proposal).
Request before the meeting: the exact LinkedIn SKU + renewal date; the owner of one CEMS event flow + the Homecoming data-flow owner; which ITS integration middleware to reuse; the current Finance procurement band.
Prepare: EventBinder company/security/background-IP/subprocessor + supplier docs; COI disclosure; Form A vs Form B commercial drafts.
Book a 90-minute technical scoping session with Robbie + AAO alumni-data owner + AMS/Portal owner + CEMS owner + PFS owner + DPO/privacy delegate + one Homecoming/external-event owner. Agenda: confirm two outcomes + ten priority fields → trace one CEMS event and the Homecoming 2026 flow end-to-end → identify the LinkedIn product/tier/renewal → select discovery samples + technical owners → confirm procurement route + acceptance authority. Then stop and let them draw their internal reality.
Quote the fixed-fee discovery only after access + acceptance owners are confirmed.
Fast-track Pilot Zero (parking) in parallel as goodwill proof — get the form owner to generate the prefill link, stand up the thin profile-holding front end (6 fields), and demo the 3-tap flow to Robbie before/at the meeting. Near-zero cost, no PII on the box, and it earns the paid discovery.

D.3 Cover message to Robbie

Use PB's cover message as-is — it is already Robbie-specific, bilingual (WhatsApp Cantonese + short English email), and correctly scoped to the two workstreams with no app/QR pitch. One tightening from PA: add a single line naming the "one alumnus, one record" outcome so the ask has a memorable spine. Draft addition to the English version's opening: "The goal is simple — one alumnus, one record: every LinkedIn refresh and every event participation traceable back to the right person in AMS." File: PB/ROBBIE_PROPOSAL_COVER_MESSAGE_V4.md.

D.4 Reconciled meeting-question shortlist

PA offered a tight top-5; PB offered a fuller 40-question bank. Reconciliation: use PA's 5 as the must-answer spine (they map to the decision drivers), backed by PB's bank as the deep reference. The spine:

LinkedIn: exact product / edition / seats / annual fee / contract owner / renewal + notice date / actual usage — and does PolyU have or qualify for Verified on LinkedIn Plus? (unblocks all of workstream 1)
Events → AMS: what does CEMS currently write to AMS? Why did Homecoming use art-mate? What data returned, and could 6,000 registrations be reconciled to alumni records? (sizes workstream 2)
ITS: who owns the AMS/CEMS schema + write interfaces; will ITS grant NetID SSO + a sandbox; is there an existing integration bus to reuse; what hosting/residency rules apply; and — bluntly — what would ITS prefer EventBinder build vs specify? (the "why not ITS" objection + reuse-first)
Money/process: budget band, current Finance procurement route + threshold, signing authority, supplier-registration timeline, and is the 90th anniversary (2027) the ship-by milestone? (procurement path)
Consent/privacy: who is the DPO delegate; what share of records has current Part VIA consent; what's the PICS/retention posture; and (softly) is there any AAO↔︎FHKPUAA data-sharing dependency? (gates every writeback)

Then, from PB's bank as needed: the "what does 'demographic data' mean in named fields" question; multi-NetID canonical-person rule; CEMS guest representation; art-mate export fields/stable IDs; PFS export mode; and "which AAO event has a manageable audience and a cooperative owner" (to pick Pilot C).

E. What I deliberately rejected — from BOTH efforts

Rejected from PA: (1) the engagement-layer product framing — app, digital rotating-QR card, wallet passes, gamification, on-site POS/scanner — over-scoped for two named workstreams and duplicative of CEMS; (2) "replace art-mate for flagships" — re-opens the price-anchor fight PA's own incumbent analysis warns against; (3) "cancel/downgrade the HK$300k LinkedIn contract" as an opener — politically risky and premature; (4) "size the discovery for direct award" — unsupported; the figure sits in the RFQ/tender zone; (5) the unverified card-tech claims (iOS PWA cache/eviction; Apple Wallet rotating barcode).

Rejected from PB: (1) the flat, un-narrated "governed path" tone — kept PB's scope but re-wrapped it in PA's "one alumnus, one record" story so it actually sells; (2) treating the incumbent as merely "one more source" — PA's five-rule doctrine is needed to avoid the price-anchor trap; (3) PB's near-total silence on PDPO substance (Part VIA / s.35D grandfathering / donations-as-DM) — PA's depth is a genuine differentiator with a technical, privacy-aware buyer; (4) PB's occasional over-hedging (V4 hedges every internal fact to a discovery question — correct for a client doc, but internally we DO know the well-sourced facts in Section B and should speak them with confidence).

Flagged as speculative in the final plan (do not state as fact): the ~HK$300k figure and its product; the HK$200k tender threshold (departmental-guide grade); art-mate 7-FTE headcount and the HKAAA→Glue-Up migration; all SaaS pricing; the Next.js portal framework; and cabi's production status.

A second, different model family (codex, gpt-5.5) re-ran the same synthesis task from scratch — blind to this plan, blind to the folder authorship (it did not know it had written PB). It converged on every major decision in Section A: PB-narrow interoperability positioning, audit-not-cancel on LinkedIn, CEMS-default event data contract, reuse-ITS-middleware-first architecture, expect-RFQ procurement, the three-proof pilot with Homecoming as a case study (not the first live test), PA's "attack the seam" incumbent doctrine kept internal, FHKPUAA out of phase 1, and card/wallet/gamification deferred. Two independent lineages reaching the same plan is the strongest available signal the spine is correct, not an artifact of one model's bias. Full output: P1/CODEX-CROSSCHECK.md.

Risks the cross-check independently confirmed — hereby ELEVATED

R1 — Delivery-capability (cabi) is a TOP risk, not a footnote. cabi's v2025 assets are real but the deal-critical pieces are net-new/unproven: no payments, no university SSO, no consent ledger, no AMS connector, no zh-HK/zh-CN localization, prototype-only wallet, and unverified live production status. Do not sell cabi as a drop-in platform — sell EventBinder integration capability and verify cabi's live status before any capability claim. (Both models flagged cabi; codex correctly ranks it top-tier. Resolve via the D.1 #10 honesty check before the meeting.) ✅ Partially verified 2026-07-12 (live read-only SSH probe of cabi2025): real production box, 408-day uptime, running dashboard + backend + analytics (radar / TimescaleDB), exposed via Cloudflare Tunnel + Tailscale — i.e. cabi already operates the exact Docker + CF-Tunnel + Tailscale stack we're proposing to PolyU, which is a genuine credibility asset for the on-prem model. cabi2025 itself carries no event/payment/SSO/consent containers (it's the analytics box). falcon23 (hostname "pelican") verified 2026-07-12: it does run a real event-management app — cabi_binder_app ("EventBinder") — plus a cabi_qr_app (QR check-in), both containerized and exposed via Cloudflare Tunnel (repo ~/repo/cabi_binder_app). So event management + QR check-in are reusable assets, NOT net-new — a real plus for the events workstream. Still unverified (do not yet claim): payments, university SSO, consent ledger, localization, and production traffic/scale — falcon23 was freshly booted (10-min uptime) and mixes f23_prod with internal_dev containers, so it reads more like a dev/demo box than a load-bearing prod service. Net for the room: "we operate an event-management + QR platform on the same Docker + Cloudflare-Tunnel + Tailscale stack" is now a true claim; payments/SSO/PDPO-consent/scale still need verifying before you promise them. Code scan of cabi_binder_app (2026-07-12) makes this precise: it's an event content-binder + dynamic registration/application-form app with QR, multi-language (en + zh-TW Traditional Chinese), email, and a token "zero-trust" access model — all reusable, and the form-builder + submission pipeline is directly reusable for the parking wedge + event registration. Absent (grep = 0): payments, SSO/SAML/OIDC/LDAP, ticketing, consent/privacy framework, attendance/check-in → those are genuinely net-new for PolyU. PDPO red flag confirmed in code: the app does device fingerprinting (clientjs / api/createFPID_record.ts, FPID) with no consent mechanism — must be stripped or consented before any PolyU deployment (PCPD-disqualifying as-is). Current v2025 platform also scanned (local ~/repo/EB/cabi, ~30 services, per its own CLAUDE.md): it's a Smart-QR + scan-analytics + campaign + "Cabi Drive" SaaS on Cloudflare (Workers/D1/R2) + NestJS/Mongo + Next.js dashboards. Reusable/claimable: the CF-Workers/Tunnel + Docker + Tailscale infra pattern (matches our proposed model), QR + scan analytics, dashboards, dynamic forms/binder, en/zh-TW i18n, and a cabi-finance payments module (scope/maturity unverified). Still net-new for PolyU: NetID SSO (only JWT + Google OAuth present — no SAML/OIDC/LDAP), a consent/PDPO layer (absent), and the AMS connector + event↔︎alumni identity resolution (PolyU-specific). #1 PDPO blocker (now confirmed as structural, not incidental): device-fingerprint analytics is central to the platform (cabi-fp-proxy, cabi-fp-collector-app-worker, FPID) — it is cabi's "analytics" value prop, and it's PCPD-disqualifying for a university → must be disabled or rebuilt as consented, account-based analytics for any PolyU deployment.
R2 — Will PolyU pay an external integrator at all? ITS built AMS in-house specifically to escape vendor licensing; they may treat this as backlog work, not vendor work. The discovery must be valuable even if ITS ends up building it (agreed source contracts, field semantics, privacy rules, tests, LinkedIn spike) — that framing (already in C.2) is what makes it buyable. This is the gating qualifier, not a side risk. (v3: Pilot Zero — parking — partially de-risks this — near-free, visible value that earns the discovery; combined with Robbie's green light and on-prem hosting, the "why pay a vendor" objection is materially softened.)
R3 — Insider / COI vs open RFQ. Kenta being an alumnus with an AAO relationship is a credibility asset (C.11) and a procurement complication. HKD 188k likely triggers an RFQ with ≥3 quotes; a direct relationship award should not be assumed, and a COI disclosure must be prepared (it could require Kenta to sit out, not merely disclose). Do not build the strategy on relationship-based direct purchase.
R4 — LinkedIn workstream thinness. Strip out the unproven "Verified on LinkedIn Plus" hope and workstream 1 reduces to first-party progressive profiling — lawful and sustainable but not novel. The value exchange to the alumnus must be real ("here's your updated professional record / network," not "please update our database"), or voluntary participation stays low. Verified Plus is a discovery feasibility test, never a promise.

Net-new items the cross-check surfaced (folded into D.1)

Budget owner may be Development/Foundation, not AAO (D.1 #11) — potentially the most important commercial unknown; neither original package mapped it.
Payments scope trap (D.1 #12), PIPL cross-border (D.1 #13), real match-rate ceiling (D.1 #14).
PA internal contradiction: PA/research/alphasoft-company.md says art-mate handled limited-quota session registration; PA's own synthesis corrects this to gate-admission QR only. Use the narrow, corrected version; never repeat the wrong one in the room.

The one caveat where both models agree and neither verified

The HKD 188k discovery price (and pilot ranges) came from PB and were adopted unchallenged by the codex rerun too. Agreement here is not validation — it's two models trusting the same single source. Verify against real cost/margin before quoting (see the price-validation flag in C.9).