Modality, Obligation and Possibility
How certain, permitted or required is this?
Linguistic marking of what is necessary, possible, permitted or expected, as distinct from what is asserted as fact.
- T1 · Documented
Field record pending — no linked language specimens yet.
What linguistic research records.
- T2 · Interpreted
boolean rules flatten a spectrum of obligation and permission
How Lanskrit reads the code deficit.
- T3 · Proposed
Must<T>, May<T>, Should<T> annotations
Speculative constructs — not executable code.
- T4 · Executed
Not yet compiled to a deterministic runtime.
Deterministic runtime — the graft as running machinery.
Each tier is a different kind of claim. We keep them visually distinct so a reader can never confuse a field record with a deterministic run.
Documented
What linguistic research records.
- necessity versus possibility
- permission versus obligation
- expectation and prediction
Interpreted
How Lanskrit reads the code deficit.
- boolean rules flatten a spectrum of obligation and permission
- AI instructions rarely distinguish must / should / may
Proposed
Speculative constructs — not executable code.
- Must<T>, May<T>, Should<T> annotations
- policy expressions with modal operators
Executed
Deterministic runtime — the graft as running machinery.
No executable runtime yet. This capability has not been compiled to a deterministic machine.
- explicit obligation types
- permission and possibility as first-class annotations
- typed policy expressions for AI instructions
- Modality overlaps with evidentiality in some languages; the boundary is not universal.
No specific languages have been linked to this capability yet.
Cited as examples of the feature, not as claims about all speakers of these languages.
Under review
Research source pending verification.
Strong candidate for AI-instruction design work.
- Record version
- 0.1
- Last reviewed
- 2026-07-21
- Controversy level
- low