Reproducible evidence

Seven local control scenarios with OpenShell.

A bounded interoperability qualification of runtime policy, action authorization, evidence freshness and outcome comparison. No real payments or customer systems were involved.

What was tested?

A real OpenShell Docker supervisor invoked external gRPC middleware at HTTP_REQUEST / PRE_CREDENTIALS. A local deterministic evaluator governed a mock PAY_INVOICE API. The committed run generated 2026-09-29T20:53:26.740263+00:00 reports PASS for all seven expected behaviors. This page summarizes that historical report; it does not claim a new qualification run.

Prudenze is a Hyperwise LLC product. Published by the Hyperwise team. Source revision: d8370eb467522e9f6f595bb550cea5786def581c.

Recorded scenario results

PASS means the expected behavior occurred. In G, a mismatch is deliberately introduced and must be detected. Revera-style comparison observes the outcome after execution; it does not prevent or reverse the action.

Committed local qualification, September 29, 2026
ScenarioRuntimeAuthorityPolicyFreshCtxDecisionAPI reachedComparisonResult
ABLOCKNOT_EVALUATEDNOT_EVALUATEDNOT_EVALUATEDNOT_INVOKEDNoNOT_APPLICABLEPASS
BPERMITVALIDPASSCURRENTALLOWYesMATCHPASS
CPERMITINVALIDHUMAN_APPROVAL_REQUIREDCURRENTDENYNoNOT_APPLICABLEPASS
DPERMITVALIDHUMAN_APPROVAL_REQUIREDCURRENTESCALATENoNOT_APPLICABLEPASS
EPERMITVALIDPASSSTALE_REASONINGDENYNoNOT_APPLICABLEPASS
FPERMITVALIDPASSUNVERIFIABLEDENYNoNOT_APPLICABLEPASS
GPERMITVALIDPASSCURRENTALLOWYesMISMATCHPASS

B: USD 500 proposed and observed. C: USD 1,500 denied for invalid authority. D: USD 900 stopped for human approval. E: V1 reasoning versus V2 action evidence. F: action evidence unavailable. G: USD 500 proposed versus USD 501 observed.

Inspect machine-readable outcomes, timestamps and evidence versions · Read the original report

Pinned tested configuration

  • OpenShell 0.1.2, commit 6648bd0c290efbc41ba131ee9831ee45cd431f94
  • Supervisor middleware protocol 1.0
  • FreshCtx 0.17.0 from public PyPI; Python 3.13.13
  • macOS 26.6.2 arm64; Docker 29.7.2 aarch64 Docker Desktop
  • mTLS gateway and launch-scoped JWT; plaintext local-development middleware transport explicitly enabled for this isolated run.

How to reproduce

Use an isolated Apple Silicon Mac with Docker Desktop 28.0 or later running, Homebrew, Python 3.13, curl, shasum and OpenSSL. Review the pinned script before running it: it installs or validates tools, downloads dependencies, creates local processes and sandboxes, writes reports and cleans up its runtime resources. Do not use production credentials, real funds or customer data.

git clone https://github.com/Hyperwise-LLC/prudenze-openshell.git
cd prudenze-openshell
git checkout d8370eb467522e9f6f595bb550cea5786def581c
./scripts/qualify.sh

Compare reports/qualification.json with the pinned report: seven scenario IDs A–G, expected API reachability and the amount discrepancy in G. The script checksum-pins protocol definitions and uses FreshCtx 0.17.0. A rerun may require compatible local infrastructure; these results do not imply compatibility with newer OpenShell versions.

Review the exact qualification script

What this evidence does not establish

This is a local deterministic mock-payment benchmark. It does not establish production readiness, customer deployment, availability, throughput, latency, multi-tenant isolation, financial compliance or correctness of production Arkon, Guardian, Revera, Claims, Supabase or Azure integrations. FreshCtx tests declared evidence equivalence and availability, not truth. Plaintext middleware transport is limited to this local development setup.

No NVIDIA partnership, certification, endorsement, approval or validation is claimed. No real payments were processed. Production evaluation requires a separate threat model, transport security, integration, performance and deployment review.

Read the source claim limitations

Use the evidence in a buying decision

Ask where authorization is enforced, how missing approval blocks execution, how stale evidence is handled, and how receipts are compared with intent. Start with execution governance, failure testing and outcome verification. Then define the controls and acceptance tests needed for your environment.