SCS Data and Integration

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

Purpose

This document defines how SCS realizes the revised SCP model in persistence, APIs, schemas, and external integrations.

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

It answers:

1. how protocol artifacts are packaged for implementation
2. which persistence domains the system must maintain
3. how replay, idempotency, and auditability are preserved in data form
4. how downstream chain or payout integrations connect to finalized protocol accounting

Contract Packaging

The Markdown specification set remains the canonical semantic source.

SCS must additionally produce machine-readable implementation artifacts such as:

1. request and response schemas
2. internal event and message schemas
3. version annotations for schema_version, semantic_version, and policy_version
4. compatibility metadata for semantic and lifecycle-sensitive objects
5. error catalogs and implementation-facing validation contracts

These artifacts are implementation deliverables. They do not replace the protocol meaning defined by SCP.

API and Integration Surface

SCS should expose implementation surfaces that realize the protocol capabilities, for example:

1. task admission and task-state inspection endpoints
2. result, transcript, proof, or evidence retrieval endpoints
3. challenge submission and challenge-status surfaces
4. reward and finalized-accounting read surfaces
5. payout-intent or payout-batch inspection surfaces
6. internal module-to-module queues or event streams for semantic, execution, verification, and settlement handoff

Exact route shape may vary by implementation, but the surface must preserve the same protocol semantics.

Persistence Domains

To realize the revised SCP, SCS should persist at least the following domains:

1. task admission state and task lifecycle events
2. semantic namespace data, including domains, canonical attributes, and candidate-evolution artifacts
3. query projection data, including query attributes and audience-index records
4. feature and model-training data, including training manifests and model artifacts where policy allows
5. execution transcripts, result bundles, and proof references
6. verification decisions, evidence references, and challenge-linked records
7. epoch definitions and window-scoped aggregation metadata
8. settlement candidate and finalized accounting context
9. reward allocations, adjustments, and downstream payout-intent records
10. reconciliation, audit, and operational trace records

Semantic Namespace Persistence

Because the revised SCP explicitly models domain-governed semantic evolution, SCS should maintain implementation stores for:

1. domain hierarchy and domain status
2. canonical attribute lifecycle state
3. query attribute definitions and projection-governance metadata
4. local attribute pools and privacy-safe candidate summaries
5. candidate aggregation windows and promotion workflow records
6. compatibility and replacement metadata under semantic_version

These stores allow the system to realize semantic growth without silently mutating protocol meaning.

Query Projection and Audience Index Persistence

When an implementation supports scalable eligibility retrieval, marketing activation, or other governed audience-selection workflows, SCS should maintain implementation stores for:

1. query projection definitions derived from semantic governance
2. audience-index rows or postings keyed by governed query signal
3. projection lineage linking each indexed signal back to source commitment, record, or protected computation
4. policy metadata defining which actor classes and workflows may use each query projection
5. projection refresh, revocation, or expiry records where query windows are time-bound

These stores must remain downstream from Vault privacy boundaries. They are not replacements for canonical private records.

Feature, Training, and Model Persistence

When an implementation supports consumer-behavior training or other model-building workflows, SCS should maintain implementation stores for:

1. feature manifests describing which protected or derived signals may participate in training
2. feature snapshots, aggregates, or training-safe dataset manifests
3. training task definitions, version context, and authorization scope
4. model artifact metadata, model versions, and evaluation records
5. replayable training evidence, lineage, or audit records sufficient to reconstruct the governed training workflow

These stores should preserve the distinction between:

1. private source records that remain inside Vault or TEE boundaries
2. derived features or aggregates that are policy-approved for training use
3. model artifacts that become system-visible outputs of the training workflow

Replay and Idempotency Properties

The implementation must preserve:

1. replay-critical version and epoch context on persisted records
2. idempotent create behavior for externally retried requests
3. deterministic linkage between tasks, semantic resolution, execution artifacts, and verification decisions
4. append-only finalized accounting history for settlement and reward records
5. explicit adjustment and reconciliation records instead of silent mutation

Settlement, Reward, and Payout Records

The revised SCP places settlement and reward inside protocol accounting, while payout remains downstream.

SCS should therefore distinguish clearly between:

1. settlement candidate context
2. finalized settlement context
3. reward-accounting records derived from finalized state
4. payout-intent, payout-batch, and reconciliation records created after finalized accounting exists

This distinction must remain visible in schemas, persistence domains, and integration boundaries.

Chain and Payout Integration Profiles

SCS may realize downstream payout through one or more chain-specific or treasury-specific integration profiles.

An implementation profile should cover:

1. payout instruction batching from finalized reward records
2. signer or treasury authority isolation
3. confirmation tracking
4. retry and reconciliation behavior
5. explicit failure recording without rewriting finalized protocol accounting

Chain-specific realization may vary across deployments. The implementation profile must remain downstream from protocol truth.

Failure and Reconciliation

The system should detect and handle:

1. duplicate submissions
2. partial downstream effects
3. missing confirmations
4. reconciliation drift
5. semantic-registry mismatches across versions
6. epoch-window accounting inconsistencies

Corrections must be explicit through adjustment, reconciliation, or replay-safe recovery records.

Relationship to SCP

This document describes how protocol-facing data and integrations are realized in a system.

For the normative meaning of semantic objects, replay context, settlement state, and reward semantics, see:

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