8000 feat(policy): require contribution, citation, and novelty review for open-problem exports · Issue #8 · Mnehmos/mathcorpus · GitHub
[go: up one dir, main page]

Skip to content

feat(policy): require contribution, citation, and novelty review for open-problem exports #8

Closed

Description

@Mnehmos

Problem

A kernel-verified packet may still be misleading if its public presentation omits prior work or overstates novelty. MathCorpus needs a publication policy that treats correctness, provenance, attribution, and novelty as separate review dimensions.

Scope

Add publication-readiness rules for packets and proof variants related to open problems, new bounds, counterexamples, or claimed new methods.

Require:

  • a contribution-class declaration: new_proof, independent_rediscovery, formalization, verification, reconstruction, adaptation, or literature_derived_synthesis
  • known-prior-art references
  • literature-search scope and date
  • citation-lineage review status
  • novelty-review status
  • AI-assistance disclosure
  • unresolved attribution caveats

Suggested publication statuses:

  • metadata_only
  • kernel_verified_unreviewed
  • citation_review_pending
  • novelty_review_pending
  • reviewed_with_caveats
  • publication_ready
  • blocked_missing_attribution
  • blocked_novelty_claim

Acceptance criteria

  • Kernel verification alone cannot produce publication_ready for an open-problem claim.
  • Citation or novelty uncertainty never changes proof truth, only public claim status.
  • Strong novelty language is blocked when prior-art review is incomplete or disputed.
  • Exports include a human-readable and machine-readable contribution statement.
  • Review records are reviewer-attributed, timestamped, and hash-bound.
  • Policy supports later correction, revocation, or addition of citations without rewriting canonical packet history.
  • Existing packets remain valid but are marked under the legacy/unreviewed policy until migrated.
  • CDC serves as a fixture classified as formal verification/reconstruction with prior-flow literature disclosed.

Activity

  1. Mnehmos commented on Jul 12, 2026

    @Mnehmos
    < 8000 div class="footer__7ecx1m FooterContainer__CesLbt">on Jul 12, 2026
    OwnerAuthor

    Implemented (local commit 61de03e, stacked on ae51810/928b2be/ed2e1a7/b3bfa63/bcdb683/8c74201/7f1ac10 — not yet pushed, see notes on #1-#7). This is the last issue in the 8-issue MCIP roadmap.

    Purely a policy layer over #7's contribution_statements/citation_reviews — no new record types needed.

    • New publication object on packet.schema.json with all 8 suggested statuses (metadata_only, kernel_verified_unreviewed, citation_review_pending, novelty_review_pending, reviewed_with_caveats, publication_ready, blocked_missing_attribution, blocked_novelty_claim).
    • Kernel verification alone cannot produce publication_ready: policy.check_publication_status rejects it outright when the packet has zero contribution_statements.
    • Open-problem claims need a real review: publication_ready on an open_problem_related: true packet requires at least one current (supersedes-aware — a superseded review doesn't count) citation_review with review_status: "endorsed".
    • Strong novelty language is blocked when review is incomplete/disputed: a contribution_class: "new_proof" declaration is rejected from publication_ready unless a current review is endorsed — disputed or absent review blocks it.
    • Citation/novelty uncertainty only changes public claim status, never proof truth: publication.status is structurally separate from trust.rung/proof_authority/status; nothing in this repo lets one affect the other.
    • Corrections without rewriting canonical history: caught and fixed a gap feat(schema): add literature-lineage, idea-attribution, and prior-art records #7 had left — citation_reviews[].supersedes now has a dangling-reference check, so the correction/revocation chain actually validates end-to-end.
    • Existing packets remain valid under a legacy default: policy.implicit_publication_status gives every packet lacking publication a sensible default (kernel_verified_unreviewed or metadata_only) — no retroactive requirement, no migration needed.
    • Exports carry both forms of the contribution statement: new mathcorpus.export.contribution_summary renders a human-readable sentence (contribution class, known prior art, publication status, unresolved caveats), added to every exported row as contribution_summary, alongside the machine-readable contribution_statements/publication fields already present.

    Real fixture, same honesty standard as #7: union_closed_sharpness.v1 gets publication.status: "reviewed_with_caveats" — deliberately not publication_ready, even though it technically has the endorsed review needed to pass the gate, because its Yu-2023 prior-art citation carries an honestly-disclosed unverified-bibliography caveat. The fixture demonstrates the policy catching exactly the kind of case it exists to catch, rather than being set to whatever status looks best.

    Scope note: "strong novelty language" is gated structurally (contribution_class == "new_proof"), not via free-text scanning of title/informal_statement prose — that would be a separate NLP-ish follow-up if wanted, not silently covered here.

    5 failure modes smoke-tested directly, including a positive case (a valid publication_ready claim correctly passes every gate). Full corpus (357 packets) + full CI-equivalent pipeline + all issue #6 tooling verified locally, 0 errors.

    Tracked in agents/github_issues/DONE.md, FEATURES.md, HANDOFF.md, TRIAGE.md.

    Roadmap complete: #1-#8 are all closed. 8 commits sit locally on main, unpushed (this repo was already ~220 commits ahead of origin before this work began) — pushing needs the repo owner's explicit go-ahead given the size.

  • Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

    Metadata

    Metadata

    Assignees

    No one assigned

      Labels

      No labels
      No labels

      Projects

      No projects

        Milestone

        No milestone

        Relationships

        None yet

        Development

        No branches or pull requests

        Issue actions

        0