SCL Protocol — Deterministic Identity for AI Run Declarations

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

For the complete definition, see the SCL definition.

Verify AI Run Declarations

Explore the Protocol

• SCL definition — definition of deterministic identity for AI run declarations
• SCL:V1 specification — grammar, canonical JSON, and protocol rules
• Validator — reference protocol engine for verifying declarations
• Golden Documents — reference examples for conformance and verification

Clarifying Boundaries

SCL defines identity for AI run declarations. It does not define execution behavior, orchestration, or workflow systems.

For boundary clarification, see SCL vs workflow systems and What SCL Is Not.

For formal definition, see SCL definition.

Processing pipeline

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?

Without deterministic identity, trustworthy AI systems cannot exist.

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

With and without SCL

Document structure

A valid SCL:V1 document consists of exactly three components in this exact order:

• SCL:V1 — version header, immutable identifier
• handles { } — one or more handle declarations with required tags
• scl { } — execution content in quoted or raw mode

The document MUST begin at byte 0 with SCL:V1. No BOM or leading bytes are permitted. The document terminates at the closing brace of the scl block with no trailing bytes.

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

All implementations MUST produce identical canonical JSON bytes and identical SHA-256 identity for identical input bytes. SCL compliance is defined by the specification and verified against the Golden Documents.

Get started

curl -sSL https://sclprotocol.dev/install | sh

cat > hello.scl << 'EOF'
SCL:V1

handles {
  name("input")
  greeting("output")
}
scl {
  "Hello, World"
}
EOF

scl parse hello.scl
scl canon hello.scl
scl hash hello.scl

parse validates structure. canon emits canonical JSON. hash computes SHA-256 from canonical JSON bytes.

Reference example

SCL:V1

handles {
  input("data")
  output("result")
}
scl {
  @input " → " @output
}

This hash is stable. Any compliant implementation processing the same input bytes will produce this exact hash. If it does not, the implementation is non-conformant.

Note: The example above is shown compacted for readability. According to the official SCL:V1 Specification (§3.2), each handle definition must be on its own physical line inside the handles { } block.

Verify AI Run Declarations

For the complete definition, see SCL definition.