Skip to content

spec: ratify single claim identity on the wire (AR-18) #48

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
tymofiy merged 1 commit into from
Jun 27, 2026
Merged

spec: ratify single claim identity on the wire (AR-18) #48

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions spec/CORE.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -253,6 +253,8 @@ Each claim is a markdown list item. A claim uses EITHER dense OR verbose form fo

Positions 1–4 are REQUIRED. Positions 5–6 are OPTIONAL. Empty interior slots are valid: `{0.85|r|E020|2026-03-10||prediction}`.

**Single claim identity (normative).** The bracket id (`[C001]`) is a claim's sole serialized identity — relations, history entries, and cross-pack references (AR-16) all resolve to it. The dense metadata block carries EXACTLY the positional fields defined above and no others: a producer MUST NOT append fields beyond position 6, and a conforming reader MUST treat any non-empty token past them as a malformed claim (rejecting it) rather than silently discarding it. An opaque or storage-layer identifier a system keeps for a claim (e.g. a database key) is non-wire — it is never emitted into, nor reconstructed from, the serialized claim; preserve it out-of-band if it must survive a round-trip. Storage-layer identity is a non-normative concern (see [STORAGE.md](STORAGE.md)).

@chatgpt-codex-connector chatgpt-codex-connector Bot Jun 27, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Preserve section targets for cross-pack refs

When this normative sentence says cross-pack references all resolve to the bracket id, it contradicts §9/AR-16's pack_name#section_ref contract and existing valid references such as typical-fixture#Findings in the maximal fixture. In implementations that adopt AR-18 literally, valid cross-pack ↔pack#section links would be rejected or rewritten as claim IDs, breaking current fixtures and authored packs; this clause should limit the claim-id identity rule to local claim references/history, or explicitly keep section refs valid for cross-pack see_also.

Useful? React with 👍 / 👎.


**Context prose** may follow the metadata on the same line (trailing prose) or on subsequent indented continuation lines (2+ spaces, AR-11).

**Relations** MAY appear on the metadata line after the closing `}` (separated from it by a space) — either starting the trailing text or following the context prose — and/or on subsequent continuation lines. In every position, relations form a comma-separated list that ends the line, and a relation symbol is parsed as a relation only when immediately followed by a valid claim-ID reference (`C` + digits or a cross-pack reference, per AR-10); other occurrences are prose. Relations use symbol syntax:
Expand Down Expand Up @@ -623,6 +625,7 @@ The following normative decisions resolve ambiguities identified during grammar
| AR-15 | `tier` is optional. When `hub`, `sub_packs` is required. |
| AR-16 | Cross-pack references: `pack_name#section_ref`. `#` is the separator. |
| AR-17 | Blank lines are permitted between structural elements (frontmatter, headings, descriptions, sections, claims). A section MAY open with a blockquote description, mirroring the document heading. Whitespace-only lines are not blank lines. |
| AR-18 | The bracket id is a claim's sole serialized identity; relations, history, and cross-pack references (AR-16) resolve to it. A claim's metadata block (dense §6.1 or verbose §6.2) carries exactly its defined fields — producers MUST NOT add fields beyond them, and readers MUST reject a non-empty undefined/trailing token rather than silently dropping it. Opaque or storage-layer identifiers are non-wire (storage is non-normative; see STORAGE.md). |

---

Expand Down