SCS System Architecture

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

Purpose

This document explains how SCS realizes the revised SCP protocol in a concrete system.

At the higher narrative level, Symphony is a decentralized privacy data platform for large-scale private data ingestion, storage, governance, protected query, business activities such as precision marketing, protected computation, and model training. SCS explains how that platform is realized in production without weakening the guarantees defined by SCP.

It answers:

1. how runtime modules realize the protocol layers
2. where trust, privacy, and control boundaries are enforced
3. how system components support the protocol lifecycle from task admission to downstream payout
4. how actors interact with the implementation surface without redefining protocol truth

Realization Principles

SCS is the implementation line of the Symphony stack.

Its job is to realize protocol truth defined by SCP, not to redefine it. In practice, this means:

1. SCP defines lifecycle meaning, actor duties, semantic evolution, epoch behavior, settlement finality, and economics rules
2. SCS defines the runtime modules, storage boundaries, APIs, and operational mechanisms that preserve those meanings in production
3. one deployment may combine or separate modules differently, as long as the same protocol semantics are preserved

Because of that, SCS should be read as the production realization model for the broader Symphony platform, not as a fixed hardware or node topology.

Runtime Realization Model

At the implementation level, SCS typically realizes the protocol through cooperating modules such as:

1. client-facing admission and API edge
2. coordination and lifecycle control
3. semantic namespace and registry services
4. Vault and protected-data access services
5. execution runtimes and proof-producing workers
6. verification and challenge handling services
7. settlement, reward-accounting, and downstream payout integrations

These are implementation modules, not new protocol layers. They exist to realize the seven logical protocol layers defined by SCP.

Mapping SCP Layers to SCS Modules

The revised SCP model uses seven logical layers. SCS normally realizes them as follows:

1. Application Layer Realization

Typical SCS modules:

1. API gateways
2. identity and authorization checks
3. admission-policy enforcement
4. task-intake services

Implementation purpose:

1. validate client intent
2. validate caller identity and authorization context
3. package admissible work into protocol-valid requests

2. Coordination Layer Realization

Typical SCS modules:

1. workflow orchestrators
2. state-transition controllers
3. retry and timeout managers
4. task-routing and handoff services

Implementation purpose:

1. move tasks across semantic, execution, verification, and settlement stages
2. enforce ordered lifecycle transitions
3. preserve auditable progression through the protocol

3. Semantic Layer Realization

Typical SCS modules:

1. domain and registry services
2. canonical attribute resolution services
3. compatibility-policy evaluators
4. local-candidate aggregation pipelines

Implementation purpose:

1. resolve meaning under semantic_version
2. bind work to the correct domain and attribute namespace
3. support governed semantic evolution without silent drift

4. Data Layer Realization

Typical SCS modules:

1. Vault storage systems
2. encrypted record stores
3. commitment and evidence stores
4. authorization-aware record materializers

Implementation purpose:

1. preserve private records inside authorized Vault or TEE boundaries
2. expose only permitted record material to downstream computation
3. maintain cryptographic linkage between records, access, and protocol-visible artifacts

5. Execution Layer Realization

Typical SCS modules:

1. protected compute runtimes
2. execution schedulers
3. proof-producing workers where required
4. transcript and result packaging services

Implementation purpose:

1. perform authorized computation
2. preserve auditable execution context
3. emit deterministic execution outputs under equal replay context

6. Verification Layer Realization

Typical SCS modules:

1. result-checking services
2. proof-validation services
3. challenge-ingress and evidence pipelines
4. verification decision publishers

Implementation purpose:

1. validate correctness and integrity before settlement
2. preserve replayable evidence
3. issue accepted, rejected, or challenged outcomes in system form

7. Settlement Layer Realization

Typical SCS modules:

1. settlement assemblers
2. root builders
3. finalized accounting writers
4. reward-record and payout-intent producers

Implementation purpose:

1. anchor verified state
2. assemble candidate and finalized accounting context
3. prepare downstream reward and payout integrations without redefining protocol finality

Actor Interaction Model in SCS

The revised SCP actor model still applies in SCS, but appears as system-facing interfaces and control planes.

At a high level:

1. ingress actors such as data producers and task submitters interact with admission, budget, and quota surfaces
2. production actors such as Vault operators, executors, and verifiers interact with protected runtime, evidence, and settlement surfaces
3. governance and treasury actors interact with challenge, adjudication, accounting, and payout-authority surfaces

SCS must preserve these actor distinctions because they affect authorization, auditability, economics realization, and operational isolation.

Trust and Control Boundaries

The implementation must enforce boundaries that preserve the revised SCP model:

1. private plaintext remains inside authorized Vault or TEE boundaries
2. semantic and policy decisions are version-aware and auditable
3. coordination remains the control plane for lifecycle progression
4. verification and challenge evidence remain replayable
5. settlement and reward history remain append-only in finalized form
6. payout authority remains downstream from finalized protocol accounting

These boundaries matter because SCS exists to preserve protocol truth under real deployment conditions, not only under idealized logic.

Epoch, Settlement, and Downstream Accounting

The revised SCP treats epoch as a stable control window rather than a prerequisite for raw data or task existence.

SCS therefore typically implements epoch-aware services for:

1. settlement grouping
2. reward calculation windows
3. payout preparation windows
4. semantic candidate aggregation windows
5. replayable partitioning where batching matters

This means a system may admit and execute work continuously while later accounting and aggregation still converge around stable epoch windows.

Implementation Assurance Expectations

SCS should support at least:

1. replay of execution and verification artifacts
2. settlement-root reproducibility
3. semantic-resolution auditability
4. epoch-window reconstruction
5. reward-accounting and downstream payout reconciliation

These are system capabilities required to preserve revised SCP semantics in production.

Relationship to SCP

This document describes implementation realization only.

For the normative meaning of protocol layers, actors, semantic evolution, epoch behavior, settlement truth, and economics, see:

1. SCP Protocol Overview
2. SCP Core Spec
3. SCP Economics and Governance