Operating Standard

MTSMU

Maximally Truth-Seeking, Maximally Useful — the HUMMBL standard for evidence-first outputs that are both accurate and actionable.

MTSMU is a HUMMBL-aligned operating standard for outputs that prioritize truth, utility, and decision relevance. It is not a metric. It is a posture: before acting, verify; before verifying, ground claims in evidence; before delivering, ask whether the recipient can use it.

What it means

Most systems optimize for one axis. MTSMU insists on both. An output that is true but useless is not MTSMU. An output that is useful but ungrounded is not MTSMU either. The standard applies to code reviews, bus messages, research summaries, decision memos, and agent outputs.

Axis	Question	Anti-pattern
Truth-seeking	Is this claim supported by evidence?	Confident assertions without receipts
Usefulness	Can the reader act on this?	Overwhelming detail with no priority
Decision relevance	Does this change what we do?	Interesting but irrelevant context

Examples

Evidence-first review

Not MTSMU: "This PR looks risky."

MTSMU: "This PR introduces a new adapter write path without a BaseNTuple EVIDENCE receipt. At Tier 1 that is required by BaseN policy. Suggested action: add a receipt in founder_mode/services/basen_tuple.py before merge."

Automation loop decision

The MTSMU loop watches the coordination bus for signals and recommends the highest-value safe action. A BLOCKED message from an agent is escalated to P1 because it is both true (a real block) and useful (an operator can unblock it). A low-value status update is observed, not escalated.

HUAOMP ranking

HUAOMP lens combinations are scored by an assumed MTSMU score: the average of truth weight and usefulness weight, adjusted for coverage and cost. The highest-ranked combinations are not the ones with the most lenses; they are the ones that best balance breadth with actionability.

Bus receipt

Every MTSMU loop action renders a machine-parseable JSON receipt with fields for action, priority, confidence, summary, evidence, reversibility, collision risk, and next step. The receipt is the truth record; the action is the useful output.

Schema

The MTSMU loop operates on normalized bus events and produces a structured plan. Both are defined in founder_mode/services/mtsmu_loop.py.

Input event

Field	Type	Description
`timestamp`	string	ISO 8601 UTC timestamp
`sender`	string	Canonical agent identity
`target`	string	Target agent or `all`
`kind`	string	Event type: STATUS, BLOCKED, QUESTION, REVIEW, WIP_START, etc.
`message`	string	Free-text body

Output plan

Field	Type	Description
`action`	string	observe, review, escalate, fix-small
`priority`	string	P0, P1, P2, P3
`confidence`	float	0.0–1.0
`summary`	string	Human-readable plan summary
`evidence`	tuple[string]	Source events and refs
`reversible`	bool	Can the action be undone?
`collision_risk`	float	Likelihood of duplicate work
`next_step`	string	Explicit follow-up instruction

{
  "action": "escalate",
  "priority": "P1",
  "confidence": 0.86,
  "summary": "blocked lane needs operator or peer action: signing blocked",
  "evidence": [
    "2026-05-05T10:01:00Z codex BLOCKED",
    "PR #635 CI fix validated but signing blocked"
  ],
  "reversible": true,
  "collision_risk": 0.2,
  "next_step": "Ask for the missing token, approval, peer review, or human action; do not bypass."
}

Operating modes

The MTSMU loop is deliberately conservative. It recommends, reviews, or escalates from live signals, and only proposes tiny fixes when fix-small mode is explicitly enabled.

Mode	Behavior
`watch`	Monitor the bus and emit receipts for high-value signals
`review`	Accept unowned review requests with a read-only lane
`escalate`	Always an option for BLOCKED or high-risk events
`fix-small`	Patch narrow lint/typo/test issues only when enabled
`quiet`	Suppress low-value `observe` receipts

Provenance

Origin: MTSMU was introduced as the HUMMBL truth/utility standard for agent outputs. It underpins the evidence-first automation loop and the HUAOMP lens ranking function.

Implementation: founder_mode/services/mtsmu_loop.py — stdlib-only watcher/planner for 24/7 operation.

Decision record: The loop is tested in founder_mode/tests/unit/test_mtsmu_loop.py with fixtures for BLOCKED, QUESTION, WIP_START, and CI-failure events.