X3D LoRA Development Environment (XLDE) — Back-of-Envelope Design Specification v0.1
Introduction
Submitted for consideration to the Web3D Consortium AI Working Group by Len Bullard per Claude Sonata and ChatGPT. This is a draft of a work item for creating a web application to support creation of a a standards conformant X3D LoRA for inclusion as a maintainable and standards conformant deliverable.
Status: Draft for discussion with the Web3D Consortium AI Working Group.
Synthesizes: "Requirements for Creating An X3D LoRA" and "From
Standard to Expertise" (aiartistinprocess.blogspot.com, July 2026), Don
Brutzman's resource assessment (email, July 2026), and MCCF's Day 63/64
specs, seeds, and proto library as a candidate data contribution.
Scope note: This document estimates two separate deliverables
the source material sometimes conflates: (1) the XLDE web platform
itself, and (2) the X3D LoRA(s) it exists to produce. They run on
different timelines with overlapping but distinct skills, and are best
planned as parallel tracks, not sequential phases — see Section 5.
References:
https://aiartistinprocess.blogspot.com/2026/07/from-standard-to-expertise-official-x3d.html
https://aiartistinprocess.blogspot.com/2026/07/requirements-for-creating-x3d-lora.html
Mockups:
1. What's being asked, briefly
The two source posts converge on one design: rather than one person hand-writing thousands of prompt/response pairs, build a collaborative platform (XLDE) that:
- treats the X3D XML object model (schema, specs, examples, conformance tests) as the single source of truth,
- auto-generates draft training material (docs, Q&A pairs, code completions, and — critically — negative examples via controlled spec violations) from that source,
- routes generated drafts through human review (Domain Expert → Editor → Reviewer → Maintainer roles) rather than requiring volunteers to invent examples from scratch,
- captures the human knowledge that can't be auto-generated (design rationale, browser quirks, committee history) in structured fields per X3D node,
- produces a versioned, reproducible corpus as the primary standards artifact — the trained adapter(s) become a downstream, re-trainable output of that corpus, not the deliverable itself.
That's the target. Everything below is how to actually build it without over-scoping a volunteer effort.
2. Asset inventory — what's immediately available (per Don's list)
| Source | Format | Assessment |
|---|---|---|
| X3D Example Archives (web3d.org) | XML encoding, thousands of scenes | High value, canonical. Already under nightly CI validation (Jenkins + the X3D Validator's DTD/Schema/Schematron stack) — meaning most of this corpus is already graded. This is a huge head start: correctness labeling that most ML projects have to build from scratch already exists here. |
| Web3D Examples (web3d.org/example) | XML encoding | Complementary catalog, same trust level as above. |
| X_ITE bundled examples (create3000.github.io) | XML encoding, X_ITE-specific | Valuable specifically for runtime/SAI idioms — ROUTE wiring, live field access patterns — the exact category where MCCF hit real bugs this month (see Section 3). Worth weighting toward this source for any "SAI Programming" focused LoRA. |
| Castle Engine model archives | Mostly ClassicVRML (.x3dv) / VRML (.wrl) | Lower priority for an XML-encoding-focused LoRA — but not worthless. See the irony noted below. |
| FreeWRL examples | Mixed encodings | Same caveat as Castle. |
| X3DOM examples | HTML-embedded, non-standard lowercase syntax | Explicitly excluded by Don. This is a genuinely important signal: a training pipeline needs a reject list as much as an approve list, or the LoRA will learn to hedge between two incompatible casing conventions. |
The irony worth naming to the Working Group directly: the single largest documented bug in MCCF's proto-conversion work this month was a classic-encoding-vs-XML-encoding confusion (EXTERNPROTO used where ExternProtoDeclare was required) — made by a frontier model, not a small local one. Don's own exclusion of X3DOM for the identical class of encoding confusion is the same problem from the other direction. Encoding-boundary confusion is probably the single highest-value error category for this LoRA to specifically target, and it's cheap to generate adversarial training pairs for: take any correct XML-encoded example, deliberately substitute classic-encoding syntax, label it wrong, explain why.
3. What MCCF specifically adds — not duplicative of the above
The archives above are overwhelmingly correct-example corpus. What they structurally can't provide, and what Appendix A of the second post explicitly flags as the hardest thing to generate automatically ("design rationale... cannot be generated automatically"), is:
- Documented wrong→right pairs with reasoning, produced organically through real debugging, not synthesized:
EXTERNPROTOvsExternProtoDeclare(classic vs. XML encoding)SFInt32holding a fractional value vs.SFFloat(a real error from a local Llama test this month)- Direct property access vs.
.getField(name).toString()for reading live X_ITE SAI state (three failed attempts before the correct pattern was found — a genuinely rare, hard-won piece of runtime-specific knowledge)
- Design-rationale documentation at decision-granularity, not just node-reference level: why per-avatar cameras got converted to PROTOs while shared free-camera rigs deliberately didn't (a real architectural judgment call with a documented wrong turn avoided), why a naming convention was adopted (traced directly to a bug it prevents), why orientation composition used nested Transforms instead of a hand-derived rotation (a documented risk-avoidance decision).
- A non-trivial, production-adjacent application domain (avatar-driven scenes with camera/dialog/behavioral-field logic) at a level of PROTO-composition complexity — parented cameras, IS-wired static ROUTEs, EXTERNPROTO libraries — that skews rarer in tutorial-oriented archives.
- A pre-existing, dated bug log — exactly the "common implementation mistakes" Appendix A asks Domain Experts to write by hand. MCCF already has several real entries, for free.
None of this is large in volume. It's disproportionately valuable in kind — closer to the "common mistakes / FAQ / historical discussion" fields in Appendix A's per-node Object Dashboard than to the bulk "Examples" field, which the existing archives already cover well.
4. Platform architecture (back-of-envelope)
Appendix A's architecture diagram is sound; the risk is over-building it. Recommended concrete shape:
Source of truth: X3D XML Schema/DTD + spec + example archives
│
┌─────────────────────┼─────────────────────┐
│ │ │
XML Object Model Specifications Examples
│ │ │
└─────────────────────┼─────────────────────┘
│
Knowledge Generation scripts (offline jobs)
— draft docs, Q&A pairs, code-completion pairs
— negative examples via controlled violations
│
┌─────────────────────┼─────────────────────┐
│ │ │
Draft Docs Draft Training Corpus Draft Test Corpus
│ │ │
└─────────────────────┼─────────────────────┘
│
Review Portal (the actual web app)
│
Approved Corpus (git-committed)
│
LoRA training run (separate, offline)
│
Benchmark grading — reuses the existing
X3D Validator DTD/Schema/Schematron stack,
plus headless X_ITE load-testing
│
Official versioned release
Key simplifying decision: content lives in git, not a bespoke database.
One file per X3D node/PROTO pattern (Markdown + YAML frontmatter), containing the Object Dashboard's sections — Description, Fields, Examples, Common Mistakes, FAQ, Implementation Notes, Historical Discussion, Benchmark Questions, Generated Training Examples, Review Status. This gets three of Appendix A's design principles for free:
- "Every contribution is version controlled" → it's git.
- "Every contribution is attributable" → commit authorship / PR review.
- "AI training artifacts are reproducible from the underlying knowledge base" → the corpus is the repo state at a tag.
The web app becomes a friendly skin over GitHub, not a second source of truth: renders the Object Dashboard nicely, generates and assigns review tasks, shows diffs, and triggers the offline jobs (generation, training, benchmarking) — all of which read/write the same repo via the GitHub API. Auth via GitHub OAuth. This avoids the two-databases-drifting-apart failure mode that kills most "documentation + AI corpus" projects.
Reuse, don't rebuild, the grading engine. The X3D Validator's DTD/Schema/Schematron stack already exists and is actively maintained (nightly CI on the example archives, per Don). Wrap it as an automated grading service for both (a) confirming generated negative examples actually fail the way they're supposed to, and (b) scoring a trained LoRA's output on the benchmark suite. For the strongest possible pass signal, add a headless X_ITE load-test tier — schema-valid is necessary but not sufficient (today's actual bug, EXTERNPROTO-as-element-name, is technically well-formed XML; only X3D-aware validation or a real load attempt catches it).
5. Effort estimates
5a. The X3D LoRA task itself
The first blog post already contains a grounded estimate from the same conversation; reproduced here as the baseline, since re-deriving it would be redundant:
| Phase | Estimate |
|---|---|
| Learn the training tools | 1–2 weeks |
| Build first dataset | 2–6 weeks |
| Run first LoRA (GPU time) | ~1 day |
| Evaluate and refine | 2–6 weeks |
| Reach a "useful" X3D assistant | 2–4 months |
| Reach a polished, community-quality release | 6–12 months |
Where MCCF's contribution compresses this: the "build first dataset" phase is the bottleneck the whole plan is designed around, and it's exactly where Section 3's material helps most — not by adding volume, but by seeding the highest-value, hardest-to-generate category (documented mistakes + rationale) before the community-generation pipeline exists to produce it at scale.
Where a volunteer/committee model changes the shape, not just the total: Appendix A's role-based structure (Domain Expert / Editor / Reviewer / Maintainer) parallelizes dataset-building across people rather than one person's serial 2–6 weeks. Total effort-hours may be similar or higher; wall-clock time to a usable dataset likely shortens, provided the Working Group can actually staff those roles — see Section 6.
5b. The web platform (XLDE) — not estimated in either source post
Given the git-backed, thin-UI-over-GitHub design in Section 4 (deliberately scoped down from a bespoke full-stack app):
| Milestone | Scope | Rough estimate (1 competent dev, part-time) |
|---|---|---|
| MVP | Object Dashboard rendering, basic task list, GitHub-backed read/write, no auto-generation yet | 4–8 weeks |
| v1 | Adds Knowledge Generation Engine (auto-drafted docs/examples/negative-examples), review/approval workflow, validator integration | +2–4 months |
| Full Appendix A vision | AI-assisted review (LoRA-in-the-loop), intelligent task generation, full multi-role permissions | +3–6 months beyond v1 |
Honesty check on these numbers: these are genuinely rough — no team is assembled, no stack is confirmed, and hosting/budget ownership (Web3D infrastructure? a member org's? GitHub Pages plus serverless functions?) is undecided. Treat as an order-of-magnitude starting point for a pitch conversation, not a committed estimate.
6. Sequencing recommendation
Run platform and dataset work in parallel, not platform-first. An MVP (Section 5b, week 4–8) can start hosting and organizing material immediately — including hand-triaging Don's existing archives and seeding the first mistake/rationale entries from MCCF's material — well before the Knowledge Generation Engine or any auto-drafting exists. Waiting for the "real" platform before starting content work wastes the exact months it would take to build it.
7. Open questions to raise with the Working Group before this becomes a committee document
- Data licensing/IP for pooled contributions across member organizations — a governance question the technical design can't resolve on its own, and exactly the kind of thing a standards body is positioned to actually settle.
- Hosting and budget ownership for the platform itself.
- Realistic staffing for the four contributor roles — Appendix A assumes a functioning volunteer community; that's a bootstrapping risk independent of the technical design.
- One LoRA or several (the first post's "X3D Core / PROTO Design / SAI Programming / CAD / HAnim / GeoSpatial / DIS" split) — affects both the platform's content organization (per-component corpora) and the effort table above (more adapters means more, individually smaller, training/eval cycles).
- Release cadence tied to spec versions (4.0 → 4.1 → 4.3...) — worth deciding early since it shapes how the git-tag-as-corpus-version model in Section 4 actually gets used.
Summary and Statement
A standards body building the tooling for its own community to make LoRAs, rather than waiting for someone else to do it to them, is a genuinely different posture than most of the current AI discourse offers people. It's opt-in, it's community-scoped, and it produces something concrete — a trained artifact and the skills to make another one — instead of just a policy position.
Whether it's X3D or some other domain with sparse training data, "here's how your community stays legible to these systems on your own terms" is a more actionable message than most of what's being shouted from either side of the replacement-anxiety debate right now. Domain-specific tooling partnerships are a real and current thing, not a hypothetical And that's a good thing for everyone.
Prepared as a discussion draft, not a committed proposal. Numbers throughout are back-of-envelope by design — the point is a concrete enough starting shape for the Working Group to argue with, not a finished plan. Submitted by Len Bullard per Claude Sonata and ChatGPT
Comments
Post a Comment