Erlyc is a model-driven engineering system. Model-Driven Engineering (MDE) inverts the usual relationship between code and diagrams: instead of code being the primary artifact and models being documentation that quietly goes stale, the model — entities, relationships, screens, roles, permissions — is the source of truth, and the application is derived from it.
The idea is old and well studied. The CASE tools of the late 1980s generated working applications from models; the Object Management Group relaunched the approach as Model Driven Architecture in 2001; and there is a serious research line on deriving access-control infrastructure from models rather than hand-writing it. Erlyc did not invent any of this. What it changes is the one thing that kept the approach from working in practice.
Why the approach stalled
MDE has been close to mainstream adoption for about twenty-five years without arriving. The obstacle was never conceptual. It was cost.
Building and maintaining a model took a trained modeller and heavy tooling, and it usually cost more than writing the code would have. That creates a predictable failure: when something needs to change and the model is the expensive path, the change goes into the generated code instead. Now two artifacts describe the system and they disagree.
The industry built elaborate machinery to live with that disagreement — round-trip engineering, protected regions, the generation gap pattern. None of it was pleasant. Within a release you had a model nobody trusted, describing a system that had moved on, which is exactly the condition MDE was invented to prevent.
What changed
A language model can now draft a specification and a data model from a description of a business. The expensive artifact became the cheap one.
Two consequences follow, and the second matters more.
Regeneration replaces reconciliation. Round-trip engineering existed only because models were costly enough to be worth synchronising. When producing one costs almost nothing, regenerating is cheaper than hand-patching the output. You discard the divergence rather than maintaining it.
Authorship does not move. The model says what you decided it says. You work the idea out on the discovery boards, answer the questions each stage raises, and edit requirements, screens, roles and the capabilities each role holds. What the machine removed is the typing, not the authority.
The problem this introduces
Classical MDE assumed a human wrote the model. Every assurance technique the field developed — metamodel conformance, constraint checking, well-formedness rules — assumes a model that might be malformed, and checks it before transforming it.
A drafted model is not malformed. It is plausible. And reviewing a plausible draft is not the same act as writing one: you read it for sense, not for what the transformation will do with the words.
A real example. A specification carried the capability line Cannot: create invoices. The phrase parser had no notion of negation, and the generated application granted invoices.create — the role held exactly the permission the specification forbade. Every artifact was internally consistent. Nothing contradicted anything. There was no malformation to catch: the document read correctly and the application did the opposite.
That failure class does not appear in the older literature, and it could not have. Someone writing that line by hand would have written it in a notation whose negation the generator understood, or the model would have refused the sentence.
Where the audit sits
If the failure mode is plausibility rather than malformation, the check has to move.
It reads adversarially — for what the generator will do with the words, not for whether they parse. It runs before you read the specification, not merely before generation, because the scarce resource is no longer correctness but attention: a reader who has not been told where to look will spend theirs confirming that a well-written document is well written.
It is also unconditional. A run can go from idea to application without stopping, in which case there is no human read at all and the audit is the only scrutiny the model receives. Human review is optional in a system like this. The audit is not.
And it reports rather than repairs. Findings are attached to the specification for you to act on. A system that silently rewrites your access model is worse than the problem it solves.
What it looks for in practice: a screen filed as though it were a role, two rows that merge silently into one role, an access model hung on a domain entity instead of the user, a role assignment the runtime will never enforce, and a capability that states what a role must not do.
What this does not do
Worth saying plainly, because the approach has real limits.
There is no runtime adaptation. The loop closes at design time. A generated application does not observe itself or reconfigure while running.
There is no formal verification. These are deterministic rule checks, not model checking and not proof. That is what a pipeline can afford to run on every read; it is not the same guarantee.
The scope is business applications — systems with roles, records and rules. Nothing here addresses embedded or safety-critical software.
And the handoff is real. Generated output is a repository you own outright, which is the right answer to lock-in and the wrong answer to divergence: once an exported application is edited by hand, it is outside the loop, and the old problem is available again to anyone who wants it.
The bet
MDE's original bet was that the model should be the primary artifact. That bet was sound. It was also unaffordable for the whole of its existence — and that is the part that changed.