175 archived artifacts sit on non-ADR-correct ordinal chunks

Priority

Low — explicitly deprioritised by the operator at filing. Nothing is broken for a consumer: these artifacts are readable, indexed, and ingestible. Filed so the measurement is not lost, not to be picked up next.

Context

Surfaced while repairing the 27 divergent duplicate artifacts in #16057 (PR #16067). Computing ADR 0004 §2.2's ordinal (chunkNumber = Math.floor(itemIndex / 100) + 1) with §2.5's ordering — "Archive tier by ascending GitHub ID within each version-folder bucket" — against complete on-disk membership per §2.2.1 shows the duplicates were the visible tip of a larger placement drift.

After #16067's repair, with duplicates at zero:

175 total, and note two of the three buckets have zero duplicates — so this is a genuinely separate axis from the identity defect, not a remainder of it.

The Problem

An ordinal is a position within a bucket's complete membership. A misplaced artifact is one whose path says chunk N while the ordering says chunk M. Nothing refuses it: PullRequestSource keys on logical name, the index maps id → path, and retrieval resolves through the index. So the corpus reads correctly today, which is exactly why this went unmeasured.

What it costs is the property ADR 0004 §2.2 exists to provide — "Two collections of the same size produce identically-shaped chunks regardless of GitHub-ID gaps." Placement is currently not derivable from membership: you must consult the index to find an artifact, and a future tool that computes a path from an ordinal will miss 175 of them.

Not a regression, and not new. archive/pulls/v13.0.0/chunk-1 held 205 files and chunk-2 held 142 against a 100-item rule, both spanning the whole ID range, while chunk-3..13 were clean contiguous 100-blocks. That is the signature of the migration ADR 0004 line 31 names: migrate-pr-archive-ac8.mjs --fallback-version v13.0.0 pre-staging into a sealed-chunk-violating bucket — a partial-membership ordinal collapsing members into the first chunk. #16067 repaired the 27 that had become duplicates; it deliberately did not re-place the rest.

The Architectural Reality

ADR 0004 §1.3 classifies resources/content/** as data-tier — deletable at will, regenerable by re-sync, and §2.6 records that the pre-ADR derailment was driven by treating on-disk state as needing preservation. That points away from a migration script and toward letting the syncers re-place from complete membership, which they now compute via buildContentInventory (ai/services/github-workflow/shared/contentInventory.mjs, the §2.2.1 reference implementation).

The blocker is not the computation. It is delivery: a re-placement produces a large generated-content commit, and the corpus publisher currently cannot deliver one — see #15977 ("The corpus generator is scheduled; the publisher has no owner"), #16002 (facet isolation / all-or-nothing) and #15993 (SEO credential scope). Filing this behind them on purpose; re-placing 175 artifacts into a pipeline that cannot commit them would strand the result in a working tree exactly as #16067 found the previous repair stranded.

The Fix

Sequenced, and the first step is a decision rather than code:

• Decide whether ordinal conformance is worth a corpus rewrite at all, given that no consumer currently reads a path derived from an ordinal. A defensible answer is "no, and ADR 0004 §2.2's derivability claim should be softened instead" — that outcome closes this ticket legitimately.
• If yes: re-place from complete membership rather than hand-migrating, and land it as one generated-content commit after the publisher has an owner.
• Either way, extend buildScripts/util/check-content-logical-identity.mjs with an ordinal-conformance mode. It already derives families from disk and builds the logical index; the ordinal check is a second predicate over the same membership. Report-only until the corpus conforms — a blocking audit today would wedge every commit, which is why #16067 wired only the duplicate check as blocking.

Acceptance Criteria

• Recorded decision on whether ADR-correct ordinals are required, or whether §2.2's derivability claim is amended to match reality. Nothing else proceeds on an assumed answer.
• If required: all three buckets conform, verified by a derived check rather than a hand-tallied list.
• An ordinal-conformance predicate exists in the existing content-identity check, exercised by a fixture on a temp corpus with a deliberately misplaced artifact.
• The count is reported by a script, so the number in this ticket can be re-derived rather than trusted — it will drift with every sync.
• Post-merge: a full audit passes and the check can be promoted to blocking.

Out of Scope

• Duplicate logical identities — #16057, done.
• The publisher/delivery gap — #15977 / #16002 / #15993. This ticket depends on them and must not attempt them.
• Chunk-layout redesign or any change to the ordinal-100 rule itself.

Avoided Traps

• Treating this as the duplicate repair's remainder. Two of the three affected buckets have zero duplicates; a fix scoped to "whatever #16057 left behind" would miss 56 artifacts.
• Hand-migrating. ADR 0004 §2.6 records that preservation-pressure over re-sync is what produced the original derailment, and #16067 demonstrated the specific hazard: a locally-computed placement is only as good as the membership it saw.
• Making the guard blocking now. The corpus does not conform, so a blocking ordinal audit would fail every commit in the repository.

Related

• #16057 · PR #16067 — the identity repair that measured this
• #15977 · #16002 · #15993 — the delivery gap this waits on
• learn/agentos/decisions/0004-github-content-architecture.md §1.3 · §2.2 · §2.2.1 · §2.5 · §2.6

Live latest-open sweep: checked latest 20 open issues at 2026-07-27T21:50:41Z plus an 8-message A2A recency scan; no equivalent found — the nearest neighbours are the delivery tickets above, none of which measure or address ordinal placement.

Origin Session ID: c038696f-94a6-4788-82bf-747c5672908c

Retrieval Hint: query_raw_memories("ADR 0004 ordinal-100 conformance 175 misplaced archive chunks") · commit anchor 3ec908287a