Text Defined Systems Engineering

Software has source code. Why doesn’t it have schematics?

Text2System is an open, human-readable language for defining engineered systems through a structured and verifiable process. Text2System turns system engineering intent into a canonical, verifiable, and projectable system definition. System intent, structure, boundaries, contracts, and constraints are progressively captured in one canonical plain-text definition.

Text2System brings software engineering the equivalent of electrical schematics: a system definition that can be parsed, built, validated, projected, and recovered from existing source into documentation, diagrams, and implementation artifacts — while algorithms and implementation details remain in their appropriate languages, such as VHDL, SystemVerilog, Rust, Zig, C, C++, or Python.

T2S defines what a system is.

Programming languages define how it behaves.

hello_system.t2s
Hello System

  system:
    id: HelloSystem

  module:
    id: Hello

  function:
    id: say_hello

  relationship:
    subject: HelloSystem
    predicate: contains
    object: Hello

  relationship:
    subject: Hello
    predicate: contains
    object: say_hello
Strict by design

One source. Two layers. Everything else is a projection.

T2S combines human-readable narrative with machine-readable semantics. Together they define the system; documentation, diagrams, generated boundaries, and other artifacts are projections of that definition.

Narrative

Readable by engineers

Architecture rationale, design intent, explanations, requirements context, and documentation remain ordinary readable text.

Semantics

Deterministic system definition

Systems, modules, interfaces, functions, types, relationships, tests, packages, and deployments are declared explicitly.

Projectors

Artifacts without redefining the system

Documentation, system graphs, Rust, Zig, Python, C ABI, validation reports, and other outputs are projections of one model.

Processing model

From plain text to system artifacts.

The canonical model sits between T2S source syntax and target-specific output.

01T2S Source
02Narrative + Semantic AST
03Semantic Builder
04Canonical System Model
05Projector
06Artifacts
What T2S defines

System structure and contracts

  • Systems and subsystems
  • Modules
  • Interfaces
  • Functions
  • Types
  • Constants
  • Errors
  • Configurations
  • Requirements
  • Constraints
  • Tests
  • Relationships
  • Packages
  • Deployments
How T2S is different

Text is the canonical system definition

  • UML can become a projected view instead of the source of truth
  • Traditional MBSE models are replaced by a plain-text canonical definition
  • Diagrams are generated views, not the authoritative model
  • Documentation is projected from the same system definition
  • Programming languages remain responsible for algorithms and behavior
  • Implementation intelligence stays in the target language and toolchain
Documentation

Language definition and practical workflows.

Read the normative T2S language specification or follow the Text2System engineering workflow from forward engineering through architecture recovery, source traceability, and editor integration.

T2S language

Read the language specification

The normative definition of Text2System syntax, semantics, system elements, relationships, and validation rules.

Engineering workflow

Use the Text2System engineering tool

Validation, projection, implementation, Rust architecture recovery, graph exploration, and source traceability through one public tool.

One model

Source, model, projections

The documentation follows the same boundary as the tools: one canonical system model between source-specific input and target-specific projections.

Downloads

Text2System engineering tool

One public tool for T2S parsing, validation, modeling, analysis, projection, implementation, architecture recovery, graph exploration, and Language Server integration.

Engineering tool · Windows

x86_64 GNU

Standalone Text2System engineering tool for 64-bit Windows.

File: text2system-v2026.9.6-1040-x86_64-pc-windows-gnu.zip

Engineering tool · macOS

Apple Silicon

Native Text2System engineering tool for Apple Silicon Macs.

File: text2system-v2026.9.6-1040-aarch64-apple-darwin.tar.gz

Engineering tool · GNU/Linux

x86_64 musl

Portable statically linked Text2System engineering tool for 64-bit GNU/Linux.

File: text2system-v2026.9.6-1040-x86_64-unknown-linux-musl.tar.gz

Editor · VS Code

Text2System extension

VS Code integration backed by the same Text2System engineering tool through text2system lsp.

File: text2system-2026.9.6.vsix

Quick start

Install. Inspect. Initialize. Project.

Start with the engineering tool help, then run the complete Rust reference workflow: initialize a T2S project, validate the system definition, project the Rust boundary and system graph, create the implementation, and verify it with Cargo.

terminal · macOS Apple Silicon
# unpack Text2System
tar -xzf text2system-v2026.9.6-1040-aarch64-apple-darwin.tar.gz
xattr -d com.apple.quarantine text2system

# inspect the available commands
./text2system --help

# editor integration is exposed by the same tool
./text2system lsp --help

# create a Rust-oriented T2S project
./text2system init rust hello_system
cd hello_system

# validate the T2S system definition
../text2system validate hello_system.t2s

# project the T2S system model to Rust
../text2system project rust

# project the same canonical model as a system graph
../text2system project graph

# create/update the Rust implementation
../text2system implement rust

# verify the projected Rust boundary
cargo check --manifest-path projected/rust/Cargo.toml

# run the implementation
cargo run --manifest-path implementation/rust/Cargo.toml
Architecture Recovery

Recover the system model from existing Rust.

Text2System can analyze a Rust crate without invoking the Rust compiler, recover structural facts, reconstruct a Canonical System Model, and project that recovered model as text or native SVG.

  • Compiler-independent Rust source analysis
  • Crates, modules, structs, enums, traits, implementations, and free functions
  • System- and module-owned function recovery
  • Canonical model JSON plus recovery evidence
  • Recovered model graph projection
terminal
# recover architecture from an existing Rust crate
text2system recover rust path/to/rust-crate

# inspect or reuse the recovered canonical model
cat path/to/rust-crate/recovered.canonical_system_model.json

# project the recovered model as text + native SVG
text2system project graph \
  path/to/rust-crate/recovered.canonical_system_model.json
Project status

A specification-first open toolchain.

The project is deliberately built in small, testable compiler stages.

T2S 1.0 Language Specification self-hosted regression verified
Parser and Semantic Builder working
Canonical System Model working and verified
Projectors: Documentation, Rust, Graph working
Renderers: Documentation, Rust, Graph text + native SVG, no external graph renderer required
Language Server diagnostics through text2system lsp; VS Code extension available
T2S_BINARY / .t2sbin planned: self-contained system artifact carrying the T2S definition and Canonical System Model, with optional implementation source code, native binaries, and resources
Zig, Python, and C ABI planned
Architecture Recovery: Rust working: Rust source → Canonical System Model → text + SVG graph
Public Source Repository coming soon
Open specification

Language knowledge belongs to everyone.

The T2S language specification is dedicated to the public domain under CC0-1.0.

Open tools

Minimal permission. Maximum reuse.

The reference tools are released under the 0BSD license.

The missing schematic language for software engineering.

Text2System treats text as the canonical system definition. Documentation and implementation artifacts stay synchronized because they are projected from the same source. Existing software can travel the other way: architecture recovery can reconstruct a Canonical System Model from source code, bringing undocumented systems into T2S for validation, documentation, visualization, testing, and refactoring.