Mian Zhang

Public Release - 2026-06-09

A useful failure should change the next version.

Artifact: Failure-to-Asset Issue Queue v0. A failure is useful only when it names the target claim, public artifact, observed failure, evidence gap, and boundary effect.

target_claim public_artifact failure boundary_effect repair_queue
Papers Evidence Map Counterexamples Registries
Failure-to-asset queue visual showing a failure event moving into issue triage and boundary repair.

Artifact

When a Failure Changes the Next Version

A public issue route for turning bounded failures into claim repair, boundary updates, and reviewable evidence gaps.

This route does not claim that every failure is valid, that public issues replace review, or that protected runtime material is needed for public criticism.

1

Target claim

Name the exact claim that the failure attacks.

2

Public artifact

Link the DOI, page, registry row, demo, manifest, or issue route.

3

Observed failure

Describe the smallest visible break without relying on protected material.

4

Evidence gap

Explain which missing field makes the claim too broad.

5

Boundary effect

State whether the claim should narrow, split, move to review, or withdraw.

6

Repair queue

Turn the failure into a public work item with an owner route and next check.

Failure As Asset

A complaint is not yet evidence.

Many failures disappear as screenshots, complaints, or meeting notes. The public route makes a failure durable only when it points to a claim and changes the evidence boundary.

The issue queue links the current public DOI record, weekly evidence context, boundary schemas, field notes, and demo receipts to a concrete repair loop: public claim, public artifact, observed failure, boundary effect, and next action.

Issue template schema showing target claim, public artifact, observed failure, and boundary effect.

Issue Shape

The smallest useful failure has fields.

A valid issue should be small enough to replay: the claim, the artifact, the observed break, the expected behavior, and the proposed boundary update.

The goal is not volume. The goal is a public repair object that can narrow, downgrade, split, or withdraw a claim when the evidence no longer carries it.

Boundary

Public criticism should not require protected material.

The queue is designed for public inputs: public pages, registries, DOI records, demos, snippets, manifests, or reproducible public failures.

Do not use customer records, account data, protected logs, operational credentials, or protected execution traces as public evidence.

Matrix

Failure-to-asset fields.

FieldRequired valueFailure modeRepair route
paper_idStable paper or route identifier.Unclear target.Ask for a public route.
target_claimThe exact sentence, claim row, or boundary row.Critique is too broad.Split into one claim.
public_artifactDOI, registry, page, demo, or manifest.No public object.Move issue to review.
observed_failureMinimal public reproduction or contradiction.Only an intuition.Add public evidence.
boundary_effectnarrow, downgrade, withdraw, split, or reject.No repair state.Patch claim boundary.
repair_statusopen, accepted, rejected, fixed, or needs reproduction.No follow-up route.Add queue state.

Challenge

Challenge one public field.

Submit the smallest public failure case that would force a claim to narrow or move back to review.

Use public materials only: public pages, registries, DOI records, demos, manifests, or bounded issue routes.