Home

The .expec language reference

Write software contracts and concrete examples, then generate supported project artifacts from them. This reference is for authors of .expec files. Start with Quick start, look up a word in the Keyword index, or choose a task below.

This edition describes pr-44, released from commit 36748015 on October 7, 2026. It documents implemented syntax and checked meaning, with finite output limits. Historical sketches may use different syntax.

Reading the examples: Every block labeled main.expec or another .expec filename contains actual .expec source. GitHub does not currently recognize .expec for syntax coloring. These blocks use approximate TypeScript coloring while keeping the exact copyable .expec text; they are not TypeScript programs. Names with spaces use backticks; ordinary text uses double quotes. JSON and command blocks use their own formats.

I want to…	Go to
Write and check my first file	Quick start
Learn names, punctuation, comments and line breaks	Lexical syntax
Describe a class, interface, component or concept	Concepts and construction
Define data, optional fields, lists or generic types	Types
Promise a public operation and its inputs/results	Capabilities and contracts
Write calculations and conditions	Expressions and operators
Describe concrete behavior through examples	Examples and scenarios
Split a specification across files or declare dependencies	Dependencies and files
Describe exceptional outcomes	Domain errors
Show who communicates with whom and in what order	Interactions
Connect a real project and choose generated outputs	Project configuration and commands
Understand what each output can establish	Output support
Find a keyword or symbol directly	Keyword index
Understand an authoring error	Troubleshooting

What checking tells you

A file can be grammatically valid and still use an unknown name or an incompatible type. A checked contract can still lack an implementation. A generated test can still need a driver. A prose promise can still need a way to verify it.

The reference calls out those differences. check is not proof that a promised application behavior works. Real execution must observe the application through implemented test drivers. A missing implementation or prose-only expectation must not be treated as a passing test.

Relationships come from declared dependencies and typed construction inputs, parameters, results and fields. They do not silently imply ownership, shared lifetime or runtime communication. Interactions describe explicit communication sequences when you need them.

Navigation and search

Use the sidebar for topics and the Keyword index for exact words and symbols, including result, fixture, ? and =>. Each page links related topics.

GitHub's wiki search accepts repo:jreyno77/ExecutableSpecificationLanguage fixture; select Wikis in search results. Add in:title or in:body to narrow the search. Native indexing may lag publication, so the index remains the direct lookup route. Search this wiki.

The documented highlighting and search behavior follows GitHub's code-block documentation and wiki search documentation. Native .expec coloring is not promised.