Part 2 of Minimum Viable Product Lines and how we designed the Universal Business Language

 Part 2 of Minimum Viable Product Lines and how we designed the Universal Business Language (OASIS-open . org UBL)

Previously I wrote how Minimum Viable Product Lines, MVPL, allows for multiple sets of requirements coded as extensions with a basic common core, and how the Universal Business Language XML format for invoices, orders, delivery advices, and the like, could be called an MVPL approach. Rather than every part (‘element’) of a UBL document being open for extension and restriction (with highly complex implications), a single extension point in every document allows custom extensions to be added without affecting the main standard document.

I wrote how this requires a degree of disciplined governance. When a need is identified for inclusion of data in a document which the standard format does not support, typical MVPL-like questions need to be asked. Is this truly something which the document standard elements do not cover, or cover inadequately? What happens if future versions of UBL (or the usage profile being used) do cater for it adequately? Will the extension need to be replaced with one which allows better use of the new version? 

However, this governance discipline needs to be applied by the UBL designers too. If the core, the main UBL standard documents, are changed to cater for new data, is this going to force people previously including this data in an extension to adopt a new extension format? Can such disruption be avoided? In principle, if an MVPL approach is persisted, might it not be best to minimise changes to the core, the standard, and prefer that new requirements be catered for in extensions? That way they can more easily be adopted experimentally, and more easily discarded if not found to be necessary. The same kinds of questions need to be asked by UBL usage profile designers too. 

As usual, I’ll let AI write a conclusion. 

“In the end, sustaining an MVPL-inspired approach in UBL is a balancing act between stability and evolution. While the core standard must remain dependable and interoperable across industries and borders, extensions provide a practical and lower-risk pathway for innovation, experimentation, and emerging business needs. The responsibility therefore sits not only with implementers, but equally with standards bodies and profile designers to resist unnecessary core changes and to thoughtfully evaluate when new requirements truly merit incorporation into the standard. By maintaining this shared discipline, UBL can continue to evolve in a way that protects long-term compatibility while enabling the flexibility that modern digital business demands.” — ChatGPT 

Minimum Viable Product Lines and how we designed the Universal Business Language

 Minimum Viable Product Lines and how we designed the Universal Business Language (OASIS-open . org UBL)

Minimum Viable Product Lines, MVPL, allows for multiple sets of requirements coded as extensions with a basic common core.  

I happily worked with the designers of the Universal Business Language: An XML format for invoices, orders, delivery advices, and the like, used for electronic business in various parts of the world. We designed it by consensus of technical delegates from various interested countries. We did not give a name to our eventually agreed extension design approach, but it could be called an MVPL approach. It proved to be a challenge to find the best design for how UBL could be truly extensible. 

At first many of us believed the promise of eXtensible Markup Language, XML, that it was truly extensible. Most of us thought this extensibility would come from its schema constraint language called XML Schema Definition language, XSD. The theory was that each discrete data item in the invoice or order document would, by virtue of being written in an XML language, be extensible, by either restricting it or extending it, in variant forms of the invoice or order format. 

XSD did not live up to this hope. We were quickly disappointed in the first version of UBL to find that certain design decisions we had made along the way had precluded the use of the restriction and extension capabilities of the schema language. We needed another way. We eventually adopted an approach very similar to the way software is extended in many applications. We designated one element as an extension point, and designed an extension format which could accommodate custom extensions. All the extensions could be added to the start of the document, without affecting the rest of the document.

In practice it is not completely honest to say an extension does not affect the rest of the document. Care must be taken. An extension that includes something already existing in the main document could have undesirable consequences for those trying to cater for how they receive such a document. For example, does the extension now include monetary amounts which need to be included in the main document monetary totals? Are there now two places where the same data item might be within the extended document? If these contradict, which must be taken as official? If an extension includes data not covered in the main document, what happens if a new version of UBL comes out which includes it? And so on.

The strength of the extensions methodology is that on the whole it allows most use of the main part of the UBL document to keep its integrity. Semantic drift is common with information formats. The system sending the UBL invoice, say, might need to provide some information such as utility usage data, or hours worked, which were not covered in the invoice design for that version of UBL. Some might want to include such data, and be ‘tempted’ to put it in a not entirely appropriate element, thus distorting the meaning of that element. Over time elements might come to be used commonly in ways not intended and contradictory to the official definition of the element. Having an extension point allows data such as utility invoice data or hours worked timesheet data to be included in an invoice in a sensible way, agreed between senders and receivers, without misusing elements of the main standard document or changing the meaning of such elements. 

These are similar principles to those used today in MVPL software architectures. In each case there is a need for good governance, especially during business analysis, but also during software coding. It is a similar discipline to that of a Compliance Office of a company. Somebody needs to ask from day one the necessary questions about whether MVPL rules are being properly applied, and so right through design and coding, and even in day to day use. 

I will let AI write the conclusion.

“In retrospect, the experience of designing UBL demonstrates that true extensibility is less about the technical promise of a language and more about the disciplined application of architectural and governance principles. The extension-point model adopted anticipated what is now recognized as a Minimum Viable Product Line approach: preserving a stable, interoperable core while enabling structured, controlled variation to meet evolving business needs. By separating innovation from standard integrity, UBL was able to support diverse global requirements without fragmenting the standard itself. Ultimately, the success of such approaches depends not only on technical design, but on sustained stewardship, clear governance, and a shared commitment among stakeholders to balance flexibility with consistency.” — ChatGPT

Minimum Viable Product Lines and AI-first coding

Minimum Viable Product Lines, MVPL, is one possible solution to a problem of writing (or even ‘vibe-coding’ using AI) an application which can be adapted to multiple sets of requirements over time. In addition, it is an approach to coding which seeks to accommodate requirements which are experimental and need to be easily discarded should they prove unwanted, without breaking the rest of the code. 

If we find such coding, and the architecture needed for it, somewhat challenging, and perhaps an onerous overhead when under pressure to deliver in haste, we might consider passing this challenge on to an Artificial Intelligence coding system. AI today might already be aware of MVPL, and not need much prompting to self-govern its coding to this approach. 

In short, a basic MVPL design approach involves two kinds of code: There is a reusable core, which caters for multiple extensions. The core code might include the User Interface, UI, together with general business rules, and some kind of code architecture which allows multiple extensions, say, through some kind of API and extension registry. The code for the extension registry might be the only code of the core that needs a change when a new extension is added. This makes it safer, and easier, to remove experimental extensions if they prove unwanted, without affecting the remaining extensions.

This is somewhat simplistic, and idealistic. In practice, a UI might change when a new extension is added or an older extension removed. This might break the core. So the core might need to evolve as extensions are added, but effort needs to be made to keep this evolution to a minimum. That can be a code and design challenge. 

I tried this with AI. I first considered how the code would need to be easily passed to the AI, if AI tooling is kept to a minimum. Simplest is to have the core code in a single file.  This code can then be passed to an AI chat tool with a sufficient context size limit. The AI can code this core. Then the AI can be tasked with coding each extension, and at this time the core can be passed to the AI tool along with instructions to not change the core, but only to code the extension. Bear in mind that a change to the core would need to be compatible with every extension, and tested with each one. 

I found that usually the AI did quite a good job coding the core such that it could have several extensions, but to get success I had to request at least two extensions in addition to the core, just to force the AI to ensure it could code a core which could accommodate multiple extensions. The UI in particular needed to be designed such that it worked with multiple, random, extensions. 

My attempts started with a calculator app, to be run in a browser. HTML and basic Javascript were the AI’s languages of choice. Basic minimal buttons provided an extensible core. Each new extension would add a new operation button, such as a percentage button n% and an inverse button 1/n. Each prompt of the AI can result in different code. Only three attempts were necessary to get a UI which would look reasonably good with just two extension buttons. 

Obviously, a decent, production-ready, commercial quality app might need a lot of human coding and design in addition to, or part replacement of, the AI code, especially for the core. Moreover, the extensions might sometimes be best coded by a human developer. A hybrid approach could work well with this MVPL approach.  

In conclusion, I’ll let AI have the last word.

“Minimum Viable Product Lines offer a pragmatic way to balance experimentation, scalability, and maintainability, particularly in an era where AI-assisted development is becoming increasingly common. By separating a stable, extensible core from modular, disposable extensions, developers can embrace rapid iteration without compromising overall system integrity. While AI can significantly accelerate both core and extension development, practical implementation still benefits from human oversight, architectural discipline, and thoughtful UI design. As AI coding tools continue to evolve, combining MVPL principles with hybrid human-AI collaboration may provide a resilient and flexible path toward building software that can adapt efficiently to changing requirements and emerging ideas.”— ChatGPT 

Using AI to code a Minimum Viable Product Line (MVPL) simple browser app

 Using AI to code a Minimum Viable Product Line (MVPL) simple browser app

First here is how a prompt could be written to an AI tool to prompt it to generate code for a simple browser-based calculator app, according to Minimum Viable Product Line guidelines.

+++++++++++++++++++++++++++++++++++++++++++++++++++++

🚀 Master Prompt — MVPL Two-File Calculator Build

Build a browser-based calculator that demonstrates MVPL (Minimum Viable Product Line) architecture.

IMPORTANT OUTPUT REQUIREMENT:

Return EXACTLY two files:

1. index.html

2. percentage.js

Return them in two clearly labeled code blocks.

Do NOT include explanations or commentary outside the code blocks.

====================================================

ARCHITECTURE GOAL

====================================================

The calculator must be fully functional and usable daily on an iPad.

The system must demonstrate MVPL principles:

- A small, stable core

- Optional removable extensions

- Safe experimentation

- Long-term scalability

====================================================

FILE STRUCTURE REQUIREMENT

====================================================

index.html

→ Contains ALL core calculator logic inline

→ Contains NO extension logic

→ Must load extensions via script tag

percentage.js

→ Contains the ONLY extension

→ Must self-register using the extension registry

No other files are allowed.

====================================================

CORE CALCULATOR FUNCTIONAL REQUIREMENTS

====================================================

Must support:

- Addition

- Subtraction

- Multiplication

- Division

- Decimal numbers

- Clear / reset

- Equals

Must prevent:

- Multiple decimals in same number

- Divide by zero

- Invalid operator sequences

Must support:

- Touch-friendly large buttons

- Keyboard input

- Clean readable display

- Works well on Safari and Chrome on iPad

====================================================

MVPL CORE ARCHITECTURE REQUIREMENTS

====================================================

index.html must include these core modules (inline JavaScript):

1. Core State Management

2. Display Renderer

3. Expression Evaluation Engine

4. Input Controller

5. UI Layout / Button System

6. Extension Registry

The Extension Registry must allow extensions to:

- Register new buttons

- Access state safely

- Trigger display updates

- Access input helpers

The core must expose a structured API object to extensions.

====================================================

CORE PROTECTION REQUIREMENTS

====================================================

The core must be clearly labeled with comments explaining:

- Core must remain stable

- Extensions must not modify core code

- Extensions must use registry API only

- This demonstrates MVPL safety and sustainability

====================================================

EXTENSION REQUIREMENTS

====================================================

Create one extension file named percentage.js.

This extension must:

- Add a % button

- Convert current display value into percentage

- Be implemented ONLY using extension API

- Self-register via ExtensionRegistry.register()

- Include comments explaining it is a removable MVPL extension

====================================================

DESIGN REQUIREMENTS

====================================================

- Clean minimal calculator UI

- Large touch-friendly buttons

- Responsive layout for portrait and landscape

- Dark modern styling

====================================================

CODE QUALITY REQUIREMENTS

====================================================

- Clear readable structure

- Educational MVPL comments explaining boundaries

- Explicitly label:

  - Core code

  - Extension infrastructure

  - Extension implementation

====================================================

OUTPUT FORMAT REQUIREMENT

====================================================

Return output exactly like this:

--- index.html ---

[full code]

--- percentage.js ---

[full code]

No additional text.

+++++++++++++++++++++++++++++++++++++++++++++++++++++

Secondly, after the index.html core has been coded, here is a prompt to accompany this core code, to prompt for a further extension to be added, without changing the core, to add new functionality.

+++++++++++++++++++++++++++++++++++++++++++++++++++++

Now we are in the “repeatable extension generation” MVPL workflow. The goal is to write a prompt that assumes you already have index.html (the core) and only wants to create a new extension (inverse.js) without touching the core, just like the percentage extension.

Here’s a high-quality prompt for this exact purpose:

📝 AI Prompt — Generate inverse.js

You are generating a new MVPL calculator extension.

Assume the core calculator is fully implemented in index.html, including:

- Core state (CoreState)

- Display renderer (DisplayRenderer)

- Input controller (InputController)

- UI layout (UILayout)

- Extension registry (ExtensionRegistry)

RULES:

1. Do NOT modify any core code in index.html.

2. Implement the extension entirely in a separate file named inverse.js.

3. Use only the public extension API provided by ExtensionRegistry.

4. The extension must self-register via ExtensionRegistry.register().

5. Include clear comments explaining that this is a removable MVPL extension.

6. Add a single button labeled "1/x" that replaces the current display value with its numeric inverse (1 / current value).

7. Handle edge cases safely (e.g., if the current value is 0, display "Error").

8. Update both CoreState.displayValue and CoreState.expression as needed.

9. Keep code clean, readable, and consistent with the existing percentage.js extension style.

10. Output exactly one code block containing the full inverse.js content. Do NOT include index.html or any explanations outside the code block.

✅ How to Use It

1. Paste your existing index.html into the prompt as reference or instruction.
2. Append the above prompt.
3. Ask the AI to output the new extension.
4. Save it as inverse.js and load via <script src="inverse.js"></script> in your index.html.

This prompt works well because it:

• Preserves core isolation (MVPL principle)
• Explicitly defines extension API usage
• Handles edge cases
• Is AI-friendly: one extension file output, no extra text