feat(inference_format): A2UI Atom Inference Format

[gspencergoog]

Overview

This PR introduces the Atom Inference Format for A2UI—a compact, Lisp-inspired symbolic S-expression representation for generating A2UI v1.0 surface declarations—along with the complete 52-run iterative optimization suite and framework.

The Atom format eliminates verbose node identifiers, explicit JSON schema scaffolding, and line-by-line variable declarations (var = Component(...)), compiling directly into valid A2UI v1.0 JSON payloads via a catalog-agnostic compiler (AtomCompiler).

---

Format Example: Standard A2UI v1.0 JSON vs A2UI Atom

Standard A2UI v1.0 JSON

{
  "version": "v1.0",
  "createSurface": {
    "surfaceId": "main",
    "catalogId": "basic",
    "components": [
      {
        "id": "root",
        "component": "Card",
        "child": "col_1"
      },
      {
        "id": "col_1",
        "component": "Column",
        "children": ["title_1", "desc_1", "btn_1"]
      },
      {
        "id": "title_1",
        "component": "Text",
        "text": "Order Confirmed!",
        "variant": "h2"
      },
      {
        "id": "desc_1",
        "component": "Text",
        "text": "Your package #12345 will arrive tomorrow."
      },
      {
        "id": "btn_1",
        "component": "Button",
        "label": "Track Order",
        "onClick": {
          "name": "trackPackage",
          "context": {
            "orderId": "12345"
          }
        }
      }
    ]
  }
}

Equivalent A2UI Atom S-Expression

<a2ui>
(Card
  (Column
    (Text "Order Confirmed!" :variant "h2")
    "Your package #12345 will arrive tomorrow."
    (Button "Track Order" :onClick (Event "trackPackage" :orderId "12345"))))
</a2ui>

---

Benchmark Results & Key Metrics (Atom vs Raw JSON & Express)

Evaluated across representative UI dataset prompts on google/gemini-3.5-flash:

Metric	Raw A2UI JSON (transport)	Express Format (express)	Atom Format (Run 52 Milestone)	Atom Gain vs Raw JSON	Atom Gain vs Express
Algorithmic Schema Accuracy	100.0%	100.0%	100.0%	0.0%	0.0%
Model-Graded Quality Score	100.0%	100.0%	100.0%	0.0%	0.0%
Code Output Tokens (Median)	882 tok	310 tok	282 tok	-68.0% 🚀	-9.0% ⚡
Input System Prompt & Catalog Tokens	10,482 tok	5,936 tok	4,452 tok	-57.5% 🚀	-25.0% ⚡
Reasoning Tokens (Median)	2,929 tok	2,235 tok	3,890 tok	+32.8%	+74.0% 😢
Composite Score ($S_{\text{opt}}$)	+0.570	+0.570	+0.661	+0.091 Gain	+0.091 Gain

---

Highlights of Optimizations Included

Across 52 automated serial optimization runs:

1. Dynamic Positional Child Resolution (Run 43): Automatically unwraps single-child and multi-child containment slots in AtomCompiler._compile_component.
2. Inline String Child Auto-Wrapping (Run 46): Whitespace-stripping and text component auto-wrapping for primitive string children inside list item containers (_auto_wrap_text_child).
3. Dynamic Event Action Alias Resolution (Run 47): Handled explicit :context S-expression maps and parameterless event context maps (context: {} omission, Run 33).
4. AST Container Slot Property Resolution (Run 35): Accelerated non-reasoning emission throughput by -22.2% (5.83s vs 7.50s).
5. System Prompt & Rule Streamlining (Run 40): Reduced prompt overhead while maintaining 100% catalog agnosticism.

---

Testing & Verification

• Pytest Conformance Suite: 772 passed (100% pass rate).
• Catalog Agnosticism Verification: test_fuzzed_synthetic_catalog_agnosticism passed (100% compliant).
• History Archiving: All 52 run artifact directories (patch.diff, report.md, run_meta.json, results.json) archived under eval/iterative/history/ and indexed in history_summary.md.

[jacobsimionato]

Wow, I'm shocked how relatively simple the prompt is to get quite good inference performance!!

[gspencergoog]

Yes, me too, but it does require a lot of reasoning: that's the downfall of this one, I think.