04 — Application Guide

The console,screen by screen.

The console is an operator surface, not a dashboard. Every screen below is a real capture of the production build running the WideWorldImporters SQL Server flagship migration. Each caption stays tied to the screen it describes, and an estimate is never presented as a billed amount.

G.00Read this first

Gemini agents enrich discovery, infer lineage, explain risk and propose recovery. Deterministic services remain authoritative for source facts, policies, state transitions, reconciliation, remediation and approval.

Open the live console

The deployed system is running and open to anyone reviewing this project. Sign in with the shared demo account below — no request, no provisioning.

Email: migration.control@tower.com
Password: migration.control
Access: Selected-estate roles: operator, viewer

Launch the console

Shared demo account, scoped to the demonstration estate. Please do not put anything confidential into it.

C.01Chapter

Enter and orient

Every view sits behind a verified identity, and the first screen already reports what the system believes about itself.

Migration Control Tower login page with Google sign-in, optional domain email access, and descriptions of operator and approver responsibilities. — Authentication and secure entry
Secure Firebase authentication with administrator-assigned viewer, operator, and approver roles.

Production overview
A single production view of migration progress, estate health, policy activity, recovery performance, and measured cost/volume evidence.
System and cloud-service health
Production health is derived from live Cloud Run revisions, BigQuery execution evidence, model readiness, connection freshness, queues, and telemetry.

C.02Chapter

Connect and understand

An estate is the durable boundary that binds sources, adapters, packs, targets, ownership and authorization — registered without the console ever holding a credential.

Estates page showing a healthy WWI SQL Server source with 48 objects, a BigQuery target, and Secret Manager-based credential handling. — Estate inventory and connection safety
Register sources and targets without exposing credentials; discover real object counts and bind execution through approved Migration Packs.

Onboarding step 1: Identity
Begin with a stable estate identity and an enforced lifecycle boundary that separates production operation from controlled acceptance rehearsal.
Onboarding step 2: Source
Bind the estate to a capability-declaring source adapter and a stable concurrency identity.
Onboarding step 3: Secret-safe connection
The console accepts private connection coordinates and a Secret Manager reference—never a database password.
Onboarding step 4: Live validation
A live private-network probe verifies SQL Server 2022, 48 measured base tables, Secret Manager resolution, and connection latency before anything is saved.
Onboarding step 5: Migration Pack
Choose a versioned, source-compatible Migration Pack that explicitly distinguishes assessment from execution.
Onboarding step 6: Review and audit justification
Review the complete configuration and provide an audit-recorded justification before the governed estate write is enabled.
Pack-driven assessment
Select a versioned Migration Pack to produce a governed assessment and proposed plan before any data movement begins.
Run-scoped lineage graph
A PII-aware dependency graph built from run-scoped SQL Server relationship evidence.
Focused lineage impact path
Focus a single dependency path to understand downstream impact and where sensitive data enters the migration scope.
Relationship provenance register
Every lineage edge resolves to inspectable source/target columns, a database constraint, confidence, and evidence provenance.

C.03Chapter

Plan and execute

Admission control decides what may run. The data plane moves rows in independent Cloud Run Jobs and reports its own measured evidence.

Data-plane job table showing completed Cloud Run operations, measured source and target rows, bytes, duration, one 99 percent controlled fault, and later full row parity. — Cloud Run data-plane proof
Real Cloud Run job IDs, measured row/byte counts, a visible 1% fault, and the subsequent clean-reload evidence.

Wave admission and operational control
Transactional admission control protects source systems while giving authorized operators an audited emergency hold.
Run register
Track assessments and executions as durable state machines, including prior evidence, retries, and approval status.
Complete run and lifecycle evidence
One immutable timeline preserves failure, investigation, deterministic remediation, revalidation, independent approval, and completion.
Per-stage execution evidence
Every stage is attributable to a specific capability, version, attempt, latency, model configuration, and trace context.
Migration plan register
Inspect target-level plan metadata without inventing missing status, source, or telemetry fields.

C.04Chapter

Detect and recover

Failure is a designed path. A failed deterministic check becomes an incident, lineage locates the responsible pipeline, and only a cataloged remediation is applied.

Resolved Sales Orders row-loss incident with Gemini rationale, deterministic clean-reload remediation, and evidence-hashed policy decisions. — Autonomous recovery and policy evidence
AI explains the incident; deterministic controls authorize, execute, and validate the only permitted recovery.

Incidents and recovery proof
The system detected a controlled row-loss fault, explained it, executed the only permitted repair, revalidated it, and preserved every denial and decision.
Evidence-backed remediation memory
Reuse proven remediations by exact failure signature while requiring fresh policy checks and deterministic revalidation every time.
Dead-letter operations
Inspect, replay, or archive poison messages without consuming them on page load or hiding queue-lease uncertainty.

C.05Chapter

Govern and approve

The policy engine is the one decision point, and the human gate is separate from it. Approval is bound to the exact plan hash.

Policies and Approvals page showing denied raw-PII access, allowed governed agent capabilities, pending requests, and a separately approved flagship run. — Policy enforcement and approval history
Deterministic least-privilege policies and an independent, justified human approval gate protect cutover.

Plan-bound human approval gate
Independent approval is bound to the exact run and plan hash, expires, and is never overwritten.

C.06Chapter

Prove it

Agent decisions, lineage provenance, reconciliation and scale are each evidenced separately, because they answer different questions.

Agent audit table interleaving Gemini discovery and lineage proposals with deterministic risk, migration, validation, and cutover decisions. — Decision and generation trail
Inspect what each agent proposed or decided, the evidence it used, its model/version, latency, validation result, and whether a fallback occurred.

Agent fleet overview
Seven versioned Cloud Run agents with measurable execution, model, latency, fallback, and readiness evidence.
Versioned agent registry
Versioned capability dispatch, per-service identities, and pinned runs make the agent fleet upgradeable and auditable.
Cross-run reconciliation
Source-to-target row counts, hashes, null profiles, aggregates, deltas, and tolerances remain independently inspectable across runs.
Control-plane evaluation scale
Reproducible control-plane scale tests process up to 20,000 definitions without invoking a model for deterministic work.
Real data-plane and operational-load evidence
Measured Cloud Run data movement and concurrent control-plane load, with queue and fleet health captured alongside throughput and latency.

C.07Chapter

Ask the tower

A read-only assistant grounded in the run's own recorded evidence — it can cite state, and it cannot change it.

Gemini 3.5 Flash Ask Control Tower drawer showing its read-only restriction, active-context option, multiline prompt, and Enter-to-send behavior. — Ask Control Tower assistant
Ask run-specific questions in natural language and receive read-only, cited answers grounded in authorized Control Tower evidence.

G.08Evidence

Three scales, measured as three different questions.

0
Rows transferred
Live / measured
31,432,246 bytes in 439,935 ms — 167.3 rows per second.
0 B
Bytes transferred
Live / measured
Reported by CloudRunJobExecutor independently of the agent control plane.
0
Definitions planned
Measured control plane
126.9 validations/sec and 132,613.5 scheduling items/sec across the control plane.
0
Concurrent decisions
Live / measured
Bounded concurrency measurement with zero captured backlog.
0
Legal transitions
Live / measured
Persisted by the final flagship run, which resumed after failure.
0
Estate objects
Live / captured
Discovered in the WideWorldImporters SQL Server source.

The live acceptance run completed three table loads containing 5 customer rows, 5 order rows and 3 tag rows, then passed 15 pre-cutover checks. The separate 73,595-row measurement is the data-plane scale run and is reported independently.

The 20,000-definition result is a planning and wave-scheduling benchmark. It must not be described as 20,000 completed bulk migrations.

G.09Boundaries

What this does not yet do.

The strongest claim here is not that everything is finished. It is that the loop is governed end to end, and that its edges are stated rather than implied.

01
Most pre-migration stages still execute inside the orchestrator despite independent service shells being deployed.
02
End-to-end cross-service trace propagation remains incomplete.
03
Tool-level authorization coverage is strongest in Discovery, Risk and Cutover; Lineage, Planner and Validation need equivalent internal coverage.
04
The 20,000-definition benchmark proves control-plane planning scale, not 20,000 bulk migrations.
05
Cloud Billing Budgets alert but do not stop spend.
06
Long-horizon behavior has fixtures and kill/resume evidence, not a continuously running multi-week production migration.

The project

About