Make business intent
explicit.

Meant is a domain-specific language that describes business intent and observable application behavior: who can act, which conditions must hold, and what an action changes. It gives product people, engineers, and coding agents a shared model to inspect.

The model is separate from the implementation. An engineer chooses architecture, frameworks, storage, and delivery mechanisms based on experience, existing systems, operational constraints, and preferences. Application tests must establish that those choices preserve the agreed behavior.

Your first model: sending an invoice

Agree on four business rules: only the owner may send an invoice; it must be a draft; it needs at least one line item; and sending changes its status to sent.

Download the complete model. This example covers sending an invoice. Creation, editing, and later actions are outside its scope.

dimension actor = owner | client

concept Invoice
  dimension status = draft | sent

concept LineItem
  field invoice: Invoice

shape Draft of Invoice
  where status = draft

shape Empty of Invoice
  where no LineItem

action SendInvoice of Invoice
  "The owner sends an invoice."
  by owner
  requires Draft else NOT_DRAFT
  requires not Empty else EMPTY_INVOICE
  effect
    status = sent

The excerpt above omits the domain header, refusal-code declarations, the Sent shape, and scenarios. They are all present in the downloadable file.

Make an expectation explicit

scenario SendingAnEmptyDraft
  with Draft, Empty
  the owner sends it via SendInvoice -> denied EMPTY_INVOICE

The simulator reproduces the refusal. The complete example also exercises sending a non-empty draft and attempting to send an already sent invoice.

These results were recorded from the CLI. The page does not run the checker. Inspect the full simulation output.

The structural check has no errors or warnings and two informational notices. Simulation also warns that this slice does not model how invoices become draft or empty, and reports that Sent has no computable exit. The full result includes these messages.

Read the vocabulary

Names refer to declarations in the model. For example, NOT_DRAFT belongs to the declared refusal vocabulary. The simulator executes supported conditions and effects. Prose it cannot execute remains unverified.

Keep engineering decisions explicit, too

An engineer can implement the invoice rules in a monolith, a service backed by a queue, or an existing application. Each design has different performance, deployment, maintenance, and failure handling. All must enforce the same sending rules.

Write the technical design separately: the stack, storage representation, interfaces, transactional boundaries, retry behavior, and operational constraints. Use the business model as input to that design. If a technical constraint requires different observable behavior, bring that change back to the people who own the requirements.

Specify and test usability, appearance, performance, security, and engineering quality separately from this business model.

Work with an agent

1. Agree on the intended behavior with the people responsible for the product.
2. Give the agent the modeling discipline and ask it to draft a focused model.
3. Run structural checks. Let the agent fix mechanical issues such as unresolved references and malformed syntax.
4. Review changes to the meaning yourself. An agent must not weaken a requirement to make a check pass.
5. Run simulation and reports. Inspect counterexamples, unverified prose, and unresolved questions.
6. Choose the technical design, implement it, and test the application against the agreed behavior.

The toolkit includes modeling instructions, a Claude Code skill installer, and a hook that checks edited model files. Application-code and runtime checks remain separate.

Start from your codebase

You don't have to write the first model by hand. Install the CLI, then give your coding agent one prompt that names one workflow, such as sending an invoice.

bun add -g meant-lang

Run `meant` and follow its instructions to build a Meant model of the <workflow> workflow in this app.

Running meant prints a short bootstrap that points the agent to its modeling instructions. From there the agent:

1. Stays inside the workflow you named.
2. Creates .meant/model.meant in code-first mode, where the running code is presumed right, and starts .meant/history.md, a numbered log of model changes.
3. Reads that workflow's code (permission checks, stored entities, status fields, handlers, guard clauses, writes, and tests) and cites the file and line behind each inference.
4. Proposes new vocabulary for your decision instead of adding it, and marks contradictions as undecided.
5. Runs check, sim, and report until the model is well-formed.
6. Installs the modeling skill and the edit hook, and notes the model in the repository's agent instructions.

You review the model, the vocabulary it proposed, any falsified claims, and the open questions. The model describes the behavior the code appears to implement. Whether that behavior is right is still your decision.

Understand verification and its limits

The checks run without an LLM. Simulation covers a bounded scope; application tests must establish that the implementation follows the model.

verified-by currently records an anchor to an application test. The CLI does not execute that referenced test. Automatic model-based application testing and runtime enforcement are future work.

Current toolkit

The toolkit uses the meant executable and the .meant extension. It needs Bun 1.4 or later.

bun add -g meant-lang

meant check path/to/model.meant --json
meant sim path/to/model.meant --json
meant report path/to/model.meant --json
meant fmt path/to/model.meant --check

meant skill
meant spec

check validates structure and references. sim explores supported behavior. report exposes unverified prose and questions. fmt provides canonical formatting. skill prints the agent discipline, and spec provides the normative language reference.

Project status

Meant Lang is a developer preview from TeamBrilliant.

The toolkit includes structural checking, formatting, bounded simulation, reports, and model-edit feedback for agents. Commands and diagnostics may change between preview releases.

The source is on GitHub under the MIT license. Report problems in GitHub issues.

Read the command reference for flags and exit behavior.