Use Case: Tacet Task Hall — Agent-Mediated Brand Bounty Task

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

Scenario

A fitness brand publishes a bounty task in the Tacet Task Hall: "We need up to 500 users who spent $100 or more in fitness-related categories in the last 3 months. Reward: $15 per qualifying participant who shares their spend breakdown."

The Tacet platform submits this as a multi-Vault query task to Symphony Core. Each participating Vault evaluates its own users for eligibility inside a TEE. Qualifying users are surfaced through the Tacet app as an Agent-driven recommendation: "This task matches your profile — tap to participate." When a user accepts, their Vault produces a de-identified spend breakdown. The brand receives an aggregated dataset of up to 500 anonymized records and settles the reward to each participating user's Tacet account.

This use case is informative. It shows how the SCP and SCS specifications support a two-sided data marketplace workflow where an AI Agent mediates between a brand's data task and individual users' consented data access — without exposing raw Vault contents to the brand, Tacet, or any other party.

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 properties that extend the existing coupon-campaign and model-training use cases in important ways:

1. the Task Submitter is Tacet (the application platform) acting on behalf of a brand advertiser, introducing a platform-as-intermediary role not present in earlier use cases
2. the task targets individual users as voluntary participants rather than silently selecting them as an audience — user acceptance is a protocol-required step before their Vault data is included
3. an AI Agent performs automated eligibility pre-screening inside each user's Vault before the user is even shown the task, reducing the user's cognitive burden to a single accept/decline tap
4. the agent's pre-screening result must not itself constitute a data disclosure — the act of determining that a user is eligible must happen inside the Vault boundary, not by the agent reading plaintext records
5. the settlement model distributes monetary rewards directly to individual users rather than to enterprise nodes acting as bulk data sellers, which requires the per-actor reward accounting to resolve at the individual data subject level
6. the brand receives a fixed-schema, de-identified output rather than a raw data dump, and the delivery format is defined at task admission so that the brand's access scope cannot expand at delivery time

It therefore validates that the protocol can support a user-consented, agent-assisted data marketplace task as a coherent end-to-end flow within the existing SCP lifecycle.

Entry Distinction

This scenario has three different layers:

1. brand-side campaign intent expressed through the Tacet Task Hall UI
2. Tacet platform action that transforms brand intent into an authorized protocol task
3. per-user agent action that evaluates eligibility and presents the task to qualifying users

The brand's desire to "find 500 fitness spenders" is not yet a protocol event. It becomes part of the SCP lifecycle only when Tacet, acting as a registered Task Submitter, admits a structured query task with explicit targeting attributes, consent requirements, output schema, and fee escrow.

Unlike the Luckin coupon campaign use case, this use case involves:

1. a voluntary participation model where each data subject must explicitly accept the task before their Vault contributes data — the task does not silently select users by evaluating records on the brand's behalf
2. an AI Agent acting as a per-user eligibility pre-screener that runs inside the Vault boundary before surfacing the task to the user — the Agent's recommendation is based on a private match evaluation, not on plaintext record export
3. a two-phase execution model: (a) eligibility check per Vault produces a yes/no result per user, followed by (b) per-user data contribution that fires only for users who accepted
4. individual-level settlement where each participating data subject receives a monetary reward recorded against their data_subject_id, not a bulk Vault Operator payout
5. a hard audience cap (max_participants: 500) enforced at the aggregation step, first-come-first-served among eligible acceptors

Protocol View

From the protocol perspective, this scenario transforms a brand's data acquisition intent into a verifiable, consent-enforced, individually-settled data contribution result.

1. Brand Task Definition and Tacet Platform Validation

The brand submits a task definition through the Tacet enterprise portal:

1. target criteria: fitness-related transaction category spend ≥ $100, time window: last 90 days
2. required output fields: total fitness spend (bucketed to $50 ranges), top 3 merchant categories, transaction frequency
3. audience cap: up to 500 participants
4. reward per participant: $15 USD, paid via Tacet's PayPal/ACH settlement channel
5. data usage declaration: market sizing analysis, internal use only, no resale

Tacet's platform-side validation (prior to protocol submission) checks:

1. the brand has an active Tacet enterprise account with verified identity and pre-funded budget ($7,500 to cover 500 × $15)
2. the required output fields do not include direct identifiers (name, address, device ID)
3. the data usage declaration does not describe prohibited purposes under Tacet's task content policy
4. the targeting criteria can be expressed using registered canonical attributes in the Semantic Registry

Only after Tacet's platform validation does the task enter the SCP lifecycle.

2. Task Admission

Tacet, acting as a registered Task Submitter, submits a QueryTaskRequest to the master cluster's API gateway.

Identity and authorization

1. the gateway authenticates Tacet's Task Submitter credentials
2. the Identity and Auth Service confirms Tacet is registered as a platform-class Task Submitter authorized to submit tasks on behalf of third-party brands

Consent scope declaration

The task declares consent_scope: task_participation_marketing, meaning the task may only include users who have granted consent for marketing-usage-scope task participation. Consent is not assumed; it is enforced per data subject at execution time.

Semantic resolution

The Semantic Registry Service resolves the targeting criteria and output schema to canonical attributes:

1. transaction_category (directly queryable, commerce domain) — filtered to fitness subcategories
2. transaction_amount (directly queryable) — aggregated over the 90-day window
3. merchant_category_rank (derived via aggregate rule over transaction_category) — top-3 ranking
4. transaction_frequency (derived via count rule) — normalized to monthly rate
5. spend_bucket (derived via bucket rule) — maps total spend to $50-wide buckets, replacing the raw total

The bucket derivation rule for spend_bucket is critical: it ensures the brand receives a bucketed value ($100-149, $150-199, etc.) rather than the exact spend figure. The brand declared spend_bucket as the required output field at submission; the Semantic Registry confirms the derivation path and registers it in the TaskEnvelope.

Privacy budget pre-check

Because the exact set of qualifying users is not known at admission time, the Privacy Budget Reservation Service performs a sampling-based pre-check across participating Vaults to confirm that sufficient budget headroom exists across the expected participant population. A formal per-user reservation is not made at admission; it is made per-user at the moment each user accepts the task.

Fee escrow

The brand's task fee is locked in the Escrow Contract on Aptos at admission time. The escrow amount covers:

1. per-participant data contribution rewards (up to 500 × $15)
2. Vault Operator share for storage and execution
3. Executor share for TEE compute
4. Aggregator and Verifier shares
5. Protocol Treasury share

TaskEnvelope assembly

The TaskEnvelope carries all the above, plus:

1. participation_mode: voluntary — signals to enterprise nodes that no data is contributed without explicit user acceptance
2. max_participants: 500 — enforced at the aggregation step
3. output_schema: the exact fields and derivation rules for the brand's result set
4. task_expiry: the task closes after 14 days or when 500 participants are reached, whichever comes first

3. Agent-Side Eligibility Pre-Screening

After the task is admitted and the TaskEnvelope is dispatched to enterprise nodes, each enterprise node's Computation Runtime runs a pre-screening step for each of its users who have active consent for task_participation_marketing.

The pre-screening runs inside the enterprise node's TEE enclave:

1. the enclave loads the relevant transactions for each candidate user from the Vault Record Store
2. it evaluates the targeting criteria: does this user have ≥ $100 in fitness-category spend in the last 90 days?
3. for users who meet the threshold, it produces an eligibility flag — a boolean plus the spend_bucket value
4. the eligibility result is sealed with the user's data_subject_id and a task-specific nonce

The eligibility result is NOT returned to the master cluster or to the brand. It is retained inside the enterprise node and surfaced exclusively to the user's Tacet Agent via an encrypted notification to the device endpoint registered in the user's delegation credential.

The Tacet Agent receives: "A brand task is available. You appear to qualify. Expected reward: $15. Tap to review."

The user sees the task card in the Tacet app. The Agent's pre-screening result does not include the user's actual spend total — it shows only the bucketed range and whether they qualify. The brand does not learn that this user was pre-screened or that they chose to decline.

4. Per-User Participation Consent and Privacy Budget Reservation

When a user taps "Accept" in the Tacet app:

1. the Tacet app sends an acceptance signal to the master cluster carrying the user's data_subject_id, task_id, and a fresh participation consent signature
2. the Consent Verification Service sends an RPC to the user's enterprise node Consent Manager to confirm that task_participation_marketing consent is active and that the user's explicit acceptance has been received
3. the Privacy Budget Reservation Service sends a reserve RPC to the user's Privacy Budget Ledger for the specific privacy budget consumption of this task (the bucketed output fields consume less budget than a raw spend query)
4. the master cluster records the user's participation commitment in the Task State Store and decrements the remaining audience cap counter

If the audience cap reaches 500 before a user's acceptance is processed, the master cluster returns a "task full" response and no reservation is made.

5. Per-User Execution and Slice Production

For each accepted user, the enterprise node's Computation Runtime executes the task slice:

1. the enclave retrieves the user's fitness transactions from the Vault Record Store
2. it applies the derivation rules from the TaskEnvelope: compute total spend, derive spend_bucket, rank top-3 merchant categories, calculate frequency
3. it produces a SliceResultBundle containing the bucketed and derived output fields with no raw transaction records
4. it appends the privacy budget consumption record to the slice evidence
5. it generates an AttestationReport for this execution slice
6. no plaintext transaction records leave the enclave

Each user's SliceResultBundle is returned to the Multi-Vault Coordinator on the master cluster.

6. Secure Aggregation and Audience Cap Enforcement

The Aggregation Runtime on the master cluster (running inside its attested TEE) receives the per-user slice results as they arrive:

1. it accumulates slices up to the max_participants: 500 cap, first-come-first-served by acceptance timestamp
2. once 500 slices are collected (or the task expires), aggregation runs: the 500 individual records are assembled into the brand's output dataset
3. the Aggregation Runtime applies a final cardinality check: if fewer than the protocol-defined minimum result cardinality participated, the result is suppressed and the task is marked incomplete
4. the aggregate result carries an AttestationReport from the aggregation enclave, proving that no more than the declared output fields were assembled
5. the Aggregation Runtime does not retain individual slice inputs after producing the aggregate

7. Verification and Settlement

Result verification

The Result Verification Service validates:

1. each per-user AttestationReport — enclave measurement, platform, freshness nonce
2. the aggregation AttestationReport
3. that the output schema matches the TaskEnvelope declaration exactly
4. that the audience cap was not exceeded

Settlement

Upon accepted verification:

1. the Settlement Plane finalizes the settlement context, linking all 500 per-user execution slices and the aggregation step
2. the Payout Service transforms the finalized reward records into a PayoutInstructionSet for Aptos
3. the Reward Contract distributes SYM from escrow: Data Contributor shares (per participating user), Vault Operator shares, Executor shares, Aggregator share, Verifier shares, Protocol Treasury share
4. the brand's Tacet account is debited; each participating user's Tacet earnings balance is credited $15 USD via the PayPal/ACH settlement channel (independent of SYM distribution)
5. the Escrow Contract releases remaining funds if fewer than 500 users participated before the task expired

Brand result delivery

The brand receives the aggregated dataset through the Tacet enterprise portal:

1. up to 500 rows, each containing: spend_bucket, top-3 merchant categories, transaction frequency — no identifiers, no raw amounts
2. a SettlementRoot reference they can use to verify the result's provenance on Aptos
3. a data lineage summary: how many Vaults contributed, which semantic version and policy version governed the run, the aggregation method and enclave measurement used

8. User-Facing Audit Trail

Each participating user can view in the Tacet "data access log":

1. that on this date, a brand task used their fitness spend data
2. exactly which output fields were derived from their records (spend bucket, merchant categories, frequency)
3. how much privacy budget was consumed
4. that they received $15 in exchange, linked to the task ID

Users can revoke their task_participation_marketing consent at any time. Revocation does not affect already-completed tasks but prevents future task participation.

---

Protocol Extension Points

This scenario requires one extension and one clarification relative to the existing SCP/SCS specification:

Platform-class Task Submitter role

The current actor model covers enterprise nodes and data producers. A platform-class Task Submitter such as Tacet — an application that intermediates between brands and users, submitting tasks on behalf of brands while also managing user delegation credentials — is a new sub-role within Task Submitter. The Actor Registry should distinguish platform-class Task Submitters from direct enterprise or individual Task Submitters because they have additional responsibilities: they pre-validate brand task content, hold user delegation credentials, and are accountable for brand compliance with data usage declarations.

participation_mode: voluntary as a first-class task attribute

The existing TaskEnvelope does not include a participation_mode field. All current use cases assume the task selects users passively (the enterprise node evaluates records and returns results without per-user consent at execution time, relying on pre-granted consent). The voluntary participation model requires a new protocol-recognized flow where execution per data subject does not begin until that user's explicit acceptance is recorded in the task lifecycle. This is a distinct protocol event between the dispatched and executing states in the task state machine.