SCP Core Spec

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

Purpose

This document defines the normative lifecycle and state semantics of SCP.

It answers:

1. how tasks move through the protocol
2. how challenge and settlement interact
3. what settlement candidate and finalized contexts mean
4. what a conforming contract boundary must preserve

Task Lifecycle

The canonical task lifecycle is:

1. accepted
2. resolving
3. dispatched
4. verifying
5. awaiting_settlement
6. completed
7. challenged
8. rejected
9. timed_out

These states define protocol meaning, not a particular process layout.

Challenge Lifecycle

The canonical challenge lifecycle is:

1. opened
2. reviewing
3. confirmed
4. not_confirmed
5. approved
6. closed_without_penalty
7. penalty_recorded
8. reopened

Challenge evidence must be replayable and linked to the relevant task, verification, and settlement context.

Settlement Lifecycle

The canonical settlement lifecycle is:

1. collecting
2. verifying_inputs
3. candidate_ready
4. finalizing
5. finalized
6. failed

Settlement Candidate Context

Candidate context is used for:

1. challenge opening
2. settlement readiness
3. fraud evidence linkage

Finalized Settlement Context

Finalized context is used for:

1. reward finalization
2. protocol audit
3. payout preparation
4. irreversible accounting references

Determinism and Replay

Determinism requires:

1. fixed object semantics
2. fixed sort and hash rules
3. stable epoch mapping
4. version-aware parameter resolution
5. replayable evidence and accounting artifacts

Parameter resolution must be a deterministic function of:

1. epoch_id
2. semantic_version
3. policy_version

Epoch Model

Epoch is a stable window identifier used to group protocol events into a replayable control context.

It is not the prerequisite for raw data upload or for the mere existence of a task.

It primarily governs:

1. settlement windows
2. reward calculation windows
3. payout batching windows
4. local attribute candidate aggregation windows
5. replay partitioning where batching matters

It does not primarily govern:

1. raw data upload into Vault
2. whether a task can be formed
3. whether semantic resolution can begin
4. whether a single authorized execution can start

Core Epoch Fields

An epoch definition should preserve at least:

1. epoch_id
2. open_at
3. close_at
4. status
5. semantic_version_set
6. policy_version_set
7. settlement scope metadata
8. reward scope metadata
9. candidate aggregation scope metadata

Epoch States

The canonical epoch state model is:

1. open
2. closing
3. closed

At most one epoch should normally be open for a given governed scope.

Open Condition

A new epoch opens when:

1. the previous epoch has reached closed, or
2. the system is creating the initial bootstrap epoch

An open epoch is the active window for assigning later settlement, reward, and aggregation scope.

Closing Triggers

An open epoch should move to closing when one or more of the following occurs:

1. the configured maximum time window is reached
2. task, verification, settlement, or aggregation volume reaches the configured threshold
3. governance or policy requires a window boundary, such as version transition or controlled maintenance

This is a mixed trigger model:

1. time may close the window
2. capacity may close the window
3. governance may close the window

Close Condition

An epoch moves from closing to closed when:

1. the settlement scope for that epoch is frozen
2. the reward scope for that epoch is frozen
3. the candidate aggregation scope for that epoch is frozen
4. unresolved items have either been resolved for the current epoch or explicitly deferred under policy

Once an epoch is closed:

1. new events must not be newly assigned to it
2. replay should reconstruct the same epoch membership
3. downstream reward, payout, and candidate aggregation can proceed against a stable window boundary

Layer-Level Norms

The protocol requires the following logical responsibilities:

1. Application validates client intent and produces protocol-valid tasks
2. Coordination orchestrates task progression and settlement handoff
3. Semantic resolves meaning under semantic_version
4. Data preserves canonical records and Commitment references
5. Execution performs authorized computation
6. Verification validates correctness and integrity before settlement
7. Settlement anchors verified state and publishes finalized accounting context

These are protocol roles. They do not mandate one process per role.

Seven Protocol Layers

The seven layers remain a core protocol abstraction in SCP.

They define semantic boundaries between responsibilities, not a mandatory deployment topology.

1. Application Layer

Purpose:

• validate client intent
• validate caller identity and authorization context
• produce protocol-valid TaskEnvelope objects

Protocol inputs:

• caller context
• authorization context
• query intent
• requested policy scope

Protocol outputs:

• TaskEnvelope
• client-visible acceptance or rejection status
• protocol-visible validation errors

Protocol invariants:

• deterministic rejection for invalid input
• no private plaintext leakage through intake responses
• no task admission without required replay tuple context

2. Coordination Layer

Purpose:

• orchestrate task progression
• manage handoff between semantic, execution, verification, and settlement stages
• track canonical protocol state transitions

Protocol inputs:

• admitted tasks
• semantic context
• execution results
• verification decisions
• challenge events

Protocol outputs:

• execution assignments
• tracked task state
• settlement submissions
• challenge openings or state transitions

Protocol invariants:

• no bypass around verification before settlement finalization
• no out-of-order state transitions
• no hidden transition that escapes protocol audit

3. Semantic Layer

Purpose:

• resolve canonical meaning under semantic_version
• bind tasks to registry-compatible semantic references
• determine compatibility before execution proceeds

Protocol inputs:

• canonicalized semantic candidates
• registry state
• semantic_version

Protocol outputs:

• SemanticResolutionResult
• compatibility decisions
• registry-compatible references

Protocol invariants:

• deterministic semantic interpretation
• monotonic Scope
• no execution on unresolved or incompatible semantic context

4. Data Layer

Purpose:

• preserve canonical private records
• expose authorized record material for execution
• maintain cryptographic linkage through Commitment references

Protocol inputs:

• canonical records
• authorization context
• execution-bound access requests
• key context where applicable

Protocol outputs:

• encrypted storage objects
• Commitment references
• authorized record material

Protocol invariants:

• Commitment = SHA256(Serialize(CR))
• no plaintext escape outside authorized Vault or TEE boundaries
• auditable access linkage between task, authorization, and record usage

5. Execution Layer

Purpose:

• perform authorized computation
• produce deterministic, proof-linked execution output
• preserve auditable data access context

Protocol inputs:

• ExecutionAssignment
• semantic context
• epoch context
• authorized record material

Protocol outputs:

• ExecutionResultBundle
• transcript references
• proof references where required

Protocol invariants:

• deterministic execution under equal inputs and replay tuple
• no unauthorized cross-Vault access
• no result admitted without auditable execution context

6. Verification Layer

Purpose:

• validate correctness and integrity before settlement
• accept, reject, or challenge execution output
• preserve replayable evidence

Protocol inputs:

• result bundles
• proof references
• replay context
• evidence inputs

Protocol outputs:

• VerificationDecision
• evidence references
• accepted, challenged, or rejected verdicts

Protocol invariants:

• no settlement finalization without accepted verification
• challenge evidence must be replayable
• verification must not rewrite execution history

7. Settlement Layer

Purpose:

• anchor verified state
• assemble root context
• publish candidate and finalized accounting context

Protocol inputs:

• accepted verification outputs
• root inputs
• settlement metadata
• challenge state relevant to finalization

Protocol outputs:

• settlement candidate context
• finalized settlement context
• settlement events
• SettlementRoot

Protocol invariants:

• deterministic root composition
• append-only finalized history
• candidate context may support challenge opening, while finalized context is required for irreversible accounting references

Domain Model

Domain is the semantic namespace and governance boundary within which canonical meaning is defined.

It exists so that:

1. semantic interpretation has a stable namespace
2. canonical attributes have an explicit ownership boundary
3. compatibility and deprecation are governed within a declared semantic scope

Domain Layering

The protocol recognizes the following semantic layering:

1. global domain: shared protocol-wide semantic governance boundary
2. domain family: a higher-level namespace grouping related domains
3. concrete domain: the direct namespace in which canonical attributes are registered and resolved
4. optional sub-domain: a narrower namespace where policy explicitly allows finer partitioning

Implementations may realize these layers differently, but protocol semantics must preserve the same hierarchy.

Domain Responsibilities

A domain is responsible for:

1. defining the namespace in which canonical attributes live
2. constraining compatibility and evolution under semantic_version
3. determining whether cross-domain references are allowed, rejected, or mediated
4. providing the semantic boundary against which resolution and governance decisions are evaluated

Core Domain Fields

A protocol-visible domain definition should preserve at least:

1. domain_id
2. parent_domain_id where applicable
3. domain_version
4. semantic_version
5. status

Domain Status

The canonical domain status model is:

1. proposed
2. registered
3. active
4. deprecated
5. retired

Only active domains, and deprecated domains where compatibility policy allows, may participate in new semantic resolution.

Canonical Attribute Model

CanonicalAttribute is a protocol object representing a standardized semantic attribute within a declared domain.

It is not free-floating. Every canonical attribute belongs to a domain.

Canonical Attribute Identity

Protocol identity should preserve at least:

1. attribute_id
2. domain_id
3. semantic_version

Where lifecycle or compatibility matters, the object should also preserve:

1. scope
2. status
3. effective_from
4. deprecated_from where applicable
5. retired_from where applicable
6. supersedes or replacement reference where applicable

Canonical Attribute Rules

The protocol requires:

1. every canonical attribute to belong to exactly one declared domain at a given semantic point
2. attribute compatibility to be interpreted relative to domain and semantic_version
3. replacement to be explicit rather than implicit when an attribute is superseded
4. semantic resolution to determine domain before selecting canonical attribute meaning

Canonical Attribute Lifecycle

The canonical lifecycle is:

1. proposed
2. registered
3. active
4. deprecated
5. retired
6. superseded

Lifecycle Meaning

• proposed: recognized by governance workflow but not protocol-usable
• registered: recorded in the namespace but not yet active for the target semantic window
• active: eligible for semantic resolution and new task use
• deprecated: still compatibility-visible but not preferred for new semantic authoring
• retired: not eligible for new task resolution
• superseded: replaced by an explicit successor attribute under governed compatibility rules

Lifecycle Rules

The protocol requires:

1. only active, and policy-permitted deprecated, attributes may resolve for new task admission
2. retired attributes must not be selected for new task resolution
3. lifecycle transitions to be bound to declared semantic governance and semantic_version
4. superseded attributes to point explicitly to the replacement path where one exists
5. equal task input and equal semantic_version to produce equal attribute resolution outcomes

Canonical Attribute Resolution Flow

For protocol purposes, canonical attribute resolution follows this logical flow:

1. determine the target domain from task scope, semantic references, and policy context
2. validate that the domain is eligible under the requested semantic_version
3. identify candidate canonical attributes within that domain
4. reject candidates whose lifecycle state is not resolution-eligible
5. apply compatibility and replacement rules
6. produce deterministic semantic references in SemanticResolutionResult

Resolution Consequences

The protocol requires:

1. unresolved domain or attribute state to block progression into execution
2. ambiguous domain or attribute mapping to be rejected rather than guessed
3. domain retirement or attribute retirement to affect only the semantic windows governed by the relevant versioning rules
4. replay of the same task under the same semantic inputs to reconstruct the same domain and canonical attribute selection

Semantic Attribute Layers

For protocol design purposes, semantic objects may appear in three related layers:

1. CanonicalAttribute, which defines protocol-recognized semantic truth
2. QueryAttribute, which defines governed query projections for audience selection, retrieval, and related query work
3. LocalAttribute, which remains inside a Vault or local semantic boundary until policy allows further projection or promotion

These layers are related, but they do not have the same purpose.

Layer Responsibilities

The protocol expects the layers to remain distinct:

1. canonical attributes answer what a record means under protocol truth
2. query attributes answer which governed query signals may be projected for cross-Vault retrieval, audience selection, or related governed query workflows
3. local attributes answer which unresolved or local-only semantics may remain private while still supporting future evolution

Layer Ordering

The normal semantic ordering is:

1. local or raw semantic material may first appear inside a Vault
2. canonical resolution may determine stable protocol meaning for the task
3. query projections may be derived from canonical or policy-permitted local material for governed retrieval workflows

This means a field may be useful for query, but still remain canonical-first in semantic meaning.

Query Attribute Model

QueryAttribute is a governed semantic object representing a query-safe projection derived from protected records for audience selection, eligibility filtering, retrieval, or related governed query work.

It is not a replacement for CanonicalAttribute, and it does not redefine protocol truth.

Query Attribute Identity

Protocol identity should preserve at least:

1. query_attribute_id
2. domain_id
3. semantic_version

Where governance, privacy, or compatibility matters, the object should also preserve:

1. status
2. derivation_rule_ref
3. query_granularity
4. privacy_class
5. allowed_usage_scope

Query Attribute Rules

The protocol requires:

1. every query attribute to belong to a declared domain or governed query namespace
2. query projections to be derived under explicit policy rather than inferred silently
3. query attributes to remain distinguishable from canonical semantic truth
4. query projection compatibility to remain version-aware under semantic_version
5. reconstructable raw private values not to be emitted merely because a query projection exists

Query Attribute Lifecycle

The canonical lifecycle is:

1. proposed
2. registered
3. active
4. restricted
5. deprecated
6. retired

Lifecycle meaning:

• proposed: recognized for governance review but not query-usable
• registered: defined in the namespace but not yet active for the target query window
• active: eligible for governed query projection and retrieval workflows
• restricted: query-usable only under narrower policy or actor scope
• deprecated: still compatibility-visible but not preferred for new query design
• retired: no longer eligible for new projection or query use

Query Projection Constraints

The protocol requires:

1. projection to occur downstream from Vault privacy boundaries
2. query-safe projections to preserve auditable linkage back to source commitments or protected records
3. query indexes to carry only the minimum governed signal needed for retrieval
4. audience-selection or campaign-eligibility work not to rely on silently changing query semantics
5. replay under the same semantic and policy inputs to reconstruct the same query interpretation

Local Attribute Pool

LocalAttribute is a local semantic artifact that has not yet been admitted as a protocol-recognized canonical attribute.

It may exist inside a Vault or local semantic boundary, but it is not by itself a cross-protocol semantic truth.

Local Pool Purpose

The local attribute pool exists so that implementations can:

1. accumulate unresolved or locally meaningful attributes
2. measure frequency, stability, and mapping confidence over time
3. produce privacy-preserving candidate signals for later promotion

Local Pool Rules

The protocol requires:

1. local attributes to remain local until promotion preconditions are met
2. raw private values or reconstructable sensitive semantic material not to be emitted directly for cross-Vault aggregation
3. local pool records to preserve enough metadata to support later audit and promotion review

Minimum Local Signals

A local pool entry should preserve at least:

1. local attribute identifier
2. candidate domain hint
3. local occurrence frequency
4. local stability indicators across epochs
5. mapping confidence against existing canonical attributes where applicable
6. privacy-safe feature summary or evidence summary

Cross-Vault Candidate Aggregation

The protocol allows local pools to contribute to a cross-Vault candidate pool, but only through privacy-preserving candidate summaries.

Aggregation Window

The default promotion aggregation window is:

1. every 10 epochs for regular candidate formation

Policy may allow:

1. every 5 epochs for high-activity domains
2. exceptional governance-triggered proposal outside the normal window

Per-epoch local accumulation is allowed, but per-epoch global promotion is not the default protocol path.

Aggregation Output

Cross-Vault aggregation must produce:

1. LocalAttributeCandidate summaries
2. candidate domain binding
3. coverage, frequency, and stability indicators
4. compatibility, conflict, or alias signals relative to existing canonical attributes

It must not directly produce an active canonical attribute.

Aggregation Constraints

The protocol requires:

1. cross-Vault aggregation to exchange candidate summaries rather than raw private local attributes
2. candidate formation to be auditable at the evidence-summary level
3. aggregation to remain downstream from Vault privacy boundaries

Promotion to Canonical Attribute

The canonical promotion path is:

1. local attribute
2. local attribute pool
3. LocalAttributeCandidate
4. proposed canonical attribute
5. registered
6. active

Promotion Preconditions

A candidate should not be promoted unless protocol policy confirms at least:

1. sufficient cross-Vault coverage or justified governance exception
2. stability across the required epoch window
3. clear domain binding
4. no unresolved conflict with existing canonical attributes, or an explicit alias/replacement declaration
5. replayable evidence summary supporting the promotion decision

Promotion Consequences

The protocol requires:

1. local attributes to remain local when promotion thresholds are not met
2. candidate aggregation to be a proposal mechanism, not an automatic semantic truth generator
3. new canonical attributes to enter the normal lifecycle of proposed -> registered -> active
4. conflict resolution to be governed explicitly rather than inferred silently

Contract Boundary

Conforming implementations must expose protocol coverage for at least:

1. task and semantic messages
2. execution and verification messages
3. settlement messages
4. reward records
5. payout instructions and events

The current canonical source of truth is the Markdown specification set. Machine-readable schema artifacts are implementation deliverables defined by SCS.

Canonical Error Families

Protocol-visible error families include:

1. SCHEMA_*
2. VERSION_*
3. AUTH_*
4. POLICY_*
5. EXECUTION_*
6. PROOF_*
7. VERIFY_*
8. SETTLEMENT_*
9. REWARD_*
10. PAYOUT_*
11. GOVERNANCE_*
12. INTERNAL_*