Methods of Organization
Primitives are building blocks. Operationalizations are patterns. But what organizes the primitives into a coherent system? This page documents the meta-framework: the structures that govern how governance itself is organized.
The Governance Tuple
Every governed decision is represented as a triple:
| Component | What it captures |
|---|---|
| CONTRACT | What was authorized — the scope, constraints, and obligations of the decision |
| DCT | Who authorized it — the Delegation Context Token that proves the authorization chain |
| EVIDENCE | What actually happened — the audit trail, outputs, and outcomes |
The tuple is the atomic unit of governed action. It is not a log entry (which records what happened) — it is a binding of authorization to action to evidence. Published as The Governance Tuple on Zenodo (DOI 10.5281/zenodo.19646940).
Base120 — The reasoning framework
Base120 is a reasoning framework with 120 operational models across 6 transformation families. It provides the deterministic governance substrate for system design and validation. Each model is an operator that transforms inputs into outputs in a defined, reproducible way.
The six families
| Family | Prefix | What it covers |
|---|---|---|
| Perception | P | How systems perceive and frame problems (P17 Frame Control, P1 Observation, etc.) |
| Decision | D | How systems make decisions under uncertainty (D1 Root Cause, D2 Premortem, etc.) |
| Inference | I | How systems reason from evidence (I1 Bayesian, I2 Abductive, I3 Deductive, etc.) |
| Reflection | R | How systems examine their own reasoning (R1 Self-audit, R2 Bias check, etc.) |
| Evolution | E | How systems adapt over time (E1 Drift detection, E2 Calibration, etc.) |
| Synthesis | S | How systems combine insights (S1 Integration, S2 Compression, etc.) |
Base120 is not a personality test or a productivity framework. It is a deterministic set of operators that can be composed into governance workflows. Source: github.com/hummbl-io/oss
CRAB methodology
CRAB (Commit, Receipt, Audit, Broadcast) is the methodology for governed multi-agent execution. Every consequential action passes through four stages:
| Stage | What happens | Primitive involved |
|---|---|---|
| Commit | An agent proposes an action. The proposal is recorded before execution. | BusWriter (PROPOSAL), DelegationToken |
| Receipt | The action is authorized and a receipt is generated binding contract, delegation, and evidence. | ReceiptEngine, DelegationContext |
| Audit | The action and its outcomes are recorded in the append-only audit log. | AuditLog, ToolCallAuditor |
| Broadcast | The outcome is broadcast to the fleet via the coordination bus. | BusWriter (STATUS/MILESTONE) |
CRAB ensures that no action is taken without a prior commitment, no commitment lacks authorization, no authorization lacks evidence, and no evidence stays private to the acting agent.
Five-tier dependency taxonomy
HUMMBL organizes its code into five dependency tiers. The tier determines what dependencies are allowed and how the code is packaged.
| Tier | What it is | Dependencies |
|---|---|---|
| Tier 0 | Pure stdlib core — no imports outside Python stdlib | None (stdlib only) |
| Tier 1 | Package with stdlib-only core + optional extras | Core: none. Extras: specified third-party |
| Tier 2 | Application with controlled dependencies | Explicit, pinned, audited |
| Tier 3 | Integration testbed — consumes everything below | All tiers below + test deps |
| Tier 4 | Full application with all dependencies | Unrestricted (but audited) |
hummbl-governance is Tier 0/1 (stdlib-only core, zero runtime deps). hummbl-governance is Tier 3 (integration testbed that consumes hummbl-governance). This separation ensures the governance primitives can be adopted by any Python project regardless of its dependency stack.
Claim-honesty protocol
Every public claim about HUMMBL is governed by a claim-honesty protocol. Each claim has:
- Status — validated, invalidated, misleading, fixed, unproven, or not checked
- Source — where the claim's truth is established (commit, CI run, PyPI metadata, etc.)
- Source quote — the exact text from the source that supports the claim
- Verified date — when the claim was last verified
- Evidence tier — A (primary, fresh), B (secondary or stale), C (missing — cannot ship)
The protocol is enforced by CI: the landing claims ledger is validated on every PR. Claims that cannot be verified are blocked from shipping. This is why the numbers on this site match the code.
KRINEIA receipt system
Changes to protected invariants (the constitution, claims manifest, public namespace) require a KRINEIA receipt before admission. KRINEIA is an append-only, SHA-256-chained receipt log. Each receipt records what changed, who authorized it, and when. The chain is tamper-evident: modifying any receipt breaks the chain.
See also: the primitives catalog and how they are operationalized.
Want to understand how this applies to your system?
Book a 30-min call →