← Files MathboxARCHIVED FILE

docs/design-v3.md

10.2 KB · Oct 3, 2026 · 06:33 UTC

↓ Download file

# Mathbox v3: research programs with versioned evidence

> **Scope:** This document explains the design of 3.0 and was last revised for
> 3.0.1. It covers neither the compact reports, ledger batches and program
> closeout added in 3.1.0 nor the deferred handoff ingestion added since then;
> see the [changelog](CHANGELOG.md) for those.

## Diagnosis

Version 2.2 had useful, focused mathematical workflows and an unusually careful
local literature cache. Three structural gaps limited long investigations:

- The research executor was explicitly restricted to one route, with no
  coordinator for a user asking to continue through several failed approaches.
- Proof, computation and review labels were prose conventions. No executable
  dependency graph noticed that a theorem's input statement or proof had changed.
- The computation validator accepted a blank template. It checked field names,
  not whether the record contained an actual assertion, range, run or valid hash.

The redesign retains the specialist boundaries and adds the missing coordination
and state layer. Additional adversarial hardening also exposed failure classes that a
nominally valid workflow could miss: audits reusing the claimant's surrogate
object, sparse iterators presented as exhaustive, parity checks masking absolute
degree errors, parallel returns without a common-base reconciliation, narrow
novelty searches, and repository migrations that inferred authority from
filenames. The fixes and regression examples are entirely synthetic. The redesign does not require
every mathematical conversation to become a managed project.

## Architecture

| Layer | Responsibility | Authority boundary |
|---|---|---|
| Research program | Own the original goal; execute distinct routes and allocate effort by information gained | Cannot turn partial success into the requested theorem |
| Specialist skills | Develop one route, audit a proof, check a source, run an experiment or edit a manuscript | A workflow cannot substitute for a missing mathematical implication |
| Project artifacts | Exact statements, full derivations, checked source translations, code and review reports | Durable arguments carry the mathematical content |
| Optional ledger | Record revisions, statement bindings, dependencies, artifact hashes, review attribution, route outcomes and execution lifecycle | Validates declared provenance and freshness, not the argument's truth |
| Evaluation | Test packaging, execution and actual mathematical task behavior separately | Software tests are not evidence of frontier research success |

Every skill is still independently installable. No helper imports a sibling
skill, no server or database is required, and there are no model/provider API
dependencies. The existing literature cache is preserved.

## Research policy changes

The new `research-program` interprets one route as one work package within a
sustained assignment. It preserves the exact goal, distinguishes routes by
their failure mechanisms, executes discriminating checks and continues with new
inputs after failure. It supports proof and counterexample searches together.
It requires actual mathematical progress rather than an indefinitely growing
list of plans. Resource/tool limits and exhausted available ideas remain honest
stopping conditions, never a reason to fabricate a breakthrough.

The individual research skill now includes structural moves for coefficient
changes, naturality, homotopy versus homology, spectral-sequence obstructions,
gluing, parameter-uniform mechanisms and counterexample design. Each move has
an exact mathematical obligation.

Fresh audit work receives the claim and raw artifacts without the author's
desired verdict. Review provenance is independent of mathematical evidence and
artifact freshness. The reviewer reconstructs the claimed object, domain and
absolute degrees independently, checks minimum cases and iterator coverage, and
does not let a regularized substitute or sampled sweep inherit the original
claim. Source work separates discovery from verification, searches equivalent
and historical terminology, follows citation chains, and distinguishes
authenticating a document, extracting its theorem and proving its applicability.
Unavailable companion skills can be replaced by direct checks with available
tools; unverifiable mathematical inputs remain conditional.

Setup applies existing user authorization to coherent edits. Its inspector
recognizes semantic filename aliases, distinguishes unavailable Git metadata
from a clean worktree, inventories computation manifests and declared path/cache
conventions, and reports competing dashboard or handoff candidates without
choosing authority from names. It does not follow symlinked files. Legacy log
migration maps source spans against the stated mission, quarantines foreign or
ambiguous material, and requires review before replacing the live index.
Manuscript setup leaves venue, language, audience, deadline, counting convention
and complete page budget unknown until confirmed. Source-derived inventory
entries remain pending until checked. Ambiguous authority changes and destructive
historical rewrites still require resolution before execution.

Parallel research uses explicit base checkpoints, owners and write scopes.
Arrival order is not ancestry, shared files are written only after coordinator
reconciliation, and a restricted theorem or conditional lemma remains a partial
result rather than silently completing the original goal. Manuscript integration
propagates accepted changes through a project map of semantic dependents instead
of relying on filename proximity.

## State invariants

- Claims have explicit hypotheses, regime, conclusion level and dependencies;
  an optional hashed statement artifact binds ledger text to the controlling file.
- Evidence is attached to the claim and all transitive dependency revisions.
- Proof/source/computation/counterexample evidence remain different types, with
  neutral generated labels such as `proof-recorded` and `source-recorded`.
- Computation cannot discharge a universal proof dependency without a separate
  recorded argument establishing why the finite assertion decides the claim.
- A linked v2 computation record pins its manifest plus the complete declared
  input/output closure; equal before/after input hashes and a completed zero-exit
  run are required before the ledger grants closure semantics.
- Changed artifacts or contracts make evidence stale. Counterexample-supported
  or retracted inputs make downstream arguments conditional. Conflicting proof
  and counterexample evidence is displayed as disputed.
- Audits address exact evidence events. Author self-review cannot be marked
  independent. Conditional computation reviews affect claim state, active review
  objects remain visible in handoffs, and pass/fail conflicts cannot display as
  an unqualified independent pass. Losing a negative audit report cannot silently
  clear its challenge.
- Claim dependencies represent jointly required obligations. Routes may name
  narrower obligations they resolve, while route-only prerequisites remain
  separately typed handoff context rather than synthetic theorem dependencies.
- Corrections append events. Revalidated evidence can explicitly supersede old
  evidence while preserving history. No automatic migration promotes old prose.
- Read-only commands never initialize or mutate the project. Writes serialize
  under a lock and publish complete event files atomically.
- Programs and route runs record common bases, observations (including explicit
  `unknown`), terminal revisions, conflicts and late-result dispositions. Run or
  route success never promotes a mathematical claim by itself.

The ledger cannot discover undeclared dependencies, prove an alleged argument,
authenticate an actor's identity or measure real reviewer independence. These
are explicit semantic responsibilities of the research and audit workflows.
Its hash chain detects accidental corruption, not a malicious complete rewrite.

## Migration and compatibility

Install v3 through the existing distribution path. Use `research-program` for
sustained requests; existing single-purpose invocations continue to work. The
ledger is opt-in for a project and has its own schema version, separate from the
plugin version. Keep existing Markdown status and proof files until their
mapping and authoritative replacement are clear. Adopt only the active claim
subgraph that benefits from tracking.

Historical computation manifests in version 1 remain readable with their
original nonempty software strings, absent/null repository revisions, and
unambiguous project- or manifest-relative output paths. The validator reports
the provenance those records cannot establish; it does not upgrade them to v2.
Blank templates require `--template`. New v2 runs can declare and hash scientific
result files, cross-check execution artifacts, and request POSIX address-space,
CPU-time and affinity caps plus cooperative numerical-library thread caps.
Python helpers require Python 3.10+. POSIX process-group termination is tested;
other platforms only receive direct-process termination from this runner.

Existing research-state schema-version-1 journals and minimal configs remain
readable without event rewriting. Generated status strings intentionally use
the neutral `*-recorded` vocabulary, so dashboards or scripts matching the old
mathematical-sounding strings must be updated. New lifecycle events require the
v3 helper.

## Evaluation boundary and future work

Real-project evaluation should remain held out and confidential. Only aggregate
measures—time to identify a false implication, repeated failed mechanisms, stale
evidence detected, reproducible runs, and useful mathematical results per
research session—belong in public reports. The elementary fixtures in this
repository test transferable failure mechanisms, not research creativity at the
frontier.

Formal-verifier adapters should record exact propositions, toolchain and kernel
results once a project supplies a Lean/Coq/other formal target. A fabricated
formalization layer would add no assurance. Literature acquisition can be
extended through authorized source providers without putting credentials in the
ledger. Parallel research should use explicit write ownership and coordinator
reconciliation; the journal deliberately has a single writer and no distributed
merge protocol.

SHA-256: 4b5cf7a210083ea6f41ae88a41a1f2cc3ec14e7c12254277e4b509385ea8e857