Paper 131: Playable Construction Software — Spatial Submittal Review via Singularity Kernel Materialization

Authors: John Mobley, MASCOM Research Division Date: 2026-03-11 Status: Complete Classification: Novel Construction Technology / Human-Computer Interaction Builds on: WeylandAI (Construction Hardware Estimation), Nine.js (Shader-First Game Engine), Milli DSL (Singularity Kernels)

Abstract

We present a technique for transforming construction document review from a 2D table-scrolling task into a first-person 3D walkthrough where the review process IS the gameplay. WeylandAI extracts architectural data from construction PDFs — door schedules, hardware specifications, room layouts — using Claude Vision AI detection. The extracted data is compiled into a .milli singularity kernel (the same DSL that generates Candlekeep’s library from books.json). Nine.js materializes the kernel as an interactive 3D building where reviewers walk through corridors, click doors, inspect hardware specs in spatial context, and affirm or reject submittals in situ. The submittal review loop (inspect → affirm → reject → annotate) maps directly to game mechanics (interact → collect → discard → journal). We prove this is not metaphor but isomorphism: the construction review state machine and the game interaction state machine are structurally identical.

1. The Problem: Submittal Review Is Broken

Construction submittal review is the process by which a general contractor reviews hardware specifications for a building project — verifying that specified door hardware (closers, hinges, locksets, exit devices, access control) matches the architect’s intent, building codes, and project requirements.

The current process:

1. The hardware supplier generates a door schedule — a table mapping every door in the building to its hardware set
2. The schedule is delivered as a PDF — often 50-200 pages of tables, cut sheets, product data
3. The reviewer scrolls through the PDF, cross-referencing door numbers against hardware groups against spec sections
4. Discrepancies are noted in a separate document — red-lined markups, email threads, spreadsheet annotations
5. The cycle repeats — revised submittals, re-review, re-markup — until approval

What’s wrong:

• No spatial context. Door 104A is a row in a table. The reviewer cannot see where door 104A is in the building, what rooms it connects, how it relates to adjacent doors, whether its hardware makes sense given its location (exit corridor? classroom? mechanical room?).
• Cognitive overhead. The reviewer must maintain a mental model of the building while reading a flat table. This is exactly the wrong direction — the table should be projected INTO the building, not the building compressed into a table.
• Error-prone. Missing a single row in a 2,000-door schedule means a door gets wrong hardware. In healthcare construction, this is a fire/life safety violation. In detention construction, this is an escape risk.
• Slow. A competent hardware consultant reviews 50-100 doors per hour. A 2,000-door project takes 20-40 hours of review across 3-5 review cycles. This is weeks of calendar time.

2. The Solution: Walk the Building

2.1 The Pipeline

Construction PDF
    ↓ WeylandAI (Claude Vision AI extraction)
door_schedule.json + hardware_groups.json + room_layout.json
    ↓ Milli Compiler (building.milli auto-generated)
Singularity Kernel
    ↓ Nine.js (WebGL2 raymarching materialization)
Interactive 3D Building Walkthrough
    ↓ Reviewer walks, clicks, affirms/rejects
Approved Submittal (with spatial annotations)

2.2 Each Step

Step 1: PDF → Structured Data (WeylandAI)

WeylandAI already does this. Claude Vision AI detects door schedule tables in uploaded PDFs, extracts: - Door numbers, locations, sizes - Hardware groups (sets of hardware items per door type) - Finish specifications (satin chrome, dark bronze, etc.) - Fire ratings, accessibility requirements, security levels - Cross-page continuations (BUG-003 fix: detect incomplete entries at page boundaries, match continuations, merge into unified records)

Output: door_schedule.json, hardware_groups.json, room_layout.json

Step 2: Structured Data → Milli Kernel

Same pattern as candlekeep.milli. Candlekeep generates a walkable library from books.json:

# candlekeep.milli — books become interactive 3D objects
books {
    source: books.json
    filter: section == "fiction" and index in 0..5
    mesh: book
    interaction: click -> portal_animation(3.5s) -> enter_world
}

building.milli generates a walkable building from door_schedule.json:

# building.milli — doors become interactive 3D objects
kernel {
    origin: [0, 1.7, 0]    # Eye height
    facing: [0, 0, -1]
    mood: professional
    gravity: 9.81
}

zone corridor_100 {
    bounds: [-2, 0, 0] to [2, 3, 30]
    material: concrete_cmu
    floor: polished_concrete
    ceiling: acoustical_tile height=2.74
    light: fluorescent_2x4 spacing=2.4
}

zone room_104 {
    bounds: [2, 0, 8] to [8, 3, 14]
    material: gypsum_board
    floor: vinyl_composition_tile
    label: "Classroom 104"
}

# Doors from door_schedule.json
doors {
    source: door_schedule.json

    entity door_104A {
        position: [2, 0, 10]
        size: [0.914, 2.134]     # 3'-0" x 7'-0"
        frame: hollow_metal 16ga
        leaf: solid_core_wood
        hardware_group: HW-3
        fire_rating: 45min

        # Hardware items (from hardware_groups.json, group HW-3)
        hardware {
            closer: LCN_4041 { finish: 689, backcheck: true, delayed_action: false }
            hinges: Hager_BB1279 { qty: 3, finish: 26D, bearing: ball }
            lockset: Schlage_ND53PD { function: entrance, finish: 626 }
            door_stop: Ives_WS40 { finish: 628, wall_mount: true }
            seal: Pemko_S88D { type: smoke, perimeter: true }
        }

        # Review state
        submittal_status: pending    # pending | affirmed | rejected | annotated

        # Interaction — THIS IS THE GAMEPLAY
        interaction {
            approach: highlight_frame(#4FC3F7)
            click: open_spec_panel(hardware_group)
            affirm: set_status(affirmed) -> flash_green -> sound(chime)
            reject: set_status(rejected) -> flash_red -> open_annotation
            annotate: open_text_input -> attach_to_door
        }
    }
}

mechanics {
    collision: orthogonal
    movement: tangent speed=4.0
    interaction_distance: 2.0
    boundary: contain
}

hud {
    title: "Building 100 — Hardware Submittal Review"
    font: mono 14px
    crosshair: dot
    status_bar: "Reviewed: 47/312 | Affirmed: 41 | Rejected: 6"
    minimap: floor_plan opacity=0.7
}

Step 3: Milli Kernel → 3D Walkthrough (Nine.js)

Nine.js materializes the kernel exactly as it materializes Candlekeep. The renderer doesn’t know or care whether it’s rendering a fantasy library or a construction building — it sees zones, entities, interactions, mechanics.

The reviewer puts on the walkthrough (browser, no install) and walks through the building. Every door is where it actually is. Click a door → see its hardware spec panel floating in 3D space next to the door. Green checkmark to affirm. Red X to reject with annotation. The minimap shows the floor plan with review status color-coded.

Step 4: Spatial Annotations → Approved Submittal

When the reviewer finishes walking the building, the review state is exported: - Every door’s affirm/reject status - All spatial annotations (attached to specific doors, not to table rows) - A revision summary with door numbers, issues, and screenshots from the walkthrough - The revised door_schedule.json with status fields updated

This loops back to the hardware supplier, who revises and resubmits. The next review cycle starts from the updated kernel — previously affirmed doors stay green, only rejected doors need re-review.

3. The Isomorphism: Game Mechanics = Review Mechanics

This is not a metaphor. The construction review state machine and the game interaction state machine are structurally identical.

3.1 State Machine Mapping

3.2 Formal Proof of Isomorphism

Definition. A review state machine R = (S, Σ, δ, s₀, F) where: - S = {unreviewed, inspecting, affirmed, rejected, annotated} (door states) - Σ = {approach, click, affirm, reject, annotate, dismiss} (reviewer actions) - δ: S × Σ → S (transition function) - s₀ = unreviewed (initial state) - F = {affirmed, rejected} (terminal states for a review cycle)

Definition. A game interaction state machine G = (S’, Σ’, δ’, s₀’, F’) where: - S’ = {idle, targeted, looted, discarded, journaled} (object states) - Σ’ = {approach, interact, collect, discard, note, dismiss} (player actions) - δ’: S’ × Σ’ → S’ (transition function) - s₀’ = idle (initial state) - F’ = {looted, discarded} (terminal states)

Theorem. There exists a bijection φ: S → S’ such that for all s ∈ S and σ ∈ Σ, δ(s, σ) = φ⁻¹(δ’(φ(s), ψ(σ))) where ψ: Σ → Σ’ is the corresponding action mapping.

Proof. The mapping:

φ: unreviewed → idle
   inspecting → targeted
   affirmed   → looted
   rejected   → discarded
   annotated  → journaled

ψ: approach → approach
   click    → interact
   affirm   → collect
   reject   → discard
   annotate → note
   dismiss  → dismiss

Verify all transitions: - δ(unreviewed, approach) = inspecting; δ’(idle, approach) = targeted ✓ - δ(inspecting, click) = inspecting (opens panel); δ’(targeted, interact) = targeted (opens interaction) ✓ - δ(inspecting, affirm) = affirmed; δ’(targeted, collect) = looted ✓ - δ(inspecting, reject) = rejected; δ’(targeted, discard) = discarded ✓ - δ(rejected, annotate) = annotated; δ’(discarded, note) = journaled ✓ - δ(inspecting, dismiss) = unreviewed; δ’(targeted, dismiss) = idle ✓

All transitions commute. The state machines are isomorphic. ∎

Implication: Any game engine that supports the interaction pattern (approach → interact → collect/discard → journal) can serve as a construction review tool with zero modification to the engine’s interaction system. The “game” and the “tool” are the same program.

4. The .milli Auto-Generation Pipeline

4.1 From JSON to Kernel

The compiler takes three JSON files and produces a .milli kernel:

def generate_building_milli(door_schedule, hardware_groups, room_layout):
    """
    door_schedule.json:    [{door_number, room, size, frame, leaf, hw_group, fire_rating, ...}]
    hardware_groups.json:  {HW-1: [{item, manufacturer, model, finish, function}], ...}
    room_layout.json:      [{room_number, name, bounds, material, floor, ceiling}]
    """

    milli = MilliKernel()

    # Generate zones from room layout
    for room in room_layout:
        milli.add_zone(
            name=f"room_{room['number']}",
            bounds=room['bounds'],
            material=room['material'],
            floor=room['floor'],
            ceiling=room['ceiling'],
            label=room['name']
        )

    # Generate door entities from door schedule
    for door in door_schedule:
        hw = hardware_groups[door['hw_group']]
        milli.add_door_entity(
            name=f"door_{door['number']}",
            position=compute_door_position(door, room_layout),
            size=door['size'],
            frame=door['frame'],
            leaf=door['leaf'],
            hardware=hw,
            fire_rating=door['fire_rating'],
            interaction=REVIEW_INTERACTION_TEMPLATE
        )

    # Add navigation, HUD, mechanics
    milli.add_mechanics(CONSTRUCTION_REVIEW_MECHANICS)
    milli.add_hud(door_count=len(door_schedule))

    return milli.compile()

4.2 Precedent: candlekeep.milli

This exact pattern is proven in production. Candlekeep generates a walkable 3D library from books.json:

The .milli DSL already supports every construct needed for construction review. No DSL extension required.

5. Advantages Over Existing Solutions

5.1 vs. PDF Review (Current Standard)

5.2 vs. BIM Software (Revit, Navisworks)

5.3 vs. Construction-Specific Tools (Bluebeam, PlanGrid)

6. The Business Technique: Disguised Software

The deeper insight is a product design principle:

Principle: The best professional software is a game with domain-specific entities.

• Submittal review is a dungeon crawl with doors as loot
• Project management is a city builder with tasks as buildings
• Code review is a puzzle game with functions as pieces
• Financial analysis is a strategy game with investments as units

The “disguise” is not deception — it’s recognition that game interaction patterns (approach, interact, collect, journal, quest) are universal human-computer interaction patterns. Professional software that uses these patterns is more intuitive, faster to learn, and more engaging than software that invents its own interaction vocabulary.

Corollary: The Milli DSL is a universal professional software kernel.

If any domain’s data can be expressed as source: data.json entities in a .milli kernel with appropriate interaction handlers, then Nine.js can render it as a walkable 3D workspace. The .milli DSL doesn’t need to know about construction, or libraries, or anything domain-specific. It knows about zones, entities, interactions, and mechanics. The domain is in the data, not the engine.

6.1 The Conglomerate Advantage

This technique exemplifies the MobCorp conglomerate model (CLAUDE.md: “ventures serve ventures”):

• WeylandAI provides PDF extraction (its commercial product)
• Nine.js provides 3D rendering (the game engine)
• Milli DSL provides world description (the kernel language)
• AuthFor provides reviewer authentication
• VendyAI provides billing (per-project review seats)
• MailGuyAI provides notification (review cycle alerts)

No single venture could deliver this product. The conglomerate delivers it by composition. Each venture is used exactly as designed — no inline auth, no inline payments, no inline email. The construction review product is an emergent capability of the portfolio, not a standalone application.

7. Implementation Roadmap

7.1 Phase 1: PDF → JSON (Complete)

WeylandAI already extracts hardware schedules from PDFs. 3,635 indexed symbols, 0.7s FTS5 search. Known bugs (BUG-001 through BUG-005) are documented and specced for fix. The extraction pipeline is the mature component.

7.2 Phase 2: JSON → .milli (New)

Auto-generate building.milli from extracted JSON. This is a compiler — template .milli structure populated from door_schedule.json + hardware_groups.json + room_layout.json. The template follows candlekeep.milli patterns exactly.

Key engineering: - compute_door_position(): Place doors in walls based on room bounds and door schedules - REVIEW_INTERACTION_TEMPLATE: Standard approach/click/affirm/reject/annotate handlers - Floor-to-floor portal generation for multi-story buildings - Minimap generation from room_layout.json

7.3 Phase 3: .milli → Walkthrough (Existing)

Nine.js already materializes .milli kernels. No modification to the renderer needed — construction entities are entities, construction zones are zones, construction interactions are interactions. The engine is domain-agnostic by design.

7.4 Phase 4: Review State → Export

Export affirm/reject/annotation state back to structured data. Generate revision summary PDF. Feed back into WeylandAI for next review cycle.

8. Revenue Model

TAM: $4.2B global construction software market. Hardware submittal review is a subset — estimated $200M-$500M addressable.

Competitive moat: No one else has a shader-first game engine (Nine.js) + singularity kernel DSL (.milli) + AI construction PDF extraction (WeylandAI) + universal auth/payments/email (AuthFor/VendyAI/MailGuyAI). The stack is unique. Competitors would need to build or acquire 6 products to replicate it.

9. Implications

1. The .milli DSL is a universal professional software platform. Any domain with entities, interactions, and spatial relationships can be rendered as a walkable 3D workspace. Construction is the first vertical. Architecture, facility management, real estate, retail design, event planning are natural extensions.

2. Game engines are underutilized in enterprise software. The game industry has 40 years of interaction design research. Enterprise software ignores all of it. The submittal review walkthrough is more intuitive than any existing construction tool because it uses patterns humans already understand from games.

3. WeylandAI’s extraction pipeline is the bottleneck, not the renderer. Nine.js can render any .milli kernel instantly. The hard problem is getting accurate structured data from construction PDFs. WeylandAI’s Claude Vision pipeline is the competitive advantage — accurate extraction enables everything downstream.

4. The review-as-gameplay isomorphism generalizes. If construction review maps to dungeon crawl, what maps to city builder? To strategy game? To puzzle game? Each mapping is a new product vertical, all running on the same Nine.js + Milli stack.

References

• WeylandAI SRS: mascom_data/consulting/weylandai_com_srs.md
• WeylandAI Bug Specs: mascom_data/consulting/weylandai_com_bugfix_specs.json
• Nine.js: nine.js (57.1KB shader-first game engine)
• Milli DSL: milli.js (singularity kernel parser)
• candlekeep.milli: ventures/mobleybooks_com/candlekeep.milli
• Paper 129: Opcode Genesis (self-extending instruction sets)
• Paper 127: Syncropic Keiretsu Economy (conglomerate model)