Show IH: Building a local-first trust layer for AI agents
Hey IH — I’m building HUQAN, an open-source, local-first trust layer for AI-assisted work.
The problem I’m exploring is the gap between an LLM’s output and the real-world action that output can trigger. A model can sound confident while the evidence is weak, a tool scope is too broad, or the next step should have required human approval.
HUQAN’s current focus is deliberately narrow: make claims and actions more inspectable through evidence, provenance, verification, policy and risk gates, approval boundaries, audit events, and Trust Receipts.
The local quickstart follows this path:
learn → review → approve → verify → Trust Receipt
Today, this is a local developer/runtime surface — not a claim that hallucinations disappear or that HUQAN is a finished universal governance platform.
I’m trying to learn where this boundary is most useful in practice. If you run AI agents or AI-assisted workflows, which failure would you want to inspect first: unsupported claims, prompt injection, excessive tool authority, or irreversible actions? What would make a Trust Receipt useful enough to keep in your workflow?
Repository: https://github.com/ali-ulu/huqan
The Trust Receipt idea is interesting because it gives you a record of what the system believes happened — but for higher-consequence workflows there’s still a separate question:
who independently verifies that the evidence, approval boundary and resulting action actually matched the intended governance path?
That’s the gap we’re exploring with OpsWatch: expected behaviour → observed action → control/approval path → evidence → independent verdict → re-verification after remediation.
Have you thought about an external assurance layer validating the Trust Receipt itself for higher-risk deployments?
Yes — I think that is an important distinction. In HUQAN today, a Trust Receipt is a local, auditable record of the supported path: what was proposed, which evidence and provenance were available, what policy/risk gate decided, what approval boundary applied, and what result was recorded. It is not an independent certification of the receipt or a claim that the whole deployment is governed.
For higher-risk deployments, an external assurance layer could independently validate receipt integrity, expected versus observed action, approval authority, evidence coverage, and re-verification after remediation. I see that as a complementary layer around HUQAN rather than something I would claim is already shipped. The key principle is that the assurance result should remain inspectable and challengeable too — not become another opaque score.
OpsWatch’s “expected behaviour → observed action → control/approval path → evidence → independent verdict → re-verification” framing is very close to the direction I would want to explore.
That’s exactly how I’d want the boundary drawn too.
The interesting model for me would be HUQAN retaining the local Trust Receipt and control path, while OpsWatch sits outside that execution environment and independently tests whether the resulting evidence actually supports the behaviour and assurance claims being made.
So rather than duplicating HUQAN, the layers could look something like:
HUQAN: action → policy/risk gate → approval → evidence → Trust Receipt
OpsWatch: expected behaviour → observed behaviour → receipt/control integrity → evidence sufficiency → independent verdict → remediation → re-verification
I strongly agree on keeping the assurance result inspectable and challengeable. An opaque “trust score” would defeat much of the purpose.
There may be a genuinely useful integration model here, particularly for higher-risk deployments where a client, board, regulator or enterprise buyer wants evidence produced by the system and a separate party independently validating that evidence.
I’d be very interested in exploring what a small HUQAN + OpsWatch reference workflow might look like.
Exactly. The goal is not just to decide whether an agent action is allowed, but to make the reasoning and evidence behind that decision inspectable before execution and auditable afterward.
That’s where Trust Receipts become important: they create a traceable boundary between what the agent proposed, what evidence supported it, what was approved, and what actually happened.
The interesting part is making agent actions inspectable before they become irreversible. Trust Receipts could be particularly useful if they make the evidence, approval boundary, and resulting action easy to audit afterward.