Say who takes part, what they decide, which records it is about and what should happen at the end.
The draft is a starting point, expressed entirely in the same definition a person would build by hand: lanes, screens with component IDs, handlers, criteria in the expression editor. Everything is visible as configuration. The validator checks it, the preview runs it on live rows as each role, and the publish gate needs the process owner's approval, exactly as for any app.
Screens can also be generated from rules that already exist. A data-quality rule on supplier records becomes the steward's correction screen with the fields the rule names; a contract on a record becomes the request screen with the fields the contract requires. This is the SmartApp composer at work: forms made where the data is defined.
When you choose to use an external model for drafting, the platform sends the description and the structure it needs to reason about: the names of screens, components, levels and roles; the definitions of data handlers (names, columns, types); and the criteria as text. It keeps every row from your systems inside the platform. The model returns a draft; the platform validates it. The handshake with the model is attested and logged, so the record shows what crossed and when.
You choose the model, and the platform can also draft on its own from the catalog and the rules; an external model adds fluency to the description step. Either way the checks are the same. The trust center states the boundary as policy.
| Crosses | Stays |
|---|---|
| Screen, component, level and role names | Every row from SAP, Oracle, the lakes and the applications |
| Handler definitions: names, columns, types | Values of any field |
| Criteria and expressions as text | Uploaded files and captures |
| The description you typed | Log entries and decisions |
An audit of 1,645 applications published with a consumer AI app builder found that 170 of them, 10.3 percent, exposed data through missing or insufficient row-level security (CVE-2025-48757, disclosed May 2025). The lesson is about where the checks sit. In Lima a draft is a definition, and the definition passes the validator, reads through handlers that apply each source's access policy, previews as each role, and publishes through a gate a person approves. The access rules come from the systems, so a generated screen can show a person only what the source allows.
Analysts now list AI-assisted development among the capabilities an enterprise application platform must have, alongside governance and data connectivity. The comparison pages show, with dated sources, how each platform approaches generated apps and where its data lives.
Any model your organisation approves; the platform's own drafting works on its own. The choice is made per platform, and the boundary is the same for all.
A draft is a definition; a write-back is switched on per object by the application team after a confirmed test write, for drafts and hand-built apps alike.
Every part of it is the same definition you would build by hand: lanes and levels, screens with component IDs, handlers, criteria in the expression editor. Every part of it is readable configuration.
It shortens the first draft. The owner still reads the criteria, runs the preview as each role and approves the version.
Bring one process and the systems it touches. In the first session we register the data handlers, draw the levels or the lanes and run the first screen on your live rows.
