Open-source Ink Receipt gates for accountable AI agents.
Black Box Labs builds model-agnostic INK Receipts with a Rust trust waist and Python product surface.
BLKBX Lab is not a chatbot wrapper.
BLKBX Lab is a receipt engine for AI actions.
The point of this repo is simple:
A regulated customer should be able to verify an AI evidence artifact locally, without trusting the vendor's hosted dashboard.
The current codebase ships:
- a Python SDK and CLI
- a Rust native trust boundary
- a deterministic
qwen35demo adapter - local evidence bundle generation
- signed INK receipt issuance
- receipt verification
- tamper demonstration
- comparison reports
- product facades for
BLKBXS,MAND8, andDUE
The codebase is intentionally mixed-language:
| Layer | Language | Job |
|---|---|---|
| Product SDK / CLI | Python | developer-facing workflow, artifacts, demos, product facades |
| Trust waist | Rust | canonical receipt semantics, signing, verification, native boundary |
| Portal scaffolds | Ruby / Rails, TypeScript | future commercial and browser surfaces, not the trust root |
| Docs / schemas / policies | Markdown, JSON, TOML, YAML | public contract, verification policy, release discipline |
The dashboard is not the source of truth.
The receipt is.
The verifier is.
Hard-written worktree snapshot as of Saturday, July 25, 2026:
| Language | LOC | Where |
|---|---|---|
| Rust | 12,900 | rust/crates/* trust waist, issuer, verifier, WASM, and TUI crates |
| Ruby | 12,581 | web/rails/* Rails console, Artifact API, workflow services, and specs |
| Python | 9,969 | python/*, product source slices, tests, and appliance verifier scripts |
| JSON | 5,582 | schemas, fixtures, packet examples, policies, manifests, and brand tokens |
| Markdown | 5,178 | active docs, READMEs, product docs, runbooks, and repo guidance |
| TypeScript | 462 | packages/ink-ts-verify verifier primitives |
| TOML | 446 | Cargo manifests, pyproject.toml, and tool config |
| YAML | 516 | CI, policy, Compose, queue, and workflow config |
| CSS | 921 | browser verifier and Rails/static UI surfaces |
| JavaScript | 576 | browser verifier and generated support scripts |
| HTML | 106 | static verifier shell |
| Shell | 285 | release, demo, and appliance scripts |
| Dockerfile | 15 | appliance container build files |
| Total counted | 49,537 | 649 current worktree files in counted languages |
Counting basis: current worktree files, including untracked implementation files, excluding build outputs, caches, virtualenvs, generated package directories, target/, and local artifact directories.
These numbers are here on purpose. The repo is not small, and the shape matters.
One idea, three go-to-market wrappers around it:
A product emits a signed, canonical receipt - a small cryptographic claim that says "this specific evidence was produced by this issuer, under this schema, at this point in its lifecycle." Anyone holding the receipt, the evidence it points to, a trust registry, and a policy file can verify it themselves, offline, without asking the issuer's API or dashboard anything.
ink-core and ink-host are the shared engine that make a receipt real: hash it, sign it, verify it, and check trust and revocation. blkbx_lab, mand8, and due are three different business vocabularies built on that same engine - AI-agent action receipts, insurance underwriting and risk receipts, and legal-matter defensibility receipts.
web/rails is a hosted multi-tenant backend meant to serve all three brands from one deployment. web/verify and packages/ink-ts-verify are the receiving-party verification surfaces or scaffolds: the piece a bank, insurer, or legal team should be able to run without trusting any hosted BLKBX interface.
The self-hosted package lives in bankabil-local-node/.
Bankabil is a self-hosted evidence appliance for startups selling into regulated institutions. It runs locally, issues verifiable receipts, generates UBR packets, and lets reviewers verify artifacts without trusting the startup dashboard or Bankabil cloud.
The appliance has two mutually exclusive profiles:
- Startup Node: Rails console, PostgreSQL, Solid Queue, and local
ink-issuer-service; it owns local signing configuration and exports BLKBXS UBR verifier packets. - Verifier Node: static
web/verifyplus a nativeinkCLI wrapper; it imports packets, verifies portable receipts, writes verifier reports, and never mounts startup signing keys.
The Startup Node exposes the Rails Artifact API under /api/v1/artifacts/*. The Verifier Node verifies exported packets through bankabil_packet_manifest.json and portable ink.receipt.v2 files. Rails can organize workflow state, but the receipt and verifier remain the trust boundary.
The published package is:
pip install --pre mechlab-sdkOptional extras:
pip install --pre "mechlab-sdk[research]"
pip install --pre "mechlab-sdk[experimental]"
pip install --pre "mechlab-sdk[all]"The primary CLI is blkbx-lab.
The compatibility CLI is mechlab.
The primary Python import is import blkbx_lab as bl.
Product facades are carried by the same wheel: import blkbxs, import mand8, import due.
Run the deterministic demo:
blkbx-lab demo qwen35 --output-dir artifacts/qwen35Verify the receipt:
blkbx-lab verify artifacts/qwen35/ink_receipt.v2.jsonTamper with the receipt:
blkbx-lab tamper artifacts/qwen35/ink_receipt.v2.jsonVerify the tampered receipt:
blkbx-lab verify artifacts/qwen35/ink_receipt.tampered.v2.jsonExpected result:
- the original receipt verifies
- the tampered receipt fails
- the artifact stays local
- the verification path does not depend on a BLKBX-hosted API
Python version:
import blkbx_lab as bl
result = bl.demo(output_dir="artifacts/qwen35")
print(result.manifest_path)
print(result.receipt_path)
verification = bl.verify(result.receipt_path)
print(verification.report)The current CLI exposes:
blkbx-lab demo Run the deterministic qwen35 demo
blkbx-lab doctor Check native runtime, trust policy, and signer state
blkbx-lab trace Capture deterministic demo evidence
blkbx-lab analyze Validate a bundle and evaluate a policy
blkbx-lab gate Issue a signed v2 receipt
blkbx-lab verify Verify a receipt
blkbx-lab compare Compare two verified v2 receipts
blkbx-lab tamper Mutate a receipt for demo purposes
blkbx-lab explain Explain a receipt decision
blkbx-lab report Render a human-readable summary
This is a real CLI surface. It is not just README copy.
Core public calls:
bl.doctor()
bl.trace(...)
bl.analyze(...)
bl.gate(...)
bl.verify(...)
bl.compare(...)
bl.demo(...)
bl.tamper(...)
bl.explain(...)
bl.report(...)
Public result objects:
DoctorResult
ActionEvidenceBundle
GateAnalysisResult
InkReceiptResult
ReceiptComparisonPacket
The receipt flow produces boring files on purpose.
| File | Purpose |
|---|---|
prompt.txt |
captured prompt text |
action.json |
normalized action object |
runtime.json |
runtime declaration |
demo_mapping.json |
deterministic demo mapping |
model_waist.json |
model/runtime waist evidence |
ink_manifest.v2.json |
evidence manifest |
ink_receipt.v2.json |
signed receipt |
ink_receipt.tampered.v2.json |
intentionally mutated demo receipt |
receipt_comparison.v2.json |
left/right receipt comparison packet |
The artifacts are meant to be moved, inspected, archived, and verified outside the vendor's system.
regulated buyer
|
v
local receipt verification
|
v
+--------------------------------------------------+
| Rust trust waist |
|--------------------------------------------------|
| ink-core no_std receipt kernel |
| ink-sign signing boundary |
| ink-verify verification primitives |
| ink-vectors deterministic test vectors |
| ink-receipt-v2 current v2 receipt verifier |
| ink-issuer-service local HTTP issuer |
| ink-cli file-based verifier CLI |
| ink-tui zero-JS terminal verifier |
| ink-wasm portable verifier target |
| ink-host std host adapter |
| ink-py PyO3 bridge into Python |
+--------------------------------------------------+
^
|
+--------------------------------------------------+
| Python public surface |
|--------------------------------------------------|
| blkbx_lab SDK, CLI, artifact orchestration |
| blkbxs banking-facing facade |
| mand8 insurance-facing facade |
| due legal-facing facade |
| adapters deterministic qwen35 adapter |
| policies demo and verification policies |
| schemas public artifact schemas |
+--------------------------------------------------+
^
|
+--------------------------------------------------+
| Commercial and appliance surfaces |
|--------------------------------------------------|
| Rails console, workflow API, Artifact API |
| TypeScript browser/static verifier scaffold |
| Compose startup and verifier node profiles |
+--------------------------------------------------+
Rust is here because the trust boundary has to be small.
The Rust layer owns the hard parts:
- receipt semantics
- canonical digest boundaries
- signing and verification
- kernel-level validation
- native verifier behavior
- WASM-compatible verification path
- zero-JS local verification path
- test vectors
- policy enforcement boundaries
ink-core is the important design signal:
#![no_std]
#![forbid(unsafe_code)]That means the kernel is intentionally constrained.
The goal is not "rewrite the app in Rust."
The goal is:
keep the receipt verifier small enough to audit and harden.
Python is here because developers need a usable surface.
The Python layer owns:
- CLI ergonomics
- SDK ergonomics
- deterministic demo flow
- artifact writing
- product facades
- policy inputs
- controls inputs
- report rendering
- packaging
But the Python layer does not silently replace the native trust path.
If blkbx_lab._ink_native is unavailable, trust operations fail instead of falling back to a looser Python implementation.
That is intentional.
Rails is a console and workflow layer.
Rails can handle:
- issuer accounts
- buyer review rooms
- receipt upload
- evidence bundle presentation
- trust registry management
- workflow status
- BLKBXS / MAND8 / DUE commercial UX
- Artifact API endpoints for generated verifier, completeness, defect, passport, replay, and export artifacts
Rails should not become the verifier.
The verifier must remain portable and local.
A portal can make verification easier to understand.
It must not be required for verification.
rust/crates/ is the trust waist:
ink-coreis theno_std,unsafe-forbidden kernelink-hosthandles file I/O, trust registries, revocations, and signing dispatchink-receipt-v2defines the portable evidence-bundle verifier surfaceink-cliandink-tuiare real native verification entrypointsink-wasmis the browser-facing verifier target, but it is not the primary trust pathink-pyis the PyO3 bridge into Python
python/blkbx_lab is the public SDK and CLI surface. python/due and python/mand8 are thin shims over the real product logic in products/due-sdk and products/mand8-sdk.
web/rails is the multi-tenant backend for commercial workflow and account surfaces. In appliance mode it runs as the Startup Node console and Artifact API. It is real application code, but it is not the verifier and it does not redefine the trust boundary.
packages/ink-ts-verify is an early-stage TypeScript verifier primitive. web/verify is a Rust-backed browser verifier surface over ink-wasm, but it remains outside the trust root and only works on real portable INK artifacts.
Banking-facing receipt infrastructure and event evidence.
Core claim:
A bank can independently verify a vendor-produced AI receipt.
BLKBXS is for fintech, banktech, and AI vendors selling into regulated financial institutions.
The current BLKBXS UBR path models a small-business loan workflow as eight Universal Banking Receipt events:
- consent
- KYB
- documents
- cashflow analysis
- AI recommendation
- human review
- loan decision
- conditional approval notice
In the Python package, blkbxs.scenarios.smb_loan_demo() loads the committed fixture generated from the UBR demo bundle and orders the graph topologically. Rails imports that packaged fixture through Blkbxs::DemoCatalog; it does not hand-author a second copy of the scenario.
The UBR JSON is the banking-domain view stored in receipt body_json. The trust record is the linked portable ink.receipt.v2 issued by the in-process bankabil_kernel native Ruby gem or, for compatibility, the configured INK issuer service. POST /api/v1/blkbxs/ubr_receipts requires a production-capable native signer or INK_ISSUER_SERVICE_URL; if issuance is missing, fails, or returns no portable receipt, the transaction rolls back and no unsigned UBR receipt is persisted.
The Bankabil Evidence Appliance packages this path for local use. Startup Node uses a local ink-issuer-service with file_ed25519 signing to issue portable receipts, then exports UBR packets containing bankabil_packet_manifest.json, receipt_graph.json, receipt files, claims-boundary and exception-register outputs, and local verification instructions. Verifier Node imports those packets and runs the native verifier without Rails, Postgres, or signing keys.
The active BLKBXS UBR contract is documented in docs/bank-verifiable-receipts.md.
Insurance-facing receipt infrastructure.
Core claim:
AI risk should be packaged for underwriting, monitoring, renewal, and claims defensibility.
MAND8 is not just "BLKBXS for insurance."
MAND8 is the insurability slice.
The public MAND8 Python surface includes mand8.authority.record() alongside exposure, control, override, incident, bundle, and schema helpers.
The Lloyd's Labs demo path is documented in docs/mand8-lloyds-labs-demo.md and uses fixed Friday, July 17, 2026 scenario data.
The external v1 proof flow is:
lloyds_incident_to_renewal
The local deterministic regression scenarios remain:
lloyds_cyber_happy_pathlloyds_human_review_edge_case
Legal-facing receipt infrastructure.
Core claim:
Legal AI work should produce reviewable, portable, tamper-evident evidence artifacts.
DUE is the legal defensibility slice.
qwen35 is the installed deterministic demo. Receipt gates are the standard.
The public adapter registry currently supports:
qwen35
qwen35-claims
qwen3.5
qwen/qwen3.5-2b
Those aliases resolve to the same installed deterministic demo adapter:
qwen35
Unsupported adapters are rejected.
That is good.
It means the current repo is not pretending to support a full model matrix yet.
The trust boundary is:
local files -> Rust verifier -> stable report
The verifier consumes local artifacts such as:
ink_receipt.v2.json
ink_manifest.v2.json
controls.supplied.json
trust-registry.json
revocations.json
verify-policy.json
The important property:
Verification should not require a BLKBX-hosted API, a vendor account, or a browser.
blkbx-lab/
python/
blkbx_lab/ primary SDK, CLI, adapters, artifacts, evidence, policies
blkbxs/ banking facade
scenarios.py UBR demo fixture loader
ubr.py UBR event helper
graph.py UBR graph validation
bundle.py UBR bundle export
mand8/ insurance facade
due/ legal facade
mech_lab/ compatibility namespace
rust/
crates/
ink-core/ no_std, unsafe-forbidden receipt kernel
ink-sign/ signing boundary
ink-verify/ verification primitives
ink-vectors/ deterministic vectors
ink-cli/ file verifier CLI
ink-wasm/ WASM verifier target
ink-host/ std host adapter
ink-issuer-service/ local HTTP receipt issuer
ink-py/ PyO3 bridge
ink-receipt-v2/ v2 receipt verifier layer
ink-tui/ terminal verifier
bankabil-local-node/ Docker Compose Startup Node and Verifier Node package
docs/ documentation hub, architecture, security, verification
schemas/ public artifact schemas
policies/ policy files
examples/ deterministic demo examples
tests/ Python test suite
scripts/ release and development scripts
Python packaging is built through maturin.
That matters because the Python package is not pure Python.
The package includes a Rust native extension:
blkbx_lab._ink_native
The native extension exposes Rust-backed operations to Python:
create_manifest
analyze
gate
verify
compare
doctor
Create an environment:
python -m venv .venv
source .venv/bin/activateInstall for development:
pip install -e ".[dev]"Run Python tests:
pytestRun Rust checks:
cargo check --workspace
cargo test --workspaceRun the no-alloc kernel check, if present in this checkout:
./scripts/check_no_alloc.shRun the demo:
blkbx-lab demo qwen35 --output-dir artifacts/qwen35This repo is early.
But the right hardening direction is visible:
- Rust trust waist
no_stdkernel- unsafe code forbidden in the kernel
- no Python fallback for trust operations
- local verification path
- deterministic vectors
- explicit compatibility boundaries
- separate product facades above the receipt layer
- Rails/TypeScript kept outside the trust root
That is the right shape for regulated buyers.
This is not:
- a general chatbot app
- a hosted-only compliance dashboard
- a prompt logger
- a fake governance UI
- a full production trust registry
- a full model replay platform
- a complete Rails product
- a full multi-adapter runtime matrix
- a finished commercial product
This is the receipt engine and proof path.
Current limits should stay visible:
- public adapter support is still centered on deterministic
qwen35 - production signing is not the default public path
- BLKBXS UBR Rails create requests are the exception: they require
ink.receipt.v2issuance through configured issuer service and fail closed when signing is unavailable - Rails is workflow and appliance console work, not verifier infrastructure
- Artifact API v1 is BLKBXS-first;
/api/v1/artifacts/proofmailreturnsnot_supported_for_productfor BLKBXS - the appliance depends on Docker Compose for packaged Startup Node and Verifier Node operation
- seeded MAND8 Lloyd's demo workspaces require hosted issuer configuration before they expose portable
ink.receipt.v2verifier handoffs - product packages ride in the same
mechlab-sdkwheel - compatibility names exist and should not be confused with the primary public surface
- the hard-written LOC snapshot should be refreshed when the repo shape changes materially
- No cross-language conformance suite yet proves Rust, Python, and TypeScript produce byte-identical results from shared vectors.
- Browser verification is real through
web/verifyandink-wasm, but native verification throughink,ink-cli, andink-tuiremains the trust root. - Python packaging is still one wheel bundling multiple packages, so
dueandmand8remain flat top-level import names. - The Rails backend has meaningful tests, but it should not be treated as equally trusted with the Rust kernel just because it exists in the same repo.
- No independent external security review of the signing and canonicalization scheme has happened yet.
Start here:
- Docs hub
- CLI and API contract
- Public object spec
- Developer architecture
- Product architecture
- Bankabil Evidence Appliance
- Independent verification
- Security hardening
- Reproducibility guide
- Contributing
- Security policy
BLKBX Lab makes AI systems produce receipts that regulated customers can verify for themselves.
Use Python to wrap AI actions with evidence artifacts.
Use Rust to verify the receipt boundary.
Keep the files portable.
Keep the verifier local.
Do not ask banks, insurers, or legal teams to trust a screenshot of a dashboard.
No receipt, no trust.
No local verification, no regulated buyer confidence.
No portable artifact, no serious audit trail.