Glowwellbeing

A method you can audit

The Glowwellbeing method is published in full: the design principles, the shape of a taught block, the coverage matrix, the build loop and the rubric with pass thresholds. A buyer or an internal L&D lead can read this page and know what will happen in the room.

Design principles

Six design principles

These six rules decide what goes into a module and what is cut. They are used when we write in-house programmes as well as public cohorts.

Work on the learner’s own material

Labs use a process, a document set or a queue that already exists in the participant’s organisation. Synthetic demos are used only to show a mechanism, then the same mechanism is applied to the live files. The point is a transferable artefact, not a classroom toy.

Every claim about a model is tested in the room

If we say a template holds on messy input, we run it on messy input during the block. If it fails, the failure is written down and becomes the next change. Statements that cannot be tested in 45 minutes are kept out of the taught segment.

Output is judged against a written rubric, never against taste

Scores use the five criteria and four bands published on this page. Facilitators do not award a “feel” mark. Participants learn to score their own output so the standard survives after the cohort.

Tools are taught as replaceable

Hosted chat, model APIs, retrieval and spreadsheet automation appear as classes of tool. When a vendor changes a screen, the rubric, the test set and the log format still apply. We name products in class only as current examples.

Failure modes get as much time as capabilities

Hallucinated citations, silent omission, prompt injection through pasted text, and cost blow-ups each have a lab. A course that only shows success leaves people unarmed on the first bad afternoon.

Nothing is taught that the group cannot repeat on Monday without us

If a step needs a private platform we cannot leave behind, we do not make it a required step. Handover notes, logs and templates are part of the contact time, not homework that might be skipped.

Capability model

Capability model in detail

Each layer has an entry condition, a closed condition and a short list of mistakes we see when teams skip it. The language below is the language used on evaluation sheets.

Literacy

Literacy covers how a language model produces the next token, what a context window is, how temperature and system instructions change behaviour, and why a fluent paragraph can still be wrong. It also covers cost and latency as design constraints, not as footnotes. A layer is closed when the participant can brief a task in writing, predict a likely failure, and check an answer in five minutes using a source they brought.

Typical errors at this layer are treating the model as a search engine, pasting confidential text into a consumer chat, and accepting the first fluent draft. We spend time on those errors in Foundations because they are cheap to fix here and expensive once a queue is connected.

Practice

Practice is the craft of turning a job into a repeatable prompt or small pipeline: decompose the task, attach reference material, lock variables, and keep a twenty-case test set. Closed Practice means a colleague can run the template and get a score that matches the author’s score within one band. The test set is part of the artefact. Without it, a prompt is a one-off.

Teams often skip the test set and then argue about quality in the abstract. They also bury the instruction in chat history so nobody can find the current version. Prompt Systems and Working Data exist to make those habits visible and then replace them with a library and a log.

Systems

Systems starts when Practice is closed. It covers calling a model through an API, chaining steps with a check between them, retries, connecting a sheet or a form to a queue, and writing a log of every run. Closed Systems means a narrow process runs without the author sitting next to it, with a named person who can read the log.

The usual mistake is wiring an untested prompt into production traffic. A second mistake is building a chain with no human review point and no fallback when the model is slow or down. Automation and Capstone both require those review points to be drawn on the process map before any code is written.

Governance

Governance is the work of saying which data may enter a model, who consents, what is stored, who reads the log, and who is accountable for a bad output that reached a customer or a staff member. Closed Governance on our rubric is a filled risk register for one use case plus an acceptable-use note that staff can actually read.

The course does not issue legal opinions and does not certify a firm against a regulatory regime. It trains the people who will sit with counsel and with IT, so those conversations start from a shared description of the system rather than from a slide of aspirations.

Coverage

Coverage matrix

Rows are independence levels. Columns are layers. Cells mark how far a public course at that level takes the layer: core, applied, deep, or a dash where we do not teach it yet.

Level Literacy Practice Systems Governance
L1 core — — —
L2 applied core — core
L3 applied applied core applied
L4 deep deep deep applied

When we write an in-house programme we start from this matrix and mark the cells the group already holds. A team that is fluent in Literacy and weak on data preparation gets Working Data before Automation. A policy group may take Governance and selected Prompt Systems modules and leave Systems for a later intake. The matrix is the planning sheet; it is also the page we put in the syllabus pack so a sponsor can see what is in and what is later.

Taught block

Anatomy of a taught block

A standard evening is 180 minutes including a break. In-house days stack two of these blocks with a longer lunch. The clock below is the one facilitators actually run.

Segment Minutes Purpose
Brief and prior-work review 20 Return scores from the last lab and name the task for tonight
Mechanics 35 How the mechanism works, with one worked failure
Guided build 45 The group builds the first version together on a shared example
Break 15 Leave the desk; we do not extend the lecture into the break
Independent lab 45 The same mechanism on the learner’s own files
Rubric review and next brief 20 Score in the room; issue the between-block assignment

Mechanics is capped at 35 minutes because attention for abstract explanation drops after that in an evening class, and because anything we cannot demonstrate in 35 minutes does not belong in this curriculum. Longer theory is moved to a reading note issued before the block. If a topic still needs more than 35 minutes of talk, we split it across two evenings rather than stretching the segment.

Build loop

The build loop

Every module repeats the same four steps. The loop is short on purpose. Changing one variable at a time is how a test set stays meaningful.

  1. 1

    Describe the task in writing

    Audience, input, required output, constraints, and what “done” looks like. If the brief cannot be read by a colleague, the prompt will not be stable either. We mark briefs that still live only in someone’s head.

  2. 2

    Draft a prompt or pipeline

    A first version with named variables and attached reference material. For Systems modules this step is a chain with a check between calls, still described on paper before it is wired.

  3. 3

    Score against the rubric

    The same five criteria every time. Scores go on the evaluation sheet with a one-line note on evidence. Disagreement inside a pair is useful; it usually means the brief was ambiguous.

  4. 4

    Change one variable

    Instruction, context, temperature, model, or input sample — one change, then score again. Multiple changes at once make the log impossible to read and the “improvement” impossible to trust.

Attempts are written in a simple log: date, variable changed, score, note. We keep that log as part of the course file. It is the evidence for reproducibility on the rubric, and it is the document a later colleague reads before editing the template. Groups that skip the log tend to regress to chat history, which cannot be handed over.

Rubric

Evaluation rubric

Four bands. Band 1 is an attempt that cannot be used. Band 4 is work another team could adopt. The pass line for a course is Band 3 on all five criteria on the final artefact.

Criterion Band 1 Band 2 Band 3 Band 4
Task framing Goal is spoken, not written, or mixes several jobs. A brief exists; inputs and “done” are still vague. Written brief with audience, input, output and constraints. Brief a colleague can run without asking the author.
Factual control Output is accepted because it reads fluently. Spot checks on a few claims; no method. Claims checked against named sources in a set time. A repeatable check that catches silent omission as well as invention.
Reproducibility Steps live in chat history. A prompt exists; versions are mixed. Versioned template plus a log of attempts. Another person reruns the work and lands in the same band.
Data handling Sensitive text is pasted without a pass. Some redaction; classes of data are unnamed. Sources classified; sensitive fields stripped; note written. A data-readiness note another project can reuse.
Handover quality Files are scattered; no owner named. A folder exists; how to run it is still oral. Pack with instructions, scores and a named owner. Pack an internal team can maintain through the next change of tool.

The pass threshold is Band 3 on all five criteria. A high score on factual control does not offset a missing handover. We score the final artefact in a short review at the end of the course; laboratory work during the weeks is formative and is used to show the same sheet in motion, not to average a grade.

Tooling

Tooling we teach on

We teach classes of tool, and we change the examples when the market moves. The 2026 rooms use hosted chat assistants, model APIs, retrieval over a folder of the organisation’s own documents, spreadsheet and workflow automation, lightweight evaluation harnesses, and logging (a sheet is enough at L2; a store with timestamps at L3).

Workstation

Participants may work in the vendor stack their employer already pays for, provided the artefact we score is the brief, the template, the test set, the log and the handover — the pieces that survive a change of screen. The rubric does not mention a product name.

Scope

Scope limits

Glowwellbeing is a professional training practice. The 2026 programme does not cover training models from scratch, GPU infrastructure, or the operation of a machine-learning platform. We do not issue legal opinions, and we do not certify an organisation against a regulatory regime. Those jobs belong to counsel, to internal audit, and to engineering teams with a different brief.

If a scoping call shows that the real need is model training, cluster design, or a formal compliance audit, we say so and stop. We will still teach the evaluation and handover skills that those other workstreams use, where that is useful, and we will not pretend the course replaces them.