Human world Machine world meaning structure intent validation natural language ⇄ deterministic model flexibility execution ambiguity strictness
Most software interfaces solve this by asking one side to adapt to the other. Humans fill forms, learn syntax, or work with machine-oriented representations. Machines, on the other hand, increasingly try to infer human intent from unstructured text.
Both approaches are useful, but neither fully solves the boundary problem.
The missing middle
There is another possibility: create a representation that does not belong completely to either side. It should remain comfortable enough for a person to read and edit, while being strict enough for software to parse, validate, transform, and build deterministically.
The goal is to create a shared representation where both can meet.
This is one of the ideas behind Text2Doc. The TEXT layer keeps natural document content readable. SIDECAR carries richer semantic composition. THEME owns presentation. The result is still approachable as text, but the responsibilities are explicit enough for deterministic tools.
Human-readable and machine-validatable
Human-readable and machine-readable are not opposites. The difficult part is choosing a small, clear set of rules that humans can understand without turning the source into a serialization format.
| Human needs | Machine needs |
|---|---|
| Readable narrative | Deterministic grammar |
| Simple authoring | Explicit structure |
| Meaningful organization | Validation |
| Freedom from layout noise | Stable transformation rules |
| Easy review and version control | Reproducible processing |
A representation that satisfies both sides becomes more than a file format. It becomes a contract at the boundary between intent and execution.
The arrival of LLMs changes the boundary
Large language models make this problem more interesting because they operate unusually well on the human side of the boundary. They can understand prose, reorganize information, suggest structure, explain content, and transform documents using natural-language instructions.
But an LLM is probabilistic. It can produce excellent results without providing the deterministic guarantees expected from a compiler, validator, or build system.
T2D
/ \
/ \
Human LLM
\ /
\ /
deterministic
tools
The important idea is that the LLM does not have to become the trusted core. It can communicate through the same explicit representation as the human and the deterministic tooling.
Probabilistic intelligence, deterministic correctness
An LLM can propose a document, rewrite a section, infer an outline, or reconstruct structure from imperfect source material. The result can then pass through a deterministic parser and validator.
Human request
↓
LLM proposes or edits
↓
T2D
↓
parser
↓
validator
↓
VALID / INVALID
↓
deterministic build
This separates two very different responsibilities. Intelligence can remain flexible and probabilistic; correctness remains an engineering property of the toolchain.
T2D as a communication container
This suggests another role for T2D: not only a document source format, but a communication container between a person and an LLM. Instead of exchanging a visually rendered PDF or a representation mixed with layout syntax, both can work on the same constrained textual document.
Human ↓ T2D ↓ LLM ↓ modified T2D ↓ Text2Doc validator ↓ deterministic rendering
The LLM can focus on meaning and transformation. Text2Doc can focus on parsing, structural validity, project semantics, and reproducible output. A human can inspect the same source before and after the change.
Recovery crosses the boundary backwards
Document generation normally moves from structured source toward a rendered result. Recovery asks the opposite question: can a rendered artifact be reconstructed into a valid source representation?
A PDF is a useful example. The PDF contains the rendered result, not necessarily the original semantic source. A recovery tool therefore should not pretend to reproduce the author's original file. It should reconstruct a valid Text2Doc representation from the evidence available in the rendered document.
T2D ── build ──→ rendered document PDF ─ recover ─→ recovered T2D project
For engineering use, the core recovery path should be deterministic: the same input and the same tool version should produce the same recovered representation. An LLM may later help review or improve that recovered document, but it does not need to be part of the trusted recovery core.
Beyond documents
The same boundary problem appears outside documentation. Systems engineering has human intent on one side and machine-processable structure on the other. This is also the motivation behind Text2System: represent architecture and engineering contracts in a form that remains understandable to people while being explicit enough for deterministic analysis and tooling.
| Domain | Shared representation | Purpose |
|---|---|---|
| Documents | T2D | Human narrative ↔ deterministic document processing |
| Systems engineering | T2S | Engineering intent ↔ explicit system model |
The common idea is not a particular syntax. It is the attempt to connect different worlds through a representation that is understandable on both sides and mechanically validatable.
A shared meeting point
AI gives us increasingly capable interpreters of human intent. Deterministic tools give us reliability, validation, repeatability, and execution. Neither replaces the other.
The interesting engineering question is what sits between them.
a representation simple enough for humans and LLMs to understand, but strict enough for machines to trust.
If that boundary is designed well, the representation itself becomes a stable meeting point. Humans can express intent. LLMs can assist with interpretation and transformation. Deterministic tools can validate and execute. Each participant does what it is good at, without asking the others to become something they are not.