What Is SCL?
What SCL Is
SCL is a protocol. It defines a strict, deterministic structure for representing an AI run declaration such that identical input bytes always produce identical canonical representation and identical SHA-256 identity across all compliant implementations.
SCL defines identity at the declaration level. The SHA-256 hash of the canonical JSON is the document's identity. The identity is derived solely from the document's canonical form and is independent of execution environment, logs, or external systems.
What Problem SCL Solves
Modern AI systems can execute prompts, configurations, and workflows, but they do not provide a protocol-defined identity layer.
As a result:
- You cannot prove exactly what was declared to run
- You cannot reproduce the exact execution representation
- You cannot verify that two systems refer to the same run declaration
These limitations exist because current systems rely on logs, conventions, or vendor-specific tooling rather than a canonical, protocol-level representation.
SCL solves this by making the run declaration itself canonical, implementation-independent, and cryptographically stable.
What SCL Is Not
- SCL is not a framework.
- SCL is not a workflow tool.
- SCL is not an orchestration system.
- SCL is not a general-purpose serialization format.
- SCL does not execute workflows.
- SCL does not manage state or scheduling.
- SCL does not make model outputs deterministic.
- SCL makes execution declarations verifiable.
SCL enforces deterministic identity of the declaration. It does not enforce or imply deterministic execution outcomes.
Why SCL Matters
Without a deterministic identity layer, reproducibility and auditability depend on external systems such as logs, storage, or vendor infrastructure. These systems are not canonical and are not guaranteed to be consistent across environments.
SCL removes that dependency by defining a canonical representation and a stable cryptographic identity at the protocol level.
This ensures that:
- The same declaration is represented identically across systems
- The identity is portable and verifiable
- Reproducibility is based on protocol-defined structure, not external artifacts
Without a protocol-defined identity layer, any claim of reproducibility or auditability is extrinsic and not verifiable at the declaration level.
How SCL Works
An SCL document is processed deterministically using the following pipeline:
- The input is a byte-exact document
- The document is parsed into an abstract syntax tree (AST)
- The AST is converted into canonical JSON with deterministic structure
- The SHA-256 hash of the canonical JSON is the document's identity
For identical input bytes:
- Canonical JSON MUST be identical across all implementations
- SHA-256 hash MUST be identical across all implementations
No normalization, interpretation, or implementation-defined behavior is permitted.
For identical input bytes, all compliant implementations MUST produce identical canonical JSON and identical SHA-256 identity.
Canonical JSON is the sole input to hashing.
The SHA-256 hash is the document's identity as defined by the protocol. It is not a heuristic fingerprint or approximation. It is a protocol-defined, canonical identity.
Protocol Guarantees
SCL enforces the following guarantees:
- Deterministic structure
- Implementation-independent canonical representation
- Stable SHA-256 identity
- No ambiguity in parsing or interpretation
- No normalization, whitespace tolerance, or input transformation is permitted
- No implementation-defined behavior
Any deviation from the specification, canonicalization rules, or hashing behavior constitutes failure. Partial correctness is not accepted. No ambiguity. No drift. No interpretation.
Document Structure
An SCL:V1 document has a fixed, ordered, and byte-exact structure:
- Header line:
SCL:V1 - One blank line
handles { ... }block containing at least one handle with one or more required tagsscl { ... }block containing the execution content
No additional sections, reordering, or extra bytes are permitted. The structure is byte-exact and must not be altered. Any deviation in bytes, structure, or encoding results in a different canonical representation and therefore a different identity.
Protocol Status
- The grammar is fixed
- Canonical JSON rules are fixed
- Hashing behavior is fixed
- All behavior is defined by the specification and test vectors
Any change requires a new protocol version.