VOSJ: An AI‑Native Migration Factory
and its Model Context Protocol Devstation Fleet

Abstract

Contents

1  Executive Summary

VOSJ turns migration from a bespoke consulting effort into a governed, AI‑driven factory: any source, any target, both connectivity modes, with audit‑grade evidence and near‑zero downtime by construction.

The thesis of this paper is simple to state and consequential in practice: migration is a manufacturing problem dressed as an engineering problem. The reason migrations are expensive is not that any single step is hard — first‑party engines already replicate disks, convert images, and migrate databases competently — but that the steps are uncoordinated, unrepeatable, unaudited, and human‑bound. Treating migration as a factory with named stations, a compiled process, machine‑checked gates, and an autonomous labour force resolves all four deficiencies at once.

1.1  The four contributions

1.2  The headline claim, stated precisely

The remainder of this paper substantiates that claim. §2–§4 frame the problem and prior art. §5–§8 describe the factory, the gated framework, the disposition engine, and the template engine. §9–§11 describe the AI execution substrate — the MCP server, the devstation fleet, and the human–AI operating model — which is the paper's primary novelty. §12–§16 cover governance, verification, the data model, security/compliance, and provider connectivity. §17–§20 cover delivery‑system assessment, economics, a worked scenario, and evaluation. §21 enumerates the inventive claims for defensive‑publication purposes; §22–§24 close with limitations, future work, and conclusions.

2  Introduction & Motivation

Enterprises hold portfolios of hundreds to thousands of applications distributed across on‑premises data centres, private virtualisation estates (including Microsoft Hyper‑V and other hypervisor / HCI platforms), and multiple public clouds. Business events — data‑centre exit, acquisition, cost pressure, regulatory localisation, end‑of‑support, or a strategic platform decision — routinely require moving large subsets of that portfolio from one platform to another, frequently reshaping them in the process (IaaS → managed services, VM → container, monolith → cloud‑native).

2.1  The migration tax

We define the migration tax as the avoidable cost premium incurred because migration is performed as a craft rather than as a manufactured process. It has five recurring components:

1. Toolchain churn. First‑party migration tools are renamed, retired, or restricted on the vendors' own cadence. A buyer should not have to track which console is alive this quarter.
2. Reinvention per engagement. Assessment, dependency mapping, wave planning, runbook authoring, replication, cutover, and reconciliation are rebuilt by hand for each project.
3. Opaque risk. Cutovers are frequently big‑bang or weakly verified; rollback plans are written the night of, by the same people executing the change.
4. Unaudited execution. Who advanced which workload, on what evidence, signed by whom, is often reconstructed after the fact from chat logs and email.
5. Human bottleneck. The work scales linearly with skilled engineers, who are scarce and expensive, so throughput is capped and parallelism is limited.

2.2  Why now — the AI inflection

The labour‑bottleneck component was, until recently, irreducible: the toil of reading a runbook, calling a transfer tool, watching replication lag, and reconciling row counts required a skilled human. Tool‑using AI agents — large language models that plan, call tools, read and write code, and operate a terminal — change this. An agent can now perform the bulk of station work, provided it is given (a) a standard way to reach tools and systems and (b) a governance envelope that makes its actions safe and auditable. The first is the Model Context Protocol; the second is the gated framework engine plus safety invariants. VOSJ is the composition of the two around a migration domain.

2.3  Scope of this paper

This is an architecture‑and‑method paper, not a benchmark study. It describes the system as designed and the invariants it enforces, situates it in the migration literature, and offers an evaluation methodology rather than headline performance numbers (any third‑party outcome figures cited are illustrative and flagged as requiring independent verification). The intended reader is a technical practitioner: a cloud or platform architect, a migration lead, a DevOps/SRE engineer, or a researcher in autonomous software engineering.

3  Problem Statement

We state the problem formally to make the design requirements precise.

3.1  Formal framing

Let a source estate be a set of workloads W = {w₁, …, wₙ}, each with an inventory record, a dependency relation D ⊆ W × W, a data footprint, and a set of non‑functional constraints (availability target, data‑residency, compliance regime). Let a target be a platform Pₜ with a landing zone L. A migration is a function that produces, for each in‑scope workload, a disposition d(w) ∈ R (the 7‑R set), a transition plan, an executed cutover, and a proof of equivalence π(w) between source and target behaviour, subject to:

• Ordering: cutover sequence respects the dependency DAG (topologically sorted, acyclic).
• Continuity: for each w, the source keeps serving until π(w) holds (no unverified cutover).
• Reversibility: an independent rollback exists and has been rehearsed before execution.
• Auditability: every state transition is attributable (actor, evidence, timestamp) and tamper‑evident.
• Authority separation: the actor that performs a transition is not the actor that authorises it.

3.2  Requirements derived

The non‑negotiable constraints — continuity (R4–R6), authority separation (R5), and auditability (R5, R8) — are the ones most often violated by ad‑hoc migrations, and the ones VOSJ enforces structurally rather than by policy.

4  Related Work & Conceptual Foundations

VOSJ does not invent a methodology; it composes and operationalises established ones. The synthesis below is the conceptual basis for the gated framework (§6) and the disposition engine (§7).

All external frameworks, programs, and tools named above are the property of their respective owners and are cited for technical accuracy. Naming, availability, funding terms, and exact phase wording change over time and should be verified against the owner's current documentation before use in a customer‑facing context.

5  The VOSJ Factory — Architectural Overview

VOSJ is a control plane that orchestrates an existing, production‑grade migration domain (a library of point‑to‑point migrate‑<source>‑to‑<target> executors covering Microsoft Azure, Azure Local, and Hyper‑V alongside other public clouds and hypervisor / HCI platforms), a provider registry, an encrypted credential vault, self‑serve onboarding, and metered billing. It wraps these capabilities in authentication, capability‑based authorisation, a full audit log, a live per‑migration board, and a buyer‑facing self‑serve experience. The architectural principle is extend, do not fork: VOSJ productises and unifies capabilities that already exist rather than duplicating them.

5.1  The four stations

5.2  Layered architecture

5.3  Cross‑cutting properties

• Observable — every station exposes a live board; every transition emits an event.
• Audited — who advanced/cut‑over/decommissioned what, on what evidence, source → target, is recorded immutably.
• Metered — effort and cost per migration are captured, making outcomes reportable and priceable.
• Config‑driven — providers, regions, prices, and thresholds are configuration, never hardcoded.
• Flag‑gated — no half‑built surface ships unflagged; closure follows the standard change‑management and CD path.

6  The Seven‑Phase Gated Reference Framework

The stations are the operating surface; a framework populates them with phases, gates, deliverables, and roles. VOSJ ships a reference framework of seven phases, each terminating in one or more gates that require machine‑checked evidence and a human sign‑off by a named role. The framework maps cleanly onto the four stations.

6.1  Why gates, and why human signers

A gate is a transition in a finite‑state machine that cannot fire until (a) its machine‑checkable criteria are satisfied (e.g. "runbook citations resolved, dependency sort acyclic, tabletops passed") and (b) a human in a named role applies a cryptographic signature. The two‑part condition is deliberate: machines verify facts; humans accept accountability. This is the mechanism by which an autonomous fleet can perform the work while a human remains the authority of record. §12 details the signing and the no‑self‑sign invariant.

7  The 7‑R Disposition Engine

Disposition is assigned per workload in Phase 2 (Examine) and stored on the workload record. It is the single most consequential decision in a migration, and VOSJ's distinctive treatment is to make it a gate input rather than advisory metadata: the kickoff gate cannot pass until every in‑scope workload carries a disposition, and the planning gate selects the runbook template and executor strictly from that disposition.

7.1  Disposition as a typed contract

Each disposition is a typed contract ⟨ executor_class, runbook_template, reconciliation_profile, cutover_style ⟩. Replatform/modernize dispositions additionally carry a delivery‑system precondition: a workload cannot be safely containerised or modernised without first standing up its pipeline, quality gate, GitOps flow, and observability — so the CI/CD 365° assessment (§17) is a hard dependency of those dispositions.

8  The Framework Template Engine

Methodologies differ by customer, regulator, and partner. Rather than hardcode one, VOSJ generalises a single hardcoded phase‑gate engine into a data‑driven, multi‑template engine. A consultant may select an existing template, clone and customise it, or create a new one. Crucially, the signing, gate‑row persistence, oversight roles, and RBAC machinery are reused unchanged; only the state‑machine source moves from frozen constants to template rows.

8.1  Compilation model

8.2  Data model (additive)

8.3  Consultant experience

• Browse — public seed templates plus the tenant's own, each with a strongest‑fit hint.
• Use — bind a template to a migration; the version is pinned.
• Clone & customise — fork a seed into a draft (lineage recorded); edit phases, activities, deliverables, gates, roles, and the V·O·S·J station map; publish and version; view a diff against the parent.
• Create — blank, or from a Vault→Orchestrate→Shift→Jump skeleton.

9  The MCP Server — Control Plane for Tools and Orders

The Model Context Protocol server is how autonomous agents reach the world — and how the world reaches them — under one governed, audited, least‑privilege channel.

The Model Context Protocol (MCP) is an open standard for connecting AI agents to external systems and tools via a uniform client/server interface. MCP encodes calls as JSON‑RPC 2.0 and currently defines two standard transports — stdio (a local child process) and Streamable HTTP (the earlier HTTP+SSE transport was deprecated in the 2025‑03‑26 revision); VOSJ runs local executors over stdio and remote servers over Streamable HTTP. VOSJ uses an MCP Hub in two directions:

• Outbound (agents → systems). The Hub is a registry and connection manager for external MCP servers — source control, issue tracking, messaging, cloud providers, and the migration executors. When an agent needs to open a pull request, query an inventory, or invoke a transfer, it calls an MCP tool; the Hub routes the call, injects credentials from secrets at connection time, enforces per‑tool authorisation, applies timeouts, and logs the call.
• Inbound (clients → platform). The Hub also exposes selected platform services as MCP servers, so an external or internal client can reach platform data and actions through the same governed surface.

9.1  Why MCP is the right substrate

On HTTP transports MCP defines an OAuth 2.1 model in which the MCP server is an OAuth Resource Server: Protected Resource Metadata (RFC 9728) advertises the authorization server, and audience‑bound Resource Indicators (RFC 8707) plus PKCE constrain a token to its intended server; on stdio the server sources credentials from its environment. The per‑tool RBAC, allow‑lists, and capability checks above are VOSJ‑Hub controls layered on top — not guarantees of MCP itself.

9.2  Order dispatch — a composition, not an MCP property

Order dispatch is a composition, not a feature of MCP. The order channel is a database‑backed durable work queue: an operator (human or a supervising agent) enqueues a work order; a target devstation (§10) claims it atomically, executes it on its own isolated clone, and reports progress and signed evidence back. MCP is used within that execution for governed tool access (host‑initiated, request/reply) — it is not the bus itself. Separating the two — a durable queue for orders, MCP for tools — decouples who issues work from where work runs, and keeps each layer doing what it was designed for (an emerging agent‑to‑agent protocol such as A2A is the conventional choice where direct agent‑to‑agent coordination is needed).

9.3  Security model (summary; full treatment in §15)

• Credentials are environment‑reference, resolved from a secret store at connect time — never plaintext in configuration; long‑lived secrets are brokered out of the execution pod (§10.4).
• Per‑server allow‑lists and per‑tool RBAC bound the blast radius of any single agent.
• Every tool call and every order transition is logged immutably for audit.
• Input arguments are validated against each tool's schema before dispatch.
• External MCP servers and tool responses are treated as untrusted input; the agent/MCP threat classes (indirect prompt injection, tool poisoning, confused‑deputy) are addressed in the threat model (§15.5).

10  The Devstation Fleet

A devstation is an autonomous, sandboxed software‑engineering agent that behaves like a human engineer's workstation. Because it executes model‑authored code, each devstation runs under a hardened runtime class (e.g. gVisor, Kata Containers, or a Firecracker microVM via a Kubernetes RuntimeClass), and holds:

• its own identity — a distinct service/persona account, so its actions are individually attributable;
• its own repository clone — a private working tree, so concurrent stations never corrupt each other's work;
• its own model credential — a dedicated seat for the coding agent it runs;
• its own source‑control credential — so commits, branches, and pull requests carry the station's identity;
• a worker loop — a poller that claims the next unit of work, executes it headlessly, and reports back.

10.1  Fleet roles

The fleet is heterogeneous; stations specialise by role — for example architect (design), builder (implementation), reviewer (independent review), tester (validation), migrator (the migration executors), fixer (remediation), and deployer (release). This division mirrors a human engineering organisation and, more importantly, enforces separation of duties: the agent that builds a change is not the agent that reviews or approves it (cf. the four‑eyes and no‑self‑sign invariants in §12).

10.2  Lifecycle & resilience

10.3  Cost posture

Because the fleet runs on the operator's own compute and on flat‑rate model subscriptions, the marginal cost of an additional unit of migration work approaches the cost of compute, not the cost of a consultant‑hour. The factory's throughput is therefore governed by orchestration and safety review, not by headcount — the precise inversion of the human bottleneck identified in §2.1. (Flat‑rate seats carry fair‑use ceilings; at the ceiling the fleet queues/throttles or falls back to metered rates — see §22.)

10.4  Runtime isolation & credential brokering

Because a devstation runs model‑authored code beside privileged credentials, two hardening rules apply. First, the execution sandbox is a hardened runtime class (gVisor / Kata / Firecracker‑microVM via RuntimeClass), so a container escape does not reach the node or neighbouring pods. Second, long‑lived secrets do not live in the execution pod: a broker/sidecar vends short‑lived, audience‑scoped, per‑task credentials (workload‑identity federation / SPIFFE‑style OIDC for the model seat; short‑TTL tokens for source control), so a compromised station leaks at most a narrow, expiring grant. The claim is therefore per‑identity segmentation with minimised standing credentials — necessary, but explicitly not a claim that code execution and credentials are fully isolated from one another (see the threat model, §15.5).

11  The AI‑Native Execution Model

The differentiator is not "AI assists the engineer." It is "the factory's labour force is autonomous agents, supervised by humans, governed so that no agent can grant itself authority."

11.1  Human–AI partnership across the clock

Human engineers operate live during working hours; AI digital twins take over off‑hours and during absence, driving the same pipeline through the same MCP channel a human would use. A digital twin is a persona configured with the standards and judgement of its principal, authorised to perform research, design, implementation, and review autonomously, and instructed to escalate only genuine owner‑level decisions (irreversible actions, external commitments, spend) to a human. The result is a workforce that is continuously available without being unsupervised: every twin's output flows through the same gates and reviews as a human's.

11.2  The execution model is the moat

The methodologies VOSJ composes are public; the executors wrap public APIs; the gates are an engineering pattern. What is hard to replicate is the operationalised combination: an autonomous fleet that does the toil, a governed channel that makes its actions safe and auditable, digital twins that keep the factory running around the clock, and a self‑improvement loop that feeds each migration's lessons back into the templates and the agents' memory. This is why the AI execution substrate, and not the migration content, is the defensible core.

11.3  Self‑improvement loop

Phase 7 (Jump to BAU & Learn) closes the loop: each migration's post‑mortem produces template‑improvement deltas and feeds the agents' learning/"dreaming" process from the captured activity dataset. Over many engagements the framework templates sharpen and the agents' priors improve, so the factory gets faster and safer with volume — a learning curve unavailable to a purely human consultancy.

12  Governance & Safety Invariants

Autonomy is only acceptable if it is bounded. VOSJ enforces a small set of invariants structurally — in the data model and the engine — rather than by policy or reviewer diligence.

12.1  RBAC and least privilege

Authorisation is capability‑based: actions are named {domain}:{resource}:{action} and granted to roles; every data route requires authentication and every mutation requires an explicit capability. Advancing a station, cutting over, and decommissioning are owner/admin‑gated. Agents are principals in this system with deliberately constrained grants — sufficient to do their job, insufficient to authorise it.

12.2  Auditability as a first‑class output

Every station transition, access grant, tool call, and cutover is logged immutably with who/what/when/source→target. For regulated estates this audit log is itself a deliverable: defensible, exportable evidence that the migration was performed under separation of duties with verified cutovers — precisely what a pure framework leaves to the integrator to assemble after the fact.

12.3  Mapping the gate machine to recognised governance frameworks

VOSJ's invariants (§12) and gate machine (§6, §14.1) are not a private control language; they are an implementation of established governance frameworks, expressed in code. For a customer POC that must scale into a regulated production estate, this mapping is the difference between “a clever pipeline” and “an auditable control environment a board and an external auditor will accept.” The table below binds each VOSJ mechanism to the framework objective it satisfies, by the framework's real name and current structure.

12.4  The governance operating model in practice

A framework mapping is necessary but not sufficient; governance must run. The operating model below is the human and procedural layer that surrounds the gate machine and keeps an autonomous fleet under board-grade oversight. It is deliberately lightweight at POC scale and hardens on the path to production (§poc-to-prod).

The Gate Council (change-advisory function)

Each engagement convenes a Gate Council — the standing change authority for that migration, and the human embodiment of ITIL's CAB and COBIT's EDM domain. It is small, named, and quorate by role, not by headcount:

• Chair — the migration director (accountable owner; second line). Convenes the council, holds the no-go authority, and is the signer of record for director-gated transitions.
• Customer sponsor — the business owner of the estate; co-signs the P1 and (for high-risk waves) P5 gates. The sponsor is the link to the customer's own governing body.
• Risk & control reviewer — the second-line voice (security/compliance), owning the threat-model posture (§15.5), the waiver register, and control-test sign-off.
• Technical authorities — the DBA (data fidelity / reconciliation) and InfoSec (freeze, access), each the named signer for their respective gates.
• AI fleet supervisor — a human accountable for the autonomous fleet's behaviour: the principal behind the digital twins (§11). This role is explicitly not a signer for work the fleet performed — the no-self-sign invariant extends to the human who runs the fleet.

The Gate Council does not execute work and does not review every artefact line by line; the machine-checkable gate criteria (§6.1) exist precisely so the council accepts accountability for a verified fact set rather than re-deriving it. The council meets per gate (asynchronously for low-risk standard-path gates; synchronously for the P5 Go/No-Go and any waiver).

Exception & waiver handling (time-boxed)

No real estate clears every gate cleanly. Governance is judged by how exceptions are handled, not by whether they occur. VOSJ treats a waiver as a first-class, signed, expiring object — never a verbal override:

Control testing & evidence cadence

Controls that are never tested are assumptions. VOSJ runs a continuous control-testing cadence rather than a point-in-time audit, matching current SOC 2 expectations of system-generated evidence across the whole period:

Keeping the autonomous fleet under board-grade oversight

The governing concern with an autonomous fleet is not that an agent does work — it is that the chain of authority could be captured by a non-human actor. VOSJ closes this structurally and procedurally:

• Authority is withheld, not delegated. Agents are minted without any sign-as-<role> capability (Invariant 1). The fleet can assemble a complete, verified evidence package; it cannot accept accountability for it. The human signer is the load-bearing oversight boundary, by construction.
• Every fleet action is attributable. One station = one identity (§10), so the board can answer “which actor did what, on what evidence, authorised by whom” for an autonomous action exactly as for a human one.
• Irreversible steps require human escalation. Cutover, decommission, and credential rotation are owner/admin-gated; a digital twin is instructed to escalate genuine owner-level decisions (irreversible actions, external commitments, spend) rather than proceed (§11.1).
• The fleet supervisor is accountable but not self-assuring. A named human owns fleet behaviour and reports to the Gate Council; that same human cannot sign off work the fleet performed — extending separation of duties to the operator of the autonomy itself.
• Board reporting on a fixed cadence. The 8-hourly digest and per-engagement control pack roll up into the customer's existing governing-body reporting, so autonomous execution surfaces in the same risk dashboard as the rest of the IT estate — visible, not parallel.

12.5  Accountability map — RACI for the key control activities

The RACI below assigns the control activities of a migration. R = Responsible (does the work), A = Accountable (single owner, signs), C = Consulted, I = Informed. Note the consistent pattern: the fleet is Responsible, a human is Accountable — the no-self-sign invariant rendered as an accountability rule. (FS = AI fleet supervisor; Risk = risk & control reviewer; IA = internal audit / third line.)

Each activity has exactly one Accountable owner (two on cutover/reversal by design — the “two-key” control of §13.2). No row makes the entity that performs the work also accountable for approving it; where the fleet is Responsible, accountability always sits with a named human.

12.6  Governance as audit-grade, exportable evidence

The strongest property of running governance through the gate machine is that the evidence is produced as a by-product of operation, not assembled afterwards. For a customer POC heading to production, the deliverable is a self-contained, verifiable governance evidence package per migration:

• The signed gate ledger — every transition as an HMAC-SHA256, hash-chained row (actor, signer role, capability, evidence hashes, timestamp), with the signing key custodied outside the database (§14.4). An auditor can re-compute the chain and detect any back-dating, forgery, or gap without trusting the operator.
• The waiver register — every exception, its authority, residual risk, compensating control, expiry, and closure — demonstrating that deviations were governed, time-boxed, and never silent.
• The reconciliation proofs — per-workload equivalence evidence (counts, checksums, constraint re-validation, smoke results) tied by hash to the gate that consumed them.
• The tool-call & order log — the full record of what the fleet did through the MCP Hub (§14.2), so an autonomous action is as traceable as a human keystroke.
• The framework binding — the pinned template id/version (§8.2), so an auditor knows precisely which methodology, gates, and signer roles were in force for that run.

13  Verification & Reconciliation

The equivalence proof π(w) required before any cutover (§3.1, Invariant 6) is produced by a reconciliation engine that compares the migrated target against the source across several categories. A cutover gate clears only when all categories are within thresholds tuned by the database authority for the specific workload.

The replication‑lag / in‑flight gate and counts/checksums/constraints are pre‑switchover conditions of the verified‑before‑Jump gate; performance/plan parity is assessed post‑cutover in P6 within the revocable window.

13.1  Baseline discipline

Verification is meaningful only against a fresh baseline. VOSJ enforces a baseline‑drift guard: a baseline older than a configured window automatically blocks the readiness gate and forces re‑baselining. This prevents the common failure of validating a cutover against a stale picture of the source.

13.2  Revocable acceptance

Even after a reconciliation pass, the database authority may revoke acceptance within a short window if drift is detected — a deliberate "two‑key" safety margin around the most consequential transition. Contingency reversal during execution requires a three‑way authorisation, so an in‑flight cutover cannot be unilaterally aborted or forced by any single actor.

14  Data Model & Implementation

VOSJ persists its system‑of‑record in a relational database with schema‑per‑domain isolation. The migration domain holds workloads, dependencies, dispositions, waves, runbooks, and evidence; the framework domain holds templates, phases, gates, and roles (§8.2); the agent domain holds MCP server configurations and tool‑call logs.

14.1  The signed‑gate state machine

The engine exposes three core operations — getCurrentState, listValidNextStates, and signTransition — that load allowed transitions and valid roles from the bound template's rows rather than from frozen constants. A transition is committed only as an HMAC‑signed row; the RBAC capability required to sign is derived from the template‑defined role. The verified‑before‑Jump gate is injected by the engine on the last Shift→Jump transition of every template and cannot be removed by a template author.

// Conceptual shape of a gate transition (illustrative)
signTransition({
  migrationId, fromState, toState,
  actor:       "persona:eng-migrator",      // who performed the work
  signerRole:  "dba",                        // who authorises (human, named role)
  capability:  "migration:gate:sign-as-dba", // minted only to humans in role
  evidence:    [ "recon-report#J1", "hash:9f3c…" ],
  ts:          "2026-06-21T22:14:07Z"
}) // => persists HMAC-SHA256(signed_row) to the tamper-evident ledger

14.2  MCP persistence

The MCP Hub stores server configurations (transport, command/URL, environment references to secrets, allow‑lists, cached tool definitions, connection status) and a full tool‑call log (server, tool, actor, arguments, result, duration). The tool‑call log is the audit substrate referenced by Invariant 4 and requirement R8.

14.3  Engineering standards

The implementation follows strict platform rules that bound complexity and risk: all model calls go through a single LLM bridge (no direct provider SDK use); all database access through a facade (parameterised SQL only, never string concatenation); all user‑generated content escaped against injection; uniform response envelopes; small files and functions; and per‑tenant data isolation enforced on every query. These are not stylistic preferences but the controls that make an autonomous fleet's output reviewable and safe.

14.4  Durability & key custody of the ledger

Because the audit ledger is the artefact the factory's value rests on, it carries an explicit durability and key‑custody posture. The PostgreSQL system‑of‑record runs with quorum‑based synchronous replication (≥3 instances, documented failover / split‑brain handling), plus continuous backup, WAL archiving, and point‑in‑time recovery, with a stated ledger RPO/RTO. Critically, the HMAC signing key is custodied outside the database (a KMS/HSM or the fail‑closed vault of §15.2), so a database compromise cannot forge or re‑sign rows, and rows are additionally hash‑chained. Note that HMAC gives integrity against non‑key‑holders, not non‑repudiation against an insider holding the key — which is exactly why the key is custodied externally.

15  Security & Compliance Architecture

15.1  Cross‑platform access — no single primitive

There is no universal way to grant a third party scoped access to a customer's cloud; VOSJ uses each provider's sanctioned, revocable pattern, and never long‑lived shared keys:

Each grant is scoped, auditable, and revocable; access is requested per engagement and withdrawn at Jump.

Delegated management has capability limits worth designing around: it cannot delegate an Owner role or data‑plane (data‑action) roles, and does not span national/sovereign cloud boundaries — material for a tool that needs broad write/transfer authority. Where delegation cannot carry the needed capability, VOSJ falls back to a scoped service principal / managed identity provisioned in the customer tenant. "Revocable" is real, but revocation propagation and in‑flight‑session behaviour are provider‑specific.

15.2  Credential vault — fail‑closed

Migration requires custody of powerful credentials. VOSJ stores them in an encrypted vault (authenticated encryption) whose master key is supplied operationally. The vault is fail‑closed (Invariant 5): with no master key present it refuses to operate rather than falling back to a default development key. (The fail‑open fallback is a classic and dangerous anti‑pattern; eliminating it is an explicit hardening requirement.)

15.3  The self‑serve signup constraint

15.4  Data protection

Moving data across regions or clouds is itself a transfer event with legal weight. VOSJ treats data handling as a sub‑processor responsibility: a data‑processing agreement and sub‑processor disclosure, standard contractual clauses for cross‑border moves, explicit data‑loss liability with rollback gates and verified‑copy guarantees, and legal sign‑off before launch. Every access grant and data movement is recorded in the audit log.

15.5  Threat model (abbreviated)

15.6  Consolidated Threat Model (STRIDE × Agent/MCP/LLM classes)

§15.5 enumerated the abbreviated mitigation table; this subsection promotes it to a deployment-grade, reviewable threat model that a customer security team can audit line by line. We model VOSJ on two axes at once: the classical STRIDE categories (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) for the conventional surface, and the agentic/LLM threat classes — OWASP Top 10 for LLM Applications (2025), the OWASP Agentic AI “Threats & Mitigations” taxonomy (Agentic Security Initiative), and the CSA MAESTRO seven-layer model — for the autonomous-fleet surface that conventional STRIDE underserves. Each row maps a threat to the concrete VOSJ control and to a recognised framework reference.

15.7  Control Framework Mapping (NIST CSF 2.0 & ISO/IEC 27001:2022)

Customer security teams do not buy controls — they buy coverage against a framework they already report on. The table below maps VOSJ's structural controls onto the six functions of the NIST Cybersecurity Framework 2.0 (Govern, Identify, Protect, Detect, Respond, Recover) and onto the relevant theme(s) of ISO/IEC 27001:2022 Annex A (Organizational / People / Physical / Technological; 93 controls). It is the artefact to drop into a vendor-security questionnaire or a customer's GRC tool.

For SOC 2 readiness the same evidence supports the Trust Services Criteria: the audit ledger and RBAC serve Security (CC-series, mandatory); HA/DR and keepalive serve Availability; multi-category reconciliation serves Processing Integrity; the fail-closed vault and least-privilege serve Confidentiality; and the DPA / cross-border-transfer posture (§15.4) plus PII handling serve Privacy (and ISO/IEC 27018 for cloud PII).

15.8  Secure Deployment into a Customer Environment

This subsection is the deployment contract for taking VOSJ from POC into a real customer estate. It is written to the zero-trust tenets of NIST SP 800-207 (never trust, always verify; least privilege; assume breach) and to the customer's likely Azure / Azure Local landing zone.

Identity & least privilege

• Per-engagement, scoped, revocable grants only — into the customer cloud via the provider's sanctioned delegated pattern (Azure: delegated management with scoped roles; cross-cloud: role assumption / workload-identity federation, §15.1). No long-lived shared keys. Access is requested at kickoff and withdrawn at Jump.
• Just-enough, just-in-time. Standing privilege is minimised; cutover, decommission, and credential rotation are owner/admin-gated and time-boxed. Where delegation cannot carry a needed data-plane or Owner capability, fall back to a scoped service principal / managed identity provisioned in the customer tenant (§15.1).
• Workload identity for the fleet. Each station authenticates with a SPIFFE/SPIRE-style or federated-OIDC workload identity; model and source-control credentials are short-TTL and per-task (§10.4).

Network & egress

• Default-deny egress on every station namespace, with an explicit allow-list to (i) the approved migration targets, (ii) the model endpoint, (iii) source control, and (iv) cluster DNS — per the CIS Kubernetes Benchmark network-policy guidance. Egress control is the load-bearing leg that breaks the “lethal trifecta”.
• Private connectivity to customer data planes (private endpoints / private link / VPN or ExpressRoute-class circuits) rather than public-internet paths; the Shift transfer runs on the source host via the sanctioned remote-management transport (§16.2), not a gateway-local copy.
• Micro-segmentation between fleet roles (architect / builder / reviewer / migrator / deployer) so a compromised builder station cannot reach a reviewer's or deployer's surface.

Secrets & key custody

• Fail-closed vault (§15.2): no master key → refuse to operate (never a default dev key). Master key in a KMS/HSM; documented rotation and split-knowledge custody.
• HMAC ledger key custodied outside the database (§14.4) so a DB compromise cannot forge or re-sign gate rows.
• No plaintext secrets in config, image, or agent context; MCP servers reference secrets resolved at connect time; rotation reconnects transparently.

Data residency & sovereignty

• Cross-region / cross-cloud data movement is a transfer event with legal weight: DPA + sub-processor disclosure, standard contractual clauses for cross-border moves, explicit data-loss liability with rollback gates and verified-copy guarantees, legal sign-off before launch (§15.4).
• Region/sovereign pinning is configuration: targets, regions, and the model endpoint are config-driven so an engagement can be constrained to a single jurisdiction or a sovereign cloud boundary (note delegated management does not span national/sovereign boundaries, §15.1).
• Every access grant and data movement is recorded in the audit log as residency evidence.

Tenancy isolation

• Schema-per-domain + per-tenant tenant_id filter on every query (§14.3); framework templates and the audit ledger are tenant-scoped (visibility: public|tenant|private, §8.2).
• Compute isolation: dedicated node pools / RuntimeClass sandboxes per engagement where the customer's risk class requires hard multi-tenancy; one station = one clone = one identity (§10).

Logging, monitoring & detection

• Ship the immutable tool-call log, gate-ledger, and station activity to the customer's SIEM (or a shared sink); map detections to MITRE ATT&CK (infra) and MITRE ATLAS (AI-specific: prompt injection, RAG poisoning, impersonation).
• Behavioural baselining of each station's tool-call sequence against its approved runbook; alert on deviation, on descriptor drift of an external MCP server, and on baseline-drift of the source estate (§13.1).
• Detection content covers the agentic classes explicitly (excessive-agency calls, anomalous egress, memory/context anomalies) — not only conventional host signals.

Incident response

• Containment primitives built in: per-station kill-switch, order-queue freeze, instant credential revocation (short-TTL tokens expire on their own), and station quarantine via the hardened runtime boundary.
• Because authority to approve is structurally withheld from agents (Inv. 1), a compromised station can be contained without any in-flight gate having been illegitimately signed; the human-signed gate is the backstop for irreversible steps.
• IR plan aligned to CSF RESPOND (RS) and ISO A.5.24–A.5.27: declare, contain, eradicate, recover (revocable acceptance / three-way reversal, §13.2), and feed lessons to the template (§11.3).

15.9  Defense-in-Depth for the Autonomous Fleet

The fleet is the paper's novelty and therefore its largest attack surface. We defend it in concentric layers, mapped to the CSA MAESTRO seven-layer model so a reviewer can see that no layer is unguarded. The principle: an attacker must defeat several independent layers, and the outermost guarantee — that no agent can authorise its own work — holds even if inner layers fail.

15.10  Residual Risk & Acceptance

No architecture is residual-risk-free. We name what remains so the customer accepts it knowingly: (i) a plausible-but-wrong evidence package from collusion/correlated error that misleads a human signer — mitigated, not eliminated, by machine-checkable gate criteria and reviewer/model diversity (§22); (ii) novel MCP/agent attack classes emerging faster than the threat model — mitigated by treating §15.6 as a living document revisited each release against OWASP/CSA/MITRE updates; (iii) provider-specific revocation propagation — in-flight-session behaviour after a grant is revoked is provider-dependent (§15.1) and must be verified per target. These are tracked in the engagement risk register (CSF GV.RM) and re-reviewed at each phase gate.

16  Connectivity & Provider Integration

VOSJ is deliberately dual‑connectivity, so coverage is not limited to platforms that expose a migration API.

16.1  Designing around durable pillars

First‑party tool naming and availability churn (services are renamed, retired, or restricted to existing customers on the vendors' cadence). VOSJ insulates buyers by architecting on the durable, API‑drivable primitives — block/disk replication, image conversion, and database migration services — and absorbing churn behind a stable control‑plane abstraction. Provider connectors are registered in a catalog, so adding or swapping a provider is a configuration and connector task, not a redesign.

16.2  The existing executor substrate

VOSJ orchestrates a real library of point‑to‑point executors spanning the common source/target pairs (on‑prem virtualization and other public clouds into Microsoft Azure, Azure Local, and Hyper‑V; and between the Microsoft platforms — plus a generic application‑migration path). Each executor maintains its own internal state machine (draft → validated → executing → completed | failed → rolling‑back → rolled‑back) with pre‑flight checks that the station conductor invokes through a bridge but never bypasses. The Shift station's transfer steps run on the source host via the appropriate remote‑management transport, rather than via a gateway‑local copy, to keep the data path correct and efficient.

17  CI/CD & DevOps 365° Assessment

Replatforming and modernization are unsafe without a delivery system to receive the modernised workload. VOSJ therefore includes a companion assessment that closes the customer's CI/CD loop end‑to‑end — scan → build → test → quality gates → security → release → deploy → provision/promote → operate → observe → feedback — scored against a weighted master checklist, a five‑level maturity model, and DORA targets.

17.1  How it plugs into the stations

17.2  Two archetypes

• The VM→container shop with no DevOps. Roadmap builds the missing pipeline, quality gate, and observability before any Refactor work begins.
• The greenfield‑no‑blueprint customer. Roadmap establishes the standard delivery loop as the operating model from the outset.

The autonomous fleet auto‑collects most of the scorecard evidence via provider/registry scanning, and the remediation agents (bug‑crusher / healing‑agent class) close the flagged gaps — another instance of the AI substrate doing the toil that makes assessments expensive.

18  Economics & Value Model

VOSJ's economics follow from its architecture. Because tooling sits on durable first‑party primitives and the labour is an autonomous fleet on owner compute and flat‑rate model subscriptions, the cost of goods per migration is low and largely fixed; value is captured at three layers:

Any specific cost‑reduction or capacity figures that may circulate in case studies (for example claims of large percentage cost reductions or multi‑million‑dollar savings) are third‑party, illustrative, and must be independently re‑verified before being presented to a customer.

19  Worked Reference Scenario

To make the model concrete, consider a mid‑market enterprise with ~180 applications on an on‑premises virtualization estate that must exit its data centre within nine months, moving most workloads to a public cloud and modernising a customer‑facing monolith.

20  Evaluation Methodology

A claim of "factory throughput with audit‑grade governance" must be falsifiable. We propose the following evaluation dimensions and metrics; we report the methodology rather than headline numbers, which depend on estate and configuration.

The governance and safety metrics are the most important: a factory that is fast but occasionally cuts over unverified, or lets an agent authorise its own work, has failed its central design goal regardless of throughput. Because those properties are enforced structurally, the expected count of violations is zero — any non‑zero result is a defect in the engine, not in operator discipline, and is therefore directly fixable.

21  Novelty & Inventive Claims

This section enumerates the inventive concepts disclosed by this paper. It is offered as a defensive publication — a public, dated, technical disclosure establishing prior art for the combinations below. The individual ingredients (migration frameworks, the 7‑R model, Strangler‑Fig, MCP, tool‑using agents) are known; the claims concern their specific combination and operationalisation. To operate as prior art, a defensive publication must be publicly deposited with a verifiable timestamp in an examiner‑searchable venue; the intended deposit channel and date are recorded in Appendix E.

The combinations in Claims 4–9 — an MCP order/tool channel commanding an identity‑isolated autonomous fleet that performs migration work under a signed‑gate engine with a structural no‑self‑sign property and an engine‑injected verified‑before‑cutover gate — constitute the paper's primary contribution and the intended subject of this defensive disclosure; §21.1 calibrates each claim against real prior art.

21.1  Differentiation against prior art (calibrated)

This subsection situates each disclosed claim against the closest art we retrieved, and assigns a calibrated defensibility after independent adversarial verification of every differentiation. We state this honestly because the intended audience — the holders of the workflow-FSM, durable-execution, and audited-authorization patents cited below — hold directly overlapping art, much of it published by the major platform vendors themselves. No individual claim is strong in isolation. Several are anticipated when asserted standalone and are recorded here as “none” precisely so this paper cannot be read as overclaiming. The contribution we actually assert is the narrow combination (§21, Claims 4–9), not any component standing alone.

Where the novelty actually is

Read honestly, VOSJ’s defensible core is not a single invention but a narrow combination applied to software migration: (a) a verified-before-cutover gate that is engine-injected and structurally non-removable by template authors (Claim 8 — the one mechanism no retrieved reference recites, and the only element that survives at moderate); welded to (b) executing agents minted without any gate-signing capability rather than policy-denied after the fact (Claim 7); (c) an identity-isolated executor decoupled from the issuer across a durable queue + MCP channel (Claim 4); (d) the same signed phase-gate FSM governing human and off-hours-twin alike, with no relaxed path (Claim 6); so that (e) 7-R disposition leaves no un-phased transition (Claim 3) and (f) each engagement’s post-mortem updates both the agent and the bound template (Claim 9). Each of these is anticipated standing alone; the asserted contribution is their welded composition in the migration domain.

We therefore claim the specific composition — engine-injected non-removable gate + no-self-sign minting + identity-isolated dispatch + same-FSM-for-twins, applied to application migration — as one combination, and we expressly do not assert novelty over any component in isolation. Claims 1, 4 and 6 contribute to the combination at weak; Claim 8 is its strongest mechanism at moderate; Claims 2, 3, 5, 7, 9 and 10 are recorded as standalone-anticipated and are abandoned as standalone-novel. Disclosing this combination as dated prior art — rather than pursuing broad claims against parties who hold overlapping art — is the intended and most defensible posture of this paper.

22  Limitations & Threats to Validity

• The signup constraint is real. Fully‑silent self‑serve onboarding is impossible across major clouds; the hosted‑redirect and reseller shapes (§15.3) are mitigations, not eliminations, of an attested human step.
• Best fit is large, heterogeneous, audit‑sensitive estates. The seven‑phase, multi‑gate apparatus is overkill for a single‑VM overnight lift; a collapsed "express" template is a clone decision, not the flagship.
• Greenfield builds gain little from Vault/Verify — there is little to discover, baseline, or reconcile.
• Vendor funding is framework‑specific. A neutral methodology does not itself unlock a given provider's migration credits; those require the provider's own program engagement.
• Autonomy quality depends on model capability and review bandwidth. The safety invariants bound risk, not quality; poor agent output still consumes human review, which is the real throughput ceiling (§20).
• Third‑party outcome figures are illustrative and must be independently verified before customer use.
• This paper describes a design and its invariants, not a completed empirical benchmark; the evaluation methodology (§20) is offered to enable independent measurement.
• Multi‑agent collusion / correlated error. Role‑separated agents give weaker independence than human four‑eyes when they share a base model, prompt lineage, or the learning loop (§11.3); the residual risk is a plausible‑but‑wrong evidence package that misleads the human signer — mitigated, not eliminated, by machine‑checkable gate criteria and by diversifying the reviewer/rollback agent's model and context.
• Subscription rate limits. Flat‑rate model seats carry fair‑use ceilings (rolling and weekly caps); at the ceiling the fleet queues/throttles or falls back to metered rates, qualifying the "marginal cost ≈ compute" framing (§18).
• MCP/agent attack surface evolves quickly. The threat model (§15.5) reflects current practice (injection, tool poisoning, confused‑deputy); it must be revisited as the protocol and the attack literature move.

23  Future Work

• Broader provider coverage — deepen first‑party connectors beyond the current pairs and promote "planned" provider stubs to full API orchestration.
• Express templates — a published, collapsed framework for small lift‑and‑shift jobs that retains the verified‑before‑cutover gate while dropping the heavyweight planning gates.
• Incremental‑delta transfer — change‑block‑tracking incremental copies with verified delta bytes, not manifest‑only tracking.
• Formal verification of the gate engine — machine‑checked proofs that no reachable state violates the no‑self‑sign and verified‑before‑cutover invariants under any template.
• Richer reconciliation — semantic and behavioural equivalence checks beyond structural reconciliation.
• Open evaluation corpus — a shared benchmark of representative estates to make §20's metrics comparable across implementations.

24  Conclusion

Migration is a manufacturing problem dressed as an engineering problem. The individual steps are tractable; the cost lives in their lack of coordination, repeatability, audit, and labour scalability. VOSJ addresses all four by treating migration as a factory: four named stations that are brand and process at once; a data‑driven framework engine that turns any methodology into one signed, gated state machine; a disposition model that enforces safe cutover styles by construction; and — the heart of the contribution — an AI execution substrate of MCP‑commanded, identity‑isolated autonomous agents and digital twins that perform the toil while a small set of structural invariants keeps every action auditable and prevents any agent from authorising its own work.

The result is a system whose scaling law is favourable (throughput bounded by safe review, not by headcount), whose risk profile is conservative (verified‑before‑cutover, reversible, separated authority), and whose governance output — an exportable, tamper‑evident audit trail — is exactly what high‑stakes buyers require. We have described the architecture, the invariants, the data model, the security and compliance posture, the economics, a worked scenario, and an evaluation methodology, and we have disclosed the inventive combinations as a defensive publication. The design's central lesson generalises beyond migration: autonomous agents become safe to trust with consequential work precisely when the authority to approve that work is structurally withheld from them.

Appendix A — Glossary

Appendix B — Phase–Gate Reference

Appendix C — Architecture at a Glance

Appendix D — References & Sources

1. Microsoft Cloud Adoption Framework — Migrate & Modernize; landing zones; wave planning. Microsoft Learn, learn.microsoft.com/azure/cloud-adoption-framework (accessed 21 Jun 2026).
2. A major hyperscaler's migration‑acceleration program — Assess / Mobilize / Migrate & Modernize; readiness assessment; TCO business case (vendor documentation; accessed 21 Jun 2026).
3. The 7 R's of cloud migration, evolved from the earlier industry‑standard 5 R's (2010–2011).
4. Another hyperscaler's rapid migration & modernization program — Assess / Plan / Migrate / Optimize (vendor documentation; accessed 21 Jun 2026).
5. The Open Group, TOGAF Standard — ADM Phases E (Opportunities & Solutions) and F (Migration Planning); Transition Architectures. pubs.opengroup.org (accessed 21 Jun 2026).
6. M. Fowler, "StranglerFigApplication," martinfowler.com/bliki/StranglerFigApplication.html (accessed 21 Jun 2026).
7. Near‑zero‑downtime hypervisor migration technology — live, bulk, and replication‑assisted modes (vendor documentation).
8. Model Context Protocol specification, revision 2025‑06‑18 (JSON‑RPC 2.0; stdio & Streamable HTTP transports; OAuth 2.1 authorization). modelcontextprotocol.io/specification (accessed 21 Jun 2026).
9. OWASP Top 10 for LLM Applications (2025), incl. LLM01 Prompt Injection. genai.owasp.org (accessed 21 Jun 2026).
10. IETF RFC 9728 (OAuth 2.0 Protected Resource Metadata) & RFC 8707 (Resource Indicators for OAuth 2.0). datatracker.ietf.org.
11. Hardened container runtimes — gVisor (gvisor.dev), Kata Containers (katacontainers.io), Firecracker (firecracker-microvm.github.io).
12. DORA — DevOps Research and Assessment; the four key delivery metrics. dora.dev (accessed 21 Jun 2026).
13. Application‑centric "migration factory" practice — factory throughput and dependency‑centric discovery at scale.
14. OWASP Application Intelligence Security Verification Standard (AISVS) 1.0 — Appendix C, “AI for Code Generation,” controls AC.8.1 (no self-approval/merge/sign/deploy of self-generated artifacts), AC.8.2 (scoped non-human identities that cannot promote their own artifacts), AC.8.4 (separation of duties across generate/review/approve/deploy). github.com/OWASP/AISVS (accessed 21 Jun 2026).
15. NIST Cybersecurity Framework (CSF) 2.0 — six core Functions: Govern, Identify, Protect, Detect, Respond, Recover. NIST CSWP 29, released 26 Feb 2024. doi.org/10.6028/NIST.CSWP.29 (accessed 21 Jun 2026).
16. NIST SP 800-218, Secure Software Development Framework (SSDF) Version 1.1 — practice groups Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW), Respond to Vulnerabilities (RV). NIST, Feb 2022. csrc.nist.gov/pubs/sp/800/218/final (accessed 21 Jun 2026).
17. The Institute of Internal Auditors, The IIA’s Three Lines Model (2020; updated 2024) — governing body, management (first & second lines), and independent internal audit (third line). theiia.org (accessed 21 Jun 2026).
18. MITRE ATLAS™ (Adversarial Threat Landscape for Artificial-Intelligence Systems) — knowledge base of adversary tactics and techniques against AI/ML systems; complementary to MITRE ATT&CK®. atlas.mitre.org (accessed 21 Jun 2026).
19. MITRE ATT&CK® — knowledge base of adversary tactics and techniques. attack.mitre.org (accessed 21 Jun 2026).
20. Microsoft Cloud Adoption Framework for Azure — Secure methodology (security guidance spanning Strategy, Plan, Ready, Adopt, Govern, Manage). Microsoft Learn, learn.microsoft.com/azure/cloud-adoption-framework/secure (accessed 21 Jun 2026).
21. ISO/IEC 27001:2022, Information security, cybersecurity and privacy protection — Information security management systems — Requirements. International Organization for Standardization (referenced for control-catalogue mapping).
22. Selected prior art reviewed for the differentiation analysis (§21.1): US 7,607,130 (workflow as data-transition-driven, permission-checked state machine); US 7,689,947 (data-driven FSM engine); US 10,474,506 (FSM-driven workflows / workflow template as FSM); US 12,141,754 (FSM workflows for data objects); US 9,836,712 (workflow-instance migration with a per-instance migrateable-state gate); US 9,098,359 (durable execution decoupling issuer from queue-polling workers); US 8,225,378 and US 11,169,973 (audited / atomic authorization). Cited as prior art over which no standalone novelty is asserted.

URLs are given as stable locators (accessed 21 Jun 2026); volatile vendor program names are intentionally generalised. Availability and terms change over time and should be re‑verified against current documentation before customer use.

Appendix E — Document Provenance & Disclaimer

This document is provided for technical dissemination and to establish prior art. It describes a system architecture and method of operation. Product, framework, cloud‑provider, and tool names referenced herein are the property of their respective owners and are used solely for technical accuracy and interoperability description; no affiliation or endorsement is implied. Any forward‑looking statements, funding terms, and third‑party outcome figures are illustrative and subject to independent verification.

Appendix F — Revision History (v1.1 peer review · v2.0 final candidate)

v2.0 (final candidate) adds a 20‑year governance contributor, a security specialist, and an online prior‑art study, all independently verified:

v1.1 incorporates the verified findings of an independent four‑reviewer peer‑review board (IP/process, AI/MCP, infrastructure, migration):

Three reviewer findings were refuted on adversarial verification and deliberately not actioned: that big‑bang is not truly prevented (the structural disposition→runbook mapping holds); that the combination claims are "obvious" (no offensive filing is contemplated); and that performance‑parity placement was wrong (it is correctly post‑cutover).

Appendix G — Governance Control Catalog

The control catalog below enumerates the operating controls of a VOSJ migration, the role accountable for each, the V·O·S·J gate it binds to, the recognised framework objective it satisfies, and the evidence it produces. It is intended as a control library a customer can lift directly into a SOX/SOC 2/ISO programme. (Owner roles: Dir = migration director/chair; Risk = risk & control reviewer; FS = AI fleet supervisor; IA = internal audit. Engine denotes a structurally-enforced, non-waivable control.)

Controls marked Engine are enforced in the data model and gate machine and cannot be disabled by a template author or satisfied by a waiver (VG-01, VG-05, VG-07, VG-10, VG-14, VG-15). The remaining controls are operating-model controls executed by the Gate Council and the three lines; all 26 emit evidence into the same tamper-evident ledger (§14.4), so the catalog doubles as the customer's control-test plan and as the index of the evidence package (VG-26).

Appendix H — Security Sign-off Checklist (POC Gate & Production Gate)

A runnable checklist for a customer security team. Each item is binary (PASS / FAIL / N/A) with evidence and a named signer; FAIL is fail-closed (blocks the gate). The POC gate qualifies a time-boxed, scoped pilot; the Production gate additionally requires the full control set before any live customer data or irreversible cutover. References point to the framework anchors in §15.6–§15.9.

H.1  POC Gate — scoped pilot, no irreversible action on production data

H.2  Production Gate — live data & irreversible cutover authorised (includes all POC items, PASS)

Signers: each row is signed by the responsible role (customer InfoSec lead for security controls; DBA for reconciliation/HA-DR; migration director + customer sponsor for the overall gate). A single FAIL on a fail-closed item blocks the gate; N/A requires written justification. This checklist is itself an auditable artefact and should be archived with the engagement's exportable audit package (§12.2).

Appendix I — POC → Production Deployment Playbook

This appendix is the operational contract for running a VOSJ-engine proof-of-concept in a real customer environment and scaling it to production. It is written to be executed, not admired: a named gate either passes or the engagement does not advance. The engine-enforced controls are on from day one — they are what make autonomy safe to demonstrate, so the POC tightens nothing and relaxes nothing about the safety invariants (§12); it only narrows scope.

I.1  POC scope & objectives

I.2  Environment prerequisites

• Runtime. Kubernetes-native deployment with a hardened RuntimeClass (gVisor / Kata / Firecracker micro-VM) for every code-executing devstation; a successful container-escape negative test recorded before any station claims work.
• Identity & access. Per-station identity + private repository clone + brokered short-lived, audience-scoped credentials (workload-identity federation / SPIFFE-style OIDC for the model seat; short-TTL source-control tokens). No long-lived shared keys. Cross-platform access uses each provider’s sanctioned, revocable pattern (cross-account role assumption with external ID; Azure Lighthouse delegated management with scoped roles; workload-identity federation), requested per engagement and withdrawn at Jump.
• Vault. Fail-closed credential vault verified by a negative test (no master key → refuse to operate, never a development-key fallback). HMAC signing key custodied in an external KMS/HSM, not in the database (§14.4).
• System-of-record. PostgreSQL with quorum-based synchronous replication (≥3 instances), WAL archiving, point-in-time recovery, and a stated ledger RPO/RTO; a tested restore drill before any live data.
• Network. Default-deny egress with a minimal allow-list; data residency pinned in configuration and verified by an egress audit.
• MCP Hub. External MCP servers pinned and allow-listed; server-provided tool metadata statically validated before exposure to the model; per-tool RBAC and capability checks enforced at the Hub; immutable tool-call + gate audit log enabled; prompt-injection guard and tool-call-sequence monitoring active.
• Kill-switch. Per-station kill-switch + queue freeze + credential revocation drilled before the POC begins.

I.3  POC gate (I.1 — must all PASS before any data moves)

I.4  POC success metrics

• Governance integrity: zero self-signed gates; 100% of gate transitions carry a valid signature by a correctly-separated authoriser (tests Invariants 1–2).
• Safety: zero unverified cutovers; every cutover backed by a complete verified-before-cutover proof (tests Invariant 6).
• Reversibility: the independent rollback for the wave is rehearsed and its mean time-to-roll-back recorded.
• Reconciliation rigor: zero post-cutover defects that reconciliation should have caught.
• Throughput: workloads cut over per unit of human supervision — the autonomy gain, isolated from raw compute.
• Audit acceptance: the customer’s internal audit accepts the exported gate ledger as evidence (this is the gating success criterion for proceeding to production).

I.5  Bridge controls — required before any live data

Between POC and production, stand up the controls that POC scope deliberately deferred:

• Control-catalogue mapping. The risk reviewer maps VOSJ’s controls (Appendix G control set) to the customer’s existing register (SOX ITGC / SOC 2 / ISO/IEC 27001:2022), producing a control-mapping manifest the customer’s internal and external auditors sign off — establishing audit-grade acceptance before scale.
• Telemetry to the customer SIEM, with tool-call and gate events mapped to MITRE ATT&CK and MITRE ATLAS; behavioural baselining for deviation, descriptor-drift, and excessive-agency alerts.
• Data-protection instruments executed: DPA + sub-processor disclosure and standard contractual clauses; data residency/sovereignty pinned and egress-audited.
• Ledger key custody moved into an external KMS/HSM with a documented rotation procedure; a third-line re-computation drill proving the hash-chained ledger verifies independently.

I.6  Scale-to-production path (staged)

I.7  Production gate (I.2 — must all PASS before the first production wave)

• Re-verify every POC I.1 item PASSES against the production tenant.
• Prove PostgreSQL HA/DR with a tested restore (quorum sync replication, WAL/PITR, stated RPO/RTO).
• Enforce four-eyes and separation of authoring/authorising: builder ≠ reviewer ≠ signer (OWASP AISVS 1.0 AC.8.4 mapping).
• Confirm the verified-before-cutover gate is present and non-removable on every bound template, with reconciliation thresholds set per workload.
• Rehearse independent rollback per wave with the baseline-drift guard and three-way contingency reversal.
• Prove confused-deputy controls: audience validation (RFC 8707); no client-token pass-through; Hub-minted downstream-scoped tokens.
• Prove tenancy isolation: a cross-tenant access test fails; per-tenant filter on every query.

I.8  Production sign-off & operate

• Independent assessment: a vulnerability scan / penetration test including AI red-teaming (prompt injection, tool poisoning, runtime escape); all criticals closed.
• Incident-response tabletop: containment → revocation → eradication → recovery → lessons, exercised and recorded.
• Residual-risk acceptance: the customer authority reviews and accepts the residual-risk register.
• Framework coverage attested and archived with the engagement’s exportable audit package: NIST CSF 2.0 (Govern / Identify / Protect / Detect / Respond / Recover), ISO/IEC 27001:2022, SOC 2, and — for the code-generating fleet — NIST SP 800-218 (SSDF) and OWASP AISVS 1.0.
• Operate & re-review: treat the threat model (§15.6) as living — re-reviewed each release against OWASP / CSA / MITRE updates; re-verify provider-specific revocation propagation per target; re-attest the residual-risk register and framework coverage at each phase gate and at engagement renewal.