The Design Is Approved. Why Is the Developer Still Asking?

What does it actually mean when a design is approved on an ERP project?

Usually, it means the business requirements and the way the system will implement them have been settled. Yet on real projects, developers keep coming back with questions after the design has been signed off.

Take an inventory movement ledger as an example. The day after its design is approved, a developer shows up with three questions:

• "What is the standard name D365 uses for the reference type on an inventory transaction?"
• "Which standard menu item should the Transaction details button open?"
• "When someone looks up a month of inventory transactions, how many seconds is an acceptable response time?"

In the design, each of these is marked "to be confirmed".

If the consultant can't be reached right away, the developer either stops work or falls back on experience and guesses. When a wrong guess surfaces late, both the design and the code have to be reworked.

The problem isn't that a design still has open items. It's that development starts before anyone has decided who will settle them, when, and on what basis.

To close that gap, JGS Consulting added a separate check between design approval and the start of development to its AI-agent-based ERP delivery method.

In this post, we use an inventory movement ledger built on Microsoft Dynamics 365 Finance & Operations (D365 F&O) to show how requirements become a design, and how the items still open are sorted out before development begins.

The conversation above is a reconstructed scenario for illustration. The items and figures from the design and the readiness sheet that follow come from documents produced on a JGS internal project.

Design approval doesn't settle everything

The design stage turns business requirements into concrete system features: what data to show, how pages are laid out, which business rules apply, and what users get as a result.

But not every technical detail can be pinned down at that point. The exact names of standard objects may need to be checked in a development environment. Without enough data, it's hard to set a performance target for an inquiry. Some features can only be finalized once you know they can actually be built.

Trouble starts when these open items are scattered across the design. If nobody knows who should check them, by when, or what work can go ahead in the meantime, the same questions come up again and again during development.

JGS handles this with two separate steps between design and development.

The first is design approval (Gate B), where the consultant and the developer review and approve the content of the design and the implementation approach.

The second is the development readiness check (C0), where the items still open after approval are gathered in one place and either decided, or given a plan for how they will be confirmed and which work has to wait.

Approving a design and confirming that you're ready to start building are two different decisions. By keeping them apart, the JGS method stops uncertainty in the design from flowing straight into development.

How two ledger requirements became a design

Let's walk through the inventory movement ledger built on our internal project.

An inventory movement ledger summarizes stock movements by item over a period. It starts from the opening quantity, adds receipts, subtracts issues, and calculates the closing quantity at the end of the period. With an opening quantity of 100, receipts of 60 and issues of 55, the closing quantity is 105.

The math is simple, but turning it into a working ERP page means making several decisions: which inventory transactions count as receipts and which as issues, how the company's own ledger types are set up, how quantities are totaled across inventory dimensions, and how users get from a total back to the original transactions.

On our internal project, the design was based on 2 requirements and 20 business rules.

The design-stage AI agent takes requirements that have been reviewed and approved internally and drafts the functional and technical designs. It doesn't just restate the requirements; it is set up to record the implementation approach together with the reasoning behind it.

It starts with the solution approach. It checks whether standard D365 F&O features can meet the requirement, then whether setup or a process change would do, and only then whether a report or an extension is needed. The point is to avoid building what doesn't need to be built.

D365 F&O already has standard features for looking up inventory transactions and checking reference documents and transaction status. But this requirement went beyond a transaction list: transactions had to be classified by company-defined ledger types, opening, receipt, issue and closing quantities had to be totaled, and users needed to drill down from a total to the underlying transactions.

After reviewing standard features and reporting options, JGS chose an extension for this requirement, and the design records why standard features alone fell short and what has to be added.

The functional design describes the layout and behavior of a ledger inquiry page and a ledger type setup page, with screen mock-ups. The technical design leaves standard objects unmodified: the totaling logic and the new pages are built as extensions, while transaction details and inventory dimensions reuse the standard features available.

The design also states how the result will be verified. Every business rule is linked to acceptance criteria that cover not only the normal flow but also error cases, boundary conditions and permission-based behavior. The ledger ended up with 50 acceptance criteria.

One principle matters most: nothing that couldn't be verified is treated as settled. If the AI couldn't confirm the name or behavior of a standard object, it marks it "to be confirmed" instead of inventing a plausible name.

An AI drafts the design, and a different AI reviews it

AI agents can produce a draft design quickly. But a document written fast isn't necessarily a document that's right. Requirements can be misread, conditions can be impossible to build, and problems that only show up in production can be missed.

To reduce that risk, JGS separates the working AI that writes the design from the reviewing AI that checks it. The reviewing AI runs on a different model, reads the design and points out problems. It doesn't edit the design; it reports defects and review comments.

At the design stage, it looks in particular for:

• Acceptance criteria that would be hard to judge as pass or fail in a real test
• Logic designed to block an action without a defined error message
• Missing conditions such as legal entity, user permissions or data volume
• Custom development for something that setup could handle

The ledger design went through three rounds of this review. One finding was that the opening-quantity calculation could slow down as transaction history grows. Because the ledger has to compute the opening quantity for whatever period is queried, performance depends on accumulated history and the query conditions. JGS added a performance check to the design so that inquiry time is measured and re-verified with real data.

That's a different kind of review from copy-editing. It catches conditions that would cause trouble in development and testing, and turns them into criteria that can be checked.

The reviewing AI's comments are not the final word, though. The consultant and the developer decide whether the design is fit for purpose and whether to approve it.

17 items to settle before development, and how we handled them

A reviewed and approved design can still have open items. That's where the development readiness check (C0) comes in.

JGS gathers every "to be confirmed" item from across the design onto a single readiness sheet. Each item gets an owner and is recorded together with the AI agent's review note. The owner then either decides the item or sets a deferral plan. Decided items are written back into the design and their "to be confirmed" marker is removed.

Items that can't be decided right away don't automatically stop development. Instead, the plan states who will confirm them, when and how, and which implementation work has to wait until then.

The readiness sheet for the inventory movement ledger listed 17 items. Two of them, including the menu location and the wording of the message shown when a deletion is blocked, were decided and written into the design. The other 15 got deferral plans.

Twelve of the deferred items were technical: the exact names or behavior of standard objects had to be confirmed in the development environment. For example, we needed to check which standard names D365 actually uses for the reference type and status values on inventory transactions. The plan was for the developer to confirm them on the first day of development, and not to build the related totaling logic before that.

The remaining three needed a threshold set outside development work. Response time is the clearest case. Picking a target before measuring processing time against real data volumes and query conditions wouldn't make sense, so the plan was to measure inquiry time first and then set the performance target based on the results.

So the readiness check isn't about having every answer in advance. It's about separating what has been confirmed from what hasn't, and managing how the open items affect development.

In the JGS method, the development agent is designed not to start work until every item has a plan and the owners have approved it.

Improving the method as we apply it

JGS is currently validating its AI-based delivery method on an internal project.

As of October 16, 2026, development of the inventory movement ledger is complete, and it is still in testing. At the same point, all 25 gaps on the internal project had finished development and entered testing, but none had yet received a final pass.

What we describe here is therefore based on design documents and development progress from an internal project, not on results verified in a live customer environment.

The method itself is still evolving. In late September, when the ledger's readiness sheet was written, the design stage couldn't look up standard metadata directly, so most technical checks had to be pushed to the start of development. Since early October, the design agent has queried standard metadata in read-only mode to verify names first, and only what still can't be confirmed goes on to the readiness check. The aim is to leave fewer open items at the start of development and to strengthen the technical evidence recorded in the design.

The ledger in this post was built before the development stage was connected to the method. That's why we cover only the readiness sheet and deferral plans that were actually written, and don't claim that the development agent's controls were applied to this case.

Some procedures are simplified on the internal project while we validate the method. AI agents help prepare and review the material at each stage, but responsibility for approving the design and starting development stays with the consultant and the developer. The point isn't for AI to make the call; it's to prepare the information and the open questions so that experts can.

AI adoption is about more than faster documents

Communication gaps between design and development are nothing new on ERP projects. The design is approved, the developer asks for more explanation, and the consultant feels it has already been covered.

Adding AI that only speeds up writing designs can leave that problem in place, or even make it worse by pushing under-verified designs into development faster.

That's why JGS separates design approval (Gate B) from the development readiness check (C0). The design should explain what to build and how. The readiness sheet should show what has been settled before development and what still needs to be confirmed.

This approach may be especially useful for:

• Implementation and enhancement projects where questions pile up in the first week of development after design sign-off
• Teams that have built on a guess about an unverified standard object
• PMOs that want to use AI while keeping clear ownership of design decisions and the evidence behind approvals

A good design isn't one with no questions left. It's one that keeps track of the questions that remain.

JGS is using AI agents to connect design writing, review and the management of open items, and is testing ways to help developers work from confirmed evidence rather than guesses.

In the next post, we'll look at the AI development agent that works only within the approved design scope, along with the build and code review process.

If you're interested in closing the gap between design and development, or in an AI-based approach to D365 F&O delivery, we'd be glad to talk.

Contact JGS Consulting: https://jgs.ai.kr/support/contact

JGS Consulting Corp. — Designing the future of business.

한국어 버전은 네이버 블로그에서 보실 수 있습니다: https://blog.naver.com/jgsconsulting