Training Programme

Juno Cassandra runs in your browser. There is nothing to install, no licence file to place on a machine, and no IT permissions to arrange before you can start learning — you are given a login, you sign in, and you work. Our training programme is built around that.

The programme has three modules. They are deliberately sequential: each one assumes you finished the one before it.

Module What it makes you able to do
1 Using Juno Cassandra Run, tune, interpret and report on a model using a domain model that already exists
2 Mentoring — your first real project Build the input set for your network and carry a modelling project through to a report
3 Building and maintaining a Domain Model Write, debug and publish the engineering model itself, with an AI assistant alongside you

Modules 1 and 2 are for every modelling analyst. Module 3 is for the one or two people in an organisation who want to own the engineering logic.

Note

Where the other documentation lives. This site covers concepts and framework reference. Step-by-step help for each setup file is built into the application itself and is available from the Help link in the navigation bar while you work. Documentation for the Default Road Network model — the domain model most road-network clients start with — is on its own site.


Module 1 — Using Juno Cassandra

Overview

The first module is about the software: the project folder, the setup files, running a model, and making sense of what comes out.

You work with a domain model that already exists — normally the Default Road Network model — and with a complete set of training input data, so that you can work through every step of a real model run interactively from the first session.

This module does not open up the domain model. We explain what the domain model is responsible for and how it plugs into the framework, because you cannot tune a model you cannot picture. We do not walk through its code. That is Module 3.

Pre-requisites

A web browser and a login. That is the whole list.

There is no software to install, no .NET runtime, no machine-specific licence, and nothing for your IT department to approve. If you can reach the internet and read your email, you can take this module.

Your login is created under your organisation’s licence — see Licensing. Training runs on your own account, in a project set up for the purpose, so everything you learn is done in the environment you will actually work in.

Topics Covered

Getting oriented

  • Signing in, two-factor authentication, and accepting the licence agreement
  • Choosing your client project and domain model
  • Finding your way around: Files, Analyse Input, Tuning, Run, Postprocessing, Journal
  • Using the in-application Help, and searching it
  • What the framework does and what the domain model does — the division of labour

Your project and its files

  • Project folder structure — inputs/, supporting/, outputs, and what you may upload where
  • The input file: what a network element is, and what the model needs to know about it
  • Fixed file names, and why capitalisation matters
  • Model configurations — configurations.xlsx, and how base_config and config_ sheets combine
  • Lookup tables — the constants your domain model reads
  • Budget definitions — categories, periods, and why every category needs a figure in every period
  • Committed treatments — forcing work you have already committed to into the model
  • KPI set definitions — naming the indicators you will report on
  • Uploading, downloading, replacing and versioning files

Checking before you run

  • Analyse Input — statistics, histograms and row filters over any input CSV, before you trust it
  • Check Setup — the pre-flight validator, and how to read what it tells you
  • The most common setup mistakes, and what each one looks like when it fails

Running

  • Your first model run
  • Watching a run, and reading the run log
  • The log of earlier runs, and comparing one run against another
  • Diagnostics files and when to look at them

Understanding the outputs

  • Output files — condition, treatments, spending
  • Postprocessing: KPI forecasts, treatment quantities, spending by year, budget utilisation
  • Parameter statistics and parameter breakdowns
  • Rankings — which elements the model treated, and why
  • Drilling into a single element’s history across the modelling period
  • Tracing an element back to its input row

Steering the model

  • Tuning: budgets, treatment unit rates, MCDA weights and settings
  • Budget category overrides — reassigning treatments without touching the domain model
  • Modifying budgets and re-running
  • Modifying thresholds and re-running
  • Budget scenario analysis: building and comparing scenarios
  • Defining an objective function for a Goal-Seek model, and running one
  • Using the Journal to record what you changed and why

Wrapping up

  • R-Scripts and the kit catalogue — reproducible charts and tables for your report
  • Reading a model critically: what a plausible result looks like, and what a suspicious one looks like
  • Where to go next

Skills Gained

After finishing this module, you should be able to:

  • Explain what the framework does, what the domain model does, and where the boundary sits
  • Set up a project’s input, setup and committed-treatment files correctly
  • Define budgets and a KPI set for your reporting needs
  • Validate a setup before running it, and diagnose a failed run without help
  • Run a model and a Goal-Seek model
  • Interpret model outputs and produce the standard charts from them
  • Adjust budgets, unit rates and optimisation settings, and explain the effect of each
  • Build and compare budget scenarios
  • Debug an anomaly down to a single element and explain what the model did to it

What is Not Covered

The domain model’s internals. You will finish this module able to use and tune the Default Road Network model. You will not be able to change how it deteriorates an element or add a treatment type it does not have — that is Module 3.

Preparing an input set for your own network. The training data is provided ready-made. Building the input set for a real network is its own body of work and it is the substance of Module 2.

The BCA optimisation method. As described elsewhere in this documentation, Juno Cassandra offers both Multi-Criteria Decision Analysis (MCDA) and Benefit-Cost Analysis (BCA). This module covers MCDA only, which is the more flexible and more widely used of the two. BCA is covered in a future module, not yet available.


Module 2 — Mentoring: your first real project

Overview

Module 1 teaches you the software using data we prepared. Module 2 is where you point it at your own network, and it is structured as mentoring rather than a workshop: we work alongside you, on your project, on an hourly basis, while you carry your first modelling analysis through to a report.

We run it this way for a reason. Our experience is that the first one or two real projects always throw up situations that no course covers — a data column your network does not have, a result that looks wrong and turns out to be right, a result that looks right and turns out to be wrong. Those are worth an hour of a modeller’s time each, and they are not worth a lecture.

Pre-requisites

  • Completion of Module 1
  • A network to model, and access to your organisation’s condition and inventory data
  • A Juno Cassandra project set up for that network

The core of it — building your input set

The single largest task in a real modelling project is producing the model input file: one row per network element, with every column the domain model needs, assembled from whatever your organisation actually holds. This is where most of the mentoring time goes.

Topics we work through on your data:

  • Deciding what a network element is for your model, and how to segment the network
  • Which input columns the domain model requires, and what each one means
  • Joining condition, inventory, traffic and treatment-history data onto each element
  • Handling missing data, outliers, and elements you should exclude
  • Sanity-checking the input set with Analyse Input before the first run
  • Setting realistic budgets and calibrating unit rates for your region
  • Establishing a base run you trust, before you start scenario work
  • Building the scenario set that answers the question you were actually asked
  • Compiling the modelling report

Support Provided

Support is delivered through scheduled online meetings, screen-sharing on your project. Typical reasons people book time:

  • You need help preparing or checking your model input file
  • You get an error you do not understand, and want the cause found
  • Your model does not give the outputs you expected
  • You do not understand why treatments are or are not triggering on certain elements
  • You want a one-hour refresher on something from Module 1
  • You need help structuring or reviewing your modelling report

Cost of Support

Our hourly rate for mentoring support is NZ$ 180/hour, with a minimum of 30 minutes per interaction. For a first modelling project you should budget for 3 to 10 hours.

Limitations of Support

We will do our best to respond quickly, but we cannot be available around the clock. We aim to respond within 24 hours, and where possible to set up an online meeting within an hour or two of hearing from you. We cannot guarantee it.

Plan your first project accordingly: tell us when you intend to start so we can make sure we are around, and leave enough slack in your own programme that a 24-hour wait for support does not cost you a deadline.

Note

If your network data is held in a structured asset management system, input preparation gets substantially easier. If it is in Juno AMS, the Data Join feature will extract and collate the data for each element you want in the model.

Even with good tooling, though, preparing the input set is usually the most time-consuming part of a modelling exercise. When we model on behalf of clients we use an extensive suite of data-join tools and custom R scripts to do it. It is a specialist skill, and it is worth adding to your repertoire on the way to becoming an expert modeller.


Module 3 — Building and maintaining a Domain Model

Overview

In Modules 1 and 2 you use a domain model somebody else wrote. Sooner or later you will want to change it: add a treatment type that is specific to your organisation, change how a distress develops, or model something that is not a road network at all — a water pipeline, a bridge stock, a building portfolio.

The domain model is a C# project, and Juno Cassandra lets a client’s own modeller own it outright: write it, debug it in the browser with real breakpoints, publish it, and run it as their live model.

This module teaches you how to work on a domain model, not the internals of one particular model. We used to run a module that walked line by line through the Default Road Network model; we no longer do, and the reason is that it taught the wrong thing. Once you can drive the Domain Model Assistant, you can open any domain model — the Default Road Network model included — ask it what the model does, and have it explain, change and check the part you care about. Where you then need a second opinion on your own model, that is what mentoring support is for, at the rate given in Module 2.

The Domain Model Assistant

You do not do this alone, and you do not do it as a software developer.

The Domain Model Assistant is a free, public VS Code project that you download and open alongside an AI coding assistant. It carries everything the AI needs and does not otherwise know: the framework API reference, the conventions that fail silently if you get them wrong, a working reference model, a library of ten canonical patterns with compiling examples, and the jcass-dm tool that scaffolds and checks your model bundle.

You describe what you want in ordinary English. The assistant does the plumbing.

Two things about that division are worth stating plainly, because they shape the whole module:

  • The assistant does not supply engineering judgement. Ask it what deterioration rate to use for chipseal and it will decline, and help you put your number where it belongs instead. The engineering stays yours.
  • Tunable numbers go in lookups.xlsx, not in code. A threshold in a lookup table can be changed on the Tuning page and re-run in minutes, by anyone. The same threshold hard-coded makes your model one that only a programmer can recalibrate.

Pre-Requisites

  • Completion of Modules 1 and 2
  • At least one completed modelling project of your own under our mentorship
  • A Windows PC you can install software on
  • Visual Studio Code and the .NET 9 SDK — both free downloads
  • A paid subscription to an AI coding assistant that runs inside VS Code. Claude is the recommended and supported choice. A browser chat window is not sufficient — the assistant has to be able to run commands and read what they printed. The subscription is yours; Lonrix neither pays for nor procures it.
  • Access in Juno Cassandra to the Debug Model page and permission to publish, arranged by an administrator

The full prerequisite list, with the reasoning behind each item, is in the Assistant’s own documentation.

Note

You no longer need to learn C# first. The previous version of this programme required trainees to complete a C# course before starting. That requirement is gone. What is still required is an appetite for precise, analytical work — you will be reading code that an assistant wrote for you, judging whether it says what you meant, and testing it. You will learn a useful amount of C# along the way, and the Assistant includes a short “C# you need” orientation that covers what matters.

Topics Covered

Orientation

  • What a domain model is responsible for, and what the framework does around it
  • How a run actually works, step by step, and where your code is called
  • Setting up the workspace: VS Code, the Assistant, and your model beside it
  • Working with an AI assistant: what to ask for, what to check, and when to stop
  • Running commands, and reading errors

Building a model

  • Planning your model: which treatments, which input columns, which parameters
  • Scaffolding a new model, building it, and checking it with jcass-dm
  • The four-name rule and the other conventions that fail silently
  • Initialisation — setting up an element at the start of the run
  • Increment — how condition develops over one period
  • Candidate selection and treatment triggering
  • Reset — how condition recovers after a treatment
  • Routine maintenance
  • Reading constants from lookups, and larger data sets from supporting/ CSVs

Patterns

  • Treatment suitability scoring, and treatment instances
  • Candidate strategies
  • Piecewise-linear and logistic models
  • Distribution simulators for Monte Carlo work
  • Multi-budget cost splitting
  • Choosing the right pattern for the engineering you are describing

Debugging and publishing

  • Uploading your model and debugging it in the browser, with real breakpoints, against real data
  • Stepping through a run and inspecting an element mid-period
  • Making a change and proving it did what you intended
  • Publishing your model to your live project — done deliberately, by you, in the browser
  • Running your published model
  • Getting your code back, and keeping a history of it

Adopting and maintaining

  • Taking on an existing domain model and finding out what state it is in
  • Adding an input column and its parameter — every place the change lands
  • Adding a treatment type
  • Recalibrating without republishing, by refitting the data a model reads
  • Keeping the Assistant up to date, and what changes when the framework version moves

Skills Gained

After finishing this module, you should be able to:

  • Explain in detail how a domain model works and how the framework calls it at run time
  • Plan a domain model from an engineering brief
  • Build a new domain model with an AI assistant, from scaffold to published
  • Take on, understand and modify an existing domain model
  • Debug your model in the browser against your own data, at a breakpoint
  • Publish, run and maintain your organisation’s own model
  • Decide correctly what belongs in code, what belongs in lookups.xlsx, and what belongs in a supporting data file

What is Not Covered

A line-by-line walkthrough of any particular domain model. As above, this is deliberate. You learn the method and the tooling, and you apply them to whichever model is in front of you.

We do not write your model for you as part of the module. Ongoing help with your own model is available as mentoring support at the rate given in Module 2, and bespoke model development is available as a separate commercial engagement.

This module is not a C# course. You will pick up what you need, and the Assistant covers the language features that come up. If you want the language properly, take a general C# course alongside it.

The BCA optimisation method is covered in a future module, as with Modules 1 and 2.