Identity Minting — Status

Unit ID: identity-minting Status: 🚧 In progress, M0–M3 complete (M2 and M3 on 2026-09-24), M4 next Plan: identity-minting.md Sketch: identity-minting.md

Is this unit complete?

No. Slices M0–M4 are planned. M4 ends with a walk-through that only a human can do.

Slice Scope Status
M0 ADR-A82 amendment, ADR-A84, licence tracking, contracts and schemas, anchor vectors, specification skeleton ✅ Complete — see VP
M1 Vocabulary, compiler recipe emission, dal:claimsConstraint checks, export-recipes ✅ Complete, 629/629 tools/persistence tests — see VP
M2 Pinned Unicode 16.0 tables, Python library, vector generation ✅ Complete, 51/51 library tests, 7 generated vectors files — see VP
M3 Java library, vector coverage of every recipe feature ✅ Complete, 43/43 Java tests, 66/66 Python, 11 vectors files — see VP
M4 Specification completion, READMEs, human walk-through ⏳ Not started

Decisions awaiting human review

The plan records six agent design decisions (P1–P6): recipe stored as canonical JSON inside the compiled TTL, dal:tuplePrefix as a list, position widths as vocabulary, natural-key rendering, the JSON restrictions that make the recipe digest simple, and (taken in M1) dal:keyConstraint as the source of a derived or natural key, with its scope value first. P1–P6 are now built on; reversing one means reworking M1.

Open question for the human

Should NfkcTrimUppercase and NfkcTrimLowercase remove default-ignorable code points? Today they do not, because NFKC keeps them. A SKU typed with a zero-width space therefore mints a different IRI from the same SKU without one, and a key of nothing but default-ignorables mints rather than failing with EmptyKeyComponent. NfkcTrimCasefold removes them. Options: (a) keep this, documented as specification §11 pitfall and vector key-default-ignorable-only-survives, (b) add a remove_default_ignorable step to both pipelines, which changes every recipe digest using them and needs a Default_Ignorable_Code_Point table. My recommendation is (b), before any adopter mints with these pipelines, since changing it later is a re-key. Both libraries implement the current definition, and the change would touch the tables, both libraries, the anchors and the specification together.

Agent decisions taken in M3 (for human review)

Found in M3, for persistence-compiler-iri-sync

A position-derived event profile using dal:RegistryTokenDerivation must still declare a dal:digestScheme, because the Slice 3 check requires one on every dal:DerivedHashIdentity profile. The scheme is unused. Relaxing the check for registry-token events is a small validator change, left for that unit.

M0 delivery detail

M1 delivery detail

M2 delivery detail

M3 delivery detail