XCP Studio
Inside XCP Studio
From an editable project to measured execution on Xbox.
XCP Studio is not a dashboard placed above separate scripts. It is the desktop surface of one shared project, toolchain and lifecycle used by people, expert developers and external agents.
No XCP account required · local project lifecycle · Windows. It ships when public packaging is ready.
Windows only — for now. XCP Studio is a native desktop application.
Project authority
One project. One source of truth.
Every interface works against the same authoritative project state. There is no privileged agent-only path, because a second authority would eventually disagree with the first.
The interface can change. The authority does not.
Portability
A Studio that stands on its own.
The Studio uses a self-contained, verified support environment. It does not depend on access to a development source tree to operate.
What portability means
A prepared Studio environment can be used independently of the private development environment.
Compatibility and integrity are checked before the lifecycle begins.
What the Studio provides
- Verified support environment
- Integrity checks before lifecycle work
- Native Windows file and folder selection
- A recent project library with explicit states
- Clear handling for available, missing and relocated projects
- Project relinking with preserved provenance
- No persistent authentication material
The Studio workflow has been validated in an independent environment. Public packaging and distribution remain a separate product step.
Create
From an empty folder to a prepared lifecycle.
- Create project
- Edit
- Validate
- Build deterministic bundle
- Prepare complete lifecycle
- Receive structured correction
The same checked lifecycle is available to the Studio, command-line work and external agents, so the project remains consistent across interfaces.
Adapt
Adaptation is controlled interpretation, not a file conversion.
An external project is assessed as structured software and reconciled with a measured execution environment. Unsupported material is made explicit rather than silently treated as equivalent.
- External source
- Project assessment
- Compatibility review
- Controlled transformation
- Declared outcome
- XCP project
Supported source types are explicitly identified. An unrecognised project stops with a clear result rather than being force-fitted through an assumed conversion path. Coverage expands only when it is measured.
Why an explicit model matters
Adaptation needs an explicit view of the source project so that what is preserved, changed or unsupported can be declared honestly.
This keeps support decisions measurable and avoids claiming a generic converter for work that has not been tested.
Every element gets one disposition
- Preserved directly
- Translated
- Substituted
- Degraded
- Unsupported
- Requires human intervention
Work that cannot cross is named, never hidden inside a readiness score.
A real Godot 2 source project, taken at an exact public revision, was adapted and driven through the complete Xbox lifecycle: 14 of 14 operations and 5 of 5 semantic acceptance assertions, closing honestly as playable with declared degradation. See the selected public evidence in XCP-Research.
Evolve
A new upstream revision does not discard your work.
A new source revision is assessed against the existing project and its declared decisions, so changes are carried forward explicitly rather than silently overwritten.
- Known version
- Later source revision
- Declared project decisions
- Compatibility review
- New project version
- Verified update and rollback
The result is a new version, not a mutation of the old one. The previous version stays installed and reachable, which is what makes the rollback exact rather than a rebuild that happens to look the same.
Playtest and observe
A verifiable lifecycle, each stage accountable.
Every stage exposes its state, its structured errors, the correction that followed, the evidence produced and the exact version identity it applied to.
- prepareAssess the project and the measured execution environment
- validateCheck that the project remains within its declared boundaries
- executeRun an identified project version on real hardware
- observeRead structured state and outcomes from the run
- correctConnect a correction to the evidence that required it
- restoreReturn to a known version when a change is rejected
Evidence view
Evidence is part of the execution path, not a report written afterward.
Runtime observations
Structured state, logs and counters read from the running project.
Captures
Deterministic frames associated with the measured run.
Receipts
What ran, against which project version, with what outcome.
Project identity
The identified project version the run came from.
Execution identity
The identified environment used for the run.
Evidence provenance
The public material that supports the stated claim.
Correction record
What failed, what changed in response and whether the change worked.
Acceptance results
Semantic assertions, passed or not, per run.
Rollback evidence
Proof that the previous version was restored exactly.
