math-knowledge-graph

name

math-knowledge-graph

description

Convert dense mathematical statements, theorem/proof fragments, model definitions, equations, losses, algorithms, and notation-heavy research-paper sections into composable knowledge graphs whose labeled edges capture the reasoning flow. Use when the user asks to understand, unpack, explain, verify, teach, simplify, or compare complex math in a paper; when they ask what an equation/model means; when they want a theorem, proof, objective, architecture, or derivation explained at levels from elementary school through Ph.D or expert; or when they need a graph of dependencies, assumptions, transformations, and implications.

Math Knowledge Graph

Turn long mathematical text into a navigable reasoning map. Preserve the formal structure, expose the dependencies, then explain the same object at the user's requested educational level.

Core Workflow

1. Intake and scope

   • Identify the object: theorem, definition, proof step, equation, model, loss, algorithm, architecture, or result claim.
   • Ask at most one calibration question if needed: "What level should I explain this at: elementary, high school, undergraduate, Ph.D, or expert?"
   • If the source context is missing definitions, state what is missing and proceed with explicit assumptions.

2. Notation ledger

   • List symbols, indices, sets, functions, random variables, operators, constants, and dimensions.
   • Mark each as given, defined here, inferred, or unknown.
   • Do not silently rename symbols. If simplifying notation, keep a mapping back to the original.

3. Statement decomposition

   • Split the math into atomic nodes: assumptions, definitions, objects, equations, transformations, claims, constraints, objectives, limits, approximations, and conclusions.
   • Keep each node small enough to be reusable in another graph.
   • Preserve quantifier order. for all x exists y and exists y for all x are different nodes.

4. Reasoning-flow graph

   • Build a Mermaid graph or an edge table using labeled reasoning edges.
   • Every edge must explain why one node leads to another: defines, assumes, implies, substitutes into, bounds, optimizes, marginalizes, takes limit, is equivalent under, contradicts, requires, is evidence for.
   • Include edge warrants: the theorem, algebraic identity, modeling assumption, approximation, or paper claim that justifies the edge.
   • For graph schema and edge vocabulary, read references/graph-schema.md.

5. Explanation mode

   • Explain the graph at the requested level. If no level is requested, default to graduate-student level for research papers.
   • Use analogies only for elementary/middle/high-school explanations; keep the original formal statement visible.
   • For level-specific constraints, read references/explanation-levels.md.

6. Check and compress

   • Run a local consistency check: dimensions, domains, quantifiers, dependency direction, hidden assumptions, and unsupported jumps.
   • End with either a one-sentence compression, a "weakest edge" note, or a short question that tests the user's model of the math.

Output Shapes

Choose the smallest output that fits the task.

• Map only: notation ledger + Mermaid graph + edge table.
• Explain only: notation ledger + level-specific explanation + minimal reasoning chain.
• Full unpacking: notation ledger + decomposition + graph + edge warrants + level explanation + checks.
• Bridge mode: explain the same equation at two or more levels, preserving the same graph nodes.
• Proof audit: graph the proof, then flag gaps, hidden assumptions, circular dependencies, and unverified algebra.

Graph Requirements

• Use stable node IDs: A1 for assumptions, D1 for definitions, E1 for equations, T1 for transformations, C1 for claims, R1 for results.
• Label every edge with a verb phrase. A bare arrow is a bug.
• Prefer 6-14 nodes for the top-level graph. Collapse repeated algebra into a subgraph when needed.
• Keep the graph composable: each node should be meaningful if reused in another graph.
• If a derivation has multiple branches, show branch join points explicitly.

Explanation Requirements

• Preserve the equation or statement before explaining it.
• Move from structure to intuition to details, not the reverse.
• Separate What it says, Why it matters, and What must be true for it to hold.
• For models and losses, explain inputs, outputs, parameters, objective, optimization target, and failure modes.
• For equations, explain each term's role and how changing it affects the result.
• For proofs, explain the strategy before the line-by-line mechanics.

Guardrails

• Do not claim a proof is valid unless the shown steps support it.
• Do not invent missing definitions from the paper. Mark them as missing or inferred.
• Do not collapse probabilistic, asymptotic, or approximate statements into exact statements.
• Do not erase conditions such as measurability, differentiability, independence, convexity, boundedness, convergence, or domain restrictions.
• Say when a graph edge is only a plausible interpretation rather than established by the source.