Skip to content

Latest commit

 

History

History
121 lines (92 loc) · 5.84 KB

File metadata and controls

121 lines (92 loc) · 5.84 KB

Jacobian documentation

Jacobian's documentation follows the Diátaxis framework, organized by what the reader is trying to do. Start with a tutorial when learning the system, use a how-to guide for a specific task, consult reference material for exact contracts, and read the explanations for design rationale.

Jacobian is a toolbox of atomic math tools for AI agents: find them with math.find, run them with math.run, get mathematical results, and compose those values across turns. Checker tools are optional additional catalog IDs—separate from producers. Catalog entries are often still called capabilities in the API. The product model and Search and execute define the contract.

Jacobian is pre-stable. The product, architecture, operation-library, and tool documents define the current contract; the installed catalog defines which operations are available in a particular checkout. Evaluations guide portfolio quality and do not grant formal authority.

Project control documents

These documents define the current product contract:

Question Document Status
What is Jacobian? Product model Product and ownership model
How is it structured? Architecture Dependencies and trust boundaries
What does MCP expose? Tool surface Fixed MCP projection
What operations are installed now? Runtime capability://catalog Current installation-specific inventory
What work is open? GitHub issues (e.g. architecture epics) Implementation priorities live in issues, not a parallel goals doc

Tutorials

Tutorials are guided learning paths. They assume no prior Jacobian experience and build toward a complete result.

How-to guides

How-to guides assume you already understand Jacobian's basic model and need to complete a specific task.

Reference

Reference documents define exact interfaces, records, gates, and test expectations.

Cross-cutting references:

Domain-owned references: Capability references grouped by owning domain (graphs, matrix, polynomial, Lean, SAT/SMT, finite math, number theory, linear algebra, topology, geometry). Adding an operation or provider does not require editing a central list; each domain owns its own subdirectory.

Evaluation references: Benchmark contracts and evaluation methods — Harbor task contracts, dataset inventory, validation gates, model observations, performance measurement, and regression policy.

Reference scenarios: Worked cases — mathematical scenario catalog and certified-homology case.

Use the runtime capability://catalog and math.find for the installed capability inventory and exact operation schemas.

Explanation

Do not add parallel “direction”, “goals”, or portfolio-planning novels under explanation/. Product intent lives in those two documents; open work lives in GitHub issues.

Contributing

Read CONTRIBUTING.md before changing code or public documentation.

Harbor benchmark authoring and verifier work uses the repository-local harbor-benchmarks skill. Source-grounded reliability probes based on recently resolved conjectures use recent-conjecture-evaluations. For hosted operation, follow Deploy the remote MCP server; ignored tmp/ records are host evidence, not source of truth.

When adding a document, place it by reader need:

  • tutorials/ — guided learning
  • how-to/ — one task
  • reference/ — contracts and lookup
  • explanation/ — only product model and architecture unless a feature needs a dedicated operational reference that does not fit architecture

Do not mix product intent with supported release behavior. Concrete work lives in GitHub issues.