sql_Σ — Governed SQL Product Engineering for Codex

Turn plausible SQL generation into a consumer-visible, authority-aware, evidence-backed data product.

Comment

Inspiration

What it does

How we built it

Challenges we ran into

Accomplishments that we're proud of

What we learned

What's next for sql_Σ — Governed SQL Product Engineering for Codex

Inspiration

SQL can compile, return rows, and still be the wrong product. The most expensive failures often live above syntax: an incorrect grain reaches the dashboard, a business classification is hardcoded into executable text, invalid values silently disappear, a five-character domain becomes nvarchar(400), or a harmless request creates permanent staging tables, logs, helper procedures, and version machinery with no consumer.

We wanted Codex to reason about those failures before generating or approving code. The result is sql_Σ, an AI-first Codex Skill for governed SQL product engineering.

What it does

sql_Σ reconstructs a SQL product contract across six owned dimensions:

  1. Semantics — purpose, consumer, grain, keys, measures, boundary behavior, and business invariants.
  2. Data — authoritative sources, domains, field fit, provenance, and sensitive-data boundaries.
  3. Execution — placement, materialization, parallel safety, resource risk, and engine mechanics.
  4. Mutation — the exact write surface, failure atomicity, concurrency, and cleanup.
  5. Operations — observability, restart behavior, deployment compatibility, and ownership.
  6. Verification — evidence shaped to the claim being made.

A candidate is not admitted merely because it is elegant or syntactically valid. It must preserve meaning, use sufficient authority, expose only consumer-required grain and measures, avoid unowned hardcode and unnecessary surfaces, fit real field domains, and carry evidence strong enough for its claims.

The Skill is intentionally anti-bloat. It does not prescribe CTEs, temp tables, logging tables, helper procedures, TABLOCK, or technical version identifiers as universal answers. A new SQL object or mechanism is created only when a named consumer and a concrete executable distinction justify it.

Synthetic demonstration

The repository includes one reproducible SQL Server challenge. The input procedure looks plausible but contains four product-level defects:

  • sale-line detail is sent to an aggregate dashboard;
  • business channel policy is hardcoded in a VALUES constructor;
  • invalid discounts are silently erased by TRY_CONVERT plus filtering;
  • ChannelCode is widened from a ten-character contract to nvarchar(400).

The reference result produced under sql_Σ:

  • publishes exactly MonthStart × StoreId × ChannelGroup;
  • reads classification from active rows in the authoritative dbo.ChannelPolicy source;
  • rejects invalid discounts and unmapped channels before publication;
  • keeps ChannelCode at nvarchar(10);
  • changes one stored procedure and creates no durable stage, log table, helper procedure, run identifier, or technical version.

One procedure-scoped #SalesScope table is retained because the same captured rowset must feed validation and aggregation. Its lifecycle is explicit: create, populate, validate, aggregate, and automatic cleanup at procedure exit.

How we built it with Codex and GPT-5.6

We used Codex as a co-architect rather than a text generator. The methodology was repeatedly tested against real SQL refactoring failure classes, raised from incident-shaped rules into reusable classes, and consolidated into one installable Skill.

The current package uses a compact ontology instead of a catalog of preferred snippets. It gives Codex direction, ownership boundaries, and admission conditions while leaving engine-specific choices to the actual contract and evidence.

For the competition demo, a fresh GPT-5.6 Codex task receives only the public Skill and the synthetic challenge. Its output is compared with an independent oracle that names the required semantic repairs without prescribing the exact implementation. The repository also includes a deterministic verifier for package structure, references, Python syntax, private-marker leakage, and the audit-pack generator.

What was built during OpenAI Build Week

The broader SQL methodology had earlier internal iterations. During the competition period we:

  • consolidated the work into the current single sql-product-engineering Skill;
  • raised repeated incident rules into typed product dimensions and admission invariants;
  • added explicit grain, consumer, authority, hardcode, field-domain, surface-cost, and evidence gates;
  • added the audit-pack generator and verification contract;
  • created the self-contained synthetic challenge, independent oracle, reference repair, and reference result;
  • created the repository verifier and the camera-free narrated demonstration.

This boundary is documented so the submission is evaluated on the competition-period product rather than on a claim that every underlying idea was invented during the week.

Challenges

The hardest problem was abstraction height. A rule that is too concrete becomes a growing blacklist of incidents. A rule that is too abstract sounds wise but cannot stop a dangerous code birth. We settled on a middle layer: every class must retain a named consumer, an owner, and an executable witness.

The second challenge was evidence hygiene. A polished SQL diff is not runtime proof. sql_Σ separates static contract checks, semantic known-answer checks, runtime execution, plan evidence, concurrency evidence, and production-readiness evidence. The included reference patch is explicitly labeled unrun against a live SQL Server; no performance claim is inferred from code shape.

Accomplishments

  • One installable Skill governs queries, views, procedures, migrations, ETL/ELT, semantic measures, and SQL Server operational work.
  • The demo repairs product semantics without creating a small civilization of helper objects.
  • The package is inspectable: rules, routes, engine projections, probes, templates, verification guidance, and audit tooling are all included.
  • Judges can reproduce the challenge without access to private infrastructure or business data.

What we learned

The best SQL assistant is not the one that writes the most SQL. It is the one that knows which semantics must survive, which source owns a decision, which detail has a consumer, which object does not deserve to exist, and which claim has actually been proved.

What is next

  • Run the same contract against additional dialects and semantic layers.
  • Add opt-in live SQL Server fixtures for plan, concurrency, and operational evidence.
  • Build a small benchmark of plausible-but-wrong SQL product failures.
  • Measure how often the Skill reduces unnecessary durable objects, excess grain, silent coercion, and embedded business policy.

Judge quick test

  1. Copy sql-product-engineering/ into ~/.codex/skills/.
  2. Open a fresh Codex task using GPT-5.6.
  3. Ask: Use $sql-product-engineering to complete demo/challenge.md against demo/input.sql.
  4. Compare the answer with demo/oracle.md and demo/reference-result.md.
  5. Run python tools/verify_submission.py.

Expected verifier result:

{
  "status": "pass",
  "required_files": 13,
  "skill_files": 9,
  "errors": []
}

Disclosure

The demonstration uses synthetic schema and data contracts. No private database credentials, production data, or personal conversation logs are included. The narrated video uses a synthetic voice and no camera.

Built With

Share this project:

Updates