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.