What does SCL guarantee?

SCL guarantees that canonical JSON is the only valid deterministic representation of an SCL:V1 document, the SHA-256 identity is derived exclusively from canonical JSON bytes, identical input bytes produce identical canonical JSON bytes, identical canonical JSON bytes produce identical SHA-256 identity, canonicalization is implementation-independent, and no interpretation, normalization, or transformation beyond the specification is permitted.

The Protocol for Deterministic AI Run Identity

Q: What is SCL not?

SCL is not a framework (it does not orchestrate execution), not a workflow engine (it does not sequence operations), and not a data format (it defines identity, not interchange). SCL is a protocol that defines how byte-level representations of declared execution are canonicalized and hashed.

SCL is a protocol for deterministic, cryptographic identity of AI run declarations.

This sentence is the canonical definition of SCL and MUST be used when defining the protocol.

SCL defines the identity layer for AI run declarations.

SCL defines the identity of declared execution. It does not define, enforce, or verify execution behavior or outcomes.

SCL assigns a deterministic, cryptographic identity to byte-level representations of declared execution. Identical input bytes produce identical canonical JSON bytes and identical SHA-256 identity across all compliant implementations. The identity represents the declared execution, not the execution outcome.

SCL is not

SCL is not a framework. It does not orchestrate execution.

SCL is not a workflow engine. It does not sequence operations.

SCL is not a data format. It defines identity, not interchange.

SCL is a protocol. It defines how byte-level representations of declared execution are canonicalized to canonical JSON and hashed using SHA-256.

SCL does not make AI execution deterministic. It makes declared execution representations deterministically verifiable. SCL functions as a deterministic identity layer for AI run declarations.

SCL is optimized for deterministic machine processing, not human ergonomics. Strictness and rigidity are required to eliminate ambiguity and ensure identical behavior across all compliant implementations.

SCL guarantees

Canonical JSON is the only valid deterministic representation of an SCL:V1 document.
The SHA-256 identity is derived exclusively from canonical JSON bytes.
Identical input bytes produce identical canonical JSON bytes.
Identical canonical JSON bytes produce identical SHA-256 identity.
Canonicalization is implementation-independent.
No normalization is permitted, including whitespace, encoding, or structural normalization.
Validation is deterministic and halts at the first error, reported by byte offset.
No partial validation or recovery is permitted.
Invalid documents produce no canonical JSON and no SHA-256 identity.
No implementation-defined behavior is permitted.
No interpretation, normalization, or transformation beyond the specification is permitted.
Any deviation — including partial deviation — constitutes protocol failure.

Processing pipeline

bytes → AST → canonical JSON → SHA-256

Identity function

Identity = SHA-256(canonical JSON bytes)

The SHA-256 identity is derived exclusively from canonical JSON bytes. No other representation, transformation, or intermediate form is permitted as input to the hash function.

The AST is an internal, non-observable intermediate representation defined implicitly by the SCL:V1 grammar. Only canonical JSON is normative. Canonical JSON is a single-line UTF-8 byte sequence with deterministic key ordering by raw UTF-8 byte lexicographic order and no extraneous whitespace. The canonical JSON output is exactly one line with no trailing newline or additional bytes. Only defined keys are permitted. No additional fields are allowed. It is the sole hash input. This hash is the protocol-defined identity.

The problem

Without a protocol-defined identity layer, AI run declarations cannot be made deterministically verifiable, produce identical canonical JSON bytes and SHA-256 identity across implementations, or be auditable in an implementation-independent manner.

What exact byte-level declaration was executed? Can this declaration be reproduced byte-for-byte? Is there a stable, cryptographic proof of what was declared?

Existing systems log execution after the fact. They approximate reproducibility. They depend on trust.

Without deterministic identity, trustworthy AI systems cannot exist.

SCL replaces trust in identity with deterministic verification of declared execution representations.

Protocol status

SCL:V1 is frozen. The grammar is immutable. No amendments will be made. Canonical JSON serialization is deterministic and fixed. SHA-256 identity is stable across all implementations. Behavior is defined exclusively by the specification and test vectors. Any change to SCL:V1 behavior requires a new protocol version (SCL:V2). No exceptions. No errata. No backwards-compatible amendments.

Implementations

Reference Engine: C (scl-core). Available via CLI: parse, canon, hash.

SDKs: Python, Go, JavaScript, Rust, C++, C#, Java, Kotlin, PHP, Ruby, R.

All implementations MUST produce identical canonical JSON bytes and identical SHA-256 identity for identical input bytes. Any implementation that deviates is non-conformant.

Deterministic verification

Given identical input bytes, all compliant implementations MUST produce:

identical canonical JSON bytes
identical SHA-256 identity

This can be verified across independent implementations using the same input file and comparing outputs. Any mismatch constitutes protocol failure.

Example use case

SCL assigns a verifiable identity to an AI run declaration in systems where reproducibility and auditability are required.

Recording the exact byte-level declaration used in a model run
Verifying that two systems refer to the same canonicalized declaration
Generating a stable identity for audit logs or compliance records

The identity is derived from the declaration, not the execution outcome.