HUMMBL validation metrics

Public repo‑local validation

Tests and CI status that are visible in each public GitHub repository (e.g., hummbl-governance, base120). These numbers are shown on repository pages and in the site stat cards.

Four things we measure

HUMMBL publishes four kinds of validation signals. They are related but not interchangeable.

Signal What it counts Example Scope
Tests Automated unit, integration, and property tests 1,032 tests in the hummbl-governance v1.2.0 PyPI description Release-scoped; see /manifest/public-release-state.json
Checks Static analysis, linting, format, and policy checks Prettier, Bandit, Semgrep, Base120 ref lint Per repo or CI
Audits Automated governance audits against HUMMBL criteria Arbiter audit score 99.5/100 Per repo
Deployments Production environments running the artifact hummbl.io served by Cloudflare Pages Per service

Private founder/operator validation

Internal test suites run in the private founder‑mode and operator infrastructure (e.g., orchestration loops, delegation token flows, bus receipts). These are not publicly visible but are included in aggregate counts.

Public repo metrics vs. aggregate validation

Public repo metrics are the counts visible in each open-source GitHub repository. Aggregate validation includes the public tests plus the private internal founder/operator systems that test orchestration, delegation, governance buses, kill switches, circuit breakers, and receipts.

Metric Public repo Aggregate
hummbl-governance v1.2.0 PyPI release tests 1,032 Release-scoped public package description
Base120 source checkout tests Source-install only Not a PyPI package claim
Internal operator tests Not visible Included
Total Per-repo counts 15,600+

When a public page or README cites a number, it should specify whether it is a public repo count or the aggregate. If it does not, it is a public repo count.

How to interpret public GitHub counts

Public repo‑local numbers reflect only the tests and CI pipelines that are open‑source. Do not assume they include the private validation suite unless explicitly noted.

What is not publicly disclosed

Details of the private internal test suites, exact test implementations, and internal CI configurations are proprietary and not included in public metrics.

Public namespace manifests

HUMMBL publishes machine-readable manifests that define the public namespace boundary — what is public, what is internal, and what claims are verified:

These manifests are version-controlled and updated whenever public claims change. They exist to keep the site honest — every public claim should be traceable to a manifest entry.

Use these metrics in a readiness review

If you are mapping an agentic AI system against HUMMBL governance primitives, start with the readiness assessment and keep public repo metrics separate from aggregate internal validation counts.

Last updated: July 2, 2026 · Terminology is coordinated with the HUMMBL Doctrine Glossary and HUMMBL Method.

Doctrine terms

The terminology used on this page is aligned with HUMMBL doctrine definitions:

  • Base120 — core operator set.
  • BaseN — governed extension model.
  • HUAOMP — doctrinal orientation for governance.
  • MTSMU — truthfulness and utility orientation.