Why SCL:V1 Is Permanently Frozen and Immutable
Core Principle
SCL:V1 is permanently frozen to guarantee that identical input bytes always produce identical canonical JSON and identical SHA-256 identity across all compliant implementations, everywhere, for all time.
Deterministic Identity Requirement
SCL defines identity as:
SHA-256(canonical JSON bytes)
This requires:
- Canonical JSON to be fully deterministic
- No variation in parsing, interpretation, or serialization
- No implementation-defined behavior
Any change to the specification would risk altering how canonical JSON is produced, which would directly change the resulting SHA-256 identity.
Why Backwards-Compatible Changes Are Not Allowed
Even backwards-compatible changes introduce risk:
- New parsing paths
- Additional rules or edge cases
- Expanded interpretation surface
These can lead to:
- Different canonical JSON outputs for the same input
- Divergence across implementations
- Version-dependent identity
This breaks the core invariant:
Identical input bytes MUST always produce identical identity.
Immutability Guarantees
Freezing SCL:V1 ensures:
- Zero ambiguity in interpretation
- Permanent cross-language parity
- Stable, verifiable identities
- No version-dependent behavior within V1
- Consistency across time and systems
Versioning Model
All changes, including backwards-compatible ones, are prohibited in SCL:V1.
Any evolution must occur in a new version:
- SCL:V2 defines a new, independent system
- No changes are introduced into SCL:V1
- Existing identities remain permanently stable
Final Constraint
Immutability is required to preserve deterministic identity.
Any modification would violate:
- Identity = SHA-256(canonical JSON bytes)
- Canonical JSON as the sole hash input
- Cross-implementation determinism
Therefore, SCL:V1 is permanently frozen and cannot be modified. For the complete identity mechanism that immutability preserves, see how SCL ensures deterministic identity.
Validate outputs using the reference engine.