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 data upload flows through the Master Node's API Gateway, which routes it to the assigned Enterprise Node's Vault for storage.

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, Classification, and Consent

If the user asks the system to interpret the receipt, the request must be admitted as authorized protocol work. The Admission Plane assembles a TaskEnvelope that captures the full authorization and semantic context for the task.

At a high level, admission establishes:

1. who is requesting the work
2. whether that caller is authorized to use the receipt content
3. that the data subject (the user themselves in this case) has granted consent for personal_use scope
4. what the intended work is, classified as task_class: parse
5. which semantic and policy context the task will run under

Because parse tasks are free for the Data Producer, the budget_lock_ref in the TaskEnvelope is null — no SYM escrow is required at admission.

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

Because this is a personal receipt parsed for the owner's own use, the consent model is straightforward: the data subject and the task submitter are the same actor, and personal_use consent is granted implicitly by the upload-and-parse action. This simplicity is specific to this use case and does not generalize to cross-Vault or third-party scenarios.

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 the authorized Vault boundary
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

Because this is a single-Vault parse task operating on the owner's own data, TEE execution is not required by default policy. The Vault operator may perform the parsing locally. Multi-Vault coordination does not apply to this scenario.

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. if the parsed data meets quality criteria, a data quality reward is calculated per the Economics model (see Economic Flow below)
3. reward accounting is finalized at epoch settlement and distributed through the Reward Contract on Aptos

For a personal receipt-parsing request, the normal outcome is that the user receives a trusted structured expense record and, if the data meets quality thresholds, earns a data quality reward.

7. Result Delivery to the Data Subject

After settlement, the finalized structured expense record must be delivered back to the user.

In this scenario:

1. the task submitter and the data subject are the same actor, so delivery authorization is inherent
2. the delivered result is the structured expense record derived from the finalized settlement context
3. delivery is confirmed as a protocol-auditable event
4. the raw receipt image and internal evidence references are not included in the delivered result

Node-Level Execution

From the SCS perspective, the same scenario maps onto the two-tier node architecture defined in SCS System Architecture. The following traces each protocol step to the node and service that handles it.

Master Nodes (3, Symphony Foundation)

The 3 master nodes collectively provide the Admission Plane and Settlement Plane services. For this use case they handle:

1. API Gateway — receives the user's upload request and parse trigger over HTTPS. Performs TLS termination, rate limiting, and request routing. Routes the raw receipt image to the assigned Enterprise Node's Vault for storage.

2. Admission Plane services — Identity & Auth Service validates the user's identity. Consent Verification Service confirms personal_use consent (reading from the Enterprise Node's Consent Manager). Semantic Registry Service resolves receipt fields against the active domain and semantic_version. TaskEnvelope Assembly Service packages the admitted task with budget_lock_ref: null (parse is free). The assembled TaskEnvelope is passed to the Task Orchestrator.

3. Task Orchestrator — drives the task through canonical state transitions (accepted → resolving → dispatched → verifying → awaiting_settlement → completed). For this single-Vault parse task, no Multi-Vault Coordinator involvement is needed. The orchestrator dispatches the execution assignment to the target Enterprise Node.

4. Settlement Plane services — Result Verification Service evaluates the execution output for correctness and integrity, producing an accepted, rejected, or challenged decision. Reward Accounting Service calculates the data quality reward (if the parsed record meets quality criteria). Payout Service batches the reward instruction for epoch settlement on Aptos.

Enterprise Node (assigned Vault)

The Enterprise Node that hosts the user's Vault handles data custody and local computation:

1. Vault Storage Engine — receives and stores the encrypted receipt image. Maintains the Commitment reference for the record. No plaintext leaves the Vault boundary.

2. Consent Manager — stores and enforces the user's personal_use consent record. Responds to consent verification requests from the Master Node's Admission Plane.

3. Computation Runtime — executes the parse task inside the Vault boundary: runs OCR, extracts fields (merchant, date, amount, line items), normalizes values, and maps them into a structured canonical record under the resolved semantic schema. Produces a commitment-linked, deterministic execution output with replayable transcript.

Step-to-Node Summary

Protocol Step	Node	Service
1. Vault Intake	Enterprise Node	Vault Storage Engine
2. Task Admission	Master Node	API Gateway → Admission Plane (Identity, Consent, Semantic, TaskEnvelope Assembly)
3. Semantic Resolution	Master Node	Semantic Registry Service
4. Execution	Enterprise Node	Computation Runtime
5. Verification	Master Node	Result Verification Service
6. Settlement	Master Node	Reward Accounting Service → Payout Service
7. Result Delivery	Master Node → User	API Gateway

Economic Flow

The receipt upload and parse scenario follows the simplest economic path in the protocol. The full pricing and reward model is defined in SCP Economics and Governance.

Parse Is Free for the Data Producer

1. no SYM is required from the user to upload and parse data
2. the computational cost of parsing is absorbed by the protocol:
   • during the bootstrap phase: funded from the Protocol Treasury and Ecosystem Incentives allocation
   • long-term: funded from the Protocol Treasury share of task fees collected on query, compute, and train tasks
3. this design removes friction from data onboarding, which is the primary supply-side driver of the ecosystem

Data Quality Reward

If the parsed receipt record meets quality criteria (parsability, non-duplication, completeness, freshness), the Data Producer earns a data quality reward:

data_reward = base_reward
            × (1 + completeness × 0.3 + freshness × 0.2)
            × domain_demand_multiplier
            × staking_multiplier

Where:

1. base_reward: minimum reward per valid record, set by policy_version
2. completeness (0.0–1.0): ratio of populated optional fields to total optional fields in the resolved schema
3. freshness (0.0–1.0): score based on data age relative to parse time (24 hours = 1.0, decaying over a configurable window)
4. domain_demand_multiplier (0.5–3.0): governance-set per-domain multiplier reflecting current ecosystem demand
5. staking_multiplier:
   • Staked Data Producers (with S_producer stake): 1.0 (100% reward)
   • Unstaked Data Producers: 0.5 (50% reward; the remaining 50% is returned to the epoch reward pool)

Staking is optional. Data Producers may participate and earn rewards without staking, but receive reduced payouts.

Future Dividends

The parsed receipt record does not stop earning at the initial quality reward. When this record is later used by downstream query, compute, or train tasks, the Data Producer receives a share of the task fee as a data usage dividend. Distribution is proportional to the number of records used and the privacy budget consumed against those records.

Settlement and Distribution

1. the data quality reward is calculated at epoch settlement by the Reward Accounting Service on the Master Nodes
2. reward distribution is executed through the Reward Contract on the Aptos blockchain
3. if the per-epoch reward pool is exhausted, remaining eligible records queue for the next epoch

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.

This use case is the simplest protocol path: single Vault, single parse task, self-consent, no privacy budget consumption, no TEE requirement, and direct result delivery to the data subject. It serves as the baseline against which more complex multi-Vault and iterative scenarios should be compared.