Fixture Corpus

June 1, 2026 · View on GitHub

Faultline's trust boundary is the checked-in corpus, not a vague accuracy claim. The current snapshot below reflects the checked-in real-fixture baseline and bundled playbooks in this repository.

Current Snapshot

  • Bundled playbooks: 182
  • Accepted real fixtures: 215
  • Top-1 baseline pass rate: 100% (215/215)
  • Top-3 baseline pass rate: 100% (215/215)
  • Unmatched fixtures: 0 (0.0%)
  • False positives: 0
  • Weak matches: 0 (0.0%)
  • Fixture metadata validation: required for real and staging corpora
  • Corpus fingerprint drift: release-gated through fixtures/real/baseline.json
  • Test corpus files: 32 (release-gated through corpus_test.go)
  • Source-detector regression fixtures: 33 repository scenarios under internal/engine/testdata/source/

These numbers describe the checked-in regression corpus only. They are useful because they are deterministic, reviewable, and reproducible from the repository state. They are baseline-gate numbers, not a claim that every accepted real fixture currently lands as a strong top-1 match.

Why It Matters

  • The corpus is built from accepted real-world CI failures under fixtures/real/.
  • Ranking changes are gated by regression checks instead of hidden online learning.
  • Playbook coverage, thresholds, and baseline behavior are visible in version control.
  • Automation consumers can audit the proof artifact that backs the product's trust story.

Corpus Mix

Real-fixture provider distribution from ./bin/faultline fixtures stats --class real:

ProviderAccepted Real Fixtures
GitHub104
Stack Exchange70
GitLab24
Reddit11
Discourse6

Adapter distribution in the same corpus:

AdapterAccepted Real Fixtures
github-issue104
stackexchange-question70
gitlab-issue24
reddit-post11
discourse-topic6

These counts describe the public proof corpus, not a claim that unknown failures are solved.

Release Snapshot Trend

Starting snapshot table for release-over-release tracking:

SnapshotBundled PlaybooksAccepted Real FixturesTest CorpusTop-1Top-3UnmatchedFalse Positive
2026-04-17 baseline (fixtures/real/baseline.json)7710316100%100%00
2026-04-18 corpus expansion7710330100%100%00
2026-04-22 v0.4 refinement pass10011330100%100%00
2026-04-22 test-gap closure pass10011632100%100%00
2026-04-22 adapter-diversity pass10011832100%100%00
2026-04-23 ingestion pass10012032100%100%00
2026-04-23 mixed-source ingestion pass10012332100%100%00
2026-04-23 auth-and-lock ingestion pass10012632100%100%00
2026-04-24 mixed-source ingestion + source-boundary refinement10113832100%100%00
2026-04-24 diverse-adapter ingestion pass10115332100%100%00
2026-04-26 v0.4.1 corpus expansion (228 fixtures)17022832100%100%00
2026-04-29 v0.4.4 feature release19322832100%100%00
2026-04-30 main baseline after overlap review1932283291.2%91.2%8.8%0
2026-04-30 v0.4.4 corpus hardening pass1932283292.1%92.1%7.9%0
2026-05-01 v0.4.4 corpus quality pass (removed 17 no-signal fixtures, added if-no-files-found pattern)19321132100%100%0%0
2026-05-02 playbook triage pass (removed 20 low-signal bundled playbooks)17321132100%100%0%0
2026-05-02 fixture promotion pass (promoted 4 staging candidates)17321532100%100%0%0
2026-05-15 v0.4.6 robustness improvements + playbook refinement + test coverage pass17321532100%100%0%0
Append one row per release cut so corpus growth and match stability stay visible over time.

Coverage Observations

  • The corpus mix is still GitHub-heavy: 104 GitHub fixtures (48%) out of 215 accepted real fixtures.
  • The current baseline shows 0 unmatched fixtures, 0 weak matches, and 0 false positives. All recent promotions are clean top-1 matches.
  • Source-detector rules are now regression-gated separately from the real log corpus. That keeps the trust boundary honest, but it also means source-surface expansion should come with paired repository fixtures, not just more YAML. The shipped source surface now includes 33 repository regression scenarios, including negative fixtures for virtualenv and test-only noise boundaries.
  • Signature and recurrence behavior is also pressure-tested separately through the noisy variant corpus under internal/signature/testdata/variants/ plus store-backed app tests. That keeps recurrence grouping and output determinism reviewable without inflating the release-gated real corpus.

Large-Scale Real-World Evaluation

The checked-in regression corpus (215 fixtures) is the deterministic trust gate. A separate large-scale evaluation validates that the bundled playbooks cover the failure patterns that actually appear at production volume.

Dataset: github-actions-2026-04-29

30,094 real-world GitHub Actions failure logs collected from public repositories in early 2026, evaluated against the v0.4.4 playbook set.

MetricValue
Total logs30,094
Matched26,915
Unmatched3,179
Coverage89.4%

Top 20 Matched Failure Classes

RankFailure IDCount% of matched
1container-crash5,59720.8%
2eslint-failure3,45712.8%
3buildkit-session-lost1,8276.8%
4ignored-exit-code1,5885.9%
5pnpm-lockfile1,2794.8%
6testcontainer-startup8893.3%
7node-version-mismatch6922.6%
8go-test-failure6362.4%
9git-shallow-checkout6172.3%
10runtime-mismatch5922.2%
11artifact-upload-failure5752.1%
12cache-miss-non-fatal5552.1%
13python-module-missing5472.0%
14gradle-build5392.0%
15npm-ci-lockfile4341.6%
16npm-peer-dependency-conflict3601.3%
17typescript-compile2701.0%
18cargo-test-failure2530.9%
19cargo-compile-error2460.9%
20formatting-failure2420.9%

The top 20 classes account for 74% of all matched cases. The five highest-volume failures (container-crash, eslint-failure, buildkit-session-lost, ignored-exit-code, pnpm-lockfile) alone account for over 50% of matches.

Unmatched Logs (10.6%)

The 3,179 unmatched logs represent genuine gaps — failure modes not yet covered by the current playbook set. All are singleton or near-singleton clusters in this dataset, indicating long-tail or highly project-specific patterns. Gap samples are generated by the eval tooling under eval-work/ when the large-corpus workflow is run; those generated artifacts are intentionally not part of the release-critical source tree.

Log Chunks Evaluation

The log-chunks dataset has been evaluated separately (87.2% coverage, 102/117 fixtures) but predates several playbook improvements shipped in v0.4.4. A re-evaluation against the current playbook set is pending.

What This Number Means

The 89.4% figure describes how often a real failing GitHub Actions log matches at least one bundled playbook. It is a coverage claim, not an accuracy claim — a matched log means the relevant playbook fired, not that the ranked output was reviewed by a human. It is separate from the checked-in 215-fixture baseline above. Evaluated on: 2026-04-29.

Contribution Prompt

  1. Open an issue with an anonymized failing snippet and environment context.
  2. Include a public source URL when possible (issue, discussion, or forum thread).
  3. Avoid secrets, private hostnames, and internal repository names.
  4. Mark expected diagnosis if known to speed triage.

Maintainers should route accepted cases through the deterministic ingest/review/promote flow:

# Ingest from a public source URL.
faultline fixtures ingest --adapter github-issue --url https://github.com/owner/repo/issues/123

# Sanitize known credential and identity patterns in the staging fixture.
faultline fixtures sanitize <staging-id>

# Preview replacements without modifying the file.
faultline fixtures sanitize <staging-id> --dry-run

# Review predicted matches and duplicate signals.
faultline fixtures review

# Promote to fixtures/real/ with a locked expectation.
faultline fixtures promote <staging-id> --expected-playbook <id>

Sanitizer Scope and Limitations

faultline fixtures sanitize applies a deterministic, rule-based pass over the raw_log and normalized_log fields of a staging fixture. It masks:

  • GitHub personal access tokens and app tokens
  • AWS access key IDs
  • Authorization: Bearer/Token/Basic header values
  • Credentials embedded in URLs (https://user:password@host)
  • Credential key=value and key: value pairs (password=, secret=, api_key=, access_token=, auth_token=, private_key=)
  • JWT tokens
  • PEM-encoded private key blocks
  • Email addresses

The sanitizer does not catch:

  • Internal hostnames, company-specific domain names, and service endpoint URLs
  • Signed or pre-authorized URLs that do not contain obvious credential prefixes
  • Customer or tenant identifiers embedded in paths or query strings
  • Usernames, project names, or repository names that could identify a contributor's environment
  • Any secret that does not match the above explicit patterns

Always inspect the fixture manually after running the sanitizer. The tool is a first-pass aide, not a guarantee of complete redaction.

Regenerate And Check

Build the CLI first:

make build

Re-run the real-fixture regression gate:

./bin/faultline fixtures stats --class real --check-baseline

Run the shipped CLI smoke checks against the checked-in examples:

make cli-smoke

Inspect the same report as JSON:

./bin/faultline fixtures stats --class real --json --check-baseline

Recompute the broader combined corpus if needed:

./bin/faultline fixtures stats --class all

Verify the bundled catalog size exposed by the CLI:

./bin/faultline list | tail -n +2 | wc -l

Source Of Truth

  • Bundled playbooks live under playbooks/bundled/.
  • Accepted real fixtures live under fixtures/real/.
  • Source-detector regression fixtures live under internal/engine/testdata/source/.
  • Test corpus files live under internal/engine/testdata/corpus/.
  • Signature and recurrence variant fixtures live under internal/signature/testdata/variants/.
  • The test corpus validates playbook matching through corpus_test.go as part of make test.
  • The checked-in regression baseline is fixtures/real/baseline.json.
  • The fixture commands are wired through faultline fixtures stats.
  • Source provenance and adapter counts are included in faultline fixtures stats output.