|
|
|
|
|
|
by jredwards7
131 days ago
|
|
|
The structural validation layer is worth separating from the semantic layer, even if the semantic problem is harder. If every AI-proposed change is validated against a JSON Schema before execution, and that validation produces a deterministic, signed result, you get an auditable record of what passed structural checks and when. That doesn't solve semantic drift (a field can be renamed and still pass validation) but it gives you a foundation to build semantic checks on top of. The key property is determinism: identical schema and payload should produce identical hashes and outcomes, regardless of which service runs the check. Without that, you end up debugging whether a failure is in your schema logic or in validator implementation differences across languages. Contract tests and regression evals work better when the structural layer underneath is provably consistent. One reference for this pattern: https://docs.rapidtools.dev/openapi.yaml |
|
|
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.