The Sovereign Security & Continuous Architecture Verification Plane for Modern Data Layers.
Cryptographic gating at the CI layer. No data. No agents. No drift.
users orders billing audit_log// SHA-256 FINGERPRINT8b3f7a1c2d9e5f77 a4c8b2e1f6d9a3b7 c5e8f2a1d4b7c9e3...
A structural mutation in your production database is invisible to standard CI/CD pipelines. No alert fires. No deployment blocks. The broken schema reaches production silently — and the blast radius expands asymmetrically.
Schema drift is the act of a database structure silently mutating between two states that a CI/CD pipeline treats as identical. A column is renamed. A foreign key constraint is dropped. A table is truncated and recreated with a subtly different field order. Standard deployment tooling has zero mechanism to detect any of this. The pipeline passes green. The build artefact ships. The structural corruption arrives in production asynchronously, far removed from the change that caused it.
Veritect addresses this at the architectural root. It inserts a strict cryptographic gating mechanism at the continuous integration layer — a deterministic SHA-256 assertion that the schema fingerprint committed to veritect.lock is structurally identical to the live database schema at the moment of deployment. If it is not, os.Exit(1) fires unconditionally. The pipeline does not continue.
This is not a passive monitoring layer. It does not observe and report after the fact. It is a hard enforcement gate with a binary outcome: schema matches lock, or deployment halts. A cryptographic invariant assertion that must pass before any artefact reaches your infrastructure.
- users.full_name VARCHAR(255) + users.first_name VARCHAR(128) + users.last_name VARCHAR(128) users.email VARCHAR(255) - users.created_at TIMESTAMP users.id UUID PRIMARY KEY - orders.user_ref FOREIGN KEY orders.status VARCHAR(32)
veritect: fingerprint mismatch expected: 8b3f7a1c2d9e5f77... actual: a9c4d2e8f1b6a3c7... veritect: dispatching diff payload veritect: → #devops-alerts (Slack) veritect: emitting structured diff stdout FATAL: exit status 1
veritect: fingerprint match ✓ hash: 8b3f7a1c2d9e5f77... tables: 4 verified, 0 delta runtime: 18ms veritect: schema integrity confirmed ✓ veritect: pipeline gate OPEN ✓
Veritect is architecturally incapable of touching your application records. It queries exclusively structural metadata from system-internal catalogs — never a single row of your data, never a value from your application tables.
The security boundary is enforced at the query construction layer itself. Veritect executes one deterministic metadata introspection query against the information_schema system catalog — the same read-only internal catalog your database engine uses to describe its own structure. It is structurally incapable of issuing any SELECT against your application tables, because no such query is ever constructed or dispatched.
This execution occurs entirely inside the client's localized virtual runner wall — the ephemeral compute environment provisioned by your CI provider (GitHub Actions, GitLab CI, CircleCI, Buildkite). The schema fingerprint is computed in memory, compared against the committed lock file, and the process terminates. No schema metadata, no structural intelligence, and no identifiers ever leave the runner boundary.
The outcome is 100% data sovereignty enforced at the execution architecture level — not by policy, not by configuration, not by runtime flags. No telemetry is emitted. No schema analytics are ingested. No external API call is made from the runner. Veritect is a single-shot binary: read DATABASE_URL, connect, introspect structure, hash, assert, exit.
information_schema.tables and information_schema.columns. No application table is referenced. No row is read, transmitted, or held in memory.
-- The complete, unabridged query executed -- against the target database. information_schema -- is a system-internal read-only catalog. -- No application table is ever referenced. SELECT t.table_name, c.column_name, c.data_type, c.character_maximum_length, c.is_nullable, c.column_default, c.ordinal_position FROM information_schema.tables t JOIN information_schema.columns c ON t.table_name = c.table_name WHERE t.table_schema = 'public' AND t.table_type = 'BASE TABLE' ORDER BY t.table_name ASC, c.ordinal_position ASC; -- Output: canonicalized structural descriptor. -- SHA-256 fingerprint computed in memory. -- No rows. No values. No application data.
A schema mutation that clears the deployment gate undetected does not produce an isolated failure. It cascades through every downstream system that assumes structural consistency at the persistence layer.
Modern data infrastructure is built on a foundational assumption: the database schema is structurally stable between deployments. Your analytical warehouse executes transformation queries referencing specific column names. Your Redis cache serializes object graphs whose shape is derived from your ORM layer. Your message queue consumers deserialize payloads whose structure mirrors your table definitions. Your API response types are validated against field sets derived from your database columns.
When a schema mutation bypasses the deployment gate, it does not produce an immediate, localized failure with a clear blast radius. It produces a cascading structural mismatch that propagates simultaneously through every downstream layer. The symptoms surface asynchronously, far from the mutation, in systems that have no native visibility into what changed or when.
Veritect is the insurance mechanism that terminates this class of failure at the only architecturally correct intervention point: the deployment gate, before the structural mutation reaches the production persistence layer. One deterministic blocking assertion eliminates every downstream consequence simultaneously.
schema mutation bypasses CI gate → ETL pipeline: column not found → Analytics layer: NULL injection → Cache cluster: deserialize panic → API layer: 500 response flood → Queue workers: dead-letter flood → Dashboards: corrupted aggregates time-to-detect: hours → days root cause visibility: zero
ETL transformation queries reference specific column names and data types. A renamed column or changed type produces NULL-injected outputs and broken aggregation pipelines that silently corrupt business intelligence dashboards over time.
Redis and Memcached instances holding serialized object graphs built from your ORM schema become structurally stale. Deserialization panics and stale field reads produce corrupt application state that is extremely difficult to trace to a schema change.
Kafka consumers, RabbitMQ workers, and Sidekiq processors that deserialize payloads mirroring your database schema fail silently or throw deserialization exceptions, dead-lettering messages and stalling critical transaction flows.
REST and GraphQL layers that derive type contracts from database schema definitions begin returning malformed response shapes. Consumers depending on stable field presence receive unexpected NULL fields or missing keys without any indication of the root cause.
Object-relational mappers that reflect schema structure at runtime encounter unexpected field mappings, producing runtime exceptions in previously stable code paths. Migration state divergence compounds across environments, making remediation non-trivial.
Veritect emits a precise, field-level structural diff payload to configured ChatOps webhooks at the exact moment of detection. Engineers receive an actionable delta — not a generic schema failure alert — enabling immediate, targeted remediation.
Five deterministic execution phases. Zero persistent state. Zero background processes. Single-shot CI gate with a binary, unambiguous outcome.
Reads DATABASE_URL from the CI secrets store and evaluates the local veritect.lock configuration state. No persistent daemon is spawned. No background process is registered. The process lifecycle is strictly bounded within a single ephemeral CI step on the host runner.
Executes a canonicalized schema metadata query exclusively against information_schema system catalogs. Complete structural introspection — covering all tables, columns, data types, constraints, and ordinal positions — completes within 20ms. No application data rows are accessed, transmitted, buffered, or held in memory beyond the computation window.
Generates a unique SHA-256 structural snapshot from the canonicalized, lexicographically sorted schema representation. The input string is fully normalized prior to hashing, guaranteeing deterministic output across all execution environments, database engine versions, replica states, and connection configurations.
Compares the computed fingerprint against the SHA-256 baseline committed to veritect.lock in version control. A mismatch triggers a hard os.Exit(1). The pipeline halts unconditionally. No warning-only mode exists. No silent-pass configuration is supported. The gate is binary: match or block.
Transmits a precise structural diff payload directly to all configured network alert webhooks. Structured JSON logging is emitted to stdout for downstream observability ingestion into Datadog, Grafana, or equivalent. Engineers receive a field-level structural delta — the exact tables and columns that diverged — not a generic failure notification.
Every architectural decision in Veritect is derived from a single constraint: touch only what is structurally necessary to assert schema integrity, and nothing more.
SHA-256 Hashing Protocol: Schema layout is extracted via a deterministic O(N log N) alphabetized query to eliminate cross-environment race conditions or false-positive breaks.
Zero-Telemetry Posture: The utility emits zero external outbound network requests to Veritect Labs servers. All execution stays localized to the environment runner.
Spoofing/Tampering: The connection string (DATABASE_URL) is loaded into the short-term runtime memory execution thread via encrypted runner environment secrets. It is never logged to stdout, cached to disk, or exposed to external processes.
Denial of Service (DoS): A 10-second hard socket connection timeout cap ('context.WithTimeout') mathematically limits process hanging, protecting the localized CI runner's resource pool.
No-Data Extraction Model: Veritect is architecturally isolated from customer tables and application transaction rows. It interacts exclusively with the metadata structures inside 'information_schema.columns'.
A single GitHub Actions step is the complete integration surface. Drop it into any existing deployment workflow without configuration overhead, infrastructure provisioning, or runtime dependencies.
# Insert this step into your deployment workflow. # Position: BEFORE your deploy / release step. # Schema mismatch triggers os.Exit(1) — hard pipeline block. # No configuration overhead. No infrastructure provisioning. - name: Execute Veritect Schema Drift Guard uses: veritect-labs/veritect@v1.0.0 with: database_url: ${{ secrets.PRODUCTION_DATABASE_URL }} slack_webhook: ${{ secrets.SLACK_DEVOPS_ALERTS }}