Production is an inspected event.
Every Genwright application passes a quality gate before it can reach production. An application that fails does not launch until the findings are cleared. This is the part that makes an AI-built system safe to depend on, and it is not optional.
The failure mode of generated software is not bad code. It is unexamined code.
A generated application usually works when you demonstrate it. The problems arrive later and quietly: a permission that lets a contractor see another contractor's rates, a record that can be edited without leaving a trace, a query that is fine at two hundred rows and unusable at two hundred thousand.
None of those show up in a demo. All of them show up in an audit, a dispute, or a bad week. Pre-flight is a fixed inspection applied to every application, every time, so that the things nobody thinks to check get checked anyway.
What pre-flight checks
Five areas. All must clear before an application can be promoted to production.
Data model integrity
Records, relationships, required fields and constraints. Orphaned references, missing keys and fields that permit values the operation cannot actually accept are findings, not warnings.
Permissions & row-level security
Every role is tested against every surface. The question is not whether the right people can get in — it is whether the wrong people can, and whether a role can reach a row it has no business reaching.
Audit trail coverage
Every record that matters carries attribution and history. Any path that writes or amends a record without leaving a trace is a finding, because that path will eventually be the one in dispute.
Performance under expected load
Tested against the volume the operation will actually reach, not the volume in the demo. Slow is a defect when a driver is standing in the rain waiting for a form to submit.
Deployment readiness
Backups, monitoring, environment separation, rollback, and offline behavior verified end to end — including what happens to a field entry made while the link is down.
Findings, not opinions
Each check produces a pass or a specific finding with the record, role or path attached. Findings are cleared and re-run. There is no override.
Pre-flight is between review and production, and it runs on every change
- STEP 01
Describe
The workflow, in plain language, from the people who run it.
- STEP 02
Build in the Studio
Against the build environment, never against live records.
- STEP 03
Pre-flight
The five checks. Findings cleared and re-run until they pass.
- STEP 04
Launch
Promoted to production with a change history behind it.
A change to a live application takes the same route as the original build. The gate is not a launch ceremony; it is how anything gets into production, including the small fix that looks harmless.
Pre-flight questions
What is pre-flight?
Pre-flight is the quality gate every Genwright application passes before it reaches production. It checks data model integrity, permission and row-level security configuration, audit trail coverage, performance under expected load, and deployment readiness. An application that fails pre-flight does not launch until the findings are cleared.
Can pre-flight be skipped for an urgent change?
No. The gate applies to every promotion, including small fixes and urgent ones. A gate with an override is not a gate, and urgent changes are statistically the ones most likely to carry a permission or audit mistake.
Does pre-flight replace our own security review?
No. Pre-flight checks that the application is correctly configured on the platform. Your security team may still want to review architecture, data handling and access policy, and Genwright supports that review rather than substituting for it.
Who sees the pre-flight results?
The builder and the customer. Results are recorded per application and per promotion, which is also what makes the Genwright Certified Builder credential verifiable — certification is assessed against real pre-flight outcomes rather than a written exam alone.
What happens if an application fails?
It does not promote. Each failure is a specific finding with the affected record, role or path attached, so it can be fixed rather than guessed at. The application is rebuilt or reconfigured and pre-flight is re-run.
Ask us what we would fail.
If you already have an application built somewhere else, describe it on a scoping call. The most useful half hour is often the one that tells you what an inspection would find.