Use Case: Receipt Upload to Personal Vault

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

Scenario

A user uploads a shopping receipt image into their personal Vault and requests the system to parse it into structured expense data.

This use case is informative. It shows how the revised SCP and SCS specifications map onto a concrete end-user flow.

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

Why This Use Case Matters

This scenario is small, but it captures most of the important boundaries in the revised Symphony stack:

1. data first enters a local Vault boundary
2. protocol work begins only after authorized task admission
3. semantic meaning must be resolved before execution can be trusted
4. private receipt content must remain inside authorized data boundaries
5. only accepted and settled results become protocol-visible truth

For that reason, the receipt example is a good way to see the difference between raw storage, protocol-recognized work, and downstream accounting.

Entry Distinction

This scenario has two layers:

1. pure upload into Vault storage
2. upload plus protocol-triggered parsing task

The full protocol flow described here assumes the second case: the receipt upload also triggers a task to interpret the receipt.

That distinction matters. Uploading a file into a personal Vault is primarily a local system event. It becomes part of the SCP lifecycle only when the system admits a protocol task that asks for authorized interpretation of that receipt.

Protocol View

From the protocol perspective, this scenario can be understood as the transformation of a private receipt into protocol-recognized work and, if accepted, into settled protocol truth.

1. Vault Intake and Local Custody

The user uploads the receipt image into their personal Vault.

At this point:

1. the raw image remains private local data
2. the receipt is still inside the Vault boundary
3. no reward, settlement, or protocol truth exists yet

This is the boundary between personal custody and protocol participation.

2. Task Admission and Authorization

If the user asks the system to interpret the receipt, the request must be admitted as authorized protocol work.

At a high level, admission establishes:

1. who is requesting the work
2. whether that caller is authorized to use the receipt content
3. what the intended work is
4. which semantic and policy context the task will run under

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

3. Semantic Resolution Under Domain and Version Context

Before execution, the protocol must determine what the receipt fields mean under the active semantic context.

In this use case, that usually means selecting an appropriate expense or personal-finance domain and resolving receipt fields against active canonical attributes, such as:

1. merchant
2. transaction date
3. total amount
4. currency
5. tax
6. payment method
7. line items

This step matters because the revised SCP does not allow execution to quietly invent meaning. The work must be interpreted under the active semantic_version and the relevant domain rules.

4. Protected Data Access and Execution

Once the meaning is resolved, authorized computation can proceed.

In this example, execution may include:

1. OCR over the receipt image
2. merchant and date extraction
3. amount normalization
4. field structuring
5. semantic mapping into an expense-oriented record

Throughout this phase:

1. plaintext receipt content stays inside authorized Vault or TEE boundaries
2. the protocol relies on record linkage, commitments, evidence, and execution artifacts rather than unrestricted plaintext movement
3. execution remains bound to the admitted authorization and semantic context

5. Verification and Accepted Result Formation

The protocol does not treat execution output as final truth by default.

Instead, the execution output 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 toward settlement.

6. Settlement, Accounting, and Optional Downstream Effects

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

In this use case:

1. settlement is what turns accepted work into protocol-recognized truth
2. reward accounting may or may not apply, depending on whether the flow is part of a rewarded network path
3. any payout consequence remains downstream from finalized accounting rather than defining truth by itself

For a personal receipt-parsing request, the normal outcome is that the user receives a trusted structured expense record, not that the user receives a protocol reward.

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 upload-triggered request, validate identity and authorization, and package admissible work into system-valid task handling.

2. Coordination and Lifecycle Control

Coordination services move the request from admission into semantic resolution, execution, verification, and settlement while preserving auditable ordering.

3. Semantic Namespace and Registry Services

Semantic services determine which domain applies, resolve receipt fields against active canonical attributes, and preserve compatibility with the current semantic_version.

4. Vault and Protected Data Services

Vault-side storage and authorization-aware data access keep the raw receipt private while exposing only permitted record material to computation.

5. Execution Runtime

Execution workers perform the receipt interpretation work inside the protected runtime context and emit replayable transcripts or result bundles.

6. Verification and Challenge Services

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

7. Settlement and Downstream Accounting

Settlement services assemble finalized accounting context. If this flow is part of a rewarded or paid path, downstream systems may later prepare reward or payout consequences without rewriting protocol finality.

Semantic Evolution in This Scenario

Receipt parsing is also a useful example of how semantic growth works in the revised protocol.

If a receipt contains a field or label that does not cleanly map to the active canonical set:

1. it may stay unresolved and require stricter handling
2. it may remain local to the Vault under policy-permitted handling
3. it may later contribute to a privacy-preserving LocalAttributeCandidate

This is where the use case touches:

1. domain
2. CanonicalAttribute
3. local attribute handling inside a Vault
4. candidate evolution under governed semantic rules

The important point is that semantic novelty can exist without immediately becoming shared protocol truth.

Key Boundary Reminders

Uploading the receipt image itself is not automatically a full protocol event.

The full SCP lifecycle begins only when the system turns that uploaded artifact into authorized protocol work that must be semantically resolved, executed, verified, and settled.

Likewise, the final structured expense record becomes protocol-recognized truth only after acceptance and settlement, not simply because an OCR or parsing step ran inside the system.