0% read on this device
Browse the curriculum

Start Here

Vision

First Principles

Operating Model

Domain Model

Agent Factory

Runtime Architecture

AI Engineering

Autonomous Workflows

Verification & Delivery

Factory Platform

Quality Engineering

Security & Governance

Case Studies

Labs

Interview Practice

Research Journal

Reference

Curriculum/Interview Practice/A focused view of boundaries, contracts, state, authority, failure paths, and tradeoffs drawn from this chapter.
Interview Practice7 min readinterview

Executive and Interview Mastery

Technical knowledge is not mastery until it can be reconstructed, defended, and adapted under questioning. Executives need the business case and risk model. Architects need boundaries and invariants. Engineers need implementation and failur

Status: Draft for studyRisk: variableLifecycle: learnContent reviewed 2026-08-25Maturity guide →
Claim boundaryThis is curriculum guidance. It does not by itself prove a production implementation.
architecture mode

A focused view of boundaries, contracts, state, authority, failure paths, and tradeoffs drawn from this chapter.

Whiteboard exercise

Reconstruct and defend this chapter’s architecture.

Reconstruct the architecture, name each boundary, and defend the tradeoffs.

explanation7 min chapter
Open the source exercise

In 20 minutes, draw the complete operating model from business intent to validated customer value. Spend five minutes on the happy path, five on authority and evidence, five on failure and recovery, and five on economics and adoption. Then erase the vendor names and prove the architecture still works.

4. Tradeoffs and alternatives

Strong opinions demonstrate judgment, but dogma signals shallow understanding. State the default, the conditions that justify it, and when another design is better. Do not use Mission Control’s stack as the universal definition of a factory.

Memorized answers are useful scaffolding but fail under follow-up. Practice causal chains: why the problem exists, which invariant matters, what the design costs, how it fails, and what evidence changes your mind.

5. Current Mission Control Implementation

Mission Control at commit b31e27564deb1c03c167e61b5ee094567c2ba7b1 is a living case study, not a completed factory.

It has the Mission/Plan/WorkOrder/Task/Attempt hierarchy, versioned Factory Configuration and readiness, policy and approval primitives, WorkflowRuns and events, independent evidence concepts, scoped context packages, service and GitHub identity contracts, operational analytics, and a browser-proven control-plane path through WorkOrder release.

It has not yet proven the complete browser-operated real Codex-to-GitHub path. The retained run stopped because no active Governance Policy and Factory Configuration existed, the GitHub App was not configured, todo 024 was incomplete, and the runtime was dirty. Trust Score, automatic autonomy calibration, first-class Risk Review, governed MCP, production memory, complete deployment governance, and intent-to-customer-value economics remain partial or future.

The strongest interview posture is to explain both the implemented foundation and the unproven boundary without embarrassment. Accurate limitation is an architecture skill.

External review

Review this chapter.

Challenge a claim, boundary, missing failure mode, unclear term, or unsupported evidence statement.

  • Claim
  • Boundary
  • Failure
  • Evidence