BuildSpec Pipeline — Data Flow Diagram

💬 Natural Language Description

"Create a REST API for a book library. Books belong to authors.
Each book has title, isbn (unique), year, pages, status.
Books can be filtered by status. Soft deletes on books."

Developer's intent (ambiguous)

Stage 1

🧠 Planner — Ontology Population

Same Qwen2.5-Coder-7B model, few-shot prompted with 2 in-context examples. Converts NL into structured BuildSpec JSON — populating the domain ontology.

Qwen2.5-Coder-7B Few-shot (2 examples) max_tokens: 6000

// Output: BuildSpec JSON array (explicit domain ontology)
[
  {
    "artifact": "migration", "table": "authors", "columns": [...]
  },
  {
    "artifact": "model", "class": "Book",
    "fillable": ["title", "isbn", "year"],
    "relationships": [{"type": "BelongsTo", "model": "Author"}],
    "has_factory": true, "soft_deletes": true
  },
  {"artifact": "controller", "class": "BookController", ...},
  {"artifact": "resource", "class": "BookResource", ...},
  {"artifact": "form_request", "class": "StoreBookRequest", ...},
  ...
]

BuildSpec JSON (explicit ontology)

Stage 2

🛡 Spec Compiler — Ontological Reasoning

Deterministic validation: checks concept completeness, constraint satisfaction, cross-reference integrity. Catches errors before the expensive generation step.

Deterministic < 1ms per spec spec_compiler.py

✘ rules['venue_id'] contains 'required_on_post'.
Use conditional_rules dict instead.

→

✔ Fix the spec, not the model.
Deterministic fix. Retry in <1ms.

✓ Required fields ✓ Conditional tokens ✓ Schema validation ✓ Defaults + paths

Validated specs (ontology-verified)

Stage 3

⚙ Code Generator — Ontology-to-Code

LoRA-adapted model transforms each validated spec into a complete PHP file. The model only decides how to generate — what to generate is fixed by the ontology.

Qwen2.5-Coder-7B + LoRA adapters_spec_v4 ~30s per file 49 training examples

// Input: one BuildSpec → Output: one PHP file

<?php
namespace App\Models;

use Illuminate\Database\Eloquent\Factories\HasFactory;
use Illuminate\Database\Eloquent\Model;
use Illuminate\Database\Eloquent\SoftDeletes;
use Illuminate\Database\Eloquent\Relations\BelongsTo;

class Book extends Model
{
    use HasFactory, SoftDeletes;

    protected $fillable = ['title', 'isbn', 'year', ...];

    public function author(): BelongsTo
    {
        return $this->belongsTo(Author::class);
    }
}

Raw PHP files

Stage 4

✅ Syntax Validation

php -l on every generated file. Catches syntax errors before the files reach the Laravel project.

php -l 26/26 valid (100%)

Syntax-validated PHP

📦 Laravel Application Files

◆ create_books_table.php

◆ create_authors_table.php

◆ Book.php

◆ Author.php

◆ BookController.php

◆ AuthorController.php

◆ BookResource.php

◆ AuthorResource.php

◆ StoreBookRequest.php

◆ BookApiTest.php

20/20 Pest tests pass Ready for Laravel 13.x

The Ontological Gap

Semantic hallucinations occur when the model fills prompt gaps from its own pretraining ontology

🤖 Model's Implicit Ontology

Learned from pretraining on millions of PHP files

❌ "Models usually have a user() relationship"
❌ "Validation includes 'optional'"
❌ "Controllers use closure-based eager loading"
❌ "Use $request->user()->create()"
❌ "Resources need ->withHttpStatus()"

👨‍💻 Developer's Intended Ontology

Application-specific, made explicit via BuildSpec

✔ "Book belongsTo Author (not User)"
✔ "Validation uses 'nullable'"
✔ "Simple array eager loading: ['author']"
✔ "Book::create($request->validated())"
✔ "response()->json(new BookResource(...))"

↑ Without BuildSpec: the model fills gaps from its own ontology → hallucinations

↓ With BuildSpec: developer's ontology is explicit and complete → no gaps to fill