SCP Core Spec

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

Purpose

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

Canonical protocol terms used here follow SCP Protocol Overview.

It answers:

1. how the protocol is structured and what each component does
2. how tasks move through the protocol, including classification, composition, and iteration
3. how semantic meaning is defined, resolved, and evolved
4. how consent, authorization, and privacy budget protect private data
5. how multi-Vault coordination and composite tasks extend the basic task model
6. how challenge, settlement, and result delivery finalize protocol outcomes
7. what a conforming contract boundary must preserve

---

Part 1: Protocol Architecture

3 Planes + 2 Services

The protocol architecture uses a 3 Planes + 2 Services model.

The three planes represent the sequential task pipeline. Each plane has a clear trust boundary and handoff contract with the next. The two services are cross-cutting: they are accessed by all three planes but owned by neither.

The rationale:

1. a "layer" implies encapsulation (each layer wraps the one below, as in OSI). SCP's responsibilities are a sequential pipeline, not nested abstractions
2. Data and Governance are genuinely cross-cutting: accessed by multiple pipeline stages, with independent lifecycle and sovereignty concerns

Admission Plane

The Admission Plane is the protocol's public-facing entry point. It receives external requests, validates them, and produces a fully-formed TaskEnvelope that all downstream processing can rely on without re-validation.

Subsystems:

1. Identity and Authorization: validate caller identity, verify authorization context against Vault-level permissions
2. Consent Verification: verify data-subject consent for personally attributable records within the declared usage scope
3. Semantic Resolution: resolve canonical meaning under semantic_version, bind to registry-compatible references, validate derivation rules and attribute compositions
4. Privacy Budget Reservation: reserve estimated privacy budget using the reserve-commit model, reject tasks that would exceed available budget
5. TaskEnvelope Assembly: assemble the immutable TaskEnvelope with all validated fields

Protocol boundary:

• entry: external request from a caller with identity, intent, and authorization
• exit: a validated TaskEnvelope, or a deterministic rejection with protocol error

Invariants:

1. deterministic rejection for invalid input
2. no private plaintext leakage through admission responses
3. no TaskEnvelope produced without: valid identity, valid authorization, valid consent (where applicable), resolved semantics, reserved privacy budget, and bound policy version
4. semantic resolution is deterministic: equal input and equal semantic_version produce equal SemanticResolutionResult
5. cross-domain derivation requires explicit cross_domain_policy validation before the TaskEnvelope is assembled

Execution Plane

The Execution Plane receives a validated TaskEnvelope and produces an ExecutionResultBundle with associated evidence. It manages the full complexity of multi-Vault coordination, composite iteration, and TEE-based computation.

Subsystems:

1. Task Orchestration: drive the task state machine through the canonical state transition rules, manage handoffs between subsystems
2. Multi-Vault Coordination: fan out to participating Vaults, track per-Vault execution slices, enforce quorum requirements
3. Computation: perform authorized computation inside Vault or attested TEE boundary, produce deterministic proof-linked output
4. Secure Aggregation: combine per-Vault slice results inside a trusted aggregation environment, enforce cardinality thresholds at the aggregate level
5. Composite Iteration Control: manage sub-task sequencing for iterative tasks, track convergence, control round progression

Protocol boundary:

• entry: a validated TaskEnvelope from the Admission Plane
• exit: an ExecutionResultBundle with proof references, attestation reports, and privacy budget consumption records

Invariants:

1. deterministic execution: equal inputs and equal replay tuple produce equal output commitment
2. no unauthorized cross-Vault data access
3. no plaintext exposure to the coordination subsystem — coordination sees only commitments and metadata
4. TEE execution must produce valid AttestationReport where policy requires it
5. privacy budget consumption must not exceed reservation beyond policy-defined tolerance
6. per-Vault slice results must meet local cardinality thresholds before leaving the Vault boundary
7. aggregation must not be performed by the task submitter
8. composite iteration must respect the iteration policy declared at admission

Settlement Plane

The Settlement Plane receives execution results and produces finalized protocol outcomes. It validates results, manages the challenge lifecycle, and anchors irreversible accounting.

Subsystems:

1. Result Verification: validate execution output against task-class-specific acceptance criteria
2. Challenge Lifecycle: manage challenge opening, evidence submission, adjudication, and resolution
3. Reward Accounting: calculate per-actor reward shares based on finalized settlement context, policy version, and actor staking status (staked vs unstaked Data Producers receive differentiated reward rates as defined by protocol economics)
4. Penalty Enforcement: apply penalties for protocol violations detected during verification or challenge
5. Payout Execution: trigger irreversible payout based on finalized reward accounting

Protocol boundary:

• entry: ExecutionResultBundle with evidence chain from the Execution Plane
• exit: SettlementRoot with finalized accounting, reward distribution, and penalty records

Invariants:

1. no settlement finalization without accepted verification
2. challenge evidence must be replayable
3. verification must not rewrite execution history
4. deterministic root composition: equal inputs produce equal SettlementRoot
5. append-only finalized history — no retroactive modification
6. candidate context may support challenge opening; finalized context is required for irreversible accounting

Data Sovereignty Service

The Data Sovereignty Service is a cross-cutting service accessed by all three planes. It is not a pipeline stage — it is a persistent service that manages the lifecycle of private data independently of any single task.

Responsibilities:

1. Record Storage and Commitment: preserve canonical private records, maintain Commitment = SHA256(Serialize(CR)) linkage, manage encrypted storage
2. Consent Management: maintain consent records per data subject, validate consent references against usage scope declarations
3. Privacy Budget Ledger: maintain PrivacyBudgetLedger per data subject per usage scope, process reservation and commitment operations
4. Vault Access Control: enforce Vault-level authorization policies, provide authorized record material only after consent and authorization verification

Access pattern:

• Admission Plane: reads consent records and privacy budget availability to validate admission
• Execution Plane: reads authorized record material during computation, commits privacy budget consumption
• Settlement Plane: reads privacy budget records for verification, may trigger budget-related penalties

Invariants:

1. no plaintext escape outside authorized Vault or TEE boundaries
2. no record access without valid consent for the declared usage scope
3. auditable access linkage between task, authorization, consent, and record usage
4. privacy budget operations follow the reserve-commit model
5. the service is authoritative for all data sovereignty decisions — no plane may override its access control

Governance Service

The Governance Service is a cross-cutting service that manages protocol configuration, actor lifecycle, and collective decision-making. Like the Data Sovereignty Service, it is accessed by all planes but owned by none.

Responsibilities:

1. Policy Version Management: maintain policy version lifecycle (draft → active → deprecated → retired), enforce epoch-boundary transitions, ensure no retroactive application
2. Epoch Management: manage epoch lifecycle (open → closing → closed), assign tasks and sub-tasks to epochs, manage cross-epoch composite task accounting
3. Actor Registry and Staking: maintain actor identities, role bindings, three-tier staking requirements (S_master for master nodes, S_enterprise for enterprise nodes, S_producer for optionally staking Data Producers), and slashing conditions
4. Governance Proposals: manage governance proposals for policy changes, attribute promotion, challenge adjudication, and protocol upgrades

Access pattern:

• Admission Plane: reads active policy version and epoch state for task validation
• Execution Plane: reads actor registry for executor assignment, reads epoch for settlement assignment
• Settlement Plane: reads policy version for reward/penalty calculation, reads actor staking status for slashing and differentiated reward rates

Invariants:

1. at most one policy version is active for a given scope at any time
2. policy version transitions occur only at epoch boundaries
3. tasks are evaluated under the policy version active at their admission time, regardless of subsequent changes
4. governance decisions require the quorum and process defined in the active policy version

---

Part 2: Task Model

This part defines the protocol's primary work unit: the task. It covers how tasks are classified, what they contain, and how they move through the protocol.

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.

State Transition Rules

The following transitions are the only legal protocol transitions. Any transition not listed here is a protocol violation.

Normal forward path:

1. accepted → resolving: task enters semantic resolution
2. resolving → dispatched: semantic resolution succeeds, task is assigned for execution
3. dispatched → verifying: execution completes, result enters verification
4. verifying → awaiting_settlement: verification accepts the result
5. awaiting_settlement → completed: settlement finalizes

Rejection and failure paths:

1. accepted → rejected: admission-time validation failure discovered after initial acceptance
2. resolving → rejected: semantic resolution fails (unresolved domain, incompatible attributes)
3. dispatched → rejected: execution produces invalid or policy-violating output
4. verifying → rejected: verification rejects the result
5. accepted → timed_out: task exceeds admission-to-dispatch timeout
6. dispatched → timed_out: execution exceeds dispatch-to-result timeout
7. verifying → timed_out: verification exceeds configured timeout

Challenge path:

1. verifying → challenged: verifier or governance actor opens a challenge against the result
2. awaiting_settlement → challenged: challenge opened against a result that has not yet finalized
3. challenged → awaiting_settlement: challenge resolved as not_confirmed or closed_without_penalty, task returns to settlement path
4. challenged → rejected: challenge resolved as approved with penalty, task is rejected

Terminal states:

1. completed, rejected, and timed_out are terminal. No further transitions are permitted from these states.

Transition Invariants

The protocol requires:

1. every transition to be recorded as an auditable protocol event with timestamp and actor reference
2. no transition to skip intermediate states (e.g., accepted cannot jump directly to verifying)
3. the replay of a task's transition history to reconstruct the same sequence under the same inputs
4. challenged to be the only state that can interrupt the forward path and create a loop

Task Classification

The protocol recognizes distinct task classes because different classes impose different protocol constraints on execution, verification, privacy, and resource accounting.

Canonical Task Classes

1. parse: single-record interpretation within one Vault boundary, such as receipt OCR or document extraction
2. query: governed retrieval, filtering, or audience selection that may span multiple Vaults through privacy-preserving projections
3. compute: stateless or bounded computation against authorized record material, such as eligibility evaluation or feature derivation
4. train: iterative model-training work that may require multiple execution rounds and cross-Vault feature aggregation

Classification Rules

The protocol requires:

1. every admitted task to carry an explicit task_class
2. task_class to be fixed at admission and immutable for the lifetime of the task
3. verification strategy, privacy constraints, and reward accounting to be parameterized by task_class
4. policy to define which task_class values require TEE execution, multi-Vault coordination, or privacy budget consumption

Class-Specific Protocol Constraints

For query class tasks:

1. execution must operate on query-safe projections or authorized Vault-side evaluation rather than unrestricted plaintext export
2. result cardinality constraints such as audience caps must be enforced as protocol invariants, not advisory limits
3. privacy budget consumption must be recorded per query execution

For compute class tasks:

1. computation must be bounded: the task must declare maximum resource consumption (time, memory, or work units) at admission
2. execution must be deterministic: equal inputs and equal replay tuple must produce equal output
3. unlike query, the output is a derived value or artifact rather than a filtered record set
4. unlike train, the execution is single-pass and non-iterative

For train class tasks:

1. the task may be realized as a composite task with multiple iterative rounds
2. intermediate artifacts such as gradients or partial model updates are protocol-visible only as commitment references, not as plaintext
3. convergence or quality thresholds defined at admission become verification acceptance criteria

TaskEnvelope

TaskEnvelope is the canonical protocol object produced by the Admission Plane upon successful task admission. It is the primary input to all downstream protocol processing.

TaskEnvelope Fields

A TaskEnvelope must preserve at least:

1. task_id: unique protocol-assigned task identity
2. task_class: one of parse, query, compute, train
3. caller_context: identity and role of the task submitter
4. authorization_context: Vault-level authorization references
5. consent_references: list of consent references for personally attributable records, where applicable
6. semantic_version: the semantic version governing this task
7. policy_version: the policy version governing this task
8. epoch_id: the epoch to which this task is assigned for settlement purposes
9. attribute_composition: the declared AttributeComposition for multi-attribute tasks, or null for single-attribute tasks
10. derivation_rule_refs: list of DerivationRule references used by the task
11. budget_lock_ref: reference to the locked monetary budget for this task, or null for parse tasks (which are free for the Data Producer under the protocol economics model)
12. privacy_budget_reservation: reserved privacy budget for this task
13. coordination_envelope: for multi-Vault tasks, the coordination envelope; null for single-Vault tasks
14. iteration_policy: for composite tasks, the iteration policy; null for atomic tasks
15. admission_timestamp: protocol-assigned admission time
16. task_timeout: maximum allowed time from admission to completion

TaskEnvelope Invariants

The protocol requires:

1. every field in the TaskEnvelope to be immutable after admission
2. the TaskEnvelope to be the authoritative source for all downstream protocol decisions about this task
3. the TaskEnvelope to be included in the task's replay tuple
4. no downstream plane or service to override or extend the TaskEnvelope's declared constraints

---

Part 3: Semantic Model

This part defines how meaning is established within the protocol. It covers the namespace hierarchy (domains), the attribute system (canonical, query, and local attributes), and how attributes evolve over time.

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 defines protocol-recognized semantic truth.

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

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

Where direct query use is relevant, the object should also preserve:

1. directly_queryable: whether this canonical attribute may be used in query projections without creating a separate QueryAttribute
2. default_query_granularity: the default QueryGranularity applied when the attribute is queried directly
3. default_privacy_class: the default privacy classification applied when the attribute is queried directly

Directly Queryable Canonical Attributes

When directly_queryable is true, the protocol allows this canonical attribute to participate in governed query workflows without requiring a separate QueryAttribute object. This avoids redundant 1:1 mirroring for attributes where the canonical value is already query-safe at a governed granularity.

The protocol requires:

1. directly_queryable to be set explicitly during attribute registration, not inferred
2. direct query use to apply the default_query_granularity and default_privacy_class declared on the canonical attribute
3. tasks requiring non-default granularity, custom derivation, or cross-domain composition to use a separate QueryAttribute with an explicit DerivationRule
4. privacy budget consumption to apply equally whether a query uses a directly queryable canonical attribute or a separate query attribute

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
5. directly_queryable status to not change the canonical truth of the attribute, only its availability for query projection

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:

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:

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

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_id: reference to the DerivationRule that produces this query attribute
3. query_granularity: a structured QueryGranularity object defining the projection resolution
4. privacy_class
5. allowed_usage_scope

Query Granularity Model

QueryGranularity is a structured protocol object that defines the resolution at which a query attribute exposes information. Granularity directly affects privacy: coarser granularity discloses less and consumes less privacy budget.

A QueryGranularity should preserve at least:

1. temporal_resolution: the time precision of the projection, one of exact, day, week, month, quarter, year
2. spatial_resolution: the geographic precision, one of exact, district, city, region, country
3. numeric_resolution: for numeric values, the bucketing specification (bucket boundaries and width) or null for non-numeric attributes
4. categorical_resolution: for categorical values, one of exact, group, binary

The protocol requires:

1. query granularity to be fixed at query attribute registration and immutable unless the attribute is superseded
2. finer granularity to require higher privacy_class and greater privacy budget consumption
3. granularity to be a factor in deterministic replay: equal granularity and equal input must produce equal projection output

Derivation Rule Model

DerivationRule is a protocol object that formally defines how a QueryAttribute is derived from one or more source attributes.

Derivation rules exist because the relationship between canonical truth and query projection must be explicit, auditable, and deterministic to support replay and privacy guarantees.

Derivation Rule Identity

A derivation rule should preserve at least:

1. rule_id
2. source_attributes: a list of source references, each specifying domain_id and attribute_id
3. transform_type: the category of transformation applied, one of passthrough, bucket, hash, boolean, aggregate, threshold, composite
4. transform_params: parameters specific to the transform type (bucket boundaries, hash method, threshold value, aggregation function, etc.)
5. output_type: the value type of the derived query attribute
6. semantic_version
7. privacy_impact_epsilon: the estimated per-execution privacy cost of this derivation

Derivation Rule Types

The protocol recognizes the following transform types:

1. passthrough: the source canonical value is projected without transformation, subject only to granularity coarsening
2. bucket: the source value is mapped to a discrete range (e.g., amount ¥42.50 becomes range ¥20-50)
3. hash: the source value is replaced by a cryptographic hash for linkage without disclosure
4. boolean: the source value is reduced to a true/false signal (e.g., "has purchased" rather than purchase details)
5. aggregate: multiple source records are combined into a summary statistic (e.g., count, sum, average)
6. threshold: the source value is compared against a boundary to produce a binary or categorical output (e.g., "purchased within last 30 days")
7. composite: multiple source attributes are combined through a defined function

Cross-Domain Derivation

When a derivation rule references source attributes from multiple domains, additional constraints apply:

1. every referenced domain must be active or policy-permitted deprecated
2. each cross-domain reference must carry an explicit cross_domain_policy of allowed, mediated, or denied
3. mediated cross-domain references require a declared mediation_authority (a governance actor authorized to approve the cross-domain binding)
4. cross-domain derivation rules must be registered in the governance workflow before they can be used for query attribute creation

Derivation Rule Requirements

The protocol requires:

1. every QueryAttribute that is not derived from a directly_queryable canonical attribute to reference an explicit DerivationRule
2. derivation rules to be deterministic: equal source values, equal transform parameters, and equal granularity must produce equal output
3. derivation rules to be versioned under semantic_version and immutable once registered
4. derivation rule changes to require a new rule registration and a new query attribute, not in-place mutation
5. privacy_impact_epsilon to be used as the basis for privacy budget consumption when the derived query attribute is used in a task

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 an explicit DerivationRule 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
6. the DerivationRule to be auditable as part of any task evidence chain that uses the query attribute

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

Attribute Composition Semantics

Real-world queries and computations almost always combine multiple attributes. SCP defines attribute composition as a protocol-level concern because composition directly affects privacy risk.

Why Composition Matters

Individual attribute queries may each be safe, but their combination can narrow result sets enough to re-identify individuals. For example, querying "Singapore users" and "Luckin customers" independently may each return large sets, but their intersection may be small enough to compromise anonymity.

Composition Identity

An attribute composition should preserve at least:

1. composition_id
2. operator: the logical operation, one of AND, OR, NOT, FILTER, JOIN
3. operand_attributes: list of query_attribute_id or directly_queryable canonical attribute references that participate in the composition
4. combined_privacy_class: the privacy classification of the composed result, which must be at least as restrictive as the highest privacy_class among the operands
5. minimum_result_cardinality: the minimum number of records in the composed result below which the result must be suppressed or generalized

Composition Rules

The protocol requires:

1. every multi-attribute query or computation task to declare its attribute composition at admission
2. combined_privacy_class to be computed as the maximum of the operand privacy classes, or higher if policy requires
3. privacy budget consumption for a composed query to reflect the composition, not merely the sum of individual attribute costs
4. minimum_result_cardinality to be enforced at two levels:
   • per-Vault level: each Vault's slice result must meet local cardinality thresholds before leaving the Vault boundary
   • aggregation level: the aggregate result must meet global cardinality thresholds, enforced inside the aggregation TEE before the result is released
5. results below the threshold at either level to be suppressed or generalized before leaving the enforcement boundary
6. attribute composition to be recorded as part of the task replay tuple so that audit can reconstruct the same composition logic

Composition and Privacy Budget Interaction

The protocol requires:

1. composed queries to consume privacy budget once for the composition, not separately for each operand attribute
2. the privacy cost of a composition to be at least as high as the most expensive individual operand, and may be higher based on the operator and the number of operands
3. repeated identical compositions against the same data subjects to consume additional budget with each execution

Semantic Attribute Layers

Semantic objects appear in three related layers:

1. CanonicalAttribute: defines protocol-recognized semantic truth (what a record means)
2. QueryAttribute: defines governed query projections (which signals may be projected for retrieval)
3. LocalAttribute: remains inside a Vault or local semantic boundary until promotion (emerging semantics not yet canonical)

The normal ordering is:

1. local or raw semantic material first appears inside a Vault
2. canonical resolution determines stable protocol meaning
3. query projections are derived from canonical or policy-permitted local material for governed retrieval

A field may be useful for query but still remains canonical-first in semantic meaning.

Local Attribute Pool

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

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.

The default promotion aggregation window is every 10 epochs for regular candidate formation. Policy may allow every 5 epochs for high-activity domains, or exceptional governance-triggered proposal outside the normal window.

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.

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 Paths

The protocol recognizes two distinct promotion paths for local attributes, reflecting that an attribute may become useful for query before it is stable enough to be canonical truth.

Promotion to Vault-Scoped Query Attribute:

A local attribute may be promoted to a vault_scoped_query attribute when it is useful for Vault-internal queries but has not yet achieved the cross-Vault stability required for canonical status.

The vault-scoped query promotion path is:

1. local attribute
2. vault_scoped_query (a restricted QueryAttribute whose allowed_usage_scope is limited to the source Vault)

Promotion preconditions for vault-scoped query:

1. stability within the source Vault across at least the configured minimum epoch window
2. a declared derivation rule that produces a query-safe projection
3. a declared privacy class and granularity
4. Vault operator approval

Vault-scoped query attributes:

1. must not participate in cross-Vault query tasks
2. may participate in single-Vault tasks where the source Vault is also the executing Vault
3. may later be promoted to a full query attribute if the underlying local attribute achieves canonical promotion
4. carry the lifecycle of a standard query attribute but with allowed_usage_scope restricted to vault_local

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:

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:

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

---

Part 4: Data Protection

This part defines the three mechanisms that protect private data: consent and authorization (who may access), privacy budget (how much may be disclosed), and TEE (where computation happens).

Consent and Authorization

SCP distinguishes between two layers of authorization that must both be satisfied before data can participate in protocol work.

Vault-Level Authorization

Vault-level authorization governs which actors and task classes may access record material inside a Vault boundary.

The protocol requires:

1. every data access to carry an explicit authorization_context linking the requesting task to a Vault-recognized permission
2. Vault operators to enforce authorization independently of the coordination layer
3. authorization grants to be scoped by task_class, domain_id, actor_id, and optionally by time window or usage purpose
4. authorization state to be auditable and replayable

Data-Subject Consent

Data-subject consent governs whether the individual whose data is stored has agreed to a specific category of usage.

The protocol requires:

1. every task that accesses personally attributable records to carry a consent_reference linking the access to a recorded consent decision
2. consent to be scoped by usage purpose, such as personal_use, marketing, analytics, or training
3. consent to be revocable, with revocation taking effect for new task admission but not retroactively invalidating already-finalized settlements
4. consent state to be stored inside the Vault boundary and not exported as plaintext

Consent Lifecycle

The canonical consent state model is:

1. granted: the data subject has actively consented to the declared usage scope
2. withdrawn: the data subject has revoked consent, blocking new task admission for the affected scope
3. expired: the consent has reached its declared time limit

Consent and Task Interaction

The protocol requires:

1. task admission to verify consent status before accepting work that touches personally attributable records
2. consent withdrawal during task execution to not abort already-dispatched work, but to block future task admission for the same scope
3. consent status to be recorded as part of the task's replay tuple so that audit can confirm consent was valid at admission time

Privacy Budget and Guarantees

The protocol governs cumulative privacy exposure to prevent repeated queries or computations from gradually reconstructing private records.

Privacy Budget Model

A privacy budget is a protocol-tracked resource that bounds the cumulative information disclosed about a data subject or record set through protocol-authorized work.

The protocol requires:

1. every Vault to maintain a PrivacyBudgetLedger tracking cumulative disclosure per data subject, per usage scope
2. privacy budget to be parameterized by privacy_class as declared on query attributes and task admission policy
3. budget consumption to be recorded at execution time and committed as part of the task evidence chain

Budget Accounting Fields

A privacy budget entry should preserve at least:

1. subject_id or record_scope: the data subject or record set whose budget is being consumed
2. usage_scope: the declared purpose, such as marketing, analytics, or training
3. consumed_epsilon: the privacy loss incurred by this task, expressed in differential-privacy epsilon units where applicable
4. task_id: the task that caused the consumption
5. epoch_id: the epoch in which consumption occurred

Budget Enforcement Rules

The protocol uses a reserve-commit model to prevent race conditions between concurrent tasks:

1. at admission, the protocol reserves the estimated privacy budget for the task, reducing the available budget for subsequent admission checks
2. tasks that would exceed the remaining budget (after accounting for existing reservations) for any affected data subject are rejected at admission
3. at execution, the protocol commits the actual consumption, which may differ from the reservation within policy-defined tolerance
4. if actual consumption exceeds the reservation beyond tolerance, the task is flagged for governance review
5. if a task fails or is rejected before execution, the reservation is released, restoring the available budget
6. if a task fails after execution has begun, the reservation is committed at the estimated level, because execution may have already disclosed information
7. committed consumption is append-only and not reversible
8. budget replenishment occurs only at epoch boundaries under explicit governance policy, not automatically

Privacy Guarantees by Task Class

For query tasks:

1. audience-selection results must not allow the task submitter to determine whether a specific individual is in the result set, unless the individual's consent explicitly permits identifiable targeting
2. result cardinality below a policy-defined minimum threshold must cause the result to be suppressed or generalized

For train tasks:

1. per-round gradient or update contributions must be aggregated across a policy-defined minimum number of Vaults before release
2. model artifacts must not memorize or allow extraction of individual training records, verifiable through protocol-defined evaluation criteria

Budget and Consent Interaction

The protocol requires:

1. consent withdrawal to freeze the affected data subject's budget, preventing further consumption
2. budget state to be visible to the Vault operator and auditable by governance
3. budget exhaustion to not revoke already-finalized settlements but to block future task admission for the affected scope

TEE Trust and Attestation Requirements

SCP treats Trusted Execution Environments (TEE) as a protocol-recognized execution boundary alongside Vault boundaries. Because TEE provides hardware-enforced isolation, it requires distinct protocol-level trust rules.

TEE Role in the Protocol

TEE serves as:

1. a protected execution environment where authorized computation runs on private record material
2. an alternative to Vault-internal execution when computation must be performed by an actor that does not directly operate the source Vault
3. an environment that can provide cryptographic attestation that a specific computation ran on specific inputs inside a verified enclave

TEE Attestation Requirements

The protocol requires:

1. every TEE-executed task to carry an AttestationReport linking the execution to a verified enclave identity
2. AttestationReport to preserve at least: enclave identity, enclave measurement hash, platform identity, and freshness nonce
3. the verification subsystem to validate attestation before accepting TEE-executed results
4. attestation to be replayable as part of the task evidence chain

TEE and Vault Boundary Relationship

The protocol defines:

1. a Vault may delegate execution to a TEE when the task requires computation that the Vault operator cannot or chooses not to perform locally
2. record material transferred from Vault to TEE must be encrypted in transit and decrypted only inside the attested enclave
3. TEE must not retain record material after task execution completes
4. the protocol treats TEE as a temporary extension of the Vault privacy boundary, not as an independent data custodian

TEE Failure Handling

The protocol requires:

1. TEE platform failure during execution to result in timed_out for the affected task or sub-task
2. attestation failure to result in rejected at the verification subsystem
3. TEE side-channel vulnerabilities disclosed after settlement to be addressable through the challenge lifecycle
4. TEE platform revocation by the hardware vendor to block new task dispatch to affected enclaves under governance policy

When TEE Execution Is Required

The protocol does not mandate TEE for all task classes. Policy determines TEE requirements:

1. parse tasks on single-Vault data may execute inside the Vault without TEE
2. query tasks that evaluate cross-Vault eligibility should execute inside TEE when the computation touches record material from a Vault that the executor does not operate
3. compute and train tasks involving cross-Vault record material must execute inside attested TEE unless all participating Vaults explicitly permit non-TEE execution under policy

---

Part 5: Execution Model

This part defines how tasks execute in practice, covering the complexities of multi-Vault coordination and composite (iterative) tasks that extend the basic single-Vault, single-pass model.

Multi-Vault Task Coordination

Many platform capabilities require a single task to access records distributed across multiple independently governed Vaults. SCP defines the protocol semantics for such coordination.

When Multi-Vault Coordination Applies

Multi-Vault coordination is required when:

1. a query task must evaluate eligibility or selection criteria against records in more than one Vault
2. a compute task requires feature material from multiple Vault boundaries
3. a train task must aggregate gradients, features, or model updates derived from records in different Vaults

Single-Vault tasks, such as personal receipt parsing, do not require multi-Vault coordination.

Fan-Out and Aggregation Model

The protocol decomposes a multi-Vault task into:

1. a coordination envelope that carries the shared admission, semantic, and policy context
2. per-Vault execution slices that run independently inside each participating Vault boundary
3. a secure aggregation step that combines per-Vault results without exposing individual Vault plaintext

Coordination Envelope

A coordination envelope preserves:

1. parent_task_id
2. participating_vault_ids: the set of Vaults that must contribute
3. minimum_vault_quorum: the minimum number of Vaults that must complete for the result to be valid
4. aggregation_method: the protocol-recognized method for combining results, such as union, intersection, secure_sum, or federated_average
5. per_vault_timeout: the maximum time each Vault has to respond before the slice is treated as timed out

Per-Vault Execution Slice

Each execution slice:

1. follows the canonical task lifecycle independently within its Vault boundary
2. produces a SliceResultBundle containing only commitment references and privacy-safe outputs
3. does not expose plaintext to the coordination layer or to other Vaults

Secure Aggregation

The protocol requires:

1. aggregation to operate on privacy-safe slice outputs, not on raw Vault plaintext
2. the aggregation method to be fixed at task admission and auditable
3. aggregation to be deterministic: equal slice inputs and equal aggregation method must produce equal aggregate output
4. cardinality constraints such as audience caps to be enforced at the aggregation step where they span Vault boundaries

Aggregation Trust Model

Secure aggregation is a trust-critical step because the aggregator receives outputs from multiple Vaults. The protocol defines the following trust requirements:

Aggregation execution environment:

1. aggregation must execute inside one of: (a) an attested TEE, (b) a secure multi-party computation protocol where no single party sees all inputs, or (c) a homomorphic encryption scheme where aggregation operates on ciphertexts
2. TEE-based aggregation is the default and must carry an AttestationReport in the aggregation evidence
3. the choice of aggregation environment must be declared in the coordination envelope and is immutable for the task

Aggregation actor:

1. the aggregator is a protocol actor subject to the same staking, penalty, and governance rules as an Executor
2. the aggregator must not be the same entity as the task submitter, to prevent the requester from observing per-Vault outputs
3. the aggregator must not retain per-Vault slice outputs after producing the aggregate result

Aggregation evidence:

1. the aggregate result must carry a cryptographic proof or attestation linking the output to the declared inputs and method
2. verification must validate the aggregation evidence before accepting the aggregate result
3. aggregation evidence must be replayable as part of the task evidence chain

Partial Completion

The protocol requires:

1. if fewer Vaults than minimum_vault_quorum complete, the parent task must be rejected or timed_out
2. if the quorum is met but some Vaults did not respond, the aggregation proceeds over the available slices and the result carries an explicit partial_coverage flag
3. verification must evaluate whether partial coverage is acceptable under the task's admission policy

Multi-Vault Authorization

The protocol requires:

1. every participating Vault to independently verify authorization and consent before executing its slice
2. the coordination layer to not override per-Vault authorization decisions
3. a Vault that rejects authorization to reduce the available coverage without blocking other Vaults

Composite and Iterative Task Semantics

A composite task is a protocol-recognized task that is decomposed into ordered sub-tasks under a shared admission, authorization, and settlement context. Composite tasks exist because certain platform capabilities, notably distributed training and multi-stage computation, cannot be faithfully represented as a single atomic task lifecycle.

Composite Task Structure

A composite task preserves:

1. parent_task_id: the root task identity
2. sub_task_sequence: ordered list of sub-task identities
3. iteration_policy: rules governing how many rounds may execute and under what convergence or budget conditions
4. aggregation_rule: how sub-task results are combined into the parent result

Sub-Task Lifecycle

Each sub-task follows the canonical task lifecycle independently. The parent task transitions are governed by aggregation:

1. the parent remains dispatched while any sub-task is in progress
2. the parent moves to verifying only when all required sub-tasks have reached awaiting_settlement or the iteration policy declares convergence
3. if any sub-task is rejected or timed_out, the parent may be rejected, retried under policy, or partially settled where policy permits partial acceptance

Iterative Execution Rounds

For training and iterative computation:

1. each round produces a sub-task with its own ExecutionResultBundle and Commitment references
2. round-to-round state is carried through commitment references, not through plaintext intermediate artifacts
3. the iteration policy defines maximum rounds, convergence thresholds, and early-stop conditions
4. each round independently consumes privacy budget where applicable

Multi-Vault Composite Interaction

When a composite task requires multi-Vault coordination, the two decomposition mechanisms compose into a three-level hierarchy:

1. Parent task: the root composite task admitted at the protocol level
2. Sub-task (round): each iterative round, following the composite task lifecycle
3. Execution slice (per-Vault): each Vault's contribution within a single round, following the multi-Vault coordination model

The protocol requires:

1. each sub-task to carry its own coordination envelope when it requires multi-Vault fan-out
2. per-Vault slices within a sub-task to follow the canonical execution slice rules (independent lifecycle, SliceResultBundle, no plaintext exposure)
3. secure aggregation to occur at the sub-task level, combining per-Vault slices into the sub-task result before the next round begins
4. the parent task to track sub-task completion, not individual slice completion
5. a slice failure in one round to affect only that round's sub-task, not the parent or other rounds

This means for a multi-Vault training task with N rounds and M Vaults, the protocol manages: 1 parent task + N sub-tasks + (N × M) execution slices. Each level has its own lifecycle, evidence, and settlement context.

Composite Settlement

The protocol requires:

1. composite tasks to settle as a unit after all sub-tasks are verified
2. partial settlement to be policy-governed and explicitly declared, not silently assumed
3. reward accounting for composite tasks to reflect the aggregate verified contribution across sub-tasks
4. the composite settlement context to preserve linkage to every sub-task settlement context

---

Part 6: Settlement and Delivery

This part defines how execution results are validated, challenged, settled, and delivered to downstream consumers.

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.

Verification Requirements by Task Class

For parse tasks:

1. verify structured output conforms to the resolved semantic schema
2. verify commitment linkage between input record and output fields

For query tasks:

1. verify result cardinality satisfies minimum_result_cardinality from the attribute composition
2. verify privacy budget consumption matches declared privacy_impact_epsilon
3. verify audience cap enforcement where applicable
4. for multi-Vault queries, verify aggregation evidence and TEE attestation

For compute tasks:

1. verify determinism: re-execution under the same inputs must produce the same output commitment
2. verify resource consumption did not exceed declared bounds

For train tasks:

1. per-round verification: validate each sub-task's TEE attestation and privacy budget consumption
2. composite verification: validate convergence state, total privacy budget, and model quality against admission criteria
3. verify model artifact does not memorize individual records (membership inference resistance)

Challenge Scope for Composite and Multi-Vault Tasks

The protocol extends the challenge lifecycle for complex tasks:

1. a challenge may target a specific per-Vault execution slice, identified by parent_task_id + vault_id
2. a challenge may target a specific sub-task round, identified by parent_task_id + sub_task_sequence_index
3. a challenge may target the aggregation step, identified by parent_task_id + aggregation
4. a challenge may target the composite result as a whole

Challenge consequences for composite tasks:

1. if a single slice is challenged and the challenge is approved, the sub-task containing that slice may be re-executed or rejected under policy
2. if a sub-task round is challenged and approved, subsequent rounds that depended on it are invalidated
3. if the aggregation is challenged and approved, the entire task result is rejected
4. challenge against a sub-task does not automatically invalidate the parent unless the sub-task is essential under the iteration policy

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

Result Delivery

SCP defines the protocol boundary for how accepted and settled results become available to downstream consumers.

Delivery Scope

Result delivery governs:

1. who may access the finalized result
2. what form the delivered result takes
3. how delivery is confirmed or acknowledged

Delivery Actors

The protocol recognizes:

1. task_submitter: always has delivery access to the finalized result of their own task
2. authorized_consumer: an actor who holds a delivery grant for a specific settled result
3. vault_operator: may deliver Vault-local results to the data subject

Delivery Form

The protocol requires:

1. delivered results to be derived from finalized settlement context, not from raw execution output
2. results containing personally attributable information to remain subject to consent and authorization constraints even after settlement
3. the delivered form to be distinguishable from the full protocol settlement context, which may contain internal evidence and accounting references not intended for external consumers

Delivery Confirmation

The protocol requires:

1. delivery events to be recorded as protocol-auditable artifacts
2. delivery confirmation to not be a prerequisite for settlement finality, which is determined by the settlement lifecycle alone
3. failed or refused delivery to not retroactively invalidate finalized settlements

---

Part 7: Protocol Configuration

This part defines the governing parameters that control protocol behavior: policy versions, epochs, and the determinism requirements that ensure replay.

Policy Version Model

policy_version is a protocol object that captures the full set of configurable protocol parameters active at a given point in time. It exists so that protocol behavior is deterministic and replayable even as operational parameters evolve.

What Policy Version Contains

A policy version governs at least:

1. per-task_class constraints: TEE requirements, maximum execution time, maximum resource consumption
2. privacy parameters: default privacy budget allocation per usage scope, minimum result cardinality thresholds, budget replenishment rates
3. economic parameters: minimum stake amounts per actor role, reward calculation formulas, penalty severity scales
4. admission controls: rate limits, concurrency caps, budget lock requirements per task class
5. multi-Vault parameters: default quorum requirements, per-Vault timeout defaults, aggregation environment requirements
6. governance parameters: challenge window duration, challenge bond amounts, governance voting thresholds

Policy Version Identity

A policy version should preserve at least:

1. policy_version_id
2. effective_from_epoch: the epoch from which this policy version takes effect
3. status: one of draft, active, deprecated, retired
4. predecessor_version_id: the policy version this one replaces

Policy Version Lifecycle

The canonical lifecycle is:

1. draft: under governance review, not yet enforceable
2. active: the current enforceable policy version for the governed scope
3. deprecated: still valid for in-progress tasks admitted under it, but new tasks must use the successor
4. retired: no longer valid for any purpose

At most one policy version should be active for a given governed scope at any time.

Policy Version Transition Rules

The protocol requires:

1. policy version transitions to occur only at epoch boundaries
2. tasks admitted under a given policy_version to be evaluated under that version for their entire lifecycle, even if the policy version is later deprecated
3. the active policy_version at task admission time to be recorded in the task's replay tuple
4. policy version changes to be announced at least one epoch in advance through governance
5. no retroactive application of new policy to already-admitted tasks

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

Epoch and Composite Task Interaction

Composite tasks may span multiple epochs. The protocol defines:

1. the parent task is assigned to the epoch in which it was admitted
2. each sub-task is assigned to the epoch that is open at the time the sub-task is dispatched
3. if an epoch closes while a sub-task is in progress, the in-progress sub-task retains its assigned epoch; subsequent sub-tasks are assigned to the next epoch
4. composite settlement aggregates sub-task settlements across their respective epochs
5. reward accounting for each sub-task follows the epoch to which that sub-task was assigned
6. if an epoch closes while the parent task has no dispatched sub-tasks remaining, the parent may be deferred to the next epoch under policy or timed out

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

---

Part 8: Contract Boundary

Conforming Implementation Requirements

Conforming implementations must expose protocol coverage for at least:

1. task and semantic messages, including task classification and composite task structures
2. consent and authorization messages
3. execution and verification messages, including TEE attestation where applicable
4. multi-Vault coordination messages, including coordination envelopes and slice results
5. derivation rule registrations and attribute composition declarations
6. settlement messages
7. reward records
8. payout instructions and events
9. privacy budget consumption records
10. result delivery 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. CONSENT_*
5. POLICY_*
6. EXECUTION_*
7. PROOF_*
8. TEE_*
9. VERIFY_*
10. COORDINATION_*
11. DERIVATION_*
12. COMPOSITION_*
13. PRIVACY_BUDGET_*
14. SETTLEMENT_*
15. REWARD_*
16. PAYOUT_*
17. DELIVERY_*
18. GOVERNANCE_*
19. INTERNAL_*