Build Delta Guard compares a candidate Unity build with an accepted baseline, then posts the size, memory, shader, bundle, and duration changes your team actually needs to investigate.
Only policy-relevant changes are raised.
A compact PR report with budget checks and the highest-confidence asset attribution available from the build artifacts.
The first pilot uses the subset that matches your workflow. The rest stay out of the way until they earn their place.
Executable, AAB, APK, IPA, Addressables, and bundle changes against an accepted baseline.
Texture, audio, scene, and other asset deltas with source attribution where the build data supports it.
Surface sudden variant growth before it becomes a build-time or runtime surprise.
Flag likely duplicated assets across bundles or build outputs with the evidence attached.
Track wall-clock regressions by target and build configuration instead of relying on CI intuition.
Apply absolute and relative thresholds per platform, branch, and metric.
The first pilot is an evaluation contract, not an open-ended integration. The evaluator decides whether one real workflow became clearer or faster.
Build engineer, technical director, engineering lead, or performance owner.
One comparable candidate/baseline pair with a persisted Unity BuildReport or equivalent report data, plus the compiled-artifact metadata needed for the agreed checks.
A ranked delta report with units, budget status, comparability checks, evidence paths, and confidence-labelled attribution.
The owner can explain or action the top material changes faster than with the current comparison process.
Once the contract above is confirmed, the first report is prepared within one week. No platform migration and no quarter-long rollout.
Name the evaluator, review point, safe input, exact output, transfer method, and success criterion.
Run a read-only analysis step in the current workflow or against the agreed sanitized sample, then produce the first report.
Run it against representative changes, tune noise, and decide whether the next scope is justified.
No. It reviews build-level change signals. Runtime profiling remains a separate workflow, and any measurable runtime budgets need an agreed, reproducible test scene.
The pilot is designed to run in your CI. It reads the build inputs and outputs needed for the agreed checks; the default model does not upload your repository to XeSoft.
A first report on one build target, connected to one existing CI workflow, with an agreed subset of budgets. We then use the result to decide whether a broader rollout is worthwhile.
A repeatable way to compare a candidate Unity build with an accepted baseline and turn package growth into traceable review evidence.
Read the workflow checklist ↗Describe the recurring production problem and the smallest representative input you could evaluate. XeSoft will first confirm whether this narrow pilot is a fit—and say so plainly if it is not.
Prefer email? outreach@xesoft.dev
We will tell you what a useful one-week pilot can cover—and what it cannot.
Request a private pilot ↑