Workplan: AXN concept and manifestation

Draft, 2026-10-18. Status: plan only. No record, dataset, page or site has been changed under it. Each increment below stands alone and waits for its own ruling.

0. Where things stand

1. How AXNs change. Since June, repairs that change a record's bytes re-derive its AXN: restore_in_place (July), the 2026-08-15 amendments, and the 2026-10-15 record repair (250+ records). Most repairs record the prior AXN and hash (axn_before, hash_before, modifications), but not all.

2. The 13 October rule. AXN protocol v2.2 record_dimensions (ruled 2026-10-13) separates three facts: the AXN, the act that established it, and the bytes held. It applies to the 2026-06-20 batch only. Extending it to other records was left as a separate ruling.

3. The 18 October scan. Old and new glyphs coexist in about 40,800 places across about 2,400 files in the archive and fleet. Every one still resolves, because the hex selects the record.

4. The working map. axn-reconciliation-manifest-2026-10-18.json traces each record's minting AXN.

   • 1,244 records still carry their minting AXN.
   • 242 batch records have been re-derived since 06-20.
   • 175 later mints have been re-derived, and their minted hash verifies against bytes retained in git.
   • 16 have a chain gap: #1–4, #863, #865, #866, #869, #1056, #1085, #1448, #1479, #1618, #1619, #1631, #1634.
   • About 1,150 glyphs in copies match no record's recorded chain.

   It is a map, not a migration. It is not landed.

1. Rulings this plan rests on

• 2026-10-13: "lets go ahead and adopt the solution for those batched axns."
• 2026-10-18: "the idea was to make a one-time exception for the emergency batch axns, which correspond to no bytes. and yes, we keep the axn, as long as the chain can be traced back to the minting bytes and axn. updating tens of thousands of identifiers at each step is beyond the scope of our current organization."
• 2026-10-18: "axn should update with changes to bytes, i dont want to revert that... which is not the same thing as saying the identifier has to change. the minting axn would simply become something like the concept doi."
• 2026-10-18: "id like to keep this incremental… i am not necessarily ready to make sweeping changes, even if that leaves the current state somewhat in disarray."

2. The model

• Concept AXN. Names the record across all its versions, as a concept DOI does. It is the minting AXN. For the 2026-06-20 batch it is the batch AXN, the one exception: it corresponds to no bytes. The concept AXN follows the record.
• Version AXN. The content-derived AXN of one manifestation. It updates when the bytes change. A version AXN identifies fixed bytes.
• Manifestation. One retained body. It is named by file path and git blob, with a verified SHA-256 and SWHID, a date, and a cause with its evidence. A version exists only where its bytes can be identified.
• Assignment. The record that an AXN string was given to a record, with its date and the act that gave it. An assignment may be recorded without retrievable bytes; where that is so, the record says so.

Central rule: the concept follows the record. A manifestation identifies fixed bytes. Earlier assignments remain inspectable, and unavailable bytes remain explicitly unavailable.

Three facts kept apart for every manifestation: an AXN assignment was recorded; its derivation is reproducible; its bytes are retained and retrievable.

For existing records, the concept designation is adopted now. It is the earliest recorded AXN, marked as adopted 2026-10-18. The archive does not claim that the original mint drew the distinction. The batch's first restored file is its earliest retained manifestation, not the bytes behind the batch AXN.

3. Resolution rules

Request	Resolves to
hex alone	the record (unchanged behaviour)
concept AXN	the record's landing page: current version, the version list, and the original manifestation named explicitly
a historical full AXN (an earlier assignment or version)	that version's page where its bytes are retained; otherwise a page stating the assignment, its date and cause, and that the bytes are not retained
manifestation address	the exact bytes, or a statement that they are withheld (see §5a) or not retained

Machine-readable relations distinguish concept, current_version, manifestation and alias. For the 1,244 records whose concept and first version share one AXN, the landing page presents the record and names its first manifestation. The manifestation URL retrieves the fixed bytes.

4. Increments

Each increment is proposed separately, and each lands on its own ruling.

1. The rule in the protocol. Draft the concept and manifestation section for the AXN protocol (data/api/axn-protocol.json), extending record_dimensions from the batch to every record. Text only; it is shown to MANUS before it is written in.

2. Forward from the next mint. New mints carry concept_axn (the minted AXN) and a first versions entry: file, blob, SHA-256, SWHID and date. The repair scripts keep re-deriving the version AXN, append a version entry with its cause and evidence, and never touch concept_axn. Nothing already in the archive changes.

3. The back-designation as data. Publish the reconciliation map as a dataset, read-only and not yet applied to records. It carries each record's adopted concept AXN, its known assignments and its retained manifestations, in one of three classes:

   • verified to minting bytes;
   • batch exception, with no minting bytes;
   • chain gap.

   Applying it to the registry is a later ruling.

4. Resolver. Add lookup by full historical AXN, using an alias table built from the recorded assignments. Version pages are built only for retained manifestations, and unavailable or withheld bytes are stated as such. Hex resolution is unchanged.

5. New pointers. Generated links whose purpose is to follow the record (citation graphs, site navigation) write the concept AXN from then on. Existing references remain untyped: they still resolve, and their intended scope (the record or exact bytes) is not inferred from which glyph they carry.

6. A check that records and does not block. It reports four classes separately:

   • unresolved references;
   • historical aliases;
   • current-version displays that are out of date;
   • byte changes with no version entry.

7. Reading queue.

   • The 16 chain gaps.
   • The ~1,150 unmatched glyphs. These may be missed assignments, transcription errors, decorative displays or wrong identifiers; they are read, never normalised automatically.
   • The 15 decorative or legacy axn_display values (e.g. 🔐🪞🎭∮ on #874–876). These are to be kept distinct from the authoritative identifier field.

5. Open questions (each needs a ruling)

a. Redaction access. Versioning settles identifier continuity, but not whether pre-redaction bytes stay retrievable. Proposal: a redacted manifestation resolves to metadata stating that the bytes are withheld, with the digest and provenance the policy permits. Separately, the bytes stripped from #870, #871 and #912 on 2026-10-15 remain in the public git history. If any stripped credential was live, it should be revoked at its source. Rewriting git history is a different and destructive act, and is not proposed here.

b. Landing page for identical concept and version. Is the presentation in §3 right for the 1,244 records whose concept and first version share one AXN?

c. The display field. Keep axn_display as a decorative field distinct from the identifier, or retire it?

d. Label for adopted designations. The working wording is "concept designation adopted 2026-10-18 (earliest recorded AXN)".

6. Not in scope

• No rewriting of existing copies anywhere. They remain resolvable as they stand.
• No reversal of any re-derived AXN.
• No edits to history: the batch assignment, the derivation ledger's events, repair maps, audits, logs, deposited texts, capture transcripts or encounters.
• Today's own changes stand. The spxi.dev change to #72 and the metadatapacket catalog refresh carry version AXNs, which the model reads as references to a version. #1686's text cites #72 by a version AXN.

∮ = 1