2 ms·
Totally agree. We treat structural validation as a separate, deterministic “compiler phase” before anything executes. Draft (AI output) → normalize/canonicaliz
by RobertSerber 8mo ago
Totally agree. We treat structural validation as a separate, deterministic “compiler phase” before anything executes.
Draft (AI output) → normalize/canonicalize → link/type-check (cross-refs, relationship/FK semantics, datasets/metrics) → append-only migration ops → canonical DSL + stable hash.
This is also why we’re building it as a compiler pipeline rather than “prompting harder”: the output is an auditable artifact (canonical DSL + hash + migration checksum) that makes contract tests/regression diffs trustworthy.
Next step is what you call out: a signed attestation per compile (schemaHash + pinned validator/version/options + canonicalHash), so identical input yields identical outcomes across services/languages.
You’re right it doesn’t solve semantic drift alone (renames can still validate), but once the deterministic floor exists we can layer semantic checks + rename-safe migrations on top without debugging the toolchain itself.