Motivation
The v1 JSONL row map currently treats UUIDs as the supported external ID kind. That is a good strict baseline, but downstream systems often already have stable string identifiers from another store or artifact format. They should be able to bind ordvec row IDs to those identifiers without inventing UUIDs solely for the manifest layer.
This overlaps with the broader row-id/remap contract tracked in #119, but this ticket is specifically for the manifest row-map schema and verifier behavior.
Scope
- Allow a small, explicit set of row-map external ID kinds beyond UUID.
- Preserve the current strict checks: row_id equals zero-based line number, db_id is non-empty, NUL-free, and unique by default.
- Keep UUID validation available as the strictest mode.
- Decide whether additional ID kinds are built in, namespaced, or extension-gated.
- Keep the verifier from interpreting application-specific ID semantics.
Acceptance Criteria
- JSONL row maps can declare a non-UUID string ID kind and verify successfully when all structural checks pass.
- UUID row maps keep current validation behavior.
- Unsupported ID kinds fail with a stable error code.
- Duplicate IDs, empty IDs, NUL-containing IDs, skipped row IDs, and row-count mismatches remain verifier failures.
- README/tests document when to use UUID versus application-defined string IDs.
Motivation
The v1 JSONL row map currently treats UUIDs as the supported external ID kind. That is a good strict baseline, but downstream systems often already have stable string identifiers from another store or artifact format. They should be able to bind ordvec row IDs to those identifiers without inventing UUIDs solely for the manifest layer.
This overlaps with the broader row-id/remap contract tracked in #119, but this ticket is specifically for the manifest row-map schema and verifier behavior.
Scope
Acceptance Criteria