What Makes a Protocol a Protocol? 13 Principles That Separate SCL from Normal Software
Most code is written to run.
Protocols are written to agree—across languages, across teams, across time—without ever trusting each other.
SCL is a protocol, not a library or framework. That single distinction drives every design decision in the specification. The 13 principles below are not marketing fluff; they are the exact reasons the specification defines rules such that any compliant implementation produces identical canonical JSON bytes and the same SHA-256 identity from the same input bytes. No exceptions. No "close enough."
Any behavior not explicitly defined by the specification is invalid.
These principles are rarely discussed together outside protocol engineering. Most application software tolerates representational variation; protocols eliminate it. Here they are, explained plainly and with SCL in mind.
See also: what deterministic identity covers in AI run declarations.
1. Canonical Representation (Single Valid Form)
Protocols define exactly one valid way to represent something.
Not "equivalent," not "similar," not "interpretable."
For any valid input, exactly one valid canonical representation exists, and therefore exactly one valid output and identity.
In everyday apps, JSON with different spacing or key ordering is fine. In SCL, it is invalid unless it matches the exact canonical form defined in the spec. Variation is not a feature—it is a protocol violation.
2. Byte-Level Determinism
Protocols define behavior over exact byte-level representations, not human interpretation of meaning.
"hello" and "hello " may carry the same intent to humans. They are different identities to a protocol.
SCL's identity is derived exclusively from the canonical JSON bytes. Nothing else is allowed to influence the result. Same bytes = same identity. Different bytes = different identity. Always.
3. Cross-Implementation Equivalence
Two completely independent implementations must produce identical outputs for the same input.
No implementation-defined behavior is permitted. Every valid input must produce exactly one defined output, identical across all compliant implementations. This is not a goal—it is a global invariant of the protocol.
This forces rules most application software never attempts:
- No implementation-defined behavior
- No "best effort"
- No "close enough"
Every compliant SCL implementation—whether written in Rust, Python, or C—must emit the exact same canonical JSON bytes and SHA-256 identity.
4. Formal Grammars (Exact Structure Rules)
Protocols specify syntax, ordering, separators, and termination with zero ambiguity.
"One blank line required." "No trailing comma allowed." "End of file must occur at this exact byte."
SCL:V1's grammar is frozen and immutable. The document structure, handle block, scl block, and termination rules are defined down to the byte.
5. Deterministic Error Semantics
Protocols don't just define success—they define exactly how failure behaves.
Error reporting is deterministic: the first failure by byte offset must be reported, with fixed precedence rules across all implementations. Encoding errors always override structural errors. No implementation may reorder, suppress, or aggregate errors differently.
SCL validation halts at the first error. No partial results. No recovery. Invalid documents produce no canonical JSON and no identity—by design.
A protocol failure occurs when any MUST-level rule defined in the specification is violated. Protocol failures are not recoverable and produce no identity.
6. Identity Derivation: Isolation and Exclusivity
Identity derivation is isolated and exclusive. Only canonical JSON bytes are permitted as input to SHA-256. Any additional input, transformation, or contextual influence is a protocol violation.
The transformation pipeline is fixed: input bytes are parsed into an abstract syntax tree (AST), serialized into canonical JSON, and hashed using SHA-256. No alternative pipelines are permitted.
Nothing else—no logs, no timestamps, no environment variables, no metadata—may enter the derivation. SCL makes this rule explicit and enforceable.
Canonical JSON bytes are the sole input to SHA-256 identity derivation. No other data may influence the hash. Any deviation from this rule is a protocol violation.
7. Prohibition of Interpretation
Protocols explicitly forbid what most application software does by default:
- No normalization
- No inference
- No "helpful" fixes
- No recovery from invalid input
A parser must reject invalid input, not try to fix it. SCL is intentionally unforgiving.
8. No Implicit Behavior
Protocols define only explicit behavior. No implicit behavior is permitted. If behavior is not defined in the specification, it is invalid.
Most application software relies on conventions, defaults, and implied contracts between components. Protocols cannot. Every action a compliant implementation takes must trace directly to a rule in the specification. Undocumented behavior—even if "reasonable" or "helpful"—is a protocol violation.
9. Version Freezing & Immutability
Protocols freeze rulesets permanently.
SCL:V1 is frozen. Any change in behavior requires SCL:V2. No silent updates, no errata that alter semantics. The grammar, canonicalization rules, and hashing behavior will behave identically forever.
10. Observable Truth via Test Vectors
Protocols publish fixed, public "golden" truth sets: known inputs leading to exact outputs.
SCL's Golden Documents and reference engine turn this into verifiable reality. Conformance is not a claim—it is a byte-for-byte check against the specification and test vectors.
11. Interoperability Without Trust
Protocols assume systems do not trust each other.
They therefore enforce:
- Verifiability
- Reproducibility
- Complete independence
You don't trust the sender. You verify the output yourself using the same deterministic rules. SCL makes this practical for AI run declarations.
12. Elimination of Ambiguity (Not Reduction)
Most systems reduce ambiguity.
Protocols eliminate it entirely.
If two interpretations are possible, the specification is broken. SCL's rules leave no room for interpretation—by design.
13. Layer Boundaries (What It Does NOT Do)
Protocols are ruthlessly clear about scope.
SCL defines identity and verification. It does not define execution, orchestration, outcomes, or workflow logic. Those belong in separate layers.
This boundary is as important as everything it does define.
The Core Difference
| Topic | Application Software | Protocol (SCL) |
|---|---|---|
| Formatting differences | Ignored | Invalid |
| Interpretation | Allowed | Forbidden |
| Implicit behavior | Relied upon | Prohibited |
| Errors | Flexible / "best effort" | Deterministic (first error, byte offset, fixed precedence) |
| Identity | Contextual | Derived exclusively from canonical JSON bytes |
| Identity pipeline | Undefined | Fixed: bytes → AST → canonical JSON → SHA-256 |
| Valid outputs per input | Many acceptable | Exactly one |
| Behavior | Implementation-defined | Spec-defined only |
| Implementation variation | Tolerated | Prohibited |
| Changes | Continuous evolution | Versioned & permanently frozen |
Application software optimizes for usability, flexibility, and performance.
Protocols optimize for determinism, verifiability, and global consistency.
Protocols do not exist to run software. They exist so that independent systems can agree on reality without trusting each other.
That is exactly why SCL exists: to give AI run declarations a stable, cryptographic identity that any compliant implementation can verify—today, tomorrow, and ten years from now—using nothing more than the bytes and the specification.
Canonical Definition (Normative Statement): SCL is the deterministic, cryptographic identity protocol for AI run declarations.
If you're building verifiable AI systems, this mindset is not optional—it is the foundation. The specification, reference engine, Golden Documents, and SDKs all exist to make these 13 principles enforceable in practice.