Symphony Current Overview

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

Purpose

This document is the starting point for the current Symphony documentation set.

At the highest level, Symphony should be understood as a decentralized privacy data platform. It is designed for large-scale private data ingestion, storage, governance, protected query, business activities such as precision marketing, protected computation, and model training.

It answers:

1. what Symphony is at the platform level
2. what SCP and SCS are within that platform
3. why they are documented separately
4. what each line covers after the latest protocol revision
5. how readers should move through the canonical set

Platform Positioning

Symphony is not only a protocol set or a system architecture description. It is the umbrella platform for privacy-preserving data collaboration and data-driven work across decentralized boundaries.

From that platform perspective, Symphony is designed to let customers:

1. upload and govern large volumes of private data
2. keep raw records inside controlled Vault or TEE boundaries
3. run protected query and analysis against governed semantics
4. support business activities such as precision marketing without exposing raw user data
5. execute protected computation and model training with replayable and auditable evidence

SCP and SCS are therefore best read as the two canonical documentation lines that explain how the platform stays trustworthy and implementable.

Two Canonical Lines

SCP: Symphony Core Protocol

SCP is the protocol specification.

It defines:

1. what the protocol governs
2. lifecycle and state semantics
3. actor duties and economics constraints
4. semantic namespace, domain, and attribute evolution
5. epoch-window, settlement, reward, and governance meaning

SCP does not define a particular deployment, database, service split, or worker topology.

SCS: Symphony Core System

SCS is the system realization specification.

It defines:

1. how runtime modules realize the SCP layers
2. how persistence and integration domains preserve protocol semantics
3. how semantic, epoch, settlement, reward, and payout artifacts are carried through implementation
4. how delivery, deployment, migration, and operations preserve protocol truth in production

SCS does not redefine protocol truth. It explains how a system implements and preserves it.

Scope

Together, SCP and SCS cover:

1. deterministic task admission, execution, verification, and settlement
2. private data protection inside Vault and authorized TEE boundaries
3. protected query, audience selection, and business activities such as precision marketing
4. privacy-preserving feature construction and model training
5. semantic namespace evolution under governed compatibility
6. epoch-windowed accounting, aggregation, and replay partitioning
7. reward accounting and downstream payout realization
8. replay, audit, and governance-safe operations

Non-Goals

This canonical set does not try to:

1. collapse protocol semantics and implementation details into one document
2. define an unbounded generic compute marketplace
3. treat downstream chain state as the source of protocol truth
4. assume one mandatory runtime topology for every deployment

Reading Order

1. Boundaries and Reading Guide
2. SCP Protocol Overview
3. SCP Core Spec
4. SCP Economics and Governance
5. SCS System Architecture
6. SCS Data and Integration
7. SCS Delivery and Operations