SDK Conformance Matrix
This page tracks the SDKs on main against the conformance levels. Level 3 is about evaluator semantics, not about which convenience features a language runtime layers on top, so this matrix separates core conformance from language-specific runtime helpers.
Current Status
| SDK | Level 0 | Level 1 | Level 2 | Level 3 | Notes |
|---|---|---|---|---|---|
| Rust | Yes | Yes | Yes | Yes | Reference implementation. Core evaluator plus Ed25519 signing. |
| TypeScript | Yes | Yes | Yes | Yes | Core evaluator plus Anthropic/OpenAI/MCP adapters, observers, and hot reload. |
| Python | Yes | Yes | Yes | Yes | Core evaluator plus observers, OpenAI/MCP adapters, and LangChain/CrewAI decorators. |
| Go | Yes | Yes | Yes | Yes | Core evaluator with receipts, sinks, and detection helpers; intentionally minimal runtime surface. |
The Level 3 status above is backed by each SDK exposing evaluate() and participating in the shared evaluation fixture corpus in CI.
Language Guides
If you want install steps and real entry-point examples for a specific language, start with the SDK sections in Getting Started:
- Rust SDK for the reference evaluator, built-in rulesets, and signing support
- TypeScript SDK for
HushGuard, adapters, observers, and hot reload - Python SDK for dataclass-based evaluation, middleware, and LangChain / CrewAI helpers
- Go SDK for the minimal runtime, receipts, sinks, and detection helpers
Feature Matrix
| Feature | Rust | TypeScript | Python | Go |
|---|---|---|---|---|
| Core Pipeline | ||||
| Parse | Yes | Yes | Yes | Yes |
| Validate | Yes | Yes | Yes | Yes |
| Merge | Yes | Yes | Yes | Yes |
Resolve (extends) |
Yes | Yes | Yes | Yes |
| Evaluate | Yes | Yes | Yes | Yes |
| Audit & Detection | ||||
| Decision receipts | Yes | Yes | Yes | Yes |
| Receipt sinks | Yes | Yes | Yes | Yes |
| Detection helpers | Yes | Yes | Yes | Yes |
| Runtime Helpers | ||||
HushGuard middleware |
No | Yes | Yes | No |
| Observer / event layer | No | Yes | Yes | No |
| Framework adapters | No | Yes | Yes | No |
| Watcher / poller / provider | No | Yes | No | No |
| Ed25519 signing | Yes | No | No | No |
SDK-Specific Notes
Rust SDK
- Acts as the reference implementation for the evaluator and signing flow
- Exports the core runtime, receipt generation, sinks, detection helpers, governance checks, and panic mode
- Is the only SDK that currently exposes Ed25519 signing and verification
TypeScript SDK
- Ships the full evaluator plus
HushGuard, observers, receipt sinks, and detection helpers - Includes Anthropic, OpenAI, and MCP adapters for mapping tool calls into
EvaluationActionobjects - Adds
PolicyWatcher,PolicyPoller,FileProvider, andHttpProviderfor long-running services
Python SDK
- Ships the full evaluator plus
HushGuard, observers, receipt sinks, and detection helpers - Includes OpenAI and MCP adapters as well as
hush_toolandsecure_tooldecorators for LangChain and CrewAI - Keeps the API close to the TypeScript middleware model while staying idiomatic to Python dataclasses
Go SDK
- Focuses on the core runtime: parse, validate, merge, resolve, evaluate, receipts, sinks, detection, and panic mode
- Participates in the shared evaluator fixture corpus and cross-SDK roundtrip checks
- Does not currently expose an observer layer, middleware wrapper, or hot-reload helper
Shared Contract and CI Evidence
The SDKs stay aligned through the shared schemas, generated contracts, and the CI fixture corpus. The main workflow publishes the evidence this page relies on:
- generated-sources checks the generated contract and model outputs that keep the SDKs synchronized
- rust, typescript, python, and go run each SDK's native unit and package tests
- shared-fixtures runs the same conformance fixture corpus against all four SDKs
- cross-sdk-roundtrip round-trips the shared corpus through all four SDKs and compares normalized outputs
- smoke-snippets executes the marked README and getting-started code snippets directly from the markdown source
The workflow definition lives in .github/workflows/ci.yml.