> ## Documentation Index
> Fetch the complete documentation index at: https://npupko.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# TypeScript and Rust SDKs for Building Hibi Resolvers
> The TypeScript and Rust SDKs handle JSONL-RPC framing for Hibi resolvers. Both bind to one shared JSON Schema source of truth from the Hibi data model.
A **resolver** is an out-of-process program that Hibi calls to grade an anchor or run a
verifier. Hibi talks to it in JSONL-RPC over stdio, one JSON message per line. The
SDKs exist so you don't have to hand-roll that framing or re-derive the message shapes:
they give you typed scaffolding in TypeScript or Rust, and you fill in the drift logic.
For the protocol itself (the methods, the request/response shapes, the
default-deny manifest), start at [Resolvers](/resolvers). The SDKs are the
language bindings on top of it.
Write resolvers in TypeScript, run them with Bun.
A native crate with a worked `echo_resolver` example.
## What both SDKs implement
Every resolver, whatever language it's written in, answers the same three-method
protocol. Each SDK reads framed requests from stdin, dispatches to your handler, and
writes framed responses to stdout.
| Method | What you return | Purpose |
| ---------- | ------------------------------------------------- | ----------------------------------------------------- |
| `describe` | the anchor `kinds` and `verifierKinds` you handle | announce your capabilities at startup |
| `resolve` | a verdict for an assertion's anchor | grade whether the anchored code drifted |
| `verify` | `supported` or `refuted` | run an executable verifier against a behavioral claim |
On `resolve`, the engine reads the relevant files itself and passes them to you as
`files { doc, code: { path: content } }`; your resolver never reaches into the working
tree. The verdict you return reads like the rest of Hibi's output:
`doc:unchanged · code:changed · behavior:at-risk` (see [Verdicts](/verdicts) for the
full vocabulary).
Verifier `kind`s are **open strings**, not a schema enum: the engine routes a
`verify` call to your resolver by exact string match, so a verifier reaches you only
when its `kind` appears in the `verifierKinds` you returned from `describe`. Declare
`"command"`, `"snapshot"`, or any string you invent — the `verify` request and
response contract is the same for every kind; only the routing key varies.
A resolver that grades anchors is advisory unless it's the engine's own built-in drift
logic. An opt-in semantic advisor may explain or triage a verdict; it never gates and
never marks a claim supported. The line stays at [Resolvers](/resolvers).
## The shared contract
The two SDKs are not independent re-implementations that can drift apart. Both bind to
**one** source of truth: every message type has a JSON Schema in
[`schemas/`](https://github.com/npupko/hibi/tree/main/schemas), generated from Hibi's
single Zod model (`src/core/model.ts`) and the protocol definition
(`src/resolver/protocol.ts`).
That single generation step has two payoffs:
* The TypeScript and Rust bindings stay in lockstep with the engine: when the model
changes, the schemas regenerate and both SDKs follow.
* A resolver in **any** language with a JSON Schema toolchain can validate its messages
against the same canonical contract, even without an SDK. The SDKs are a convenience,
not a requirement.
You can emit the schemas yourself from the CLI:
```sh theme={null}
hibi schema # all schemas
hibi schema --name Verdict # one named schema
```
## Building the Rust SDK
The Rust SDK is a standalone crate: it builds without the CLI, so you can develop a
native resolver in isolation and run the worked example:
```sh theme={null}
cd sdk/rust && cargo build --examples
```
## Next
The protocol the SDKs implement: methods, the JSONL-RPC seam, the default-deny manifest.
Where `verify` fits: executable verifiers, the change-gate, and the no-model boundary.