The Intent File Specification

The Intent File Specification defines a vendor-neutral format — a single declarative YAML file (*.intent) per project — that describes a whole application one altitude above the models a conforming generator produces from it: its entities, relations, workflows, forms, reports, permissions, integrations and seed data.

The Intent File never emits application code. It stops at the model layer; a conforming generator deterministically turns it into the platform's model artefacts, and those into a complete running application.

This repository is the normative home of the specification. A rendered, navigable version — with the DSL reference, worked examples and the Intent-Driven Development manifesto — is published at intentfile.org (source: intentfile.github.io).

Current version

Version	Status
1.0	superseded
1.1	superseded - added aggregates, checks: kind: guard, posts, the notify block (attach: print, forEach), pattern and header-mediated dependsOn (proposal)
1.2	superseded - added lifecycle stages + report scope + status names, locksWithMaster, generates prompted input and computed lines, defaultValue row seeding, print-template row filtering (proposal), the scope boundary and the authoring assistant's honesty rule (proposal), and aligns document numbering with deployed practice
1.3	superseded - added event-driven creation (generates.event, proposal), resolves register lookup (proposal), the lifecycle status graph (proposal), the history change trail (proposal), resolver-path task assignment (proposal), and immutability covering composed collections (proposal)
1.4	superseded - added the glue event axis: process-step events and queue/topic/folder arrivals (proposal), attach: recordPrint fan-out (proposal), notify link placeholders {recordUrl} / {inboxUrl} / {appUrl} (proposal), and role-scoped field visibility visibleTo (proposal)
1.5	current - adds unrecognised-key errors (proposal), multilingual report columns (proposal), the related register (proposal), the declared payload envelope (proposal), outbound departures (proposal), relative moments in a schedule's where (proposal), and entity-level unique (proposal)

Structure

versions/     the specification, one file per version - the newest version file is normative (currently versions/1.5.md)
              written once, at a release, and never edited again
proposals/    every pending semantic change, in the open, until a release folds it into a version
examples/     complete example .intent files

A version document does not change between releases: cite versions/1.2.md today and it reads the same next month. What the format is about to become lives in proposals/.

Participate

The specification evolves in the open — every change is a pull request against this repository:

• Editorial fixes (typos, wording, clearer examples): open a PR directly against the current version document.
• Specification changes (new constructs, changed semantics): report the gap as an issue, then open a PR adding a document under proposals/. That PR never touches versions/ — merging it records that the direction is accepted, and the change is published when a release folds every accepted proposal into a new version.

See CONTRIBUTING.md for the full flow and the ground rules (vendor-neutrality above all), and GOVERNANCE.md for how decisions are made. Participation is covered by the Code of Conduct.

License

Apache License 2.0