# OUDEA v0.1 Final Draft — Editorial Verification Notes

This file is **non-normative**. It records implementation-verification items that do not change the agreed architectural rules unless a finding requires a separately reviewed specification change.

## Ahmad Alsharef — implementation verification

Before publication of v0.1, verify against the current bytEM implementation and tests:

1. **DEID normalization**
   - path case sensitivity;
   - hostname normalization;
   - percent-encoding;
   - Unicode handling.

2. **DEID redirect / migration behavior — resolved for v0.1**
   - redirects are retrieval-only and do not redefine DEID identity;
   - canonical DEID migration is not implemented and is not defined by OUDEA v0.1;
   - v0.1 defines no successor field or forwarding semantics;
   - unresolved DEIDs must not be silently substituted with another identifier.

   **Future direction:** consider an explicit persistent tombstone/withdrawn state so an implementation can distinguish an unknown DEID from one that was previously registered and deliberately retired. HTTP `404 Not Found` versus `410 Gone` semantics may then be standardized. This is not a v0.1 requirement.

3. **Duplicate supply items**
   - actual behavior when one DEID has multiple items of the same `supply_type`;
   - current enforcement/use of `asset_key`, per-supply Schema and `asset_version`;
   - which behaviors are validated by automated tests.

4. **References**
   - verify the public Reference behavior against current implementation;
   - confirm directional references require no backlink for successful execution;
   - confirm referenced DEIDs are handled one at a time through Find/Exchange and nested references are not recursively auto-exchanged;
   - confirm complete aggregate Exchange requires all directly required `part_of` references to resolve.

5. **Lifecycle / readiness**
   - exact conditions for `draft → registered`;
   - exact behavior of `registered / reserved`;
   - when a DEID first becomes publicly discoverable;
   - exact meaning and tested behavior of `registered / advertised`;
   - whether attempted Exchange in advertised state creates a demand signal and whether that is Core behavior or bytEM-specific behavior;
   - exact condition for transition to `registered / exchangeable / open`;
   - API versus dataset readiness behavior;
   - which lifecycle/readiness values are persisted and which are derived.

## Future conformance-test suite

For a subsequent OUDEA version, review which proposed DEID, Class/Schema, Reference, Find/Exchange, Lifecycle/Readiness and Extension conformance tests are already implemented/testable in bytEM and which require new fixtures or public contracts.

Conformance tests must verify public OUDEA behavior, not private bytEM internals.