Jupiter

Philosophy

Refutation is a control signal for the next search action, rather than text appended to an idea. The review process and its conclusion should be traceable along the same evidence path.

Architecture & control flow

1. 01

   Prefer model responses, with semantic seeds maintaining search structure when a response is absent.

2. 02

   Create a draft candidate, write its refutation ledger, then move it to checked or refuted state.

3. 03

   Directly refuted or insufficiently supported candidates cannot follow the acceptance path.

4. 04

   Persist lifecycle events, consume responses by request identity and align reviewer output fields.

Architecture outline derived from this version’s control flow.

What this version changes

Compared with Stars, repairs default candidate generation, ledger blocking, state persistence and the draft→checked→accepted lifecycle.

Implementation & evidence scope

This stage still checks the pipeline using seeds and manual or simulated responses. Complete real-model candidates, cross-model review and live mathematics–physics literature refutation were not independently validated here.

Code & bundled material

The introduction draws on bundled notes, changelogs and central code. Software tests, synthetic diagnostics and scientific effectiveness use different evidence standards.