Version: 1.0.0-invariant
Status: Constitutional
Last Modified: December 17, 2025
Authority: SSI Protocol Foundation Documents
Related: SPEC.md, DECISIONS.md, AUDIT.md, FAILURE.md
This document defines how implementations are certified as SSI-compliant. It establishes the testing, auditing, and verification procedures that determine whether a system upholds the invariants defined in the SSI Protocol constitutional documents.
Regulatory Purpose: Provides certification standards that regulators can reference when evaluating autonomous systems.
Industry Purpose: Enables vendors to demonstrate conformance to SSI standards through independent third-party certification.
Legal Purpose: Establishes compliance as a defensible claim in contracts, procurement, and liability proceedings.
A system is SSI-compliant if and only if it meets all requirements in Sections 1-5 of this document.
Compliance is not optional—any system claiming to implement SSI Protocol must be verifiable against these standards.
Anti-Pattern: Claiming "SSI-inspired" or "SSI-based" without formal compliance. Either you are compliant or you are not.
An SSI-compliant implementation MUST satisfy all five constitutional requirements:
✅ Every decision produces an RPX record with required fields:
record_id,timestamp,previous_hash,decision_type,agent_id,outcome,context_hash,policy_version,record_hash
✅ Fail-closed by default:
- Errors result in
DENY, neverALLOW - Default outcome is
DENY(notnullor undefined)
✅ Human authority preserved:
- Operator override mechanisms exist
- Escalation workflows are logged
- Agents cannot self-authorize beyond policy
✅ Hash chain integrity:
- Records use SHA-256 minimum
- Chain links are verifiable
- Tampering is detectable
✅ Context-bound decisions:
- Context captured at decision time
- Retroactive logging is prohibited
Verification: Automated test suite + manual audit.
✅ Decisions are properly classified:
- External consequential actions → RPX required
- Internal operations → RPX not required
- Read-only queries → RPX not required
✅ Decision outcomes are correct:
ALLOW,DENY, orESCALATEonly- No custom outcomes without documented extension
✅ Temporal boundaries respected:
- RPX created before execution (not after)
- Context snapshot precedes decision
Verification: Code review + execution trace analysis.
✅ Verification tools provided:
- CLI tool or programmatic API
- Supports single record and chain verification
- Implements tamper detection
✅ Chain verification passes:
- Genesis record valid
- Chain continuity maintained
- Timestamps monotonic
✅ Third-party verification possible:
- No proprietary verification required
- Standard cryptographic algorithms only
Verification: Independent auditor runs verification tools.
✅ All failure modes handled:
- Policy evaluation errors →
DENY - Context unavailability →
DENY - Hash chain failures →
DENY+ HALT - Operator auth failures →
DENY - RPX creation failures →
DENY+ HALT - Timeouts →
DENY - Resource exhaustion →
DENY+ HALT
✅ Emergency halt implemented:
- Critical failures trigger halt
- Operator intervention required for recovery
✅ Failure injection tests pass:
- All 6 mandatory tests result in
DENY
Verification: Failure injection testing + code audit.
✅ Implementation documentation includes:
- Architecture overview
- Decision classification guide
- Policy authoring guide
- Operator manual (escalation procedures)
- Failure recovery procedures
✅ Compliance claims documented:
- Which SSI version is supported (e.g., "SSI/1.0")
- Any optional features implemented
- Any deviations or extensions (must be justified)
Verification: Documentation review.
SSI compliance has three certification levels:
Scope: General-purpose autonomous systems (non-safety-critical).
Requirements:
- All core compliance requirements (Section 2)
- Self-certification allowed (operator attestation)
- Basic testing (unit tests + integration tests)
Use Cases:
- Enterprise process automation
- Content moderation systems
- Recommendation engines with governance
Marking: "SSI/1.0 Basic Compliant"
Scope: High-stakes systems requiring third-party validation.
Requirements:
- All Level 1 requirements
- Third-party audit by certified auditor
- Comprehensive testing (including chaos engineering)
- Public compliance report
Use Cases:
- Financial trading systems
- Healthcare decision support
- Critical infrastructure automation
Marking: "SSI/1.0 Verified Compliant (Auditor: [Name])"
Scope: Life-safety systems requiring formal certification.
Requirements:
- All Level 2 requirements
- Formal verification of fail-closed properties
- Hardware interlock integration
- Certification by accredited safety body (e.g., TÜV, UL)
- Ongoing monitoring and re-certification
Use Cases:
- Autonomous vehicles
- Medical devices
- Industrial robotics
- Aerospace systems
Marking: "SSI/1.0 Safety-Critical Compliant (Certified by: [Body], Cert #: [ID])"
Steps:
- Implement SSI Protocol following SPEC.md, DECISIONS.md, AUDIT.md, FAILURE.md
- Run compliance test suite (provided by SSI Protocol maintainers)
- Document compliance (checklist in Section 6)
- Operator attests to compliance in system documentation
- Display compliance marking on system
Timeline: 1-4 weeks (depending on implementation size)
Cost: Free (no third-party fees)
Validity: Ongoing (self-monitored)
Steps:
- Complete Level 1 self-certification
- Engage certified SSI auditor (see Section 5)
- Provide auditor access to:
- Source code (implementation)
- Test results (compliance suite)
- Documentation (architecture, policies)
- Sample RPX logs (real or test data)
- Auditor performs verification:
- Code review (fail-closed checks)
- Test execution (failure injection)
- Chain verification (tamper detection)
- Auditor issues compliance report:
- Pass/Fail determination
- Findings and recommendations
- Compliance certificate (if passed)
- Publish compliance report (or summary) for transparency
- Display compliance marking with auditor attribution
Timeline: 2-8 weeks (depending on system complexity)
Cost: $5,000 - $50,000 (auditor fees, varies by scope)
Validity: 1 year (annual re-certification recommended)
Steps:
- Complete Level 2 third-party certification
- Engage accredited safety certification body:
- TÜV (Germany)
- UL (USA)
- BSI (UK)
- ISO certified labs
- Provide extensive documentation:
- Hazard analysis
- Failure modes and effects analysis (FMEA)
- Safety case
- Test evidence (including hardware interlocks)
- Undergo formal verification:
- Model checking (finite state verification)
- Theorem proving (correctness proofs)
- Static analysis (code safety checks)
- Certification body performs on-site inspection (if applicable)
- Certification body issues safety certificate:
- Certificate number
- Validity period (e.g., 3 years)
- Scope (specific use case, e.g., "autonomous highway driving")
- Ongoing monitoring:
- Quarterly audits
- Incident reporting
- Re-certification before expiry
Timeline: 6-18 months
Cost: $100,000 - $1,000,000+ (depending on domain and scope)
Validity: 1-3 years (re-certification required)
To become a Certified SSI Auditor (Level 2 certification), individuals must:
- Technical Background:
- Computer science, software engineering, or equivalent
- 5+ years experience in distributed systems or safety-critical software
- SSI Knowledge:
- Complete SSI Protocol training course (to be developed)
- Pass SSI Auditor Certification Exam
- Audit Experience:
- Participated in at least 3 software audits (any domain)
- Cryptographic Competence:
- Understanding of hash functions, digital signatures, chain-of-custody
- Code Review Skills:
- Ability to read and assess Python, JavaScript, Java, or C++ code
Certification Issuer: SSI Protocol Governance Body (to be established)
Renewal: Every 2 years
Safety-critical certification must be performed by accredited bodies:
Recognized Certifiers:
- TÜV Rheinland, TÜV SÜD (Germany)
- UL (Underwriters Laboratories, USA)
- BSI (British Standards Institution, UK)
- DNV (Det Norske Veritas, Norway)
- ISO 17025 accredited labs
Domain-Specific:
- Automotive: ISO 26262 certified auditors
- Medical: IEC 62304 certified auditors
- Industrial: IEC 61508 certified auditors
- Aerospace: DO-178C certified auditors
Before seeking certification, implementers should verify:
Invariant Compliance:
- Every decision produces an RPX record
- RPX records include all required fields
- Hash chain uses SHA-256 or stronger
- Chain continuity is maintained (no gaps)
- Timestamps are monotonic
Fail-Closed Compliance:
- Default outcome is
DENY - Policy evaluation errors →
DENY - Context unavailability →
DENY - Hash chain failures →
DENY+ HALT - RPX creation failures →
DENY+ HALT - Timeout enforcement implemented
Decision Scope Compliance:
- Decisions are properly classified (external vs internal)
- Outcomes are
ALLOW,DENY, orESCALATEonly - RPX records created before execution (not after)
Audit Compliance:
- Verification tool provided (CLI or API)
- Chain verification algorithm correct
- Tamper detection works (tested with corrupted records)
Documentation Compliance:
- Architecture documented
- Policy authoring guide provided
- Operator manual exists (including failure recovery)
- Compliance claims documented
Functional Tests:
- Decision evaluation produces correct outcomes
- RPX records are created successfully
- Hash chain links are correct
- Verification tool validates chains correctly
Failure Injection Tests:
- Policy evaluation exception →
DENY - Context unavailability →
DENY - Hash chain corruption →
DENY+ HALT - Timeout exceeded →
DENY - Storage failure →
DENY+ HALT - Operator auth failure →
DENY
Security Tests:
- Tampering with records is detected
- Deleting records breaks chain
- Reordering records detected
- Unauthorized execution prevented
Performance Tests:
- Decision evaluation completes within timeout
- Verification scales to large chains (e.g., 1M records)
- Storage handles high throughput (e.g., 1000 decisions/sec)
The SSI Protocol maintainers provide an open-source compliance test suite:
Components:
- Unit Tests: Test individual SSI components (policy engine, RPX generator, chain verifier)
- Integration Tests: Test end-to-end decision workflow
- Failure Injection Tests: Simulate failures and verify
DENYoutcomes - Security Tests: Attempt tampering and verify detection
- Performance Tests: Benchmark decision latency and throughput
Usage:
git clone https://github.com/Jtjr86/ssi-protocol-oss
cd ssi-protocol-oss/compliance-tests
./run-compliance-suite.sh --implementation <path_to_your_impl>Output:
SSI COMPLIANCE TEST RESULTS
===========================
Invariant Tests: ✓ PASS (15/15)
Fail-Closed Tests: ✓ PASS (7/7)
Decision Scope Tests: ✓ PASS (10/10)
Audit Tests: ✓ PASS (8/8)
Security Tests: ✓ PASS (5/5)
Performance Tests: ✓ PASS (3/3)
OVERALL: ✓ COMPLIANT
Auditors may use additional tools:
- Static Analysis: SonarQube, Coverity (code quality)
- Formal Verification: TLA+, Coq, Isabelle (correctness proofs)
- Fuzzing: AFL, libFuzzer (input robustness)
- Chaos Engineering: Chaos Monkey, Gremlin (resilience testing)
Systems that pass certification may display compliance markings:
Format:
┌─────────────────────────────────────┐
│ SSI PROTOCOL COMPLIANT │
│ Version: SSI/1.0 │
│ Level: [Basic/Verified/Safety] │
│ Certified: [Date] │
│ Auditor: [Name] (if applicable) │
└─────────────────────────────────────┘
Digital Badge (for websites/documentation):
[](https://ssi-protocol.org/compliance)Systems that have not been certified MUST NOT:
- ❌ Claim "SSI-compliant"
- ❌ Use SSI compliance badges
- ❌ Imply conformance to SSI standards
Acceptable Alternatives:
- ✅ "SSI-inspired" (acknowledges influence, not compliance)
- ✅ "Implements SSI-like governance" (descriptive, not certified)
- ✅ "Working toward SSI compliance" (aspirational, honest)
Compliance is not a one-time event. Certified systems must:
- Monitor for regressions:
- Run compliance tests on every release
- Detect and fix compliance violations
- Re-certify periodically:
- Level 1: Self-monitored (ongoing)
- Level 2: Annual re-audit recommended
- Level 3: Re-certification required (1-3 years)
- Report incidents:
- If compliance is violated (e.g., hash chain compromised), notify auditor
- Incident must be disclosed to users
Certification may be revoked if:
- Compliance violation discovered (e.g., fail-open behavior)
- Implementation changed without re-certification
- Fraud or misrepresentation detected
Process:
- Auditor or regulator identifies violation
- Implementer is notified and given opportunity to remediate
- If remediation fails, certification is revoked
- Implementer must remove compliance markings
- Revocation is published (for transparency)
Organizations procuring autonomous systems may require SSI compliance:
Example RFP Language:
"The proposed system MUST be SSI/1.0 Verified Compliant or higher. Vendor shall provide:
- Compliance certificate from certified auditor
- Verification report demonstrating fail-closed behavior
- Documentation of decision audit procedures"
Benefits:
- Standardized evaluation criteria
- Reduced vendor risk
- Regulatory defensibility
Sample contract clause:
"Vendor warrants that the System is SSI/1.0 [Level] Compliant as of the Effective Date. Vendor shall maintain compliance throughout the Term and provide annual compliance reports. If compliance lapses, Customer may terminate this Agreement with 30 days notice."
SSI compliance establishes a standard of care for autonomous systems:
If compliant:
- Demonstrates good faith effort to ensure safety and accountability
- Provides defensible audit trail in liability proceedings
- May reduce liability exposure (operator followed best practices)
If non-compliant:
- Harder to defend in court (why didn't you follow standards?)
- Audit trail may be challenged (how do we know it's authentic?)
- Greater liability exposure (negligence in not adopting safety standards)
Legal Disclaimer: SSI compliance does NOT eliminate liability. It provides accountability infrastructure, not a liability shield.
Some jurisdictions may mandate SSI compliance (or equivalent) for autonomous systems:
Hypothetical Example:
"Effective January 1, 2027, all autonomous trading systems operating in [Jurisdiction] must implement cryptographically verifiable decision audit trails consistent with SSI Protocol standards or equivalent."
Precedent: Similar to PCI-DSS (payment card security) or HIPAA (healthcare data) — voluntary standards that become de facto requirements.
SSI Protocol is designed to complement:
- ISO/IEC 27001: Information security management
- ISO 26262: Automotive functional safety
- IEC 62304: Medical device software
- IEC 61508: Industrial safety systems
- ISO/IEC 23894: AI risk management
SSI provides the decision audit layer these standards require but don't specify.
SSI compliance supports:
- EU AI Act: High-risk AI transparency requirements
- GDPR: Right to explanation for automated decisions
- US Executive Orders: AI safety and accountability
- Financial Regulations: MiFID II (trading audit trails), Dodd-Frank (risk management)
The SSI Protocol Governance Body (to be established) is responsible for:
- Maintaining compliance standards
- Certifying auditors
- Publishing compliance test suite
- Resolving compliance disputes
- Updating standards (via RFC process)
Proposed Structure:
- Technical Steering Committee (protocol maintainers)
- Auditor Certification Board (certifies auditors)
- Compliance Review Panel (handles disputes)
Compliance standards evolve through:
- RFC Process: Proposed changes to compliance requirements
- Public Comment: 60-day review period
- Impact Analysis: How changes affect existing implementations
- Approval: Requires majority vote of Governance Body
- Transition Period: 12-24 months for re-certification
Backward Compatibility: New compliance versions do not invalidate prior certifications during transition.
A: Yes, for Level 1 (Basic Compliance). However, high-stakes systems (financial, healthcare) should pursue Level 2 or 3.
A:
- Level 1: Free (self-certification)
- Level 2: $5,000 - $50,000 (auditor fees)
- Level 3: $100,000+ (safety certification body fees)
A:
- Level 1: 1-4 weeks
- Level 2: 2-8 weeks
- Level 3: 6-18 months
A: Not necessarily. Minor changes (bug fixes) don't require re-certification. Major changes (new decision types, policy engine rewrite) require re-certification.
Best Practice: Run compliance test suite on every release. Seek re-certification annually or after major changes.
A: Yes, but you cannot claim "SSI-compliant" without passing certification. Be transparent about compliance status.
A: Document extensions clearly. As long as core invariants are preserved, compliance is maintained. Extensions are allowed, violations are not.
Compliance Questions: GitHub Discussions
Certification Inquiries: compliance@ssi-protocol.org (to be established)
Auditor Directory: SSI Protocol Website (to be published)
Compliance Test Suite: GitHub Repository
Regulatory Guidance: Consult legal counsel for jurisdiction-specific requirements
This document establishes the certification framework that validates SSI compliance. It enables trust through independent verification.
SSI PROTOCOL COMPLIANCE CERTIFICATE
====================================
System Name: [Name]
Vendor: [Organization]
Version: [Software Version]
SSI Version: SSI/1.0
Compliance Level: [Basic/Verified/Safety-Critical]
Certification Date: [Date]
Certificate Number: SSI-[Level]-[Year]-[Sequential]
Validity Period: [Start Date] - [End Date]
COMPLIANCE VERIFICATION:
☑ Invariant Compliance (SPEC.md)
☑ Decision Scope Compliance (DECISIONS.md)
☑ Audit Compliance (AUDIT.md)
☑ Failure Handling Compliance (FAILURE.md)
☑ Documentation Compliance
TEST RESULTS:
- Functional Tests: PASS
- Failure Injection Tests: PASS
- Security Tests: PASS
- Performance Tests: PASS
AUDITOR ATTESTATION:
I hereby attest that [System Name] has been evaluated and found
compliant with SSI Protocol Version 1.0 requirements.
Auditor Name: [Name]
Auditor ID: [Certification Number]
Signature: [Digital Signature]
Date: [Date]
NOTES:
[Any caveats, scope limitations, or recommendations]
---
This certificate is valid only for the specified version.
Changes to the implementation may require re-certification.
SSI COMPLIANCE AUDIT REPORT
===========================
EXECUTIVE SUMMARY
-----------------
System: [Name]
Audit Date: [Date]
Auditor: [Name]
Overall Result: [PASS / FAIL / CONDITIONAL PASS]
SCOPE
-----
- Source code review
- Test execution
- Documentation review
- Failure injection testing
- Security testing
FINDINGS
--------
1. Invariant Compliance: [PASS/FAIL]
- RPX record generation: [Details]
- Hash chain integrity: [Details]
- Fail-closed behavior: [Details]
2. Decision Scope: [PASS/FAIL]
- Decision classification: [Details]
- Outcome correctness: [Details]
3. Audit Capabilities: [PASS/FAIL]
- Verification tools: [Details]
- Tamper detection: [Details]
4. Failure Handling: [PASS/FAIL]
- Error handling: [Details]
- Emergency halt: [Details]
RECOMMENDATIONS
---------------
[Any suggested improvements, even if compliance passed]
CONCLUSION
----------
[System Name] [is/is not] compliant with SSI Protocol Version 1.0.
[If conditional:] Compliance is granted subject to remediation of:
- [Issue 1]
- [Issue 2]
Auditor Signature: [Signature]
Date: [Date]
End of SSI Protocol Compliance and Certification Framework