Begin with an example, not a grammar
Use the appointment rule from the home page: when the service cancels an appointment, it must offer another date within five working days. Ask a domain specialist for cases that should pass, cases that should fail and awkward cases that expose missing meaning.
The team may discover that a controlled document template is enough. Choosing not to create a new language is a valid result. These five steps are a proposed first method: the rebooking example will test and revise them, and an independent team has not yet tried them.
Five steps
- Name the need and the people. State who will write, review or act on the language and what decision or description is currently unclear.
- Collect examples and counterexamples. Use real-looking but non-sensitive cases to find missing distinctions, exceptions and time rules.
- Agree the meaning. Record the concepts and relationships independently of their final written or visual form. For the appointment rule, cancellation by the service and non-attendance by the person are different events.
- Choose the smallest language and tools. Reuse the proposed CoreLang base when it fits a business-related language. Choose text, a table, a diagram or another form when that better suits the people and task.
- Try it and revise it. Check valid and invalid examples, show useful error messages, observe people editing it and record what must change. Add an execution path only when running the language serves its purpose.
What the method should leave behind
Keep the original question, representative examples, the agreed meanings, rejected choices, validation results, user observations and unresolved questions. A parser test shows that text has the expected structure. It does not show that domain specialists understand the rule. An executable result shows that one example can run. It does not show that the language should become general purpose.