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.