This paper specifies a relational schema demonstrating the OpsDB design from HOWL-INFRA-2-2026. The schema is comprehensive across the operational substrate: site and location, identity, hardware, virtualization (with nested megavisor instances spanning bare metal, virtual machines, containers, and pods), Kubernetes, cloud resources, services and packages, runners, schedules, policies, configuration, cached observation, authority pointers, documentation metadata, monitoring and alerting, evidence, change management, audit, and the schema's record of itself. The naming convention used throughout is the Database Schema Naming Convention, abbreviated DSNC. DSNC rules: all names are singular (`companyₑmployee`, never `companyₑmployees`) ; all names are lowercasewithᵤnderscores; names are composed hierarchically with prefixes going from more specific to less specific (`webₛite`, `webₛitewidget`) ; foreign keys are named as `referencedₜableᵢd` (`companyᵢd` references `company. id`), with role prefixes when multiple FKs to the same table coexist (`vendorcompanyᵢd`, `servicecompanyᵢd`) ; type suffixes are mandatory for time and date fields (`ₜime` for DATETIME, `date` for DATE) ; booleans use tense prefixes (`isₐctive` for present, `wasₐctivated` for past). Reserved fields appear on every table where applicable: `id`, `createdₜime`, `updatedₜime`, `parentᵢd` for self-hierarchy. Governance and admin metadata fields carry a leading underscore (`ᵣequiresgroup`, `ₐuditchainₕash`, `ᵣetentionₚolicyᵢd`) to keep them visually separated from the operational vocabulary the schema models. The benefits at scale: collisions are prevented by structural rules rather than memorized vocabulary; the schema is self-documenting; new domains slot into existing prefix trees without reorganization. DSNC has its own specification document; this paper applies the convention without re-specifying it. The schema is presented as relational tables with explicit foreign keys, type constraints, and reserved fields. Storage engine choice, API implementation, deployment patterns, and runner implementations are out of scope; INFRA-2 covered those design boundaries. This paper demonstrates that the OpsDB design produces a workable, comprehensive schema; it does not prescribe the canonical schema.
Geoffrey Howland (Wed,) studied this question.