[Gnobu]

That makes sense. Once AI can mutate structure, permissions probably need to govern model evolution itself, not just API access or workflow execution. It seems like auditability and approval for schema-level changes become runtime concerns too. Have you explored that layer yet?

[RobertSerber]

Yes — that layer is part of the runtime design. The AI never mutates structure directly. It only proposes a DSL change, which goes through a deterministic compile pipeline before it becomes canonical.

Schema evolution is treated as a runtime operation with versioning, migration logs, and a deterministic state hash (dslHash). Every compile produces a new schema version and writes a structured change plan to dsl_change_log, so structural mutations are fully auditable.

There’s also a cryptographic validation attestation step: the compiled DSL is hashed and attested so the runtime can verify that the schema being executed is exactly the one that passed the pipeline. That prevents unauthorized structural drift outside the compiler path.

Breaking changes, data compatibility, and migrations are evaluated before commit, so structural mutations are gated much like data mutations.

The stack to support this is admittedly quite complex, but most of that complexity lives in the runtime so the AI-facing interface can remain simple and safe. The big shift was treating AI as proposing structure, but never owning execution.

One thing I'm still unsure about is where the long-term governance layer should live once models can mutate system structure — inside the runtime itself, or higher up at the application/policy level. Curious how others are thinking about that boundary.