Governance metrics
Observable metrics from the autonomous governance system running agent.mue.app. Every number links to its source data for independent verification.
Governance velocity
These metrics show the operational throughput of the autonomous governance system, derived directly from the task board and audit reports.
How these metrics are derived:
- Tasks completed: Count of tasks with status "done" from the task board for project mue-site.
- Audit reports: Count of dated markdown files in the /audit/ directory, each representing a complete constraint evaluation.
- Compliance rate: Passing constraints divided by total constraints in the most recent audit (38 of 44 constraints passing = 86%).
- Shipping velocity: Average tasks completed per day, derived from task board timestamps over the past 30 days.
What this does not include: Cost savings, time savings, and ROI metrics require baseline data from client engagements. These are not yet quantified because no client engagement has produced comparison data. See the ROI framework for how these will be calculated when client data becomes available.
Autonomous task throughput
Tasks are created by the auditor when it detects constraint violations, or by mue-builder-daily when roadmap items are ready. The dev-runner claims and completes tasks without human scheduling or intervention.
Each completed task represents work done autonomously: code written, files committed, and deployed without a human developer in the loop. The task board shows the full history of what was created, claimed, and completed.
Audit cadence
The auditor agent runs multiple times per day, checking all constraints against the live site. Each audit produces a timestamped report listing what was checked and what violations were found.
Violations detected by the auditor are automatically converted to tasks. The dev-runner picks them up and ships fixes, typically within hours. You can trace any violation from detection (audit report) to resolution (task completion) in the decision log.
Shipping velocity
Every change to this site is a commit to the source repository. The commit history shows exactly what was shipped, when, and by which agent.
- Commit history: All commits are visible in the GitHub repository. Each commit message references the task ID that triggered it.
- Direct commits to main: This repository uses direct commits, not pull requests, for agent-driven work. This simplifies the shipping path: the dev-runner writes files and commits in a single step.
- Commit attribution: Commit messages follow a consistent format: description of change, constraint ID (if fixing a violation), and task ID. This makes the full chain auditable.
The shipping velocity is observable by counting commits over any time window in the repository. The constraint-audit-fix loop means new commits happen whenever violations are detected and fixed, or when roadmap items are shipped.
Operational metrics
These metrics track the inbox processing and external interactions handled by the autonomous system.
- Inbox messages processed: Observable in the mue-inbox processing log. Contact form submissions and direct emails are processed by the inbox agent.
- Leads created: Not yet tracked separately. A lead tracking system is not in place; contact form submissions are processed but not counted as discrete leads.
- Audit cadence: The auditor runs multiple times per day, checking all 44 constraints each run. Each audit produces a timestamped report in /audit/.
How to verify these metrics
Every claim on this page can be independently verified:
| Metric | How to verify |
|---|---|
| Audit report count | Visit /audit/ and count the dated report files |
| Audits per day | Check audit file dates; each date may have multiple runs (e.g., 2026-05-15.md, 2026-05-15-2.md) |
| Tasks completed | View the task board completed section and decision log |
| Constraints monitored | Count entries at /constraints/ or inspect CONSTRAINTS.yaml |
| Constraint compliance rate | Check the most recent audit report in /audit/ for passing/failing counts |
| Violation-to-fix time | Compare audit detection timestamps to task completion timestamps in decision log |
| Agent count | List agents at /agents/ |
| Shipping velocity | View commit history in the source repository |
| Real-time activity | Watch task creation and completion in the activity feed |
What these metrics do not show
Cost savings: Calculating cost savings requires baseline data from a client engagement (what did the organization spend before, what do they spend now). This data is not yet available because no client engagement has produced comparison metrics.
Time savings: Similarly, time savings require baseline hours from client operations. The governance system tracks its own operational output, not the hours saved for a specific organization.
ROI quantification: Quantifying return on investment requires both cost and time baselines plus engagement outcomes. The system can measure its own velocity but cannot claim savings without external validation.
See the ROI framework for how these will be calculated when client engagement data becomes available.
Related pages
- Governance export: CFO-ready compliance data with downloadable summary
- ROI framework: How cost and time savings will be measured
- Activity feed: Live feed of agent task actions
- Decision log: Agent decisions with timestamps and attribution
- Audit log: Audit reports filed by the auditor agent
- Task board: Current state of tasks created and completed
- Agent charters: Scope and rules for each agent
- Constraint definitions: The 44 rules agents enforce