Use Case: Targeted Coupon Campaign for Recent Luckin Customers

Version: v1.0 (Draft) Status: Draft Authoritative: Informative

Scenario

Luckin Coffee wants to run a promotional campaign in Singapore for users who have purchased from Luckin within the last 30 days.

The campaign goal is to identify up to 5000 eligible users and issue them coupons through downstream business systems.

This use case is informative. It shows how the revised SCP and SCS specifications map onto a concrete advertiser-driven audience-selection and coupon-distribution scenario.

Canonical protocol terms used here follow SCP Protocol Overview and SCP Core Spec.

Why This Use Case Matters

This scenario is useful because it demonstrates several important properties of the revised Symphony stack:

1. the requesting party is an advertiser rather than an end user
2. eligibility depends on protected purchase-history data inside Vault boundaries
3. the task includes geography, time-window, and audience-cap constraints
4. selection results must be verifiable before they become campaign-usable truth
5. coupon issuance remains downstream from finalized protocol accounting

It therefore shows how the protocol can support privacy-preserving marketing activation without turning raw consumer records into protocol-visible plaintext.

Entry Distinction

This scenario has two different layers:

1. business-side campaign intent
2. protocol-recognized eligibility and audience-selection work

The advertiser's desire to "send coupons to recent Luckin customers in Singapore" is not yet a full protocol event by itself. It becomes part of the SCP lifecycle only when the system admits a concrete authorized task with explicit targeting constraints.

Protocol View

From the protocol perspective, this scenario transforms campaign intent into a verifiable and settleable audience-selection result.

1. Campaign Intent and Local Business Input

Luckin defines a campaign with these business constraints:

1. advertiser identity: Luckin Coffee
2. geography: Singapore
3. eligibility window: last 30 days
4. audience rule: users with recent Luckin purchase activity
5. audience cap: 5000
6. downstream outcome: coupon issuance

At this point, the campaign is still a business request, not protocol truth.

2. Task Admission and Constraint Binding

The system turns that request into authorized protocol work.

At a high level, admission establishes:

1. that the advertiser is authorized to submit the campaign
2. that the campaign has explicit policy and budget context
3. that the geography and time-window constraints are fixed for this run
4. that the audience cap is part of the protocol-evaluated task definition

Only after this step does the campaign become protocol-recognized work.

3. Semantic Resolution of Eligibility Meaning

Before any matching can happen, the task must be interpreted under the active semantic context.

That means the protocol must resolve what concepts such as these mean in the current domain and semantic_version:

1. Luckin purchase
2. purchase recency
3. Singapore eligibility
4. campaign audience membership
5. coupon-targetable identity or contact handle

This step matters because the revised SCP requires shared meaning before protected computation can be trusted.

4. Protected Eligibility Evaluation

Once the meaning is resolved, authorized computation can evaluate eligibility against protected records.

In this use case, protected work may include:

1. checking purchase history for Luckin activity
2. evaluating whether the purchase fell within the last 30 days
3. confirming the Singapore geography condition
4. assembling an eligible audience candidate set
5. applying the audience cap of 5000 under policy-defined selection logic

Throughout this phase:

1. raw purchase history remains inside authorized Vault or TEE boundaries
2. the protocol relies on evidence, commitments, and replayable artifacts rather than unrestricted plaintext exposure
3. selection remains bound to the admitted campaign constraints

5. Verification and Accepted Audience Result

The protocol does not treat a candidate audience list as final truth immediately.

Instead, the eligibility result must be checked for correctness and integrity. In outcome terms, the result may be:

1. accepted
2. rejected
3. challenged

Only accepted work can continue into settlement.

6. Settlement, Accounting, and Coupon-Issuance Basis

If the result is accepted, it can enter settlement and become part of finalized protocol accounting.

In this scenario:

1. settlement turns the accepted audience-selection result into protocol-recognized campaign truth
2. finalized accounting becomes the basis for downstream coupon issuance
3. the actual coupon send remains a downstream business effect, not the source of protocol truth

The protocol therefore determines which audience result is trusted. Downstream systems determine how that trusted result is turned into issued coupons.

System Realization View

From the SCS perspective, the same scenario is realized through cooperating runtime modules.

1. Admission Surface

Client-facing admission services receive the campaign request, validate advertiser identity and authorization, and bind the campaign constraints into a system-valid task.

2. Coordination and Lifecycle Control

Coordination services move the campaign through semantic resolution, protected eligibility evaluation, verification, and settlement while preserving ordered progression and auditability.

3. Semantic Namespace and Registry Services

Semantic services interpret the campaign under the appropriate commerce, transaction, identity, geography, and audience domains, while preserving compatibility with the active semantic_version.

4. Vault and Protected Data Services

Vault-side storage and authorization-aware data access keep purchase-history records private while exposing only permitted material to eligibility computation.

5. Execution Runtime

Execution workers evaluate recent-purchase conditions, geography filters, and audience-cap logic inside the protected runtime, and then emit replayable result bundles.

6. Verification and Challenge Services

Verification services validate the audience-selection result, preserve replayable evidence, and publish an accepted, rejected, or challenged outcome.

7. Settlement and Downstream Coupon Issuance

Settlement services assemble finalized accounting context. Downstream campaign systems can then use that finalized result as the trusted basis for coupon issuance without rewriting protocol finality.

Semantic and Eligibility Handling

This scenario is also a good example of governed semantic interpretation.

If the campaign depends on concepts that do not map cleanly to the active canonical set, several things may happen:

1. the task may remain blocked until the semantics are clarified
2. some concepts may stay local under policy-permitted handling
3. emerging campaign or audience concepts may later contribute to governed semantic evolution

This is where the use case touches:

1. domain
2. CanonicalAttribute
3. local attribute handling
4. governed candidate evolution

The important point is that campaign logic does not get to redefine protocol meaning privately or silently.

Settlement and Coupon Issuance Consequences

This use case does not mean that Luckin automatically receives protocol rewards.

Instead, the main protocol consequence is:

1. a trusted, accepted, and settled audience-selection result
2. a finalized accounting basis for downstream coupon issuance

If the campaign operates inside a rewarded network path, reward consequences may also exist for production roles such as:

1. Vault operators
2. executors
3. verifiers

Those consequences remain downstream from protocol-recognized state transitions.

Key Boundary Reminders

The campaign brief itself is not yet a full protocol event.

The full SCP lifecycle begins only when the system turns that business intent into authorized protocol work with explicit audience, location, and recency constraints.

Likewise, the coupon send itself is not the protocol truth. The protocol truth is the accepted and settled audience-selection result that downstream systems then act upon.