Documentation

How Changy evaluates change plans, and how to configure it.

Overview

Changy ingests a company's change-management policy, a draft change plan, and any supporting documents or codebases; evaluates the plan for gaps against a rubric derived from that policy (or a generic ITIL v4 checklist if no policy is supplied); helps fill those gaps through a follow-up interview; and generates audience-specific communications for end users, management, stakeholders, and colleagues.

Requirements

• macOS 26 (Tahoe) or later
• Apple Silicon, if using the bundled on-device model (no restriction if using an OpenAI-compatible API backend instead)
• ~4.3GB free space for the bundled Qwen2.5-7B-Instruct (4-bit) model, already inside the signed app — no first-run download

Installation

Download Changy (a 3.6 GB .zip — most of that is the bundled on-device model), then:

1. Unzip it
2. Drag Changy.app to /Applications
3. Open it

Try It With the Examples

Two example documents, built to exercise the full evaluate → interview → enrich pipeline end to end, are available to download below — they aren't bundled inside the app download itself, so grab them separately:

Add the policy file as the Company Policy document and the draft plan as the Draft Change Plan:

Documents — both example files added.

Run an evaluation. Against this pair, a real run scores it 2 of 7 criteria satisfied (Risk Assessment, Testing), 1 partially satisfied (CAB Approval — the plan states the risk level but never mentions sign-off), and 4 missing (Backout Plan, Change Window, Communication, Post-Implementation Review) — each finding cites the specific part of the plan it's based on:

Evaluation — cited, specific findings against the policy-derived rubric.

The Interview screen turns each gap into a concrete follow-up question. Answer them, apply the answers, and the plan is revised in place:

Interview — answers applied, plan updated.

The same document afterward — all four gaps closed, merged directly into the plan.

From there, Communications generates an audience-appropriate write-up in one click — see the feature grid above for an example.

How Configuration Works

Every setting has three possible sources, checked in this order:

1. MDM-forced — pushed via a Configuration Profile's Managed Preferences payload. The app detects a value was actually forced by an administrator (not just present) via CFPreferencesAppValueIsForced, and locks the corresponding control in Settings with the usual "set by your organization" treatment.
2. User Settings — whatever the user set in-app, stored in standard UserDefaults.
3. Built-in default — used if neither of the above set a value (e.g. the local MLX backend, or every integration off).

Any MDM — Jamf, Kandji, Intune, or a manually installed profile — can push this configuration. It's an "Application" / custom-preferences payload of type com.apple.ManagedClient.preferences, targeting the app's bundle identifier, com.spectrechen.changy, as the domain.

Configuration Reference

Every key Changy reads, exactly as it appears in the shipped configuration schema:

* Booleans are pushed as the literal string "true" or "false" in the profile, not a plist <true/>/<false/> — Managed Preferences values are read as strings.

Security Note

Local Model (MLX)

The default backend. A bundled, 4-bit-quantized Qwen2.5-7B-Instruct model runs entirely on-device via Apple's MLX framework — no first-run download, fully offline. This is what forcedBackend: mlx selects, and it's the default if the key isn't set at all.

Settings — the same backend and web search options a Configuration Profile can also force.

OpenAI-Compatible API

Point Changy at any OpenAI-compatible endpoint instead — useful for centralizing on an org-wide model deployment rather than the bundled local one.

<key>forcedBackend</key>
<string>openAICompatible</string>

<key>openAICompatibleBaseURL</key>
<string>https://api.openai.com/v1</string>

<key>openAICompatibleAPIKey</key>
<string>sk-...</string>

<key>openAICompatibleModelName</key>
<string>gpt-4o-mini</string>

Jira & Confluence

Off by default, independently toggled. Both share the same two-field auth shape: leave *Email blank for a Data Center instance (the token is used as a Bearer PAT), or fill it in for Cloud (Basic auth with the token as an API token).

<key>jiraEnabled</key>
<string>true</string>
<key>jiraBaseURL</key>
<string>https://yourcompany.atlassian.net</string>
<key>jiraEmail</key>
<string>you@yourcompany.com</string>
<key>jiraAPIToken</key>
<string>...</string>

<key>confluenceEnabled</key>
<string>true</string>
<key>confluenceBaseURL</key>
<string>https://yourcompany.atlassian.net/wiki</string>
<key>confluenceEmail</key>
<string>you@yourcompany.com</string>
<key>confluenceAPIToken</key>
<string>...</string>

Settings — Web Search, Jira, and Confluence, each independently toggled.

Jamf Pro

Authenticates the same way Jarl does — a Jamf Pro API Role and API Client (client ID + secret), configured under Settings → System → API Roles and Clients in Jamf Pro.

<key>jamfEnabled</key>
<string>true</string>
<key>jamfBaseURL</key>
<string>https://yourcompany.jamfcloud.com</string>
<key>jamfClientID</key>
<string>...</string>
<key>jamfClientSecret</key>
<string>...</string>

Microsoft Intune

Uses an Azure AD app registration (tenant ID + client ID + client secret).

<key>intuneEnabled</key>
<string>true</string>
<key>intuneTenantID</key>
<string>...</string>
<key>intuneClientID</key>
<string>...</string>
<key>intuneClientSecret</key>
<string>...</string>

Settings — Jamf Pro and Intune, same pattern: enable, then fill in the connection details.

Web Search

An optional tool (Brave Search API) the model can invoke during evaluation to check a draft plan's claims against current, real-world information. Off by default — enabling it sends the plan's rubric criteria and derived search queries to a third-party search API, which an organization may not want without opting in.

<key>webSearchEnabled</key>
<string>true</string>
<key>braveSearchAPIKey</key>
<string>...</string>