Platform and plugins
KD is organized as a platform with algorithm plugins. Each plugin implements the algorithm-specific search procedure and scientific logic, while the platform provides the infrastructure shared across algorithms, including data preparation, derivative computation, term evaluation, coefficient fitting, run management, visualization, checkpointing, and batch execution.
The plugin contract
An algorithm plugin implements the following members. It prepares itself against the components the platform hands it, proposes candidates, evaluates them, updates itself on the results, exposes its best score and best expression, serializes its configuration and its state, and builds its own final result together with the target that result is expressed in.
KD checks these members when a run starts. A missing member raises a single error that names every gap, so an incomplete algorithm fails before the search begins.
The platform provides the iteration loop, keeps batches in 1:1 correspondence with the candidates the algorithm proposed, calls back for early stopping and for figure data, writes checkpoints atomically from the algorithm's own state, keeps the run record, and assembles the result object.
The platform does not re-score the winning candidate. The algorithm builds its own final result because the residuals and the target must be computed in the same domain. If the platform computed the residuals while the algorithm supplied the target, the two could refer to different quantities.
Optional services
The platform also provides derivatives, term execution, the design matrix, the linear solver, and surrogate network training. An algorithm uses the services that fit its method and implements the rest itself. The table below lists what each algorithm implements on its own.
| Algorithm | What it brings of its own |
|---|---|
| SGA-PDE | expression-tree search, its own sparse fit, and its own surrogate when run in autograd mode |
| DLGA-PDE | genetic search over a term genome and its own evaluators; the platform trains its surrogate network from the configured values |
| DISCOVER | a policy network over token sequences; candidates are scored through the platform evaluator |
| EqGPT | a pretrained transformer; two of its three modes run without platform derivatives at all, on evaluators it builds per case |
| LLM4ED | a language model proposing candidates, with the finite-difference templates and the sparse fit ported alongside it |
| PySR | an external search engine; the platform supplies the design matrix and refits the coefficients |
| PySINDy | an external engine whose native coefficients are kept, with the platform refit recorded next to them as a cross-check |
Declared capabilities
Each algorithm declares its capabilities as data on the class. The declaration covers the equation forms and data layouts of each mode, the source of that mode's derivatives, the name and direction of its score, whether the algorithm returns its answer in one shot, which parameters exist and which of them survive a resume, which parameters change the scientific identity of a run, and how far each mode can honour a sketch.
kd.instrument_schemas() returns those declarations, one entry per algorithm:
schema = next(s for s in kd.instrument_schemas() if s["algorithm"] == "pysindy")
print(schema["score_kind"], schema["score_direction"], schema["one_shot"])
print(schema["modes"])
print([(knob["name"], knob["resume_tier"]) for knob in schema["knobs"]])
NMSE min True
[{'name': 'default', 'forms': ['EVOLUTION'], 'topologies': ['grid'], 'provider_kind': 'finite_diff', 'description': '', 'sketch': {'fixed_terms': 'lowered', 'anchors': 'exit_checked', 'hole_count': 'exit_checked', 'derivative_order': 'generation_enforced', 'operator_set': 'generation_enforced', 'field_axis_set': 'generation_enforced'}}]
[('threshold', 'init_only'), ('max_iter', 'init_only'), ('normalize_columns', 'init_only')]
The sketch block of a mode is that mode's answer, clause by clause, for a partially
specified equation passed to Model.fit(sketch=...): lowered, generation_enforced,
fit_enforced, exit_checked, or unsupported. All six clauses are always listed, so a
mode that supports none of them still carries six keys.
The platform reads the declaration rather than keeping its own tables of the same information. It uses the declaration to decide which derivative provider to build, which datasets to accept, how to label a score, and what a resume may change. Programs driving KD read the same call, and the specification strips and parameter tables on this site are generated from it, so they cannot diverge from the code they describe.
The cost class in that entry (light, medium, heavy) is declared by the algorithm
rather than measured at runtime. It is an estimate used for routing.
Algorithms are registered inside the package, and the seven listed above are the ones a released version provides. An additional algorithm is added to KD together with its declaration.