IoL Workflows
Institute of Learning · how a process is written, run and checked

Three artefacts, one process

Every IoL process now has three sources that people write and a set of outputs nobody edits. The document says what must be true. The model says what happens next. The registry says what each word means. Everything else is generated from those three, and the build refuses to publish when they disagree.

WRITTEN BY PEOPLE · CONTROLLED DOCUMENTS (AW-03) · CHANGED TOGETHER IN ONE PULL REQUEST GENERATED BY THE BUILD ON EVERY PUSH · NOBODY EDITS THESE WHAT COMES BACK same steps, same numbers: the build refuses a mismatch Process document AW-10 · the document of record Purpose, scope and boundary Who is accountable: one A per decision Controls, written so they can be tested Records, service standards, measures Version, effective date, change log The owner signs it. The assessor reads it. Short enough to read in ten minutes. Registry Architecture/registry/ · five CSV files role: who, as a position, never a person sys: where a record lives de: one field, one definition, one type records, with their step and system tables, the bridge to Dataverse The Quality Lead keeps it. Both neighbours cite it by id, never by retyping the name. Process model AW-10.process.yaml · the workflow Steps, one performer each Decisions, branches, returns, timeouts Durations, waits, supplier lead times Resources, headcounts, calendars Scenarios: the same process, one thing changed Never signed on its own. Its version is the document's version. cites ids cites ids Site pagenzary.github.io Word renderingfor reading offline Form and tableiol_purchaserequest Event logevery step, timestamped DiagramBPMN 2.0 Executableruns in an engine Simulationwhat if renders builds the fields generates Audit sample (AW-24) Real cases from the log, checked against the controls Ten real cases with timestamps Measured durations replace the model's targets the log is the sample measurements replace targets findings revise the document
The three artefacts on top are written by people and travel together under document control. Everything in the middle row is generated from them. The bottom row is the loop that makes a process real: the event log supplies the audit sample and the measured durations, and both feed back into what people wrote. A process counts as implemented when its owner has signed the document, its form exists, ten real cases have gone through with timestamps, an audit sample has been taken, and the document has been revised once from what the cases showed.

Which question, which artefact

"Where is the purchasing process?"The process document: what must be true, who is accountable, what evidence is kept.AW-10 · the document of record
"What happens after step 6?"The process model: the step, its performer, its branches and where each one leads.AW-10.process.yaml
"What does the form need?"The registry: every field with one definition, one type, one place of capture and its Dataverse column.Architecture/registry/

Who touches what

The process owner signs the document and answers for the controls in it.
The Quality Lead keeps the registry and the templates; a name is added there before it is used anywhere.
Whoever edits a document edits its model in the same pull request; the build checks they still agree.
Nobody edits the site, the diagrams, the executable model or the simulation results; they are regenerated on every push.

Where the pack stands

Fifty-one process documents exist. Two carry a model (AW-10 purchasing and WF-21 CE/CME), and one, AW-10, is registered end to end in the dictionary: twelve steps, thirteen records, sixty-four fields. A document without a model is a process that cannot yet be run; a document whose names are not in the registry cannot yet have a form. The order of work is the order of this picture, one process at a time, and purchasing goes first because its transactions are happening this month.