EventBinder / PolyU AAO Crosscheck

Independent adversarial review of the PA and PB packages.

A. Contradiction / Decision Table

A1. Consensus Facts I Would Treat As High-Confidence

Agreement caveat: both packages may share the same false assumption that "event participation does not already flow to AMS." Both correctly mark it as a discovery question, but the pitch collapses if ITS shows CEMS already writes all required participation data into AMS (PB/POLYU_ALUMNI_DATA_INTEROPERABILITY_PROPOSAL_V4.md:73, :858).

A2. Contradictions And My Decisions

B. Evidence-Confidence Audit

B1. Claims Safe To State In The Room

B2. Claims That Would Embarrass The Pitcher If Stated As Fact

C. Final Recommended Plan

C1. Positioning

Chosen: "PolyU Alumni LinkedIn and Event Data Interoperability Discovery."

Why: It matches Robbie's two named workstreams, respects CEMS/AMS, gives ITS a non-threatening role, and produces assets PolyU can use even if implementation goes to ITS or tender. PB's V4 phrasing is the right client-facing position (PB/POLYU_ALUMNI_DATA_INTEROPERABILITY_PROPOSAL_V4.md:17-35; PB/POLYU_ALUMNI_BID_PLAYBOOK_V4.md:290).

Why not PA's broader engagement app/layer as the opening: It is strategically interesting but too broad for the stated ask. It invites "we already have CEMS," "we already have portal," "why an app?", "who approved rewards?", and "why are you replacing our systems?"

Meeting line:

"I took the two areas literally. This is not a new event system, app, or QR feature. It is a profile-assertion contract for LinkedIn feasibility and a canonical participation-data contract across CEMS, art-mate, PFS, and approved sources, with AMS writeback, consent, provenance, and exceptions."

C2. Workstream 1: LinkedIn Profile Refresh

Chosen: Audit and feasibility proof, not a promise of enrichment.

Scope:

• Identify exact LinkedIn SKU, owner, users, annual cost, renewal/notice date, reports, exports, API rights, permitted purposes, storage, deletion and revocation terms.
• Score the current spend against its purchased job: aggregate insight, recruiting, ads, learning, employer engagement, or alumni profile update.
• Test only PolyU-approved, member-consented OAuth/Verified path with staff/test accounts.
• Define profile_assertion records: source, field, observed time, consent, confidence, raw-payload expiry, status, confirmation, writeback.
• Store alumni-confirmed corrections, not raw LinkedIn payloads, unless LinkedIn and PolyU approve durable storage.
• No scraping, browser automation, or third-party scraped enrichment without separate DPO/legal review.

Why: PA proves mainstream LinkedIn products cannot solve the CRM refresh problem (PA/research/research-linkedin.md:9-39). PB usefully identifies a possible Verified Plus path but correctly makes it conditional (PB/POLYU_ALUMNI_DATA_INTEROPERABILITY_PROPOSAL_V4.md:156-170, :208-234).

Why not alternative: Do not lead with "cancel LinkedIn." It risks embarrassing an internal owner and could be wrong if the product serves another job. Do not sell Verified Plus as the solution because access, use-case approval, storage and adoption are all unproven.

C3. Workstream 2: Event Registration Data Integration

Chosen: CEMS-default, source-agnostic participation contract.

Scope:

• Trace one CEMS event from registration to attendance to final AAO/AMS record.
• Trace Homecoming 2026 main art-mate admission data and selected activity/PFS/CEMS data to final reconciliation.
• Inventory all AAO event sources: CEMS, art-mate, PFS/LimeSurvey, faculty/department tools, associations, manual lists, hybrid/Zoom, walk-ins.
• Define canonical participation contract: source system/event/registration IDs, canonical event ID, participant type, registration/ticket/cancellation/waitlist/payment references, attendance status, check-in/out, role, guest sponsor, consent/PICS, provenance, source counts and processor version.
• Define identity confidence rules: AMS/CEMS authenticated reference auto-link; verified email/mobile plus graduate facts proposed link; name/social-only no auto-link; guest never auto-converts.
• Build exception and reconciliation workflow: unmatched, duplicate, ambiguous, invalid, stale, missing-consent, partial-writeback.
• Create mandatory external vendor data-return terms for future events.

Why: This is exactly where both packages converge: fragmentation exists, but the data-return path is unknown. PB's canonical-source contract is the clearest shape (PB/POLYU_ALUMNI_DATA_INTEROPERABILITY_PROPOSAL_V4.md:331-356, :426-443). PA's art-mate work adds the incumbent reality and price anchor (PA/INVESTIGATION.md:150-164).

Why not alternative: Do not build ticketing, payment, QR, seating, refund or event UX before proving CEMS gaps. Do not require every event to use CEMS; specialist tools may be valid. Make data return mandatory instead.

C4. Target Architecture

Chosen: Minimal semantic integration layer, placement undecided until ITS review.

The layer can be implemented inside AMS, on an existing ITS integration platform, as an ITS-managed service, or as an EventBinder-managed service under approved hosting. Do not pre-commit.

Core components:

• source_adapters: CEMS API/export, art-mate export/API if available, PFS/LimeSurvey export, controlled CSV.
• profile_assertion: LinkedIn or alumnus-provided field assertions, reviewed before AMS update.
• event_participation: canonical event ledger for registration and actual attendance.
• identity_link: AMS person linkage with confidence and reversible decision history.
• consent_evidence: purpose, notice text version, timestamp, channel, withdrawal status, downstream propagation.
• exception_queue: unmatched/ambiguous/invalid records and count reconciliation.
• ams_writeback_or_staging: ITS-approved API, staging table, batch import, or manual approval file.
• ops_dashboard: source counts, queue age, delay to AMS, accepted updates, failures.

Why: It preserves AMS as system of record and avoids a second alumni master. It also keeps EventBinder defensible if ITS later builds production connectors (PB/POLYU_ALUMNI_DATA_INTEROPERABILITY_PROPOSAL_V4.md:397, :637; PA/PROPOSAL.md:81-85).

Why not alternative: A standalone EventBinder-owned app/platform has more sales upside but is easier for ITS to reject and harder to procure.

C5. Privacy / PDPO Approach

Chosen: Design for purpose-specific consent and minimal data from day one.

Rules:

• PICS at or before collection; state purpose, voluntary/mandatory fields, consequences, transferee classes, access/correction contact.
• Separate event operation, profile correction, direct marketing, attendee directory, LinkedIn connection, FHKPUAA provision and analytics purposes.
• Marketing consent is never a condition for event ticketing/check-in/profile correction.
• Direct marketing to named alumni, donation solicitation and membership drives require Part VIA handling; silence is not enough.
• FHKPUAA data provision for its own direct marketing requires written consent; non-DM sharing still needs DPP3/purpose analysis.
• No personal data in QR codes, URLs, unapproved logs, unapproved AI services, or undeclared subprocessors.
• Raw LinkedIn responses and unconfirmed external values expire quickly unless contract and PICS permit retention.
• Production data only in PolyU-approved hosting with subprocessor, breach, retention and deletion evidence.

Why: PA's legal/privacy work is stronger and should be adopted (PA/research/research-playbook.md:31-43; PA/PROPOSAL.md:269-280). PB adds supplier/data-terms discipline (PB/POLYU_ALUMNI_BID_PLAYBOOK_V3.md:192-213; V4 PB/POLYU_ALUMNI_BID_PLAYBOOK_V4.md:264-276).

Why not alternative: "We'll clean it up later" will fail with a university DPO. Consent/provenance is not a compliance afterthought; it is the product.

C6. Procurement And Commercial Structure

Chosen: Quote a fixed-scope discovery after the 90-minute scoping meeting.

Recommended discovery:

• Name: PolyU Alumni LinkedIn and Event Data Interoperability Discovery.
• Duration: six weeks.
• Price target: HKD188,000, with internal acceptable band HKD168,000-198,000 if PB V4 scope holds and synthetic/anonymised data is used (PB/POLYU_ALUMNI_BID_PLAYBOOK_V4.md:86-90).
• Expect Finance Office RFQ / at least three quotations, not direct award, because public guide says over HKD50k-HKD200k requires RFQ and over HKD200k tender (PB/POLYU_ALUMNI_BID_PLAYBOOK_V4.md:246-251).
• Do not split scope to avoid thresholds.
• Prepare supplier registration, company profile, CVs, insurance position, conflict-of-interest disclosure, security/privacy summary, subprocessor list, background-IP schedule, data deletion procedure.

Pilot pricing after discovery:

• LinkedIn development proof only: HKD120k-220k.
• CEMS plus one external/PFS connector proof: HKD280k-480k.
• Combined controlled production pilot: HKD520k-900k.
• Exclude LinkedIn Plus fees, partner onboarding, external API fees, AMS/CEMS changes, legal advice, production hosting and payment rails (PB/POLYU_ALUMNI_BID_PLAYBOOK_V4.md:98-108).

Why: PB is materially better here. PA's "same spend as LinkedIn" anchor is useful in a board discussion but not as a procurement plan.

Why not alternative: A big HKD1m+ platform proposal will likely trigger tender before trust is built. A cheap direct-award quote underprices the real risk and still may not avoid RFQ.

C7. Pilot Design

Chosen: Three proofs, staged after discovery.

1. LinkedIn profile refresh proof:

   • five to ten approved test/staff accounts;
   • OAuth/Verified flow if available;
   • compare/review/confirm/revoke/audit;
   • synthetic AMS first;
   • production extension only for 50-200 volunteer alumni after LinkedIn/PolyU approval.

2. Event participation integration proof:

   • one recent/upcoming CEMS event;
   • one external/PFS source, preferably controlled Homecoming 2026 sample or future art-mate export;
   • schema validation, idempotent ingestion, matching, exceptions, reconciliation, AMS staging/writeback.

3. Controlled live AAO event:

   • 100-400 attendees;
   • CEMS as operational system where suitable;
   • measure delay to AMS, person-link rate, exceptions, staff effort.

Why: PB's acceptance criteria are correct and testable (PB/POLYU_ALUMNI_DATA_INTEROPERABILITY_PROPOSAL_V4.md:654-733). PA's Homecoming 2027 ambition can stay as the milestone only after small proofs.

Why not alternative: Homecoming as first live implementation is reckless. It has too many attendees, family/group bookings, volunteers, vendor seams, and reputational risk.

C8. Incumbent Handling

Chosen: Coexistence plus mandatory data-return standard.

Actions:

• Do not badmouth art-mate or AlphaSoft in the meeting.
• Ask who owns the relationship, what contract/data terms applied, what fields came back, whether scan/attendance was returned, and how AAO reconciled it.
• Treat art-mate as a valid specialist/public ticketing rail where it has a reason to exist.
• Require future external vendors to return canonical participation data, source counts, consent/PICS evidence, retention/deletion certificate and error SLA.
• Use the seam, not the vendor: "one alumnus, one identity, one participation record in AMS, even if multiple rails run underneath."

Why: PA's incumbent profile is the best unique contribution in either package (PA/INVESTIGATION.md:150-172; PA/research/alphasoft-synthesis.md:12-23).

Why not alternative: A feature-vs-feature comparison against art-mate invites a HKD1/head anchor and loses the room.

C9. Meeting / Discovery Strategy

Chosen: Working session, not sales deck.

Required participants:

• Robbie / AAO IT owner.
• AAO data/operations owner.
• AMS/Alumni Portal technical owner.
• CEMS product/data owner.
• PFS/LimeSurvey owner if still in AAO flows.
• DPO/privacy delegate.
• Homecoming or external-event owner.
• Procurement/Finance input, even if only after the technical part.

90-minute agenda:

1. Confirm the two outcomes and ten highest-value fields.
2. Draw real AMS/Portal/CEMS/PFS/art-mate/LinkedIn flows.
3. Trace one CEMS event and Homecoming 2026 to final AAO records.
4. Identify LinkedIn SKU, owner, renewal and intended value.
5. Confirm interfaces, sample data, test accounts, security/privacy route.
6. Confirm procurement band, acceptance owner and discovery quote inputs.

D. Under-Weighted Risks

1. The numbers are full of false precision. 516K alumni is a homepage number, not reachable-contact count. HKD300k is an unverified LinkedIn SKU. art-mate cost is rack-rate inference. 4,000 portal updates at launch may not predict recurring yield. Discovery must replace all of these with real denominators.

2. Both packages assume the client will pay for an external integrator. ITS built AMS in-house to escape vendor licensing. They may view this as backlog work, not vendor work. The discovery must be valuable even if ITS builds it, or there is no reason to buy it.

3. CEMS may already solve more than either team knows. If CEMS already writes participation into AMS, the event workstream narrows to non-CEMS sources, adoption gaps and vendor-return standards. That is still useful, but much smaller.

4. The actual ask is narrower than PA's best ideas. Digital card, wallet, rewards, Homecoming passport, FHKPUAA unification and app/PWA are tempting, but they are not the two named workstreams. Over-scoping is the easiest way to lose Robbie.

5. LinkedIn Plus is wishful until proven. PB's newer LinkedIn angle is intriguing but could be unavailable, slow to certify, contractually restricted, low-adoption, or impossible to store in AMS. The core solution must stand without it.

6. Optional alumni participation may be low. Voluntary LinkedIn connection and profile confirmation are measured outcomes, not acceptance criteria. Alumni may not care. The value exchange needs to be real, not "please update our database."

7. PDPO consent state may make the database less usable than assumed. Legacy records, direct marketing, donation asks, FHKPUAA sharing and third-party enrichment all need purpose/consent evidence. If current PICS/consent coverage is thin, the first measurable win may be consent refresh, not career data.

8. Event-source identity is messy. Family bookings, group purchases, guests, changed names, multiple awards, multiple NetIDs, shared emails and walk-ins can destroy naive match rates. Low-confidence links must never auto-merge.

9. Procurement can kill momentum. HKD188k likely means RFQ. The pilot likely means tender. A PolyU alumnus with a direct AAO relationship should prepare a conflict-of-interest disclosure. Do not assume relationship-based direct purchase.

10. EventBinder delivery-capability risk is real. PA's cabi review shows useful assets but also no payments, no university SSO, no consent ledger, no AMS connector, no zh-HK/zh-CN localization, no gamification engine, prototype wallet, and unverified live v2025 status. Overclaiming capability is dangerous.

11. Standard PolyU terms may capture IP or impose heavy data obligations. PB uniquely catches this. Background IP, subprocessor approvals, no production data in AI tools, retention/destruction evidence, incident duties, warranty and insurance need to be priced and negotiated.

12. Incumbent price anchoring is brutal. art-mate can do registration/static QR cheaply and already has relationship trust. EventBinder must not be evaluated as a ticketing tool. The category has to be data governance and AMS-linked participation.

13. Mainland alumni access is under-tested. PolyU has mainland networks and WeChat login. A Cloudflare-first stack may have access/performance and PIPL/cross-border implications. Discovery must ask hosting and mainland channel questions early.

14. Payments are a hidden scope trap. CEMS claims payment; art-mate has PayMe/card/Alipay/WeChat rails; cabi apparently lacks payment processing. If AAO wants paid events, refunds, memberships or donations, this becomes procurement, finance and PSP integration scope.

15. Advancement/donor data is barely mapped. Alumni Affairs versus Development/Foundation flows matter because donation solicitation is high-risk direct marketing and could be the budget owner. Both packages under-map this stakeholder area.

16. FHKPUAA politics can stall the project. PA is right that FHKPUAA is a real adjacent data domain. PB is right to keep it out of scope. The risk is letting it drift in accidentally without data-user, consent and ownership clarity.

17. Public-source confidence is not internal truth. Both teams infer from public pages, source snippets, headers and forms. The first meeting must aggressively separate "public evidence" from "PolyU's actual architecture and contracts."

Spoken Summary

My sharpest strategic call: lead with PB's narrow interoperability discovery, not PA's broader engagement app. Robbie asked for LinkedIn profile refresh and event registration data integration. Win the first contract by making AMS/CEMS stronger, not by trying to sell PolyU another product.

The three biggest disagreements:

1. Scope: PA wants an Alumni Engagement Layer with app/card/rewards; PB wants canonical data contracts and connectors. I choose PB for the first pitch. PA's vision belongs in the later roadmap.
2. LinkedIn: PA says LinkedIn cannot feed individual records; PB says Verified on LinkedIn Plus may offer a consented path. I resolve it this way: ordinary LinkedIn is not a bulk feed; Verified Plus is only a discovery dependency, never the core promise.
3. Incumbent: PB underplays art-mate; PA understands the real status-quo threat. I use PA's coexistence and price-anchor analysis, but keep it out of the client-facing critique.

The risks both teams most dangerously under-weight: false precision in all the numbers, ITS deciding to build it themselves, and EventBinder overclaiming delivery capacity before cabi/payment/SSO/privacy/support gaps are verified.

Output file: /Users/kenta/repo/puaa/P1/CODEX-CROSSCHECK.md