8000 feat(schema): define MathCorpus Interchange Protocol v1 for Proof Search enrichment · Issue #1 · Mnehmos/mathcorpus · GitHub
[go: up one dir, main page]

Skip to content

feat(schema): define MathCorpus Interchange Protocol v1 for Proof Search enrichment #1

Closed

Description

@Mnehmos

Goal

Define a versioned interchange contract shared by MathCorpus and llm-driven-proof-search so rich proof-search evidence can move between repositories without MathCorpus depending on Proof Search's internal SQLite schema.

MCIP v1 records

Define JSON Schemas for:

  1. PacketIdentity
  2. ProofVariant
  3. ProofProfile
  4. RestrictionProfile
  5. DependencyManifest
  6. AttemptRecord
  7. NegativeExample
  8. RepairTrajectory
  9. ModelRun
  10. EmpiricalDifficultyAggregate

Every record must carry schema version, packet ID, formal statement hash, environment hash, artifact hashes, timestamps, trust status, and export eligibility. Model-related records must include a model-config hash and redaction-aware public metadata.

Acceptance criteria

  • Schemas live under a versioned schema/mcip/v1/ path.
  • Canonical serialization and hashing rules are documented.
  • Unknown fields fail closed unless explicitly versioned.
  • The protocol distinguishes canonical packet data from child evidence records.
  • A conformance fixture set includes one successful proof, one failed attempt, one repair chain, and one multi-model aggregate.
  • MathCorpus validation can validate MCIP bundles independently of Proof Search.
  • Cross-repository compatibility and version-negotiation rules are documented.

Activity

  1. Mnehmos commented on Jul 12, 2026

    @Mnehmos
    OwnerAuthor

    Implemented (local commit 7f1ac10, not yet pushed to origin — see note below):

    • 10 MCIP v1 record schemas + a bundle transport envelope under schema/mcip/v1/: PacketIdentity, ProofVariant, ProofProfile, RestrictionProfile, DependencyManifest, AttemptRecord, NegativeExample, RepairTrajectory, ModelRun, EmpiricalDifficultyAggregate.
    • Every record carries the required envelope (schema_version, record_id, packet_id, environment_hash, created_at, trust_status, export_eligibility, record_hash); model-related records (AttemptRecord, ModelRun, EmpiricalDifficultyAggregate) add model_config_hash + a redaction-aware public_metadata object.
    • Canonical serialization/hashing rule and cross-repo version-negotiation policy documented in schema/mcip/v1/README.md (reuses the corpus's existing canonical-JSON + SHA-256 convention).
    • additionalProperties: false everywhere → unknown fields fail closed. Smoke-tested directly: an injected unknown field, a tampered record_hash, and a violated NegativeExample.proof_authority const are all correctly rejected.
    • tools/validate_mcip.py validates a bundle structurally and by hash, with zero dependency on Proof Search's SQLite schema.
    • tools/gen_mcip_fixtures.py deterministically generates the 4 required conformance fixtures (successful proof, failed attempt, repair chain, multi-model aggregate — 17 records total); all validate clean with --check-hashes.
    • CI gets a new step running the fixture check; the existing 355-packet corpus still validates with 0 errors.
    • README documents explicitly that MCIP records are child evidence only — never packet data — matching the acceptance criterion that canonical packet identity stays separate from evidence.

    Tracked in this repo's dev-issue log: agents/github_issues/DONE.md, FEATURES.md, HANDOFF.md.

    Note: local main is ~220 commits ahead of origin/main (pre-existing, unrelated to this work) — pushing needs a separate explicit go-ahead given the size, so this closes based on local verification, not a visible diff yet.

  2. added 9 commits that reference this issue on Jul 12, 2026
    7f1ac10
    8c74201
    bcdb683
    b3bfa63
    ed2e1a7
    928b2be
    ae51810
    61de03e
    d1c9edf
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