XCP

Architecture & Evidence

A measured lifecycle built to prove what happened.

Deterministic projects, authenticated execution and machine-verifiable evidence across PC and Xbox.

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.

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 selected public evidence is published separately from the private implementation.

Public evidence

XCP-Research contains selected public reports and evidence supporting the measured claims on this site. It is an evidence repository, not the private XCP implementation.

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

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

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
Private implementation
Implementation identifiers, binaries and internal configuration remain outside public surfaces

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.
  • No public installer exists, and none is claimed.
  • Adaptation is measured as a playable behavioural subset; full source equivalence is not claimed.
Inside XCP Studio Availability