A DSL for business intent & behaviorDeveloper preview

Build what
you meant.

Meant Lang is a small, checkable language for how an application should behave: who can act, under what conditions, and what changes. Your team and coding agents can check the model. Engineers choose how to build it.

See an example

Human intentCheckable modelEngineering judgment

01 / FROM INTENT TO A MODELWho can act, when, and what changes.

Less room
for guesswork.

Requirements written in English can leave decisions open to interpretation. Agents can fill those gaps with assumptions.

Meant gives you a small, clearly defined language for describing intended behavior: who can act, under what conditions, and what changes. Your team makes those decisions explicit, giving agents less to guess.

“Send the invoice”
leaves a lot unsaid.

Who can send it? What if it is empty? Can it be sent twice? An agent needs these decisions before it can build the behavior you intended.

Here, the model says when SendInvoice is allowed and what it changes. Storage, API routes, framework, and deployment belong to a separate engineering design.

Explore the complete model

Sending an invoice

concept Invoice
  dimension status = draft | sent

concept DenyCode
  field copy: string
  values
    NOT_DRAFT "Only a draft invoice can be sent."
    EMPTY_INVOICE "An invoice needs at least one line item."

shape Draft of Invoice
  where status = draft

shape Empty of Invoice
  where no LineItem

action SendInvoice of Invoice
  by owner
  requires Draft else NOT_DRAFT
  requires not Empty else EMPTY_INVOICE
  effect
    status = sent

The full example includes the remaining declarations and three scenarios.

Explore the modeled behavior

Try sending the invoice.

Recorded CLI results

The scenario

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

The recorded outcomeDenied: EMPTY_INVOICE

The invoice has no line items, so SendInvoice is denied.

✓ Matches the scenario expectation

Select a scenario to see its recorded simulator result. Inspect the evidence and its limits ↗

02 / THE ENGINEER’S CHOICESThe invoice rules stay the same.

Choose how
to build it.

The same invoice rules can work in a small application or an existing system. Choose a design below to see what an engineer might build.

The business contractAgreed behavior

When can an invoice be sent?

Only the owner can send it.
It must be a draft.
It must contain at least one line item.
Sending it changes its status to sent.

Changing the framework or database leaves these four rules intact.

The engineering decisionsYour judgment

Use one application.

Handle the invoice workflow in a Django application, with SQLite for storage and an email provider for delivery.

Application: Django monolith
Storage: SQLite
Delivery: Email provider integration

These are example designs. Meant does not choose the stack or generate the application.

Whichever design you choose, test the application against the four rules.

03 / BUILT FOR PEOPLE AND AGENTSDraft, review, implement, test.

From agreed rules
to application tests.

Agree on the behavior

Product managers and engineers decide the rules, exceptions, and outcomes in the business’s own words.

Check the model

An agent drafts the model. Deterministic checks catch structural mistakes. Simulation explores supported claims and can expose counterexamples.

Choose the implementation

The engineer chooses the architecture, stack, and integrations. Agents work from those decisions and the agreed model.

Test the application

Test that the application behaves as agreed. Review changes to the requirements before asking an agent to implement them.

Start from your code

Model your
existing app.

Point your coding agent at one workflow in your codebase. It drafts the model from the code, and you decide what the model means.

How it works →

Install, then prompt your agent

bun add -g meant-lang

Then give your agent one prompt that names one workflow:

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

It reads that workflow's code.

Permission checks, stored entities, status fields, handlers, guard clauses, and tests become declarations, each citing the file and line it came from.

It proposes; you decide.

New vocabulary waits for your verdict, and contradictions in the code are marked as undecided instead of guessed.

You review what it found.

Check, simulation, and report show the falsified claims, unverified prose, and open questions to settle with your team.

Checks and limits

What the checks
can tell you.

The checker is deterministic.

No LLM decides whether a model passes its structural checks.

Simulation has a defined scope.

A counterexample disproves a claim. A passing bounded search covers only the conditions searched.

Unknowns stay visible.

Some requirements remain in prose that the simulator cannot execute. Reports list them for review.

The application needs its own tests.

The current toolkit checks models. Automatic application conformance and runtime enforcement are not implemented.

Questions about Meant

Where Meant fits.

Why use a DSL instead of a requirements document?

Prose is a useful starting point. A model adds references, conditions, outcomes, and expectations that the checker and simulator can inspect. You can keep requirements in prose; reports identify what remains unverified.

Does Meant generate application code?

The current toolkit does not generate applications. The model is an input to engineering design and agent-assisted implementation. Engineers choose the architecture, stack, integrations, and operational tradeoffs.

Does a passing model mean my application is correct?

No. Structural checks and bounded simulation provide evidence about the model. Application tests, integration checks, and reviews must separately establish that the implementation follows the intended behavior.

Do product managers need to learn the whole language?

Start by reviewing the rules and scenarios with an engineer. Agents can help draft the syntax. You decide whether the model says what the business means.

Can I install Meant today?

Yes. Meant is a developer preview: install it with bun add -g meant-lang (Bun 1.4 or later). The source is on GitHub under the MIT license. Read the project status.

Start with one workflow

Start with the
invoice model.

Read the rules, follow the three scenarios, and see what the simulator checks.

Explore the language

Build what
you meant.

Less room
for guesswork.

“Send the invoice”
leaves a lot unsaid.

Try sending the invoice.

Choose how
to build it.

When can an invoice be sent?

Use one application.

Move delivery to a worker.

Use the existing system.

From agreed rules
to application tests.

Agree on the behavior

Check the model

Choose the implementation

Test the application

Model your
existing app.

It reads that workflow's code.

It proposes; you decide.

You review what it found.

What the checks
can tell you.

The checker is deterministic.

Simulation has a defined scope.

Unknowns stay visible.

The application needs its own tests.

Where Meant fits.

Start with the
invoice model.

Build what you meant.

Less room for guesswork.

“Send the invoice” leaves a lot unsaid.

Try sending the invoice.

Choose how to build it.

When can an invoice be sent?

Use one application.

Move delivery to a worker.

Use the existing system.

From agreed rules to application tests.

Agree on the behavior

Check the model

Choose the implementation

Test the application

Model your existing app.

It reads that workflow's code.

It proposes; you decide.

You review what it found.

What the checks can tell you.

The checker is deterministic.

Simulation has a defined scope.

Unknowns stay visible.

The application needs its own tests.

Where Meant fits.

Start with the invoice model.

Build what
you meant.

Less room
for guesswork.

“Send the invoice”
leaves a lot unsaid.

Choose how
to build it.

From agreed rules
to application tests.

Model your
existing app.

What the checks
can tell you.

Start with the
invoice model.