XCP

Architecture & Evidence

A measured lifecycle built to prove what happened.

The foundation behind creating, adapting and iterating on Xbox projects: deterministic builds, controlled execution and results you can inspect.

Overview

From an editable file to a measured frame.

  1. Person / IDE / AI agent
  2. Authoritative XCP project
  3. Deterministic preparation
  4. Compatibility assessment
  5. Controlled PC–Xbox exchange
  6. Managed project state
  7. XCP runtime
  8. Bounded execution
  9. Observation / evidence / rollback

Foundations

What the runtime is made of.

These are not features layered onto a general-purpose host. Each one exists because a specific class of unverifiable outcome had to be made impossible.

Deterministic project contracts

Equivalent project inputs produce a stable, identifiable result. Invalid or inconsistent input is rejected before execution.

Controlled execution exchange

The PC and Xbox exchange only the material needed for a bounded run. Credentials are not retained on the console.

Versioned deployment

Each prepared version is identifiable and kept distinct so that a run can be attributed to the version that produced it.

Verified state changes

A run proceeds from an explicit version state, with transitions recorded as evidence rather than inferred afterward.

Exact rollback

The previous version is restored, not rebuilt. A rejected candidate cannot disturb the version that is working.

Structured errors

Failures are exposed in a form that people and tools can inspect, correct and verify.

Correction evidence

The observed failure, the corrective change and the resulting outcome remain connected in the evidence.

Controlled execution plans

The planned work is fixed before a run begins, making the observed outcome attributable to a defined execution.

Bounded computation

Only work that stays within the declared execution limits is admitted.

Recoverable SSD storage

XCP uses application-private storage on Xbox for content-identified pages and verified commit records. After an interruption, recovery accepts only confirmed data within declared storage limits.

Resumable block computation

Progress advances only after a block's verified result is committed. A resumed run checks completed blocks and restarts at the first unconfirmed one, preserving work without increasing the application's memory budget.

Reference verification

Results are checked against a canonical reference before they become evidence.

Measured acceleration

Accelerated work is accepted only when its result agrees with the verification path.

Public-platform operation

XCP stays within the documented platform boundaries measured for this programme.

Application isolation

Project material and evidence remain within the application boundary used for the measured run.

Reproducible evidence

Selected public reports identify the conditions and outcomes supporting the claims on this site.

Performance figures appear further down as proof that this foundation is substantial. They are not the purpose of the product.

Evidence hierarchy

Eight layers, from a sentence to a digest.

A reader should be able to stop at the layer that satisfies them and keep descending if it does not.

  1. 1Human-readable summaryWhat was attempted and what happened.
  2. 2Machine-readable verdictA decision field a tool can branch on: pass, ready, not ready.
  3. 3Project identityThe project version the run was performed against.
  4. 4Execution identityThe identified execution environment used for the run.
  5. 5Observations and capturesCounters, logs and deterministic frames with their own digests.
  6. 6Correction ledgerThe failures, the corrections and their order.
  7. 7Exact update and rollback proofThe version chain, restored rather than rebuilt.
  8. 8Public report referencesSelected public material supporting the stated claim.

Measurements

What has been measured, and where.

Local means tested on PC; measured on Xbox means driven live on retail hardware. The open source implementation and selected public evidence can both be inspected on GitHub.

Public source

The xcp-xbox repository is the canonical public source, with preserved reference material, build instructions and contribution paths. Measurements below describe historical research runs; new development packages need their own Xbox evidence.

Creation, from zero, by an agent with no repository access

State
Measured on Xbox
Lifecycle operations
28 / 28 aggregate, across one interactive game and one utility
Blocker assertions
12 / 12
Captures
6 / 6
Confirmed ledger corrections
6 / 6
Final state
7 / 7 verified lifecycle states
Agent isolation
No repository access, samples, network, credentials or live system access
Correction chain
Observed failures were corrected and verified through the lifecycle
Final decision
pass

Adaptation of a real external source

State
Measured on Xbox
Source
Minilens v1.2 — a Godot 2 project, GPL-3.0-or-later, used as an adaptation subject and not an XCP product
Lifecycle operations
14 / 14
Semantic acceptance
5 / 5
Readiness decision
Playable with declared degradation
Declared degradations
Some source material required declared conversion or replacement before execution
Scope

The run above is exact and stands. Its adaptation is a playable behavioural subset of the original; full source equivalence is not claimed. The adapter's first attempt on this source refused a real collision rather than forcing it through — a pipeline that never refuses a real input has not been tested on one.

Evolution across a later authorized revision

State
Measured on Xbox
Change scope
A later authorized source revision was reconciled into a new project version
Lifecycle
14 / 14 operations, 5 / 5 assertions, 3 / 3 captures
Version chain
Exact update and rollback were verified

Three Godot projects, bounded playable reconstructions

Projects
Blokki, Minedot and Open RTS
State
Historical Xbox runs
Result
3 / 3 bounded playable reconstruction results; 15 / 15 human playability checks passed
Interaction
Physical Xbox controller input and recorded observations
Scope
Measured scenarios with declared substitutions and presentation corrections; full source fidelity and universal Godot compatibility are not claimed

This three-project synthesis is separate from the Minilens adaptation and the creative-host restoration test below. It summarizes preserved historical outcomes and does not validate newly rebuilt development packages.

Creative host, restored exactly after a fresh session

State
Measured on Xbox
Projects
Three public projects installed, launched, observed and captured
Fresh-session restore
An exact prior version was restored; inconsistent bindings were rejected
Observation after restore
Recorded observations remained consistent after restoration
Violations
0

Recoverable SSD workspace: two separate experiments

State
Historical Xbox runs
Storage scale
8 GiB in one application-private namespace: 2,048 unique pages of 4 MiB each
Storage verification
The namespace survived Home/Resume, was fully reread and verified, then removed with repeatable cleanup
Streaming compute
A separate 4 MiB field, processed as 256 tiles of 16 KiB with verified results
Interruption recovery
After an interruption, 128 committed tiles were verified and skipped; the remaining 128 were computed on resume
Measurement scope

The 8 GiB result measures persistent storage and recovery for one namespace, not the full physical SSD capacity or computation over an 8 GiB dataset. The streaming compute experiment used 4 MiB in total. Neither result adds RAM, introduces transparent swap or expands the UWP process memory budget. These historical runs do not validate newly rebuilt public packages; those require independent Xbox measurements.

Studio, validated outside the development repository

State
Measured local
Independent run
The Studio created and opened a project, then completed preparation, adaptation and evolution outside the development environment
Validation
The relevant validation suites passed
Xbox impact
None. The validation did not require a live console mutation.

Identities

Evidence that identifies the run without exposing the implementation.

Evidence without an execution identity is a description of an event, not a record of one.

Execution identity
Each measured run is bound to an identified project version and execution environment
Evidence provenance
Selected public reports state the test conditions, assertions and outcomes
Publication scope
The development source is public; operational records, credentials and private environment details remain outside the public repository

Correction ledgers

A ledger is append-only and hash-chained, written while the work runs. It records the structured failure, the correction derived from it and whether the retry succeeded — so a claim that something was fixed can be checked against the sequence that fixed it, rather than trusted.

Measured platform envelope

Hardware
Retail Xbox Series hardware in Developer Mode
Resource envelope
Measured within the documented application constraints of the platform
Compute results
Measured workloads are recorded in the selected public evidence

These are application-level results, not full-console figures. No full-console claim is made anywhere in this programme.

Runtime boundaries

Constrained by design.

These constraints govern the measured environment. They are the reason the measurements above are worth reading.

No jailbreak or firmware modificationPublic UWP
No arbitrary native-code uploadPlatform boundary
No shell or process spawningExecution boundary
No full trustPlatform boundary
No broad filesystem accessApp-private only
No unrestricted code generation on the consoleExecution boundary
No client-supplied executable graphics logicExecution boundary
No credential persistence on XboxSession boundary
No capability expansion beyond the measured boundaryVerified
No unmeasured GDK or full-console claimIn the evidence

FAQ

Four questions worth answering directly.

Does XCP jailbreak or modify the console?
No. XCP operates within measured Xbox Developer Mode and public-UWP boundaries. It does not modify firmware, bypass the platform security model or upload arbitrary native code.
Does the AI model run on the Xbox?
No. Reasoning, creation, adaptation and correction happen on the PC side. Xbox executes bounded, validated artifacts through the measured XCP runtime, and the console stores no model-provider credentials. A model provider may itself be remote.
Is XCP an alternative to publishing a game on Xbox?
No. XCP is a development and verification platform that runs on retail Xbox Series hardware in Developer Mode. It is not a consumer distribution route and does not replace retail publishing.
Can XCP run any existing game?
No. Adaptation reconciles a source project against the measured host profile, and every element receives one explicit disposition. Work that cannot cross is reported as degraded, unsupported or requiring human intervention rather than silently dropped.

Current claim boundary

What this programme does and does not assert today.

XCP Studio runs on Windows only — for now. It is a native desktop application; the console side is unaffected.

  • XCP operates on real retail Xbox Series hardware through Developer Mode.
  • It is not a consumer publishing replacement.
  • AI reasoning is normally PC-side; the console executes validated artifacts.
  • The Studio workflow has been validated in an independent environment.
  • The source and development build instructions are public; a prebuilt consumer installer is not offered.
  • Adaptation is measured as a playable behavioural subset; full source equivalence is not claimed.
Explore the open source stack Development status