Hi HN,

I’ve been experimenting with a small idea around structured outputs for AI systems and wanted to share an early spec to get feedback.

*JSE (JSON Structural Expression)* is a lightweight convention that allows *S-expression style logic to be encoded inside valid JSON*.

The motivation is simple:

Modern AI models can reliably generate JSON. However, JSON is usually treated purely as *data*, while many AI interactions actually need to express *structured intent or computation* (similar to Lisp expressions, DSLs, or ASTs).

Tool calls and MCP solve some of this, but they tend to be *API-specific protocols* rather than a *general structural representation*.

JSE tries to fill that gap with a minimal rule set.

---

### Core idea

In JSE:

* Strings starting with `$` are treated as *symbols* * JSON arrays or objects can represent *S-expressions* * The format remains *100% valid JSON* * Metadata can coexist with expressions * `$quote` allows raw data sections

Conceptually:

> Just as a *group* consists of a *set plus operations defined on it*, > *JSE is an S-expression system applied to JSON data.*

Example:

```json ["$add", 1, 2] ```

Or with metadata:

```json { "$call": "$search", "query": "JSON S-expression", "top_k": 5 } ```

A system that understands JSE can interpret these as structured operations, while systems that don’t can still treat them as ordinary JSON.

---

### Why this might be useful for AI

Many AI systems need to communicate things like:

* reasoning plans * tool pipelines * structured transformations * query languages * DSL-like instructions

Today these are usually implemented as:

* ad-hoc JSON schemas * tool-specific formats * embedded code strings

JSE attempts to provide a *uniform representation for structured intent* that is:

* deterministic * machine interpretable * easy for LLMs to generate * easy for humans to read

Importantly, *JSE does not aim to be a full Lisp or a Turing-complete system*. Each implementation can choose how much of the expression space it supports.

---

### Design constraints

The format tries to satisfy a few practical goals:

* Always valid JSON * Easy for LLMs to generate * Close to S-expression semantics * Extensible for metadata * Lightweight enough to embed in prompts or API responses

---

### Example use cases

Some areas where this might be useful:

AI orchestration systems Agent communication protocols Structured reasoning traces Prompt-embedded DSLs Cross-model communication formats

---

### Spec and repo

Early spec and examples are here:

https://github.com/MarchLiu/jse

The spec is intentionally designed so it can also be *embedded directly inside prompts*, allowing models to generate JSE structures consistently.

---

### Questions I’d love feedback on

* Is there prior art I should study? * Would this be useful compared to JSON Schema / tool calling? * Does the `$symbol` design feel reasonable? * Are there obvious edge cases in the semantics?

Curious to hear thoughts.