Steward: Contract-driven governance engine for AI systems

community
1

I'm sharing Steward, an open-source governance engine for evaluating AI outputs against human-authored contracts.

The goal: deterministic, traceable verdicts (PROCEED / ESCALATE / BLOCKED) with evidence-backed accountability.

Crate structure:

steward-core → Deterministic evaluation (zero LLM calls)
steward-runtime → Optional async LLM orchestration
steward-cli → Pipe-friendly CLI

Key design decisions:

  1. Parallel lenses with tokio::join! — Five independent evaluators fan-out, synthesizer fans-in. Each lens implements a Lens trait; runtime uses LensAgent (async). Reasonable pattern or overengineered?
  2. BTreeMap for determinism — All config maps use BTreeMap + LensType derives Ord to guarantee iteration order. Worth the overhead vs IndexMap?
  3. ProviderFactory trait for LLM providers — Dynamic registration via ProviderRegistry instead of a ProviderType enum. Adds complexity but avoids enum bloat as providers grow.
  4. Hard boundary: no LLM in steward-core — The synthesizer is a strict policy machine. All LLM assistance lives in steward-runtime. Is this separation clear from the API?
  5. Fallback chain — On LLM failure: Cache → Simpler Model → Deterministic (core) → Escalate. Configured via Vec. Suggestions on the pattern?

Also includes:

  • Python bindings (PyO3/maturin)
  • Node.js bindings (napi-rs)
  • Domain packs: healthcare, finance, legal, education, HR

Repo: Steward GitHub

This is a work in progress—contributors welcome.
Happy to receive any feedback.
Thank you!

2

Is is a fun work, or you are looking for a purchaser? If second, then let me know.

1 Like