arian-gogani/nobulex

> **Current billing research:** When a billing dry run agrees with the wrong invoice. On released Kill Bill 0.24.19, embedded-H2 regressions reproduced two catalog-change amount errors before separate proposed fixes in PR #2320 and PR #2321, then passed with those fixes. Both PRs are open. This is research, not a deployed Nobulex billing control or a customer result. If you own a billing release process, the note asks one concrete question about how you independently check expected invoices.
> **Verification-boundaries research:** What did PASS actually check? Six paired historical parser cases, 27 synthetic fixtures, explicit limits, and corrections to our own benchmark.
**Decision integrity for automated financial actions.** A market-data response can be well formed and still contain stale prices, missing sessions or the wrong instrument. The current Nobulex prototype checks evidence about a proposed action, evaluates a bounded policy, and returns PERMIT, BLOCK or ESCALATE with a receipt.
The active code and instructions live in **nobulex-registry**. Despite its name, that repository now houses the gateway and its verification harness. This repository preserves our earlier agent-receipt and trust-score implementation; it is no longer the product landing page.
| Start with | What you can check |
|---|---|
| Offline wrong-window example | Three fictional time-series cases through a real classifier, including a case that must abstain. |
| Gateway code and tests | How evidence status and execution decision are kept separate. |
| Verification-boundaries study | Where a PASS verdict stops being justified, including corrections to our own benchmark. |
| Methodology | What a signed receipt proves, and what it cannot prove. |
Run the offline example after cloning the active repository:
**Current limit:** the published prototype is not connected to a customer's production execution path. The offline example uses fictional data. A signature authenticates a decision record; it does not establish that the financial data in it is true.
If your team has seen valid-looking data produce a wrong financial action, email a short example. A description without credentials or customer data is enough. You can also open a reproducible issue against the prototype.
Earlier Nobulex receipt and trust-score direction (historical)
The material below is preserved for readers of the earlier implementation. It is not the current offer, a fresh verification of its claims, or evidence of production trading protection. The old notice incorrectly said that nothing below was retracted; that blanket assurance was too broad.
---
**What this repository was built as.**
A credit and trust protocol for autonomous AI agents: actions produce signed
receipts, receipts accumulate into a trust score, and a higher score unlocks
more access. Everything below is that implementation, kept readable. It is not
the current direction, which is the gateway linked at the top of this file.
Website · Quickstart · Spec · PyPI · npm
Reference implementation of the **OWASP Agentic Skills Top 10 (AST09)** execution-receipt pattern · listed in the OWASP solutions catalog · in the Microsoft Agent Governance Toolkit adopters · merged to the Dify marketplace
---
Install
---
How it works
Every agent action produces a cryptographic receipt -- Ed25519 signed before and after execution, hash-chained for tamper evidence. A third party can verify the full history without trusting the agent or the operator.
Here is the whole idea in one run (python -m nobulex demo):
Change one byte of a receipt and verification fails. That is the whole guarantee.
**Performance:** ~13,683 signed receipts/sec at p50 (Python SDK, single core). Full signed-and-chained receipt takes ~73 μs end-to-end. See BENCHMARKS.md for the full breakdown; reproduce with python3 scripts/benchmark.py.