Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

`darnit-reproducibility`: reproducibility layer + tightness taxonomy

Đang mở
  • Có gì không ổn?
#415 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
25/100
Loại issue
Tính năng
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Ít trao đổi
Công nghệ
python
Lĩnh vực
tooling

Hướng nghiên cứu

Start by comparing the taxonomy needs in this issue with #393 (ontology) and #227 (HermeticBuild), then review the declaration options: .project/ context and [reproducibility] in .baseline.toml. Clarify the declaration format and how existing controls map to layer and tightness; done means the taxonomy handles compound layers and the third-party-binary case and can serialize into the ontology vocabulary.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

module-reproducibility

Summary

"Reproducible" is not a single concept. Auditing meaningfully requires two
independent axes:

  1. Layer being reproduced.
  2. Tightness of match at that layer.

Without this taxonomy, users cannot declare what they are aiming for and
darnit cannot audit meaningfully -- the required signals differ per (layer,
tightness) pair. A repo can be statistically reproducible without pinning
PYTHONHASHSEED; a regulatory-grade forensic tool cannot. Conflating these
under one "reproducibility" label produces false PASS or false FAIL,
depending on which direction the assumption drifts.

Layers to name explicitly

  • Layer 1: Source -> built tool. Deterministic compilation,
    SOURCE_DATE_EPOCH, pinned toolchain, container-build digest. This is
    build reproducibility; overlaps with RE-02.01 HermeticBuild (#227).
  • Layer 2: Built tool + inputs -> outputs. Pinned execution
    environment, seeded RNG, deterministic ops, workflow spec, data
    lineage. This is what most people mean by "reproducible experiment."
  • Layer 3: Outputs -> conclusions. Downstream statistical processing,
    meta-analysis, plot generation. The layer where analytical
    reproducibility (same inputs -> same conclusions under the declared
    test) lives.

Compound case the taxonomy must handle: source that compiles to a tool
(Layer 1) that then runs the experiment (Layer 2). Two layers, potentially
different tightness tiers each. Similarly, experiments that consume a
third-party binary the researcher did not build -- Layer 1 is somebody
else's problem, but Layer 2 remains auditable.

Tightness tiers to name explicitly

  • Bit-for-bit: byte-equal outputs. Regulatory, forensic,
    cryptographic, hermetic-build contexts.
  • Within tolerance: outputs statistically equivalent under a declared
    epsilon or distributional test (KS, chi-square, etc.). The honest bar
    for stochastic ML, MCMC, ensemble methods, sampling, GANs.
  • Runs-to-completion: environment + data available; produces some
    result of the declared type. The honest bar for most published
    notebooks and the floor darnit should never audit below.

Scope

  • Formalize the (layer, tightness) two-axis taxonomy.
  • Design how a repo declares its target: candidate surfaces are a new key
    in .project/ context or a [reproducibility] block in
    .baseline.toml. Decide during clarify.
  • Map darnit-reproducibility's existing controls onto (layer, tightness)
    so each control knows which target it audits against.

Non-goals for v0

  • The specific signal checks (see #416).
  • Auto-remediation of missing tier declarations.
  • Rewriting existing controls to be tier-aware in the same PR -- tag
    with a default tier and re-tag in a follow-up.

Constitution alignment

  • II. Conservative-by-Default: if a repo declares "bit-for-bit" but
    a control at that tier is missing evidence, WARN -- never silent PASS.
  • IV. Never Guess User Values: the (layer, tightness) declaration is
    a user-judgment key. darnit MAY propose a tier from repo heuristics
    (e.g., Dockerfile with digest -> likely bit-for-bit at Layer 1) but
    MUST NOT conclude it.
  • III. TOML-First: tier declaration lives in TOML or .project/,
    not in Python.

Related

  • #414 (extractor module).
  • #416 (heuristic checks -- each control declares its (layer, tightness)
    applicability).
  • #393 (ontology) -- the taxonomy must serialize into the ontology
    vocabulary.
  • #227 (HermeticBuild) -- the canonical Layer 1 / bit-for-bit control.
Ngôn ngữ chính
Python
Star
22
Fork
27
Merge trung bình
1 ngày 20 giờ
Pull request đã merge (30 ngày)
39

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của darnitdevorg/darnit

Tất cả issue của darnitdevorg/darnit

Issue tương tự

Thêm issue về Python

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.