Requirements become business objects, not screens
A business asks for a system to manage supplier onboarding, and the first document produced is a list of screens. There is a page for registration, a page for review, a page for approval, and a page for reporting. Six weeks later there is a working set of screens and no agreed answer to what a supplier record is, whether the same supplier can appear twice, or who may see the tax document.
The alternative starts from the objects. A supplier, an application, a document, a review decision, a rejection reason. Each has a definition, an identifier, a lifecycle and an owner. Forms become a consequence of the object model rather than its starting point, and the question that follows every requirement can be asked: which object does this touch, and what does it mean for the object to be in that state?
The data model is the contract with the business
A structured application rests on a model both sides can read. The engineering side builds to it; the business side reviews it. That review only works if the model is expressed in business terms rather than in tables, so the artefact under discussion is a set of definitions, relationships and constraints, and the system is generated against those.
What the model must also carry is the part most specifications omit: identifiers that mean the same thing across every system the application touches, because an application that writes a record other systems cannot reconcile has moved the problem rather than solved it.
Permissions belong in the design, not in a later setting
Access control is usually deferred, and deferral is expensive. If the model does not say which roles may see which attributes of an object, every screen invents its own rule and every report exports a wider set of fields than the business intended.
A better approach makes permission a property of the object model and of the action performed, so a read, a write and an approval each carry their own allowed roles and field masking. The same model then drives the interface, the integration and the audit record, which removes the possibility of a path that was never given a rule. It also makes the permission boundary testable rather than merely described.
Workflow is part of the model, not a separate system
Many application estates contain a records system, a workflow engine and a reporting tool, configured separately and reconciled by hand. Each encodes a version of the process, and the three versions disagree as soon as anything changes.
When the states, the transitions, the approvers and the timers are expressed as part of the business model, the application can be generated from one description and reporting can be answered from the same records. An exception then becomes a first-class state rather than a database row somebody has to remember to look for, and the design of those states is the subject of designing AI workflows with human approval and exception handling.
Reporting should read the model rather than rebuild it
Reporting built separately from the operational model is where definitions quietly diverge. Two reports show two different numbers for the same measure, and reconciling them becomes somebody's job. If the operational model is the source, a report is a question asked against it, and the definitions are the ones the business already agreed to. How reporting moves from periodic packs to continuous operational information is treated in from monthly reports to continuous operational intelligence.
Test the application, not the prompt
A generated application can be tested in the ordinary way, and this is one of the strongest arguments for structuring work this way. Each rule in the model has expected outcomes a business owner can confirm. Each transition has a precondition that can be exercised. Each permission has a role that should succeed and a role that should fail. These are conventional acceptance tests, and they run in seconds.
The test set is therefore also the documentation, the demonstration to the business and the regression check when the model changes. It replaces the familiar alternative, where a change to a prompt is reviewed by reading the prompt and a change to a system is reviewed by running the demonstration and hoping. A model expressed as rules and states can be diffed by someone who does not write code.
A sequence for delivering the first version
- Collect the business objects, their definitions and their owners, and agree the identifiers that must mean the same thing in every system.
- Define the lifecycle states and transitions of one object, including the exception states, and get them agreed before any interface work.
- Set out the roles, the permitted actions and the masking rules against that model, so access control is designed rather than configured.
- Write the acceptance tests for the rules and the transitions, and let the business confirm the expected outcomes.
- Deliver the first version as a working slice of the model with its reporting, review what users actually did, and change the model rather than accumulating special cases in the interface.
The measures that show the approach working are the number of definitions still in dispute, the count of rules expressed outside the model, the time from a stated requirement to a working slice, and the number of reports whose measures disagree with each other.
The sequence that produces those objects in the first place is in how to map a business process before building an AI agent. The delivery discipline for this kind of application is set out in business application engineering, and what happens to the application after the team that built it moves on is addressed in making enterprise AI maintainable after the pilot.