Summary

  • LACNIC’s public Hackathon repository tells an agent to inspect, and in active mode update, a shared ai-harness before a mutating session. The repository records that harness only as a 13-byte symbolic link to ../ai-harness.
  • The Hackathon commit therefore identifies the local rule file but not the repository URL, immutable revision or digest of the sibling rulebook. A small external-instruction receipt would close that reproducibility gap without claiming that any run was unsafe or wrong.

Thirteen bytes can carry more authority than a long policy document. In the current tree of LACNIC’s public Hackathon repository, the path ai-harness is not a directory of checked-in rules. Git records it with mode 120000, the form used for a symbolic link, and its blob decodes to one short target: ../ai-harness.

That design may be entirely sensible on the intended workstation. A shared harness can keep review rules, tests and operating conventions consistent across several projects. Fix a defect once and every participating repository can benefit. The September change also adds unusually careful brakes: it distinguishes maintenance from active mode, requires a clean canonical checkout before mutating work and tells the agent not to open that work in a linked worktree. These are signs of an operating contract being made more deliberate, not evidence of negligence.

The unresolved issue is identity. The Hackathon repository can prove which version of its own AGENTS.md was committed. It can prove that ai-harness points one directory upward. It cannot, from that commit alone, prove what occupied the target path when an agent read its first line, ran its updater or invoked its preflight.

That distinction matters because the external file is not merely reference material. The September AGENTS.md says that before any command, an agent should read the first line of ai-harness/AGENTS.md and apply AI_HARNESS_MODE. In maintenance mode, the agent must not update or execute the harness. In active mode, it is told to run ./ai-harness/harness/framework/update-framework.sh, then follow the full map. That map in turn runs git-preflight before a new mutating session.

The sibling checkout therefore helps decide which instructions exist, whether an update occurs and which preconditions a mutating run must satisfy. Two machines can hold the same Hackathon commit yet expose different first lines, updater logic or preflight rules if their sibling checkouts differ. Nothing in the public record proves that this divergence happened. The point is narrower: a Hackathon commit hash cannot, by itself, reconstruct the complete instruction state.

What the two commits establish

The chronology is short and useful. On 12 July 2026, commit 16c37db9fe6e1c1b0bc7260b744ee7595a10de67, labelled “chore: adopt shared ai-harness,” added the local agent file, the relative link and a set of project-specific examples. Its instructions said to update the common framework without interaction before a new session and then read the harness map.

On 8 September, commit a68504f87dd5226238bb65b62b89d40419ed7c1f expanded that contract. It introduced the two modes, limited what maintenance mode may read or write, described the preflight’s clean-checkout condition and recorded that a framework-oriented Hackathon review had reached a partial doctor result while an independent review remained pending. The change was merged in commit 6f9f60846acb30d4dcbf3969908743671c4a2921.

The merge tree binds AGENTS.md to blob 34e8fb06a0d71b939283dea4d77381ff029ad981. It also binds the link itself to blob 2244dfc17eaa1d54869e0bb3ff01ff258c6b0a0e. Those are strong identities for the material stored inside the Hackathon repository. The second blob, however, proves only the relative pathname. It is not a Git submodule pointer and does not name a commit in another repository.

The local contract contains no GitHub URL for the sibling, no tag, no immutable commit and no content digest. That absence does not show that LACNIC lacks an external provisioning rule. A workstation image, private setup script or operator runbook may supply one. It shows only that a reader holding this public repository and its commit does not possess that part of the evidence.

Freshness and reconstruction are different goals

The updater reveals a familiar tension. A central harness is valuable precisely because it can move. A project team may want the latest reviewed rules at the start of every session. Pinning the harness forever would defeat that purpose. But allowing the external rules to move does not require the resulting identity to remain unknown.

The useful distinction is between selection and recording. A team may select “latest approved” at runtime. Once selected, it can record the exact repository and immutable revision that satisfied the request. It may update from one revision to another, then retain both identities and the updater result. Freshness remains possible; reconstruction becomes possible too.

This is where software-provenance practice offers a modest analogy. SLSA 1.2 describes provenance as verifiable information that follows an artifact through the moving parts of a supply chain to where, when and how it was produced. LACNIC has not said that this Hackathon workflow implements SLSA, and an agent instruction set is not automatically a build artifact. The useful lesson is simply that a moving dependency becomes auditable when its resolved identity accompanies the output.

A receipt smaller than the rulebook

The missing object need not copy the harness into every project. It can be a compact external-instruction receipt attached to a mutating session. At minimum, it would identify the Hackathon commit and the ai-harness link blob; the sibling repository URL and immutable commit; the observed first-line mode; the harness revision before and after the updater; the preflight version and result; the canonical checkout and worktree identity; the time; and the operator or automation identity that initiated the run.

If the updater fails, the receipt should say whether work stopped or continued on the earlier revision. If the first-line mode changes, that transition should be visible. If a rule is corrected later, a correction entry should point back to the affected receipts rather than silently rewriting history. Secrets, prompts and the full project state need not be published. The purpose is to bind authority, not to expose working material.

That record would also improve review. A reviewer could distinguish a code defect from a rule-version difference. An operator could reproduce the preflight that admitted the session. A future maintainer could determine whether an old outcome belongs to an old project commit, an old harness, or both. Without the binding, all three explanations remain plausible.

The public repository does not show a security incident, an incorrect Hackathon result or a deployed production pathway. It shows a cleaner and more interesting governance problem: the instructions have become consequential enough to receive modes, update rules and preflight gates, while their external version remains outside the project’s own evidence boundary. Once a rulebook can authorize mutation, naming the rulebook is part of naming the run.

Sources