Run the read-only check in your existing CI or on an offline workstation whenever the pilot allows it.
Your source stays
where the work runs.
XeSoft private pilots start with a written input, output, transfer, access, and deletion boundary. Studio-controlled CI or offline execution is preferred; sharing a repository or binary with XeSoft is not the default.
Use only the smallest artifact, diff, log, or report needed to judge the agreed output.
Passwords, signing keys, store credentials, cloud tokens, and production personal data stay out of the pilot.
Default deployment boundary
The preferred first pilot runs as a read-only step inside the studio's existing CI environment or on a studio-controlled offline machine. Inputs remain inside that environment and the generated report is written to the studio's chosen build artifact, pull-request check, or local path.
If a self-contained prototype must run outside the studio environment, XeSoft and the evaluator agree the exact sanitized sample, transfer method, permitted use, access owner, and deletion date before anything is transferred.
Minimum input by offer
Build Delta Guard
First input: A studio-controlled accepted/candidate build-summary pair, or the minimum Unity BuildReport, Addressables layout, and artifact metadata selected for a CI-local comparison.
Not required: Source code, runner credentials, signing material, player data, build summaries, revision labels, dependency lists, metric values, and local results are not submitted by the lab evaluation form.
Project Integrity Bot
First input: A studio-controlled CI-local extractor over one accepted revision and one candidate PR, or a deliberately sanitized structured manifest of the minimum path/meta/GUID, changed-reference, Package Manager, and Git LFS evidence selected for local comparison.
Not required: Write access, merge rights, deployment credentials, unrelated repository history, repository snapshots, path lists, GUIDs, serialized references, package or LFS records, revision labels, findings, and local results are not submitted by the lab evaluation form.
Mobile Release Auditor
First input: A studio-controlled accepted/candidate AAB, APK, or IPA pair for a CI-local extractor, or the minimum structured manifest, entitlement, dependency, architecture, symbol, metadata, and payload inventories selected for a local comparison.
Not required: Signing keys, provisioning credentials, store accounts, source code, player data, packages, inventories, hashes, release identifiers, payload values, and local results are not submitted by the lab evaluation form.
Build Failure Fingerprinter
First input: A comparable last-green and failed Unity CI log pair, evaluated in the browser-local lab, inside studio-controlled CI, or as a manually reviewed sanitized sample.
Not required: Credentials, repository access, raw confidential transfer, changed-path lists, fingerprints, and local results are not submitted by the lab evaluation form.
Editor Iteration Guard
First input: A studio-controlled base-versus-change Unity fixture and timing-only summaries for compilation, assembly reload, asset import, and enter-play-mode steps.
Not required: Unrelated source, credentials, production data, write access, timing summaries, runner metadata, phase samples, and local results are not submitted by the lab evaluation form.
When XeSoft receives a sample
Only the sample required for the agreed evaluation is used. Human access is limited to Ahmad Alrefaai, the operator of XeSoft. Pilot inputs are not sold, used for another customer, placed in the outreach ledger, published as examples, or submitted to a third-party AI service without the studio's written approval.
Working copies are deleted on the agreed date, with 30 days after the evaluation ends as the default maximum. A shorter period can be agreed. Minimal contract, correspondence, suppression, or dispute records are handled separately from technical pilot inputs.
Credentials, personal data, and accidental exposure
XeSoft does not request passwords, private keys, CI secrets, cloud credentials, app-store credentials, signing certificates, provisioning secrets, or production player data. The studio should redact tokens and personal data from logs before evaluation.
If an unexpected secret or production personal record appears in a supplied sample, analysis stops. XeSoft deletes the affected working copy, tells the studio contact, and requests a corrected minimum input before continuing.
What the private pilot does not claim
XeSoft does not currently claim SOC 2 or ISO 27001 certification, an independent penetration test, enterprise SSO, a staffed 24/7 security operation, general availability, or deployment at other studios. Those controls are not implied by a private-pilot invitation.
If the studio requires a security questionnaire, data-processing agreement, approved transfer method, or additional control before any technical input is used, that requirement is resolved before the one-week delivery clock begins.
Before the first run
- Name the workflow owner and the person allowed to approve input access.
- Choose studio-controlled execution or document the exact transfer method.
- List the minimum files and confirm the excluded secrets and personal data.
- Choose the report destination, access scope, and deletion date.
- Write one evaluator-owned success criterion and one stop condition.
Security questions, deletion requests, and suspected incidents can be sent to outreach@xesoft.dev.
DEFINE THE BOUNDARY FIRSTOne workflow.
One workflow.
Only the data it needs.
Describe the current pipeline and XeSoft will propose the smallest safe input, read-only execution point, report, and deletion boundary.
Discuss the boundary ↗