Völva

Simulate Before You Act

Problem

Admin tools act on many Macs or on a production server. A wrong merge rule, a missing API privilege or a misread smart group affects the whole fleet. Admins test by deploying to a pilot group and waiting, which is slow and still risky.

Context & forces

• Admins need confidence before deploying, not just logs after.
• A preview is only trustworthy if it uses the same code path as the real run.
• Some effects cannot be checked from the Mac (Jamf's internal behaviour, timing).
• Simulations should be cheap enough to run often.

Solution

Separate deciding from doing. Build the core as a deterministic function from inputs to a plan, and let the real run carry the plan out. A simulation runs the same function and stops before the effects, then shows the plan in a form admins understand: merged files, a timeline, a report.

 inputs ──▶ deterministic core ──▶ plan ──┬──▶ execute   (real run)
                                          └──▶ show/report (simulation)

Variants of the same idea:

• Preview of a configuration on the admin's own Mac, before it goes into MDM.
• Dry run on the device: plan and report, change nothing.
• Read-only simulation against production: read like the real run, write nothing.
• Model simulation: replay a documented model of a system over simulated time.

For developers

• Pure core: state transitions as (state, event, now) → (state, effects) and rendering as bytes from inputs. A fake clock makes timing testable.
• The same validation runs offline (validate) and on the device.
• Mark assumptions. Where behaviour is not documented, the simulation says so (confidence levels, findings) instead of pretending to know.
• Simulations write reports, not state: nothing in the real data store changes.
• AI-proposed changes are simulated only after the user confirms them, and never executed from model output alone.

Consequences

• Admins see the effect of a change before any Mac does.
• Determinism also makes the tool easier to test and to explain.
• The design must keep effects out of the core, which costs some structure up front.
• A simulation is only as good as its model; undocumented behaviour stays an assumption.

Known uses

• Mimir: mimirctl preview merges fragments locally and shows the vendor files a group of Macs would get; DryRun makes the daemon plan and report only.
• Ratatoskr: ratatoskr preview renders dialogs and workflow stages on the admin's Mac without the services running; validate checks configuration; Jamf scripts support DRY_RUN=1. The workflow engine's transitions are pure functions.
• Gimle: Simulate reads Jamf Pro like a backup and compares it with the newest backup, writes nothing to the backup folder and shows whether a backup would succeed and what it would change, with its own reports.
• Janus: a deterministic engine (snapshot, scenario, rules) → timeline simulates the lifecycle of a Jamf-managed Mac, marking each rule as documented or assumed.

Name

The völva was the seeress who told what would come before it came.