🌉 Hashimori
橋守 · the bridge keeper
A tiny, deterministic rules engine for AI use case governance. Policy in YAML. Intake in JSON. Decision in milliseconds — with an audit trail.
Your AI policy is a PDF. Your teams ship AI features every week. The bridge between those two facts is, today, a spreadsheet and a recurring meeting — and it is either a rubber stamp or a bottleneck, depending on the week.
Security teams are good at digging moats. Hashimori is the bridge keeper: the small, boring, auditable piece of code that decides what crosses, what doesn't, and what needs a human — so your reviewers spend their judgment on the five cases that deserve it instead of the fifty that don't.
Sixty seconds
No install, no clone — paste this:
curl -sL https://raw.githubusercontent.com/OSMoats/hashimori/main/rulepacks/red-zone/red-zone.yaml -o red-zone.yaml
curl -sL https://raw.githubusercontent.com/OSMoats/hashimori/main/examples/intake/loan-agent.json -o loan-agent.json
uvx --from git+https://github.com/OSMoats/hashimori hashimori evaluate --rules red-zone.yaml --context loan-agent.json
No uv? pipx run does the same thing:
pipx run --spec git+https://github.com/OSMoats/hashimori hashimori evaluate --rules red-zone.yaml --context loan-agent.json
🌉 hashimori v0.2.0 → DENIED
⛔ RED ZONE — evaluation short-circuited. No review queue. No committee.
REDZONE-001 Consequential decisions with no human in the loop [red-zone]
Fully automated decisions that materially affect a person's access to
credit, work, housing, care, or justice are categorically prohibited.
↳ path to yes: Put a qualified human between the model output and the
decision taking effect (review-and-approve, not review-after-the-fact),
then resubmit.
REDZONE-005 Irreversible autonomous actions without a gate or rollback [red-zone]
Agents that move money, delete data, or change production systems must
have an approval gate AND a rollback plan before they run unattended.
↳ path to yes: Add an approval gate for irreversible actions and a
tested rollback plan, then resubmit.
audit: context 4e84afea7ff2… · 1 pack(s) hashed · 2026-09-09T00:16:08Z
That rejection took milliseconds, cited two exact rules, told the team how to fix each one, and left a reproducible audit record — and nothing was installed on your machine. Nobody scheduled a meeting.
Want it around for good? pip install git+https://github.com/OSMoats/hashimori,
or git clone the repo to explore the rule packs, skills, and tests directly.
How it works
1. Red zones short-circuit. Every enterprise AI policy has a "never"
list. Hashimori checks it first, and a match is an instant, final DENIED —
with the rule's message and its remedy (the path to yes). Your highest-risk
patterns get your fastest answers.
2. Everything else is graduated. Risk factors add weights to a score; the score picks a tier: fast-track auto-approval with obligations, standard security review with an SLA, or elevated review with the full committee. Most submissions are boring — the engine clears them so humans review the rest.
3. Unknowns fail closed. Conditions evaluate three-valued: true, false, or unknown when the intake didn't answer the question. A use case with unknowns can never be auto-approved — it routes to review with the missing answers named. The vague submission doesn't slip through; it gets a to-do list.
4. Every decision is reproducible. Decisions carry SHA-256 hashes of the rule packs and the intake context, the engine version, and the reason chain. Same inputs, same decision — provable in an audit, two years later.
# This is a complete, working red zone.
red_zones:
- id: REDZONE-001
name: Consequential decisions with no human in the loop
when:
all:
- path: use_case.decision_impact
in: [credit, employment, housing, medical, legal]
- path: oversight.human_in_loop
is: false
message: Fully automated consequential decisions are prohibited.
remedy: Add pre-decision human review, then resubmit.
refs: [NIST-AI-RMF:MANAGE-2.2, EU-AI-Act:Art.14]
Full schema: docs/schema.md.
No LLM in the decision path. Ever.
This is the design decision everything else hangs on. Models are brilliant at reading policies and terrible at being audited — so Hashimori uses AI only at the edges, through four drop-in agent skills:
policy-to-rules— feed it your AI policy (PDF, Word, text, markdown); it emits a validated rule pack with tests, and an honest list of what it couldn't encode.intake-copilot— turns a team's messy PRD or Slack thread into clean intake JSON, and refuses to launder risk.decision-memo— turns a decision JSON into a kind, clear memo for the team and a complete record for GRC.rule-redteam— attacks your rule pack and hands you the holes as failing test cases.
The skills draft; the engine decides; humans own the policy. That's the whole trick.
Your policy, tested like code
Rule packs ship with decision tests, and CI fails when a policy change flips a decision you didn't mean to flip:
hashimori test examples/tests/decisions.yaml --rules rulepacks/baseline rulepacks/red-zone
✓ internal docs answerbot fast-tracks
✓ autonomous loan agent is denied without a meeting
✓ vague submission fails closed, never approves
✓ employee emotion recognition has no path to yes
7/7 policy tests passed
Governance as a pull request
The best intake form is a file in the team's own repo. With the GitHub Actions integration, teams submit AI use cases as PRs: red zones fail the check with the remedy in the log, "needs review" auto-assigns your reviewers via CODEOWNERS, and the merge is the auditable record.
Start with your own policy
hashimori init governance/ # rules + intake template + tests, ready to edit
or point the policy-to-rules skill at the PDF you already have. The shipped
rulepacks encode the "never" list and graduated-review shape
most enterprise AI policies share — edit the vocabulary and weights to match
yours. (They're engineering starting points, not legal advice.) A worked
industry example — rulepacks/healthcare — shows
how to extend the vocabulary for a specific domain (FDA SaMD clearance,
HIPAA BAAs, 42 CFR Part 2 consent) and compose it correctly alongside the
red-zone pack.
Industry packs layer on top of red-zone instead of
baseline and bring their own vocabulary — see
rulepacks/finance for credit/underwriting, AML,
algorithmic trading, robo-advice, and third-party cardholder-data patterns:
six red zones and eight risk factors mapped to DORA, APRA:CPS230/CPS234,
PCI-DSS, ECOA/Reg B, FCRA, SR-11-7, SEC, and FINRA.
What Hashimori is not
- Not a GRC platform. It's the ~600-line decision core that platforms are missing. Bring your own intake UI, ticketing, and dashboards — or use the PR flow and have none.
- Not a model evaluator. It governs use cases (what you deploy, to whom, with what oversight), not model weights.
- Not vendor-anything. MIT-licensed, one dependency (PyYAML), runs anywhere Python runs, exports plain JSON. Fork it and make it yours — that's the point.
Hashimori vs. OPA vs. a GRC platform
Three different tools that get compared because they all touch "policy" — here's how to tell which one you actually need in about thirty seconds.
| Hashimori | OPA / Rego | Generic GRC platform (Vanta, OneTrust, Credo AI, ...) | |
|---|---|---|---|
| Purpose-built for AI use-case governance | Yes — red_zones, risk_factors, tiers, reviewers, remedy are AI-governance-shaped out of the box |
No — general-purpose policy engine; you build this vocabulary yourself in Rego | Partial — usually an "AI governance" module bolted onto a much broader compliance product |
| Policy language | A small YAML condition tree (leaf + all/any/none) |
Rego — a full declarative logic language, far more expressive, far steeper learning curve | Usually a proprietary rules/form builder, not a language |
| Where policy lives | A YAML file in your own git repo | A .rego file in your own git repo |
A vendor's hosted UI — not yours, not in your git history |
| Core you can actually read | ~600 lines, one engineer, one afternoon | The OPA runtime — mature, but nobody reads it end to end before trusting it | Closed source |
| A decision is | A pure function of (packs, context) — reproducible, SHA-256 hashed | A pure function of (policy, input) — reproducible | Usually workflow-driven (tickets, approvals) — not a deterministic function |
| Rule packs ship with tests | Yes, first-class (hashimori test) |
Yes, via opa test |
Rarely a concept at all |
| Broader compliance surface (vendor risk, evidence collection, training tracking, cross-framework audit mapping) | No — deliberately out of scope | No | Yes — this is the point of a GRC platform |
| Ecosystem maturity (sidecars, admission control, bundles, decision logs at scale) | Still small and young | Yes — mature, used far beyond AI (Kubernetes, API authz, infra-as-code) | Yes — mature, enterprise-grade |
| Generates/red-teams rule packs from a policy doc via AI | Yes (policy-to-rules, rule-redteam skills) |
No | No |
| Cost / license | Free, MIT | Free, Apache 2.0 | Usually paid, often enterprise-priced |
Need general-purpose policy enforcement across many systems, not just AI intake? Use OPA — it's more powerful and more mature. Need a single system of record for your whole compliance program — vendor risk, evidence, audits? Use a GRC platform. Need the specific "should we approve this AI use case" decision, in code, reviewable by one engineer, with an audit trail two years from now? That's what Hashimori is for.
Design principles
- Deterministic core, intelligent edges. Auditability is a feature you can't retrofit.
- Small enough to read. One security engineer can review the entire engine before trusting it. That is a governance property, not a nicety.
- The remedy is part of the rejection. Governance that only says "no" trains teams to route around it. Every red zone ships a path to yes.
- Fail closed, loudly. Missing answers create review work, never silent approvals.
Contributing
Rule packs for your industry, integration recipes, and new edge skills are the most valuable contributions — see CONTRIBUTING.md.
License
MIT. Built by Aakash Yadav and contributors, in a personal capacity. First presented at AI TechWorld 2026.
The financial-services rule pack was built by Tushar Badlani, in a personal capacity.
Release files for hashimori 0.2.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| hashimori-0.2.0.tar.gz | 28.1 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| hashimori-0.2.0-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 46.9 kB
Release files / hashimori-0.2.0.tar.gz
| Download URL | hashimori-0.2.0.tar.gz |
|---|---|
| Size | 28.1 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
b9ecaee5d6edd48dd3ef83fcff77a9097b6e7ddcfc10eff2c1b89971b5832183
|
|
BLAKE2b-256 checksum How to use checksums |
aee48af36ba6255a980d573c7a7a82d681a5f3460205aacad158928d9a5108b6
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 9, 2026.
Transparency logRelease files / hashimori-0.2.0-py3-none-any.whl
| Download URL | hashimori-0.2.0-py3-none-any.whl |
|---|---|
| Size | 18.8 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
3a4ec7b3e16c54c30fe3a1fc325866f6f612b8e7283f2e25fcd4fb423abf11ca
|
|
BLAKE2b-256 checksum How to use checksums |
fdf0c33b86664dd034b935404f34b25185710b44d3d21b79fd01fc2ff94cb373
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
Yes |
| Uploaded via |
twine/7.0.0 CPython/3.13.14
|
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
PyPI Publish Attestation
PyPI verified that this artifact, at this checksum, originated from the publisher listed below.
Signed by GitHub Actions, verified by PyPI on Sep 9, 2026.
Transparency log