Operational Autonomy and Trust Calibration
Replace vague autonomy labels with scoped, revocable operating authority.
A focused view of boundaries, contracts, state, authority, failure paths, and tradeoffs drawn from this chapter.
Reconstruct and defend this chapter’s architecture.
Reconstruct the architecture, name each boundary, and defend the tradeoffs.
Jump to validation criteriaOpen the source exercise
Draw the six levels from memory. Then add:
- Factory, Mission, WorkOrder, policy, and trust ceilings;
- the effective-level calculation;
- human promotion and automatic demotion paths;
- the governance matrix;
- validator disagreement and Risk Review;
- the Trust Score inputs and hard overrides; and
- the evidence-focused human decision packet.
Explain one Level 4 documentation deployment and one Level 2 database migration. Identify every human decision, agent action, evidence record, and demotion trigger. The exercise fails if a model upgrade silently increases authority.
4. Tradeoffs and alternatives
Six levels create clarity, but they can create false precision. Two workflows at Level 3 may have very different tools, blast radii, and evidence. The level must summarize a versioned policy envelope rather than replace it.
A Trust Score can be gamed. Teams may optimize the number instead of safety. Transparent components, hard policy overrides, severity-aware events, and human review of promotion reduce that risk. The component history matters more than a single current number.
Exception-first approval can hide gradual degradation if “routine” is defined too broadly. Sampling, trend review, audits, and periodic deep inspections must remain part of governance.
A Factory Governance Board can become a bottleneck. It should govern policy and promotion standards, not approve routine WorkOrders. Decision ownership should remain as close as possible to the accountable domain.
5. Current Mission Control Implementation
Verification baseline
This study inspected Mission Control commit
8014d5af427b43ff5c5a63cfdf82ec92742c208c
on 2026-08-03. The working tree was clean.
Thirty focused tests passed. They covered Factory Configuration, Mission governance, WorkOrder governance, and WorkOrder revision. These tests support the mechanisms described below. They do not prove a complete autonomy ladder or trust-calibration system.
Capability assessment
| Doctrine capability | Status at studied commit | Evidence and interpretation |
|---|---|---|
| Risk-proportional autonomy | Product doctrine with implemented guards | The North Star defines Green, Yellow, and Red risk behavior. WorkOrder governance evaluates approvals and evidence before acceptance. |
| Versioned Factory authority | Implemented mechanism and unit-tested | convex/factory/configuration.ts versions repository, workflow, executor, policy, environment, budget, verifiers, risk boundary, and recovery controls. The Factory Configuration tests passed. |
| Evidence-based acceptance | Implemented mechanism and unit-tested | workOrderGovernance.ts blocks acceptance for missing, failed, stale, expired, revoked, or unapproved evidence. Ten focused tests passed. |
| Evidence-focused operator attention | Active product doctrine; partial implementation | The North Star defines an exception-first attention contract. Current UI surfaces approvals and required actions, but this study did not verify one complete decision packet or approval-fatigue outcome. |
| Factory Operational Autonomy Levels 0–5 | Not implemented as a canonical factory control | No versioned OAL field, inheritance rule, or effective-level calculation was verified. An unrelated L1–L3 field exists in a hiring surface and must not be treated as this doctrine. |
| Governance matrix | Partial and fragmented | Approval permissions and risk roles exist in several records. The complete accountable-owner matrix is not represented or enforced as one canonical contract. |
| Validator-conflict Risk Review | Not verified | Mission Control can retain failed and conflicting evidence concepts, but this study did not verify a first-class disagreement record, policy escalation, and operator recovery flow. |
| Factory Trust Score | Not implemented | No canonical transparent trust score, scoped trust ceiling, component history, or hard-override contract was verified. |
| Automatic autonomy demotion | Not implemented | Recovery, retry, quarantine, and risk controls exist in parts of the system. No evidence showed outcome-driven recalculation and enforcement of a lower operational autonomy ceiling. |
| Human-only promotion | Future doctrine | Mission Control requires approvals for several actions, but no canonical workflow promotes an autonomy scope after sustained evidence and governance review. |
Browser evidence status
No fresh browser journey was performed for this chapter. Source paths and unit tests are not proof that operators can inspect, promote, demote, or recover an autonomy scope through the product.
Review this chapter.
Challenge a claim, boundary, missing failure mode, unclear term, or unsupported evidence statement.
- Claim
- Boundary
- Failure
- Evidence