MentorMind Varro eduKG
The maturity ladder

Module 04

The maturity ladder

draft -> checked -> bound -> hardened.

Learning intent

By the end of this module you will be able to

  • Place draft, checked, bound, and hardened in maturity order.
  • Explain what each maturity rung does and does not guarantee.

Success criteria

  • Explain why checked is not the final production state.
  • Distinguish bound from hardened.
  • Describe why hardened does not mean immutable.

Retrieval warm-up

Before the new material

Recall

Does the `ask` verb ever mutate state? If not, which verbs do?

Answer

No. `ask` is read-only; it retrieves authoritative truth. Only `run` (execute an action) and `create` (make a new artifact) mutate, and both under preview-by-default.

Recall

Both `show` and `ask` are read-only. What distinguishes them?

Answer

`ask` retrieves a value into the conversation; `show` renders a selection for presentation (a view or table). Same read, different intent.

Recall

What happens in a workflow when a `check` step fails?

Answer

`check` validates an artifact against its contract and emits diagnostics; it never executes. On failure the workflow fails closed, so any following `create` or `run` does not proceed.

Learner readiness

Before this reference page

Assumed terms:

Terms introduced or strengthened here:

You are ready to continue when you can:

  • explain why checked does not yet mean hardened
  • place Plasma, Gas, Liquid, Solid, and Crystal in increasing formalisation order
  • state why proof tooling belongs at the hardening end, not at the first learner step

Representation

Load-bearing diagram

Maturity ladder A left-to-right ladder showing draft, checked, bound, and hardened as increasing maturity states, with checked not treated as final. Maturity ladder 1draft 2checked 3bound 4hardened
A left-to-right ladder showing draft, checked, bound, and hardened as increasing maturity states, with checked not treated as final.

Concept · grounded · RICH E4

draft

VslMaturity level: unverified intent.

Worked examples

system magatama.seed.year10_demonstrator {
  maturity draft
}

`maturity draft` is the lowest rung: unverified intent. At draft the checker tolerates unresolved references and inferred defaults so authoring can proceed before everything is bound.

system parser-spec {
  maturity draft
  # refs may dangle; defaults may be inferred at this rung
}

`maturity draft` is the lowest rung of the ladder `draft -> checked -> bound -> hardened`. At draft, unresolved references and inferred defaults are tolerated, and lowering diagnostics are warnings rather than errors. This corresponds to `VslMaturity::Draft`, which the lowering severity function maps to `Warning`. Evaluate it as a TODO-tolerant compile mode: the document parses and is queryable while still incomplete, so you can stand up structure before every reference resolves.

Try it

Author a checked VSL system header and explain why the maturity rung is an explicit contract claim rather than decorative status text.

system mentormind.example.maturity {
  mission "..."
  authority lane "operator:research"
  domain education
  maturity draft
  # context root and body still TODO
}
Model answer (passes varro check vsl)
system mentormind.facilities.room_booking {
  mission "Specify a governed room-booking surface for a campus, exposing booking state as typed contracts under research authority"
  authority lane "operator:research"
  domain education
  maturity draft

  context root = "helios://local/mentormind/facilities/room-booking?view=detail&tab=contract&bind=auto"

  enum RoomState {
    value free
    value held
    value booked
  }

  type Room {
    field room_id: string required
    field capacity: integer required
    field state: RoomState required
  }

  compile booking-runtime -> varro

  action hold-room {
    risk low
    binding required
    input room_id: string required
  }

  query rooms.free {
    output Room[]
  }

  workflow reserve-room {
    inspect selection
    resolve rooms.free
    check hold-room
    render center.detail
  }

  runtime specification {
    host governed
    commit-mode host-only
  }
}

Common trap

❌ Learners read `maturity draft` as a defect or an unfinished mistake.

Correction

✅ `draft` is a legitimate rung for in-progress intent; it deliberately tolerates unresolved refs and inferred defaults. It is the start of the ladder draft to checked to bound to hardened, not a failure.

Check yourself

List the four VSL maturity rungs in order and say what changes at `bound`.

Answer

draft, checked, bound, hardened. At `bound` the spec is tied to a concrete contract, so unresolved references become checker errors rather than warnings.

Check yourself

What does the `draft` maturity rung allow that stricter rungs do not?

Answer

`draft` tolerates unresolved references and inferred defaults; it represents unverified intent so authoring can proceed before everything is bound.

Concept · grounded · RICH E4

checked

VslMaturity level: validated by the checker.

Worked examples

maturity checked

`checked` is the second rung: the document has passed the checker. References resolve and types are consistent, but it is not yet bound to a concrete contract or hardened for production.

system parser-spec {
  maturity checked
  # structure parser-validated; lowering diagnostics still warnings
}

`maturity checked` is the second rung. Structure is parser-validated (`varro check vsl` passes) but lowering diagnostics remain warnings — like `Draft`, `VslMaturity::Checked` maps to `Warning` in the lowering severity function. The jump in obligation happens at `bound`, not here. Evaluate the boundary: checked guarantees the shape is well-formed and queryable, but does not yet force every reference to resolve into an executable lowering — that promise belongs to the next rung.

Common trap

❌ Learners think once a spec is `checked` it is production-ready.

Correction

✅ `checked` only means the checker passed. Two rungs remain: `bound` (tied to a concrete contract) and `hardened` (production, strictest diagnostics).

Check yourself

What does the `checked` rung guarantee, and what does it not?

Answer

It guarantees the checker passed (refs resolve, types consistent). It does not mean bound to a concrete contract or hardened for production.

Concept · grounded · RICH E4

bound

VslMaturity level: bound to a concrete contract.

Worked examples

maturity bound

`bound` is the third rung: the spec is bound to a concrete contract, so unresolved references become checker errors rather than warnings. Promotion to bound is the point at which laxness ends.

system parser-spec {
  maturity bound
  # lowering diagnostics now ERROR, not warning
}

`maturity bound` is the third rung and the first with teeth: the lowering severity function escalates `VslMaturity::Bound` (and `Hardened`) to `Error`, so a missing or unresolved lowering target now fails rather than warns. This is the rung where the spec commits to being executable. Evaluate it as flipping `-Werror` on for lowering: everything that was a tolerable gap at draft/checked now blocks promotion.

Common trap

❌ Learners conflate `bound` with the top production rung.

Correction

✅ `bound` ties the spec to a concrete contract so unresolved refs become errors, but `hardened` is a further rung that applies the strictest production posture. Bound is necessary but not the summit.

Check yourself

What is true at the `bound` rung that is not true at `checked`?

Answer

At `bound` the spec is bound to a concrete contract, so unresolved references are errors. It is stricter than `checked` but below `hardened`.

Concept · grounded · RICH E4

hardened

VslMaturity level: hardened/production.

Worked examples

maturity hardened

`hardened` is the top rung: production-ready. Everything is bound, checked, and the strictest diagnostics apply. A hardened system should not be silently relaxed back to draft.

system parser-spec {
  maturity hardened
  # top of draft<checked<bound<hardened; lowering errors enforced
}

`maturity hardened` is the top rung of the ladder. Like `bound`, `VslMaturity::Hardened` maps lowering diagnostics to `Error`; hardened is the strictest promotion state a `.varro` document declares. This maturity ladder is the document's own rung and is orthogonal to the plasma->crystal phase model: maturity is the VSL's self-declared strictness, while phase describes how far the spec has crystallised toward proved Rust. Evaluate the design: a document can be `hardened` VSL and still only sit at the Gas phase, because the two axes measure different commitments.

Common trap

❌ Learners think a `hardened` spec is frozen and cannot be revised.

Correction

✅ `hardened` is the strictest, production rung, but it can still be revised through governed change. What it should not be is silently relaxed back to draft to dodge diagnostics.

Check yourself

What does the `hardened` maturity rung represent?

Answer

The top, production rung: everything is bound and checked, the strictest diagnostics apply. It should not be silently relaxed back to draft.

Module assessment · scored

Module assessment: the VslMaturity ladder

  1. A spec reaches `checked`. A reviewer wants to ship it as the production contract, calling `checked` the final state. Why is that wrong?

  2. Why is `bound` not the same as `hardened`, even though both are above `checked`?

  3. A teammate refuses to touch a `hardened` spec, insisting hardened specs are immutable forever. Why does that misread the ladder?

  4. A spec sits at `draft`. A manager reads that as 'the spec is broken'. Why is that the wrong inference about the maturity level?