How the WeebPal Development Framework works

By Hai Nguyen · WeebPal Technology Corporation · 26/06/2026

This is a closer look at the framework itself: the working process it is built around, how a project moves from raw input to a delivered result, what The Lodestar is, how the development documents are organised, who does what, and how the model scales. The scope question (L5 × S4) is covered separately; here the focus is the mechanics.

The working process

Before AI enters the picture, a serious project already runs through six steps:

1. Gather requirements, then analyse them.
2. Build a prototype to check understanding with the client.
3. Design the architecture.
4. Break the work into epics, stories, and tasks.
5. Assign that work to people.
6. Put a quality-control process in place: correct, consistent, safe, secure, reusable.

None of those six steps is complete or correct by default:

• Requirements gathering misses things, so it needs a way to recover.
• Analysis is always short in places.
• A prototype only shows intent; it gets corrected as gaps appear.
• An architecture is only as good as the current infrastructure, tooling, and budget allow.
• Epics, stories, and tasks are never fully specified up front.
• People write bugs.

Because every step can be wrong, the project needs a process to manage and check quality. AI does not remove that need. It works inside the same process: it does more of the production, and the management and review stay where they were.

Working with AI

• Do not expect bug-free code from AI.
• AI's job is to solve each problem it is given.
• The person leading the work is responsible for turning that output into what the project needs.
• AI needs enough context and standards (Project Input and The Lodestar) to head the right way.
• Break the work into pieces small and clear enough for AI to handle one at a time.
• Review every output and iterate until it meets the requirement.

The framework is how those points are put into practice.

One diagram, three flows

The model fits on one diagram. It reads more easily as three flows laid over each other.

• Build flow (left to right): Project Input → Project Documents → Results / Code. The pipeline that turns requirements into working software.
• Command chain (top to bottom): Client → Project Supreme Commander → Corps Commander → AI Soldiers. Each layer sets direction for, and checks, the layer below.
• Standards (the constant): The Lodestar is authored and improved by the Project Supreme Commander, and it guides the AI Soldiers. Everything else references it.

The rest of this article takes those flows one at a time.

The Lodestar: the standards at the centre

The Lodestar is the WDF Guidelines: a reusable core of standards and instructions that is not tied to any single project. It is the part the rest of the work steers by, which is why it sits at the centre of the model.

Two things define it:

• One owner. Only the Project Supreme Commander maintains it. It needs the most architectural depth, and a shared standard stops being a standard if everyone edits it ad hoc.
• Create, then improve. It is authored once, then refined as projects expose gaps. Because it is shared across projects, improving it on one project carries over to the rest.

From input to documents

Project Input is whatever states the requirement: text, docx, xlsx, pdf, image, diagram, mindmap — whatever the client provides. It is raw and incomplete by nature.

The development documents (Docs) are what you get when The Lodestar is applied to that input. The Lodestar tells AI how to turn raw input into a structured set of documents; those documents then become the technical reference AI follows while building.

In short: Docs = The Lodestar applied to Project Input.

The development documents: A to Z

The framework defines fourteen document layers, named A to Z. A project builds the set it needs: a larger build uses the full range; a smaller one can simplify to a subset such as A–F.

• A · Project Info — AI config, project overview, project context, prompt catalog, framework primer.
• B · Requirement — project and technical requirements, features, business workflows, acceptance criteria.
• C · Design — diagrams, architecture decisions, entities, modules, APIs, sitemap.
• D · Development — conventions, epics, stories, tasks, code map.
• E · Quality — test strategy, test results, traceability, solutions, performance results.
• F · Release — deployment, release checklist, changelog, release comms.
• G · Governance — ADRs, risk register, blockers, change requests.
• H · Operations — incidents, runbooks, dependencies.
• I · External — API spec, SDK docs, webhooks.
• K · Knowledge — glossary, conventions, patterns, lessons.
• M · Maintenance — workflows, decision trees, monitoring.
• S · System — services, contracts, topology.
• U · User Guide — user guide, getting started, FAQ.
• Z · Reviews — coverage audits, build readiness, go / no-go.

C-Design and D-Development carry the most weight on most projects — they hold the architecture decisions and the work breakdown that decide the quality of the result.

The command chain

People are organised into layers. Direction flows down; review flows up; people stay accountable at every level.

• Client (Business Owner). Owns the business need. Provides Project Input, clarifies requirements, accepts the result.
• Project Supreme Commander (Solution Architect). Designs the architecture and the solution. Owns The Lodestar, splits the work, coordinates.
• Corps Commander (Dev, BA, QC, DevOps). Reviews and reconciles what AI produces, by discipline. Catches what is wrong or missing and holds the standard.
• AI Soldiers (implementation). Do the implementation work, guided by The Lodestar and the documents.

AI Soldiers do the building, but carry no accountability — they do the work, people are responsible for it.

The review loop

Output is not accepted on the first pass. It moves through a loop:

1. AI produces against the documents.
2. The Corps Commander checks it against the documents and The Lodestar.
3. Anything wrong or missing goes back for correction.
4. Repeat until it meets the requirement.

When a gap points to a weak standard rather than a one-off mistake, it feeds back into The Lodestar as an improvement — so the same gap does not return on the next project.

What the lead does

The Project Supreme Commander is the person running the model.

• Role. Leads the project as solution architect or tech lead. Sets direction and standards; AI implements.
• Responsibility. Turns raw AI output into what the project needs. Keeps the result correct, consistent, safe, secure, and reusable. Decides, and is accountable for the outcome.
• Way of working. Owns The Lodestar. Splits the work into epics, stories, and tasks. Reviews each output. Iterates until it meets the requirement.

A single pass through the model

One feature, end to end:

1. The client provides the requirement as Project Input.
2. Guided by The Lodestar, AI drafts the C-Design and D-Development documents; the Corps Commander reviews them.
3. AI Soldiers implement against those documents.
4. The Corps Commander reviews the result and sends back anything that misses the standard.
5. Once it passes, the completed work goes to the Client to accept.

The same loop runs at every step: produce, check against the documents and The Lodestar, correct, repeat.

How it scales

A small number of people set direction and review the work; AI handles most of the implementation. Headcount stays low. What matters is where people put their attention, not how many of them there are.

WeebPal Development Framework · a method for delivering software projects with AI.