Build Failure Fingerprinter compares a failed Unity CI log with an accepted last-green run, suppresses shared noise, and returns a stable failure signature, the first materially divergent error chain, and one evidence-backed next check.
Only traceable, rules-backed evidence is raised.
A deterministic triage report that separates observed log evidence from rule-based inference and says when the comparison is too limited to support a diagnosis.
The first pilot uses the subset that matches your workflow. The rest stay out of the way until they earn their place.
Check Unity, target, scripting backend, platform tooling, and job context before attributing any difference.
Normalize timestamps, paths, process IDs, and other agreed volatile tokens so the same failure can recur under one signature.
Separate errors already present in a successful run from the first new or materially changed error chain.
Apply a small explicit ruleset for compiler, package, import, platform, licensing, cache, test, and infrastructure failures.
Correlate supplied changed paths only when the evidence supports it; leave the field empty when it does not.
Return one bounded diagnostic branch with its rule and source lines, not an invented root-cause claim.
The first pilot is an evaluation contract, not an open-ended integration. The evaluator decides whether one real workflow became clearer or faster.
Build or release engineer, tools engineer, engineering lead, or producer accountable for build-triage time.
One complete failed log and one comparable last-green log after agreed redaction, plus non-secret job metadata and an optional path-only change manifest.
A deterministic fingerprint, comparability result, first divergent chain, confidence-labelled failure class, traceable evidence, and one bounded next diagnostic check.
The owner needs fewer manual comparisons to choose the next check—or can identify the missing output that prevented that reduction.
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.
Not in the first pilot. The report uses versioned deterministic normalization and classification rules. Every non-unknown result must cite the rule and source lines that produced it.
No. The preferred pilot runs locally inside your CI and writes only the report. A sanitized log pair can be used instead; XeSoft does not request a repository clone, CI token, signing key, or environment-secret dump.
A first offline or CI-local report over one agreed failed/last-green pair, covering the failure families and output fields confirmed with the evaluator before the clock starts.
A deterministic workflow for separating shared log noise from the first materially divergent failure chain and choosing one bounded next check.
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 ↑