MentorMind Varro eduKG
Crystallisation phases

Module 05

Crystallisation phases

Plasma -> Gas -> Liquid -> Solid -> Crystal.

Learning intent

By the end of this module you will be able to

  • Place Plasma, Gas, Liquid, Solid, and Crystal in increasing formalisation order.
  • Explain what changes when a specification moves from prose to checked and proved artifacts.

Success criteria

  • Identify Liquid as the VSL plus Lean-spec consistency stage.
  • Explain why Solid is generated but not fully proved.
  • Explain why Crystal still depends on the source VSL and Lean artifacts.

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

Crystallisation phases A left-to-right sequence from Plasma to Gas to Liquid to Solid to Crystal, showing increasing formalisation and proof strength. Crystallisation phases 1Plasma 2Gas 3Liquid 4Solid 5Crystal
A left-to-right sequence from Plasma to Gas to Liquid to Solid to Crystal, showing increasing formalisation and proof strength.

Concept · grounded · RICH E4

Plasma

Crystallisation phase: intent as prose.

Worked examples

# Plasma: "We want a contract that imports the Year 10 project as a demonstrator without inheriting its safety authority."

The Plasma phase of crystallisation is unstructured intent, written as prose. Nothing is typed yet; this is the raw goal before any VSL exists.

# parser-spec.varro  (phase: plasma)
We want to parse HSC papers into a structured KG.
Open question: how do we model multi-part questions?
# ...no `type`/`action`/`workflow` declarations yet

At the Plasma phase a `.varro` file is essentially a Quarto markdown document: design thinking and rationale as prose, with no formal VSL declarations yet. Consistency is maintained by human memory and the cost of change is near zero. Crucially the file is already under version control, so the specification's history begins here. Evaluate it as the hottest, most malleable state — the same artefact that will later acquire `type` and `action` blocks, not a throwaway design doc that gets discarded once "real" specs start.

Common trap

❌ Learners expect the Plasma phase to already include formal declarations.

Correction

✅ Plasma is pure prose intent with no VSL yet. Formal VSL declarations first appear in the Gas phase.

Check yourself

What form does a specification take in the Plasma phase of crystallisation?

Answer

Unstructured intent as prose. No VSL exists yet; formal declarations first appear in the Gas phase.

Concept · grounded · RICH E4

Gas

Crystallisation phase: formal VSL declarations.

Worked examples

system magatama.seed.year10_demonstrator { ... }

The Gas phase is the first formal condensation of prose intent into VSL declarations: systems, types, enums, workflows. It is structured but not yet property-checked.

# parser-spec.varro  (phase: gas)
## Rationale: papers decompose into parts...   <- prose persists
type QuestionPart {                            <- formal VSL emerges
  field part_id: string required
}

At the Gas phase formal VSL declarations (type/workflow/action) begin to crystallise inside the same `.varro` file, mixed with the surviving prose. It is parser-validated by `varro check vsl` but has no formal properties; the spec is queryable by agents yet not semantically complete. Evaluate the key design choice: the prose is not replaced by the VSL — documentation and specification coexist in one file, which is what eliminates doc/spec drift by construction.

Try it

Translate a prose room-booking requirement into a formal VSL system that represents the Gas phase: typed declarations that can be checked before anything is generated.

# Prose: rooms can be free, held, or booked.
# Convert the prose into checked VSL declarations.
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 assume that once intent is in VSL (Gas) it is verified.

Correction

✅ Gas is structured VSL but not yet property-checked. Consistency against Lean-spec comes in Liquid; proof comes only at Crystal.

Check yourself

What is produced in the Gas phase of crystallisation?

Answer

Formal VSL declarations (systems, types, enums, workflows) condensed from prose intent. It is structured but not yet property-checked.

Concept · grounded · RICH E4

Liquid

Crystallisation phase: VSL + Lean-spec properties, consistency-checked.

Worked examples

# VSL + Lean-spec property: forall import. import.safety_case_ref present

The Liquid phase pairs the VSL with Lean-spec properties and checks them for consistency. The structure of Gas is now backed by stated invariants that hold together.

# parser-spec.varro  (phase: liquid)
# VSL @ checked maturity   (structure)
# Lean-spec properties     (invariants, e.g. total_marks == sum(part.marks))
# both machine-checked against each other

At the Liquid phase the VSL sits at checked maturity and is joined by authored Lean-spec properties for key invariants; an internal Lean representation of the VSL structure is consistency-checked against the `.varro` file. Authority is dual: VSL owns structure, Lean-spec owns properties. This is where the spec is most actively governed because both shape and invariants are machine-checked. Evaluate the human cost: you author properties, not proofs — the correspondence proof is generated later at Solid/Crystal.

Common trap

❌ A senior engineer assumes the usual order: write the Rust, then bolt on Lean proofs afterward to verify it — so Lean is a downstream QA gate.

Correction

✅ That was the revised-away v2 model. At Liquid, Lean-spec is authored upfront as a property complement to VSL, before Rust exists. Rust is then generated and the correspondence proof is generated. The human writes properties; proofs and code are produced from the joint authority, not hand-written and later checked.

Check yourself

What is added in the Liquid phase of crystallisation?

Answer

Lean-spec properties paired with the VSL, checked for consistency. The structure of Gas is now backed by stated, mutually consistent invariants.

Concept · grounded · RICH E4

Solid

Crystallisation phase: Rust generated from VSL + Lean-spec.

Worked examples

# parser-spec.varro  (phase: solid)
# Rust generated from joint VSL + Lean-spec authority.
# It compiles and passes tests; Lean proofs may contain `sorry`.

At the Solid phase Rust is generated from the joint VSL + Lean-spec authority, the compiler enforces structural consistency, and the generated code compiles and passes tests — but Lean proofs may still be partial (`sorry` permitted). The specification is executable but not yet fully proved. Critically, VSL is not deleted here: it remains the human-readable surface, and editing it triggers regeneration of the Rust. Evaluate solid as a legitimate long-term resting state: not everything needs to reach Crystal.

# parser-spec.varro  (phase: solid)
# Rust generated from joint VSL + Lean-spec authority.
# It compiles and passes tests; Lean proofs may contain `sorry`.

At the Solid phase Rust is generated from the joint VSL + Lean-spec authority, the compiler enforces structural consistency, and the generated code compiles and passes tests — but Lean proofs may still be partial (`sorry` permitted). The specification is executable but not yet fully proved. Critically, VSL is not deleted here: it remains the human-readable surface, and editing it triggers regeneration of the Rust. Evaluate solid as a legitimate long-term resting state: not everything needs to reach Crystal.

Common trap

❌ Learners treat Solid (Rust generated) as the fully verified end state.

Correction

✅ Solid is generated Rust that compiles but is not yet fully proved. Crystal is the terminal state where the Rust is proved against the Lean-spec with zero `sorry`.

Check yourself

What is produced in the Solid phase, and how does it differ from Crystal?

Answer

Solid is Rust generated from the VSL plus Lean-spec; it compiles but is not yet fully proved. Crystal is the terminal phase where that Rust is fully proved with zero `sorry`.

Concept · grounded · RICH E4

Crystal

Crystallisation phase: Rust fully proved against Lean-spec (zero sorry).

Worked examples

-- all obligations discharged; no `sorry` remains

The Crystal phase is the terminal state: the generated Rust is fully proved against the Lean-spec with zero `sorry`. Intent has crystallised end to end from prose to verified code.

# parser-spec.varro  (phase: crystal)
# Rust fully proved against Lean-spec; zero `sorry` in proof files.
# correspondence proof generated and checked -> mathematical certainty

Crystal is the coldest, most constrained phase: the generated Rust is fully proved against the Lean-spec with zero `sorry`, and the correspondence proof is generated and checked, yielding mathematical certainty for every stated property. As at Solid, VSL is not discarded — it remains the editable surface, and an edit triggers re-verification rather than a free-text change. Evaluate the endpoint: Crystal is certainty for stated properties only; it does not invent invariants you never wrote at Liquid.

Common trap

❌ An engineer assumes the .varro is scaffolding: once Rust is generated and proved, the VSL is deleted like generated-code intermediate artefacts usually are.

Correction

✅ VSL persists at every phase, including Crystal. The `.varro` file is the single continuous source from plasma through crystal and remains the human-readable surface of record; edits trigger re-verification. Deleting it would discard the most accessible documentation of the system's shape (the v2 'delete VSL at solid' idea was revised away).

Check yourself

What condition defines the Crystal phase of crystallisation?

Answer

The generated Rust is fully proved against the Lean-spec with zero `sorry` remaining. Intent has crystallised end to end from prose to verified code.

Module assessment · scored

Module assessment: the crystallisation phases

  1. A spec is at the `solid` phase. A developer announces it is 'fully proved'. Why does that conflate two distinct phases?

  2. Once a system reaches `crystal` (proved Rust), a teammate deletes the `.varro` and Lean sources to 'clean up'. Why is that a misconception about crystallisation?

  3. What is the correct ordering of crystallisation phases from least to most formalised, and where does `liquid` sit?

  4. At the `gas` phase a developer assumes the formal VSL declarations are already verified. Why is that premature?