Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Ground truth: decide on gradient validation (currently fully unimplemented)

Open
  • Is something wrong?
#986 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
kotlin, python
Domain
machine-learning, testing

Research direction

Start by reading gt/pytorch/io/writer.py, GroundTruthLoader.kt, GroundTruthValidator.validateGradientsInternal, CONTRACT.md, and TESTING.md to understand what is implemented and documented. Decide whether gradient validation should be implemented on both sides or explicitly de-scoped; done means the chosen path is made consistent across code and documentation, including removing misleading unused API surface if de-scoped.

Written by the indexing model from the issue text.

Description

assessment question sub-issue

Sub-issue of #984.

Despite the "gradienttracer" name, no gradient is ever actually checked today.
ToleranceConfig.GRADIENT, GroundTruthTestCase.expectedGradients, and grad_*-tensor
parsing all exist on the Kotlin side (GroundTruthLoader.kt,
GroundTruthValidator.validateGradientsInternal) — but store_experiment_as_gguf
(gradienttracer's gt/pytorch/io/writer.py) never calls .backward() or writes any
grad_* tensor. validateGradientsInternal is explicitly a placeholder (// TODO: Implement actual gradient computation via tape) that always reports failure if ever
invoked with real data.

Decision needed

  • Implement it: add .backward() + grad_* tensor serialization to
    store_experiment_as_gguf (every @Executable input already has requires_grad=True
    set, so the gradient is available, just not captured), and implement SKaiNET-side
    backward-pass execution in GroundTruthValidator.validateGradientsInternal to actually
    compare against it. This is real, nontrivial work on both sides — SKaiNET's own
    autodiff/backward execution path needs to be driveable from
    skainet-test-groundtruth, which it currently isn't.
  • Explicitly de-scope it: if gradient validation isn't a near-term priority, say so
    in CONTRACT.md and TESTING.md (which currently reads as if this already works),
    and consider whether the dead expectedGradients/ToleranceConfig.GRADIENT/
    validateGradients parameter surface should be removed rather than left as
    looks-implemented-but-isn't.

Either answer is fine — the point of this issue is picking one, since right now the code
reads as "supported" when it silently isn't.

Dominant language
Kotlin
Stars
52
Forks
15
Avg merge
1d 1h
Merged PRs (30d)
41

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from SKaiNET-developers/SKaiNET

All issues in SKaiNET-developers/SKaiNET

Similar issues

More Kotlin issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.