Core records
| Record | Authority |
|---|---|
| Connection | Configured source kind, authorized scope, enabled state, source health and read generations. |
| Observation | Reported source identity, selected metadata, provenance and last-observed state. |
| Binding | Exactly one canonical agent for an observation; monotonic revision. |
| Canonical agent | Business name, owner, purpose, lifecycle and review decisions. |
| Related asset + link | Typed tool, model, application or identity context explicitly associated with an agent. |
| Identity review | Latest pair choice, fingerprint, review revision, actor, reason and correction metadata. |
| Registry event | Successive record and decision changes with actor and details. |
Identity is scoped
All inventory relations carry tenant_id. Composite primary and foreign keys include it so identical source IDs in two tenants do not collide or cross-link. Internally, an observation ID derives from its connection, provenance and normalized source ID. Do not construct an external business identity from its display name.
Exactly one binding at commit
A binding primary key permits at most one binding per observation. A deferred reverse composite foreign key requires at least one at commit. Ingest can insert the observation first and binding second in the same transaction; it cannot commit half of the pair. Rebinding updates the existing binding rather than creating a second authority.
Presence, staleness and lifecycle
Presence describes whether a source returned an observation according to its adapter’s completeness rules. Stale describes unavailable or outdated source evidence. Lifecycle is a business decision. None of these fields starts or stops a provider agent. An owner assignment is a recorded decision, not owner acceptance or a security identity grant.
Schema ownership
Alembic is the only schema-change path; constructors check rather than create schema. Inventory history uses catproof_alembic_version. The guided-review baseline adds h0008 for identity reviews and binding revisions. Use explicit migrations and populated-upgrade tests for new schema changes. Never stamp an unrelated application’s Alembic history.