dtoro
18cb79caf9
- seeds/ontology.yaml: 59 entity types (5 abstract, is-a hierarchy), 46 relationship types with cardinality, 6 lifecycles with terminal states and named precondition checks - seeds/inventory.yaml: 110 entities / 142 relationships translated from legacy inventory.yaml (fleet, services, ingress, storage, governance, archaeology); thin spots marked for backfill - seeds/policy.yaml: 4 risk classes, 27 approval rules (hierarchy-aware, per-entity overrides), autonomy kill-switch off (cold start) - api/openapi.yaml: full v1 REST contract (40 paths), RFC 9457 errors, cursor pagination, idempotency, ETag/If-Match, scopes; redocly-clean - docs/adr/0001-0010: initial architecture decision records - scripts/validate-seeds.py: Phase 0 gate — hierarchy, lifecycles, endpoints, cardinality, policy cross-refs (0 errors) - plan: layer CHECK gains 'meta' (root type), cardinality gains 'many-to-one' Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
696 B
696 B
ADR 0005 — UUIDv7 + slug entity identity
Status: accepted (2026-07-07) · Plan: rev 3, R3-5 (resolves audit D1)
Context
Rev 2 used TEXT primary keys ('host:hubris') — renames break FKs, and date-string signal IDs are race-prone.
Decision
Primary keys are UUIDv7 (time-ordered, generated in Go). Every entity also carries a unique human slug ('host:hubris'); (type, name) is unique too. The API accepts UUID or slug everywhere; slugs may change (rename), UUIDs never do.
Consequences
- Renames are metadata updates; history and edges survive.
- UUIDv7's time-ordering keeps B-tree inserts append-mostly.
- Seeds and exports use slugs (human-diffable); ingest resolves to UUIDs.