> For the complete documentation index, see [llms.txt](https://clarity-7.gitbook.io/clarity-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://clarity-7.gitbook.io/clarity-docs/clarity-moniversive-invariant-static-mis/education-learn-the-language-.mis/01-language-mindset.md).

# 1 — Language mindset

> Generated 2026-07-29T03:15:30Z

Most languages ask you to describe **steps**: call this, branch here, catch exceptions there. MIS asks you to describe **what must remain true** and **what result you want** under explicit gates. The checker (`bin/misc`) validates that your module is well-formed; the execution model (Static ML) is concerned with schedules that satisfy **`constraint`** lines without breaking **`invariant`** lines.

That shift is the whole language. Once you stop looking for `main()` and start looking for **`module` → `invariant` → `outcome`**, files become predictable. The **150** modules in the [showcase](/clarity-docs/clarity-moniversive-invariant-static-mis/education-learn-the-language-.mis/mis-showcase.md) all follow the same skeleton; differences are domain names and predicate counts, not syntax surprises.

## Code = intent, state = invariants

Think of a module as a small specification document. **`invariant`** paragraphs are laws that hold for every successful transition. **`outcome`** paragraphs are named intents: “when someone invokes `bump`, these preconditions must hold, and afterwards these relations must hold.” You are not writing a loop; you are writing a **contract for one transition** at a time.

This is why MIS feels closer to formal methods than to scripting — but you still author text files and run a familiar CLI check. The ergonomics goal is **local readability**: a reviewer should understand module behavior by scanning invariant names and outcome names without reading a call graph.

## How this differs from mainstream languages (without leaving MIS)

| Mainstream habit          | MIS habit                                               |
| ------------------------- | ------------------------------------------------------- |
| Class + methods           | `module` + `outcome`                                    |
| `if (!ok) throw`          | `require` + named `fail` (when you model failure modes) |
| `assert` at end           | `constraint` on the post-state                          |
| Hidden mutable singletons | `state` fields declared in the module                   |
| Logging / events          | `signal` declarations                                   |

You can map ideas from other languages **after** you learn MIS on its own terms. This book keeps that mapping optional so the language stays central.

## What you need installed

Only the **`misc`** checker and a text editor. Typical loop:

```bash
bin/misc examples/mis/kernel_swap_to_mis.mis --check --compact-letters
```

Next: [Module anatomy](/clarity-docs/clarity-moniversive-invariant-static-mis/education-learn-the-language-.mis/02-module-anatomy.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://clarity-7.gitbook.io/clarity-docs/clarity-moniversive-invariant-static-mis/education-learn-the-language-.mis/01-language-mindset.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.