hummbl-governance
Runtime governance primitives imported into customer-controlled Python systems. This is the primary public package surface.
Product architecture
How HUMMBL components fit together
HUMMBL provides runtime governance primitives for agentic AI
systems. The public architecture starts with
hummbl-governance, records decisions through the
Governance Tuple, uses Base120 as a secondary reasoning substrate,
and exposes MCP as an integration layer.
Package status, release metrics, validation status, and provenance boundaries are governed by the public release-state manifest. Do not merge separate HUMMBL artifacts into one package or infer certification from compliance mapping.
Component flow
Governance Tuple
CONTRACT × DCT × EVIDENCE: what was authorized, who authorized it, and what happened.
Base120
Secondary governed reasoning substrate. Base120 is not the primary public package and remains source-install-only unless the public release-state manifest says otherwise.
MCP server
Integration surface for Claude and MCP-compatible clients using
source-of-truth strings such as recommend_models,
hummbl://models, and
npx -y @hummbl/mcp-server.
Manifests and validators
Release-state, validation pages, receipts, snippet validators, runtime snippet checks, and claim-risk triage keep public claims scoped.
Layer responsibilities
Governance primitives enforce runtime behavior
Delegation tokens, governance buses, kill switches, circuit breakers, and related primitives are the library layer a system imports.
The tuple makes governance auditable
The Governance Tuple binds permission, delegation, and observed evidence so a reviewer can separate intended authority from actual behavior.
Base120 guides reasoning, not package identity
Base120 can help choose or explain reasoning moves, but it does
not replace hummbl-governance as the primary public
artifact.
MCP connects clients to governed context
MCP makes HUMMBL context available to compatible clients without changing the underlying package or release-state boundaries.
What runs where
| Surface | Runs where | Evidence produced or referenced |
|---|---|---|
hummbl-governance |
Package-installed Python runtime | Delegation records, bus events, stop states, policy checks, and local receipts generated by the importing system. |
| Governance Tuple | Inside the governed workflow | CONTRACT, DCT, and EVIDENCE fields that connect authorization to execution. |
| Base120 | Source checkout or documented API/MCP access path | Reasoning context and model-selection traces when a workflow chooses to record them. |
| MCP server | MCP-compatible client environment | Tool/resource calls and client configuration evidence, as documented by public MCP setup pages and validators. |
| Public trust surfaces | Static site, manifests, CI, and reports | Release-state manifest, validation metrics, snippet reports, runtime snippet checks, claim-risk triage, and receipts. |
Boundary rules
- Treat Base120 as source-install-only unless the public release-state manifest says otherwise; docs, API examples, and MCP integration do not change that boundary.
- Do not infer certification, FedRAMP authorization, government approval, or legal advice from compliance mappings or defense positioning.
- Do not infer current release metrics from historical audit snapshots, research notes, or older docs.
-
Do not merge Base120, BaseN, MCP server, and
hummbl-governanceinto one artifact.
Use the architecture map
Start with the library if you are building, the validation page if you are reviewing evidence, and the release-state manifest if you need the current public claim boundary.