# Contributing a bounded investigation ## Start Read the existing tasks and relevant ledger records. Pick a question that could change our understanding, not merely produce more output. State the model, exact inputs, hypotheses, success criterion, controls, compute cap, and stopping rule before the run. Independent replications are welcome; label them so they are not mistaken for new work. Starter tasks are suggestions pending owner curation, not exclusive assignments. For the pilot, coordinate work in a Tangled issue or pull request. An issue comment is an advisory reservation, not a canonical task decision. Automated leases are deferred. ## Pre-work checklist Use the [public evidence library](https://noita-research-lab.cee.wtf/#evidence=) or build locally and run `node scripts/search-evidence.mjs `. Both search the complete contents and paths of historical artifacts and merged contributions. Search matches every word, irrespective of order or frequency; a matching file is not proof that a particular phrase or numerical sequence occurs. Open the source text and inspect the relevant row. The public `evidence/index.json` lists source paths, exact-byte hashes, sizes, previews, and raw-text URLs for agent access. Complete this before expensive analysis. Include it within the research budget; if time runs out during orientation, checkpoint rather than skip the checks. - [ ] Record the repository commit, question, model, inputs, index convention, success criterion, controls, compute cap, and stopping rule. - [ ] Search `tasks/`, `ledger/legacy/phase-ii.json`, and `ledger/contributions/` for the question, model names, related IDs, synonyms, and relevant message windows. Check open and recently merged pull requests. Record which sources and searches you actually inspected and any access gaps. - [ ] Read the closest records' referenced artifacts in `ledger/legacy/phase-ii-evidence.zip`. The ZIP contains paths such as `lab/experiments//...`; the ledger's `source_path` and `references` identify starting points. Inspect result tables/JSON rows, notes, and reviews as text or data. Do not execute archived or contributed code merely to inspect prior work. - [ ] Follow corrections and superseding records. Compare operation order, assumptions, parameter ranges, input hashes, and zero-based/end-exclusive indices. A renamed model or shifted window does not by itself make work new. - [ ] Write the nearest-prior comparison in `research-notes.md` inside your contribution directory: record ID, exact artifact path and row/key, what it establishes, and what this investigation would add. If a match already exists, deliberately choose replication or a different question before running. For example, the 16 forbidden E4/W4 offsets for the exception-free full 83-cycle already appear in `lab/experiments/T003-E003/deletions.json`, the `rows` entry with `L: 83`, under `individually_forbidden_offsets`. A smaller independent checker can be useful, but reproducing that list is replication. Also read `T003-C003` and `lab/experiments/T003-E008/boundary_review.txt`: the 30 observed symbols do not justify assuming 30 shared actions; the corrected hypothesis uses 29 internal transitions. An older result's superseded interpretation does not erase its data. ## Post-work checklist - [ ] Repeat the related-work search using the actual output: exact offset sets, bounds, parameters, counterexamples, and equivalent formulations. Compare detailed artifacts, not only titles. Recheck remote work since the recorded starting commit; inspect changes without overwriting your working files. - [ ] Append an outcome comparison to `research-notes.md`, preserving the original plan. Cite the closest prior artifact and say exactly what was reproduced, extended, corrected, or left unresolved. List searches/access gaps and any differences between the plan and the work performed. - [ ] Reflect that classification in the title and statement; add the relevant record/task IDs to `related`. For replication, identify its value (for example, a simpler checker or independent method). Do not present duplicated results as new findings. If duplication is discovered late, keep the evidence and relabel it. - [ ] Check the final claim against its assumptions and controls. Distinguish a necessary condition from a complete witness, a timeout from exclusion, and a conditional result from decipherment. Keep failed runs and known flaws visible; remove stale counts or descriptions after corrections. - [ ] Inspect the final diff: only your contribution directory, no authority changes or secrets. Validate and generate the review pack after the last edit, including `research-notes.md`, so the digest covers the comparison evidence. These are contributor checks, not canonical verification. The owner still reviews duplication, usefulness, and correctness independently. If a check cannot be completed, mark it incomplete with the reason rather than checking it off or claiming novelty. ## Package Create `ledger/contributions//submission.json`, with code and small input files inside that same directory. Include only files needed to evaluate the result; no credentials, hidden files, links, executables downloaded from third parties, or environment dumps. The tooling fingerprints every file, including helper scripts. Include `research-notes.md` with the pre-work plan and post-work comparison above. Use the existing JSON fields for the summary; do not add checklist fields to `submission.json`. Checklist completion is reviewed by the owner, not enforced by the schema validator. Required record fields: ```json { "schema": "noita-contribution/v1", "id": "your-unique-id", "kind": "experiment", "title": "A concrete question", "statement": "What the evidence establishes", "assumptions": ["Explicit assumptions"], "related": ["Existing task or claim identifiers"], "method": "Procedure, controls, compute budget, and actual outcome", "limitations": ["What remains unresolved"], "author": "Your public handle or attribution" } ``` Kinds: `claim`, `experiment`, `task-proposal`, `peer-review`. Claims must additionally provide `verifier` with `entrypoint`, `argv`, `sha256`, `inputs` (path/hash pairs), `timeout_seconds` (at most 300), `memory_mb` (at most 2048), and at least two described `controls`, covering genuine positive and negative cases. Longer discovery runs are fine within your budget, but the claim should come with a small verification artifact. If no suitable verifier exists, submit an experiment or conjecture rather than claiming verified status. A deterministic provenance check may verify a narrow source claim; it cannot verify the source's truth merely by finding matching text. Use argument arrays, not shell command strings. The owner will review and run the approved verifier in isolation. No submission is executed by validation or site build. ```sh node src/cli.mjs validate ledger/contributions/your-unique-id node src/cli.mjs review-pack ledger/contributions/your-unique-id .local/review-pack ``` Submit a pull request containing only your contribution directory. Changes to tooling, prompts or policy belong in a separate maintainer proposal and are never trusted merely because they arrived with a scientific result. Failed experiments and counterexamples are valuable. A timeout is UNKNOWN, not an exclusion. ## What happens next The Work next board shows suggested first experiments, prerequisites and merged attempts. Suggested tasks retain their formal `proposed` status until owner curation. Announce a bounded attempt in a Tangled issue or PR so others can see the scope; include a checkpoint and stopping time. A static board does not reserve tasks or automatically track active remote work. Check Tangled before starting and submitting. The Activity view records maintainer history with the exact merged bundle and review links. A merged replication is retained evidence; it neither closes its related question automatically nor grants owner verification. Contributions remain visible in the review queue until their formal workflow is configured and completed. The owner curator checks scope and duplication. The owner's Astra reviewer evaluates the verifier and the scientific implication. An approved exact bundle is independently run by the owner, then Astra reviews the result. A signed final decision promotes, rejects, or requests revision. Community reviews do not skip any of those steps. Changing any file creates a new bundle digest and requires a new approval chain. Keep earlier results and corrections visible. Do not rewrite an accepted claim in place.