Data Collection

Note

Status: ACTIVE

Access the HYWE Architectural Training Dataset on Hugging Face 🔗

HYWE operates a continuous, deterministic data collection workflow supporting the generation of structural architectural training datasets. This data is entirely sourced from the Teach Panel, HYWE's dedicated spatial data collection interface.

---

1. Data Philosophy

HYWE does not attempt to train generative models to produce spatial geometry "from scratch." Instead, it operates on a much cleaner experimental setup:

Deterministic candidate generation → Measurable features → Human preference data

The dataset is designed to answer a specific, highly constrained question: Given a finite set of deterministic spatial alternatives generated from the exact same programmatic intent, which organizational configurations do humans prefer and why?

This approach enables:

• A constrained experimental setup: Evaluating complete, procedurally generated topologies rather than hallucinating unstructured geometry.
• Lightweight representation: Massive buildings defined in a few kilobytes of Base34 alphanumeric tokens.
• Deterministic regeneration: Guaranteed identical layout recreation on any device without float drifting.
• Procedural variation: A single relational intent node tree evaluated across 24 distinct topology sequences.
• Efficient dataset structuring: Pure, token-dense arrays perfect for future spatial analysis.

---

2. The "Teach" Interface (Input)

Data collection is entirely user-driven through the interactive Teach interface in the HYWE editor. The interface acts as an active preference-collection tool, allowing designers to tag and describe why a specific deterministic variation is successful. The goal is to pair the designer's logical selection with a high-quality natural language description.

(For a detailed guide on how to use the Narrative Generator, Spatial Tags, and Voice Transcription tools, please see the dedicated Teach guide).

---

3. Data Collection Pipeline

When a user clicks "Commit to Dataset," the engine processes the layout using a closed-loop pipeline:

Designer Intent (Tags & Voice) ➔ HYWE Syntax Generation ➔ Cache Retrieval (24 Variations) ➔ Hynteract Ingestion ➔ JSONL Dataset Commit

1. Procedural Extraction: The engine extracts the Base34 syntax and the final intent narrative.
2. Zero-Compute Cache Fetch: Instead of recalculating geometry for all sequences, the Teach engine instantly extracts the 24 pre-computed topological variations directly from the local UI LayoutCache.
3. Hynteract API: The data is fired to the Hynteract serverless endpoint, which structures the raw geometry into token-efficient JSON Lines.

---

4. Dataset Format & Logic (Output)

The finalized records pushed to Hugging Face follow a strict JSONL schema designed for machine learning.

Each record contains three top-level fields:

1. definition: The source-of-truth HYWE Syntax (Base34 rules, node specifications, and constraints).
2. description: The natural language narrative generated in the Teach panel.
3. configuration: An array of container-scoped strings representing the actual layout coordinates.

Sequence Sweeps

Every committed record contains all 24 deterministic sequence variations (e.g. VRCCNE, HRCWWW) for every container, regardless of which sequence the user was actively looking at. This ensures the AI can learn how sequence rules physically alter the exact same topological requirements.

Container-First Payload Format

Each string in the configuration array strictly follows this delimiter-based, Base34 format:

Marker(ID_1;ID_2;...;ID_N | Variation_0 | Variation_1 | ... | Variation_23)

Example: L0(1;1.1 | F,5,H,5 | G,6,I,6 | ...)

• Marker: Identifies the space (L0 for Base Level, N1 for Nest, etc.).
• IDs: A semicolon-separated list of local nodes in the container (e.g. 1;1.1;1.2).
• Positional Variations: Inside each of the 24 variation blocks, the coordinate strings are semicolon-separated and strictly align by index with the IDs listed in the header.
• Base34 Coordinates: Raw hexel spaces are encoded as a flat list of interleaved X,Y coordinates (e.g. F,5,H,5).

Decoding Base34 to Base10

Base34 is a positional numeral system using 34 as the radix. It utilizes a 34-character alphanumeric subset of standard numerals and Latin letters.

Conversion Logic:

1. Character Mapping: Identify the base value of each character based on the specific 34-character alphabet implemented, mapped sequentially from 0 to 33.
2. Positional Weight: For multi-character strings, multiply the value of each character by 34 raised to the power of its positional index (counting from right to left, starting at 0).
   • E.g., 10 → (1 × 34^1) + (0 × 34^0) = 34.
   • E.g., 1A → (1 × 34^1) + (A_value × 34^0).
3. Negative Values: If a coordinate string begins with a - (e.g., -F), calculate the positive value first, then apply the negative sign.

(Note: Most modern programming languages provide built-in parsing functions to handle this conversion automatically).

---

Current Goal

The data collection pipeline is currently active, but it is strictly focused on collection. The goal is to build a robust dataset mapping human preference to deterministic topological outputs. By investigating whether relational programmatic intent, combined with rich ephemeral descriptors and multi-sequence variations, can yield structured human preference data, HYWE provides a scientifically grounded foundation for future spatial analysis. You can track the progress of this data collection ecosystem on our Hugging Face Dataset Card.