FAILURE MAP

Understand the failure.
Verify the repair.

Small, reproducible software failures. The broken implementation, the fix that didn’t work, and the one that passed—preserved together.

Explore the cases ↓How results are verified ↗
100840Executable case variants
20168Distinct failure mechanisms
302520Executed implementations
20168Open-access cases

WHAT THE ARCHIVE CONTAINS

100840 executable cases. 20168 are open.

Every case records the implementation that fails, the fix that did not work, and the repair that passed its checks—with recorded outputs and source hashes. This release adds 100840 cases across 20168 failure mechanisms and 254 domains.

The open tier gives you the failure and the unsuccessful fix for one case in every mechanism. The remaining 80672 cases, 5 variants per mechanism, are member-only: the verified repair, its recorded checks, and the full fixture suite are held in the member archive. Read the methodology ↗

A RECORD OF WHAT WENT WRONG

Browse the archive / 100840

Python · Standard library
REFERENCEFAILURE MECHANISMDOMAINACCESS
FA-56301

Spectral reference frame chain: LSR-to-topocentric inversion removes only one stage of the frame chain · case 01

The adapter reports an incorrect recover topocentric while other fields remain valid.

Astronomical coordinate conventions● Open access↗
FA-56302

Spectral reference frame chain: LSR-to-topocentric inversion removes only one stage of the frame chain · case 02

The adapter reports an incorrect recover topocentric while other fields remain valid.

Astronomical coordinate conventions◈ Members↗
FA-56303

Spectral reference frame chain: LSR-to-topocentric inversion removes only one stage of the frame chain · case 03

The adapter reports an incorrect recover topocentric while other fields remain valid.

Astronomical coordinate conventions◈ Members↗
FA-56304

Spectral reference frame chain: LSR-to-topocentric inversion removes only one stage of the frame chain · case 04

The adapter reports an incorrect recover topocentric while other fields remain valid.

Astronomical coordinate conventions◈ Members↗
FA-56305

Spectral reference frame chain: LSR-to-topocentric inversion removes only one stage of the frame chain · case 05

The adapter reports an incorrect recover topocentric while other fields remain valid.

Astronomical coordinate conventions◈ Members↗
FA-56306

Spectral reference frame chain: Geocentric spectral input incorrectly receives a topocentric observer shift · case 01

The adapter reports an incorrect lsr from geocenter while other fields remain valid.

Astronomical coordinate conventions● Open access↗
FA-56307

Spectral reference frame chain: Geocentric spectral input incorrectly receives a topocentric observer shift · case 02

The adapter reports an incorrect lsr from geocenter while other fields remain valid.

Astronomical coordinate conventions◈ Members↗
FA-56308

Spectral reference frame chain: Geocentric spectral input incorrectly receives a topocentric observer shift · case 03

The adapter reports an incorrect lsr from geocenter while other fields remain valid.

Astronomical coordinate conventions◈ Members↗
FA-56309

Spectral reference frame chain: Geocentric spectral input incorrectly receives a topocentric observer shift · case 04

The adapter reports an incorrect lsr from geocenter while other fields remain valid.

Astronomical coordinate conventions◈ Members↗
FA-56310

Spectral reference frame chain: Geocentric spectral input incorrectly receives a topocentric observer shift · case 05

The adapter reports an incorrect lsr from geocenter while other fields remain valid.

Astronomical coordinate conventions◈ Members↗
FA-56311

Wcs header card semantics: CTYPE projection parsing mistakes an appended distortion tag for the projection code · case 01

The adapter reports an incorrect projection while other fields remain valid.

Astronomical coordinate conventions● Open access↗
FA-56312

Wcs header card semantics: CTYPE projection parsing mistakes an appended distortion tag for the projection code · case 02

The adapter reports an incorrect projection while other fields remain valid.

Astronomical coordinate conventions◈ Members↗
FA-56313

Wcs header card semantics: CTYPE projection parsing mistakes an appended distortion tag for the projection code · case 03

The adapter reports an incorrect projection while other fields remain valid.

Astronomical coordinate conventions◈ Members↗
FA-56314

Wcs header card semantics: CTYPE projection parsing mistakes an appended distortion tag for the projection code · case 04

The adapter reports an incorrect projection while other fields remain valid.

Astronomical coordinate conventions◈ Members↗
FA-56315

Wcs header card semantics: CTYPE projection parsing mistakes an appended distortion tag for the projection code · case 05

The adapter reports an incorrect projection while other fields remain valid.

Astronomical coordinate conventions◈ Members↗
FA-56316

Wcs header card semantics: Case-folding spectral CUNIT conflates milli- and mega-frequency prefixes · case 01

The adapter reports an incorrect frequency hz while other fields remain valid.

Astronomical coordinate conventions● Open access↗
FA-56317

Wcs header card semantics: Case-folding spectral CUNIT conflates milli- and mega-frequency prefixes · case 02

The adapter reports an incorrect frequency hz while other fields remain valid.

Astronomical coordinate conventions◈ Members↗
FA-56318

Wcs header card semantics: Case-folding spectral CUNIT conflates milli- and mega-frequency prefixes · case 03

The adapter reports an incorrect frequency hz while other fields remain valid.

Astronomical coordinate conventions◈ Members↗
FA-56319

Wcs header card semantics: Case-folding spectral CUNIT conflates milli- and mega-frequency prefixes · case 04

The adapter reports an incorrect frequency hz while other fields remain valid.

Astronomical coordinate conventions◈ Members↗
FA-56320

Wcs header card semantics: Case-folding spectral CUNIT conflates milli- and mega-frequency prefixes · case 05

The adapter reports an incorrect frequency hz while other fields remain valid.

Astronomical coordinate conventions◈ Members↗
FA-56321

Wcs header card semantics: CRPIX header defaulting conflates an explicit zero with an absent card · case 01

The adapter reports an incorrect reference pixel while other fields remain valid.

Astronomical coordinate conventions● Open access↗
FA-56322

Wcs header card semantics: CRPIX header defaulting conflates an explicit zero with an absent card · case 02

The adapter reports an incorrect reference pixel while other fields remain valid.

Astronomical coordinate conventions◈ Members↗
FA-56323

Wcs header card semantics: CRPIX header defaulting conflates an explicit zero with an absent card · case 03

The adapter reports an incorrect reference pixel while other fields remain valid.

Astronomical coordinate conventions◈ Members↗
FA-56324

Wcs header card semantics: CRPIX header defaulting conflates an explicit zero with an absent card · case 04

The adapter reports an incorrect reference pixel while other fields remain valid.

Astronomical coordinate conventions◈ Members↗
FA-56325

Wcs header card semantics: CRPIX header defaulting conflates an explicit zero with an absent card · case 05

The adapter reports an incorrect reference pixel while other fields remain valid.

Astronomical coordinate conventions◈ Members↗
FA-56326

Wcs header card semantics: WCS dimensionality ignores either image axes or explicit degenerate transform axes · case 01

The adapter reports an incorrect dimension while other fields remain valid.

Astronomical coordinate conventions● Open access↗
FA-56327

Wcs header card semantics: WCS dimensionality ignores either image axes or explicit degenerate transform axes · case 02

The adapter reports an incorrect dimension while other fields remain valid.

Astronomical coordinate conventions◈ Members↗
FA-56328

Wcs header card semantics: WCS dimensionality ignores either image axes or explicit degenerate transform axes · case 03

The adapter reports an incorrect dimension while other fields remain valid.

Astronomical coordinate conventions◈ Members↗
FA-56329

Wcs header card semantics: WCS dimensionality ignores either image axes or explicit degenerate transform axes · case 04

The adapter reports an incorrect dimension while other fields remain valid.

Astronomical coordinate conventions◈ Members↗
FA-56330

Wcs header card semantics: WCS dimensionality ignores either image axes or explicit degenerate transform axes · case 05

The adapter reports an incorrect dimension while other fields remain valid.

Astronomical coordinate conventions◈ Members↗
FA-56331

Wcs header card semantics: Human-readable WCSNAME is used as an alternate-key suffix · case 01

The adapter reports an incorrect selected suffix while other fields remain valid.

Astronomical coordinate conventions● Open access↗
FA-56332

Wcs header card semantics: Human-readable WCSNAME is used as an alternate-key suffix · case 02

The adapter reports an incorrect selected suffix while other fields remain valid.

Astronomical coordinate conventions◈ Members↗
FA-56333

Wcs header card semantics: Human-readable WCSNAME is used as an alternate-key suffix · case 03

The adapter reports an incorrect selected suffix while other fields remain valid.

Astronomical coordinate conventions◈ Members↗
FA-56334

Wcs header card semantics: Human-readable WCSNAME is used as an alternate-key suffix · case 04

The adapter reports an incorrect selected suffix while other fields remain valid.

Astronomical coordinate conventions◈ Members↗
FA-56335

Wcs header card semantics: Human-readable WCSNAME is used as an alternate-key suffix · case 05

The adapter reports an incorrect selected suffix while other fields remain valid.

Astronomical coordinate conventions◈ Members↗
FA-56336

Wcs header card semantics: PV projection coefficients are bound to storage axes instead of world axes · case 01

The adapter reports an incorrect projection parameter while other fields remain valid.

Astronomical coordinate conventions● Open access↗
FA-56337

Wcs header card semantics: PV projection coefficients are bound to storage axes instead of world axes · case 02

The adapter reports an incorrect projection parameter while other fields remain valid.

Astronomical coordinate conventions◈ Members↗
FA-56338

Wcs header card semantics: PV projection coefficients are bound to storage axes instead of world axes · case 03

The adapter reports an incorrect projection parameter while other fields remain valid.

Astronomical coordinate conventions◈ Members↗
FA-56339

Wcs header card semantics: PV projection coefficients are bound to storage axes instead of world axes · case 04

The adapter reports an incorrect projection parameter while other fields remain valid.

Astronomical coordinate conventions◈ Members↗
FA-56340

Wcs header card semantics: PV projection coefficients are bound to storage axes instead of world axes · case 05

The adapter reports an incorrect projection parameter while other fields remain valid.

Astronomical coordinate conventions◈ Members↗
FA-56341

Sealed envelope: replacement digest · case 01

An old sealed envelope remains revealable after a replacement commit.

Auction allocation rules● Open access↗
FA-56342

Sealed envelope: replacement digest · case 02

An old sealed envelope remains revealable after a replacement commit.

Auction allocation rules◈ Members↗
FA-56343

Sealed envelope: replacement digest · case 03

An old sealed envelope remains revealable after a replacement commit.

Auction allocation rules◈ Members↗
FA-56344

Sealed envelope: replacement digest · case 04

An old sealed envelope remains revealable after a replacement commit.

Auction allocation rules◈ Members↗
FA-56345

Sealed envelope: replacement digest · case 05

An old sealed envelope remains revealable after a replacement commit.

Auction allocation rules◈ Members↗
FA-56346

Sealed envelope: reveal phase · case 01

Reveal admission loses one side of the commit/reveal phase interval.

Auction allocation rules● Open access↗
FA-56347

Sealed envelope: reveal phase · case 02

Reveal admission loses one side of the commit/reveal phase interval.

Auction allocation rules◈ Members↗
FA-56348

Sealed envelope: reveal phase · case 03

Reveal admission loses one side of the commit/reveal phase interval.

Auction allocation rules◈ Members↗
FA-56349

Sealed envelope: reveal phase · case 04

Reveal admission loses one side of the commit/reveal phase interval.

Auction allocation rules◈ Members↗
FA-56350

Sealed envelope: reveal phase · case 05

Reveal admission loses one side of the commit/reveal phase interval.

Auction allocation rules◈ Members↗
FA-56351

Sealed envelope: withdrawal tombstone · case 01

Withdrawal fails to invalidate an unopened sealed commitment.

Auction allocation rules● Open access↗
FA-56352

Sealed envelope: withdrawal tombstone · case 02

Withdrawal fails to invalidate an unopened sealed commitment.

Auction allocation rules◈ Members↗
FA-56353

Sealed envelope: withdrawal tombstone · case 03

Withdrawal fails to invalidate an unopened sealed commitment.

Auction allocation rules◈ Members↗
FA-56354

Sealed envelope: withdrawal tombstone · case 04

Withdrawal fails to invalidate an unopened sealed commitment.

Auction allocation rules◈ Members↗
FA-56355

Sealed envelope: withdrawal tombstone · case 05

Withdrawal fails to invalidate an unopened sealed commitment.

Auction allocation rules◈ Members↗
FA-56356

Sealed envelope: replay disclosure · case 01

A repeated opening emits the sealed payload again.

Auction allocation rules● Open access↗
FA-56357

Sealed envelope: replay disclosure · case 02

A repeated opening emits the sealed payload again.

Auction allocation rules◈ Members↗
FA-56358

Sealed envelope: replay disclosure · case 03

A repeated opening emits the sealed payload again.

Auction allocation rules◈ Members↗
FA-56359

Sealed envelope: replay disclosure · case 04

A repeated opening emits the sealed payload again.

Auction allocation rules◈ Members↗
FA-56360

Sealed envelope: replay disclosure · case 05

A repeated opening emits the sealed payload again.

Auction allocation rules◈ Members↗
FA-56361

Sealed envelope: first valid reveal · case 01

Payload retention uses position without checking reveal verification.

Auction allocation rules● Open access↗
FA-56362

Sealed envelope: first valid reveal · case 02

Payload retention uses position without checking reveal verification.

Auction allocation rules◈ Members↗
FA-56363

Sealed envelope: first valid reveal · case 03

Payload retention uses position without checking reveal verification.

Auction allocation rules◈ Members↗
FA-56364

Sealed envelope: first valid reveal · case 04

Payload retention uses position without checking reveal verification.

Auction allocation rules◈ Members↗
FA-56365

Sealed envelope: first valid reveal · case 05

Payload retention uses position without checking reveal verification.

Auction allocation rules◈ Members↗
FA-56366

Sealed envelope: nonce binding · case 01

A nonempty nonce is treated as proof of binding to this envelope.

Auction allocation rules● Open access↗
FA-56367

Sealed envelope: nonce binding · case 02

A nonempty nonce is treated as proof of binding to this envelope.

Auction allocation rules◈ Members↗
FA-56368

Sealed envelope: nonce binding · case 03

A nonempty nonce is treated as proof of binding to this envelope.

Auction allocation rules◈ Members↗
FA-56369

Sealed envelope: nonce binding · case 04

A nonempty nonce is treated as proof of binding to this envelope.

Auction allocation rules◈ Members↗
FA-56370

Sealed envelope: nonce binding · case 05

A nonempty nonce is treated as proof of binding to this envelope.

Auction allocation rules◈ Members↗
FA-56371

Sealed envelope: signer binding · case 01

Reveal authentication admits a different bidder for a single reveal.

Auction allocation rules● Open access↗
FA-56372

Sealed envelope: signer binding · case 02

Reveal authentication admits a different bidder for a single reveal.

Auction allocation rules◈ Members↗
FA-56373

Sealed envelope: signer binding · case 03

Reveal authentication admits a different bidder for a single reveal.

Auction allocation rules◈ Members↗
FA-56374

Sealed envelope: signer binding · case 04

Reveal authentication admits a different bidder for a single reveal.

Auction allocation rules◈ Members↗
FA-56375

Sealed envelope: signer binding · case 05

Reveal authentication admits a different bidder for a single reveal.

Auction allocation rules◈ Members↗
FA-56376

Sealed envelope: preopening secrecy · case 01

Receiving a reveal is confused with authorized public opening.

Auction allocation rules● Open access↗
FA-56377

Sealed envelope: preopening secrecy · case 02

Receiving a reveal is confused with authorized public opening.

Auction allocation rules◈ Members↗
FA-56378

Sealed envelope: preopening secrecy · case 03

Receiving a reveal is confused with authorized public opening.

Auction allocation rules◈ Members↗
FA-56379

Sealed envelope: preopening secrecy · case 04

Receiving a reveal is confused with authorized public opening.

Auction allocation rules◈ Members↗
FA-56380

Sealed envelope: preopening secrecy · case 05

Receiving a reveal is confused with authorized public opening.

Auction allocation rules◈ Members↗
FA-56381

Sealed envelope: lot binding · case 01

A reveal can be replayed against a different lot.

Auction allocation rules● Open access↗
FA-56382

Sealed envelope: lot binding · case 02

A reveal can be replayed against a different lot.

Auction allocation rules◈ Members↗
FA-56383

Sealed envelope: lot binding · case 03

A reveal can be replayed against a different lot.

Auction allocation rules◈ Members↗
FA-56384

Sealed envelope: lot binding · case 04

A reveal can be replayed against a different lot.

Auction allocation rules◈ Members↗
FA-56385

Sealed envelope: lot binding · case 05

A reveal can be replayed against a different lot.

Auction allocation rules◈ Members↗
FA-56386

Sealed envelope: verified reveal count · case 01

Invalid reveals consume the count of accepted envelopes.

Auction allocation rules● Open access↗
FA-56387

Sealed envelope: verified reveal count · case 02

Invalid reveals consume the count of accepted envelopes.

Auction allocation rules◈ Members↗
FA-56388

Sealed envelope: verified reveal count · case 03

Invalid reveals consume the count of accepted envelopes.

Auction allocation rules◈ Members↗
FA-56389

Sealed envelope: verified reveal count · case 04

Invalid reveals consume the count of accepted envelopes.

Auction allocation rules◈ Members↗
FA-56390

Sealed envelope: verified reveal count · case 05

Invalid reveals consume the count of accepted envelopes.

Auction allocation rules◈ Members↗
FA-56391

Amendment priority: increase priority · case 01

Increasing requested size keeps its obsolete queue position.

Auction allocation rules● Open access↗
FA-56392

Amendment priority: increase priority · case 02

Increasing requested size keeps its obsolete queue position.

Auction allocation rules◈ Members↗
FA-56393

Amendment priority: increase priority · case 03

Increasing requested size keeps its obsolete queue position.

Auction allocation rules◈ Members↗
FA-56394

Amendment priority: increase priority · case 04

Increasing requested size keeps its obsolete queue position.

Auction allocation rules◈ Members↗
FA-56395

Amendment priority: increase priority · case 05

Increasing requested size keeps its obsolete queue position.

Auction allocation rules◈ Members↗
FA-56396

Amendment priority: price priority · case 01

Only upward price amendments lose auction queue priority.

Auction allocation rules● Open access↗
FA-56397

Amendment priority: price priority · case 02

Only upward price amendments lose auction queue priority.

Auction allocation rules◈ Members↗
FA-56398

Amendment priority: price priority · case 03

Only upward price amendments lose auction queue priority.

Auction allocation rules◈ Members↗
FA-56399

Amendment priority: price priority · case 04

Only upward price amendments lose auction queue priority.

Auction allocation rules◈ Members↗
FA-56400

Amendment priority: price priority · case 05

Only upward price amendments lose auction queue priority.

Auction allocation rules◈ Members↗

INSPECTABLE BY DESIGN

Every result has a runnable source.

Runnable implementations with recorded outputs, source hashes, and explicit contracts. Related variants share a failure mechanism and belong together in evaluation splits.

Read the methodology ↗