physics-erdos-loop

Physics Erdős Loop

Use this loop to produce a positive, framework-consistent, verified result—not merely an articulate account of why one attempt failed. It adapts the Erdős-style persistent proof loop to physics while adding claim governance and software reuse.

Non-negotiable outcome

Honesty is required but is not itself success. Classify a failed candidate, no-go, obstruction, residual, bound, or inconclusive computation as attempt evidence and continue. Do not close the effort on it. Equally, do not turn honest review into a ratchet toward trivial claims: preserve the strongest meaningful positive result, make the minimum truthful scope repair, and leave the larger objective open when it is not yet met. Weakening is subject to the same persistence discipline as failure-chasing. Each attempt must change something material — candidate concept, numerical method, oracle class, formalism, or target statement — rather than re-examine a known route under tighter standards; repeating a route with only stricter evidence thresholds is drift, not diligence. A new acceptance criterion invented mid-campaign must name the observed failure it prevents, be recorded once, and bind future attempts rather than retroactively invalidating finished ones. Close each attempt with two typed fields: route_verdict is established, refuted with mechanism, or blocked with that route's missing construction; evidence_scope states the strongest earned scientific meaning, such as NUMERICALLY_UNRESOLVED or REPRESENTATION_SCOPED. Neither field propagates automatically to the obligation or campaign. The next attempt inherits a direction, not a smaller question.

Success requires the requested object plus all of these gates:

• accepted dependency closure and declared imports;
• natural compatibility with framework invariants, or a separately accepted minimal foundational revision;
• strongest practical oracle and claim-appropriate sensitivity evidence;
• preregistered comparison of plausible candidates when a mechanism is being selected;
• impact-bounded downstream replay;
• reusable importable implementation;
• claim-by-claim review and release promotion;
• synchronized generated docs and memory;
• empty debt ledger.