Use Case: Privacy-Preserving Consumer Behavior Model Training

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

Scenario

A model operator wants to train a consumer-behavior model using protected receipt and purchase-history data distributed across many Vaults.

The model goal may include:

1. purchase-propensity prediction
2. category or brand affinity estimation
3. coupon-response modeling
4. privacy-preserving user clustering

This use case is informative. It shows how the revised SCP and SCS specifications map onto a training workflow that uses protected records without turning raw consumer purchase data into unrestricted centralized plaintext.

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. model-training intent is distinct from protocol-recognized training work
2. protected source records may remain inside authorized Vault or TEE boundaries
3. training may depend on derived features, query projections, or protected computation rather than unrestricted record export
4. model artifacts and evaluation results must be linked to replayable evidence and version context
5. the resulting model is downstream from governed training truth rather than a substitute for protocol truth

Entry Distinction

This scenario has two different layers:

1. business-side or research-side desire to train a model
2. protocol-recognized training work with fixed policy, semantic, and privacy constraints

The request to "train a consumer-behavior model on purchase data" is not yet a protocol event by itself. It becomes part of the SCP lifecycle only when the system admits an authorized training task with explicit feature scope, version context, and privacy-preserving execution rules.

Protocol View

From the protocol perspective, this scenario transforms training intent into a verifiable and governable model-training result.

1. Training Intent and Scope Definition

The requesting party defines the training goal and constraints, such as:

1. target prediction or clustering task
2. eligible user or market scope
3. allowed feature families
4. model output type
5. evaluation threshold or acceptance criteria

At this point, the request is still a business or research intent rather than protocol truth.

2. Task Admission and Constraint Binding

The system turns that request into authorized protocol work.

At a high level, admission establishes:

1. who is authorized to submit the training task
2. which record domains, feature families, or query projections may be used
3. which privacy, policy, and version constraints apply
4. what outputs count as the protocol-evaluated training result

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

3. Semantic Resolution of Training Meaning

Before training can proceed, the protocol must resolve the semantic meaning of the task under the active context.

That may include determining:

1. which domains define the protected source records
2. which canonical attributes or query attributes are admissible for feature construction
3. which local-only signals must remain private
4. which semantic_version and policy_version govern the run

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

4. Protected Feature Construction and Training Execution

Once the meaning is resolved, authorized computation can perform feature construction and training.

In this use case, protected work may include:

1. deriving approved feature aggregates inside Vault or TEE boundaries
2. assembling training-safe datasets or federated training inputs
3. running model optimization, aggregation, or update steps
4. producing model artifacts, metrics, or replayable training transcripts

Throughout this phase:

1. raw purchase history remains inside authorized Vault or TEE boundaries unless policy explicitly allows a narrower export path
2. the protocol relies on commitments, evidence, lineage, and replayable artifacts rather than unrestricted plaintext movement
3. training remains bound to the admitted feature, policy, and version constraints

5. Verification and Accepted Training Result

The protocol does not treat a produced model artifact as final truth immediately.

Instead, the training 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 Model-Use 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 training run into protocol-recognized training truth
2. finalized accounting becomes the basis for downstream model registry updates, deployment, or gated usage
3. the deployed model remains a downstream system effect rather than the source of protocol truth by itself

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 training request, validate submitter identity and authorization, and bind the task constraints into a system-valid training task.

2. Coordination and Lifecycle Control

Coordination services move the training workflow through semantic resolution, protected feature construction, execution, verification, and settlement while preserving ordered progression and auditability.

3. Semantic Namespace and Registry Services

Semantic services interpret the training workflow under the relevant commerce, behavior, identity, and model-governance domains, while preserving compatibility with the active semantic_version.

4. Vault and Protected Data Services

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

5. Execution Runtime

Execution workers perform feature construction, training, aggregation, and model artifact generation inside the protected runtime, and then emit replayable result bundles.

6. Verification and Challenge Services

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

7. Settlement and Downstream Model Use

Settlement services assemble finalized accounting context. Downstream model systems can then use that finalized result as the trusted basis for model registry updates, deployment, or consumer-facing activation without rewriting protocol finality.

Semantic and Feature Handling

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

If the requested model depends on concepts that do not map cleanly to the active canonical or query sets, several things may happen:

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

This is where the use case touches:

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

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

Key Boundary Reminders

The desire to train on consumer behavior is not yet a full protocol event.

The full SCP lifecycle begins only when the system turns that training intent into authorized protocol work with explicit feature, privacy, and evaluation constraints.

Likewise, the trained model itself is not automatically the protocol truth. The protocol truth is the accepted and settled training result that downstream systems then use as the basis for deployment or activation.