What this app touches.

#01What RIVET changes on your system

#Registry — tweaks

All 14 tweaks write to HKEY_CURRENT_USER. There are no HKLM tweaks.

Every one of these is a documented Windows setting. RIVET does not write to undocumented keys, does not "clean" the registry, and does not delete registry keys.

Tweak writes are performed by handing arguments to %SystemRoot%\System32\reg.exe. This is deliberate: under MSIX packaging, in-process registry writes can be redirected into the package's private hive rather than the real one, so the write is shelled out to escape the container.

After a write to a shell-cached key, RIVET broadcasts WM_SETTINGCHANGE and SHChangeNotify so Explorer picks the change up without a sign-out.

#Registry — startup entries

Enabling or disabling a startup item writes a 12-byte binary value to:

• HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\StartupApproved\Run
• HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\StartupApproved\Run
• The StartupFolder equivalents of both

This is the same mechanism Task Manager's Startup tab uses. The Run and RunOnce keys themselves are read but never modified — RIVET does not delete anyone's startup entries, it flags them approved or not.

HKLM writes require elevation. RIVET runs unelevated (see section 5), so all-users startup entries will fail with an explanatory message rather than silently.

#Registry — licensing

HKCU\Software\KirbySystems\RIVET, value TrialStart, an ISO-8601 date written on first launch. That is the entire licensing footprint.

#Services

• Stop / restart: standard service control, 20 second wait. Refused if the service reports it can't be stopped.
• Start type: ChangeServiceConfig, plus ChangeServiceConfig2 for the delayed-auto flag. Accepts Automatic, Automatic (Delayed), Manual, Disabled. Boot and System start types are rejected outright.
• RIVET never creates or deletes a service.

All of these need elevation and will report that they need it rather than failing silently.

#Scheduled tasks

• RIVET creates its own tasks in a root folder named \RIVET, used to implement startup delay. Each carries a RIVET-Delay|… source tag, and RIVET only ever deletes tasks matching that tag.
• For third-party logon tasks, RIVET toggles the Enabled flag. It does not modify their triggers, actions, or principals.
• Task enumeration skips the \Microsoft folder entirely — RIVET will not show you, or let you disable, Windows' own scheduled tasks.

#Files deleted

Cleanup operates on a fixed allow-list. There is no user-supplied path anywhere in it.

Scanning skips reparse points, so symlinks and junctions won't be followed out of the intended tree. Deletion is per-file; anything locked or access-denied is skipped rather than force-deleted.

You see a full preview with byte counts before anything is deleted.

#Processes and power

• Process kill (single or by group), from the process list.
• Lock, sleep, restart, shut down, from the console.

#Everything RIVET writes about itself

%LOCALAPPDATA%\KirbySystems\RIVET\ — settings, action log, session data, snapshots, startup impact measurements, trial marker, crash log, and downloaded AI model weights. Uninstalling and deleting that folder removes every trace except the two registry values above.

#02Rollback and recovery

Read this section carefully, because the answer is more limited than you might expect.

#What can be reverted

#The important limitation

For a registry tweak, the history file carries a typed recovery record: the tweak's catalogue id, whether the value existed before, its prior value and type, and the value RIVET applied. The registry key and value name are not taken from the file — they are re-derived from RIVET's own tweak catalogue by id at undo time, so a corrupt or edited record can never aim a write at an arbitrary key. A record that fails validation leaves its entry as read-only history.

Before undoing, RIVET re-reads the live value. If it is not the value RIVET set — changed by something else, or removed — the undo is refused and the row explains why. RIVET never silently overwrites a change it did not make.

For every other reversible action the captured state lives only in memory on the action object; entries reloaded on the next launch are audit history, not an undo stack. HISTORY shows UNDO AFTER RESTART, THIS SESSION ONLY or IRREVERSIBLE on each row, and warns if the history file could not be written. Test it: apply a tweak, close the app, reopen it, and REVERT is still offered on that row — but not on a service stop.

The log holds 200 entries, oldest trimmed. Files written by earlier versions load unchanged as history.

#System Restore

RIVET calls SRSetRestorePointW in exactly one situation: a cleanup that includes the Windows Update download cache. No other operation creates a restore point — not registry tweaks, not service changes, not startup changes, not ordinary temp or cache cleanup.

Creating a restore point requires elevation, and RIVET runs unelevated. In normal use this call will fail, and the failure is reported in the operation's outcome message. The cleanup proceeds regardless.

If you want a restore point before making changes, create one yourself first.

#Change preview

Every action is previewed before execution. The preview is constructed from the typed action itself, not from AI output, and shows the specific old-to-new changes and byte counts. Confirmation is a separate explicit step.

#03The local AI assistant

#Model

Qwen3 1.7B, Q4_K_M quantised GGUF (~1.28 GB) by default, with Qwen3 4B (~2.5 GB) as an option. Both are a fixed, hardcoded list — the app cannot be pointed at an arbitrary model or URL by the user or by anything the model outputs.

#Where it runs

RIVET refuses to load the model at all if free RAM is below the model's resident size.

If Ollama or Foundry Local is already running locally, RIVET will use that instead, in that priority order, before falling back to its own bundled runtime.

#Where the weights live

%LOCALAPPDATA%\KirbySystems\RIVET\models\. They are not bundled in the package — they're downloaded on first use (see section 4) and verified by SHA-256 against the hash in the catalogue before being moved into place.

#What the model is given

Facts are computed deterministically and injected into the prompt. The model does not query anything itself. Depending on the question, it may receive:

• CPU / RAM / disk / GPU / network utilisation, temperatures, uptime
• The top five processes by CPU and by memory, with names and a safety rating
• Drive free and total space, adapter names, SSID, signal strength
• CPU and GPU model, OS caption and build, system manufacturer and model
• The last eight conversation turns

Intent classification runs on the question text alone, with no system data attached. Action explanations receive only the action's own description and change list, with no system state.

#What it can do

There is no tool-calling, no function schema, and no path or command is ever parsed out of model output and executed. Proposed fixes are constructed deterministically before the model is consulted, and only two kinds exist: a cleanup when reclaimable space exceeds 500 MB, and a 60-second startup delay for a high-impact entry. Both go through the same preview-and-confirm dialog as manual actions, and the confirm button's availability never depends on anything the model said.

Two output guards run over model text: one rejects prose naming a file path, registry key, or executable that wasn't in the supplied facts; the other rejects malware or safety verdicts. Off-topic questions are refused without consulting the model at all.

#04Network

There is no telemetry, no analytics, no crash reporting, no update check, and no account system anywhere in RIVET.

There are four network paths in the codebase:

1. Model weight download — the only outbound internet connection. An HTTPS GET to Hugging Face for the GGUF file, with a Range header when resuming a partial download. No query string, no identifying headers, no request body. Nothing is uploaded. The URL comes from the hardcoded catalogue and cannot be influenced by the user or by model output. The response is SHA-256 verified before use.
2. Ollama, if you're running it — 127.0.0.1:11434.
3. Foundry Local, if you're running it — 127.0.0.1:5273.
4. Loopback enforcement. OLLAMA_HOST and FOUNDRY_LOCAL_ENDPOINT are honoured for the port only. A non-loopback host is rejected and replaced with 127.0.0.1, with a visible reason. 0.0.0.0 and :: are rewritten to loopback. Both clients have proxy support explicitly disabled so a system proxy can't intercept the traffic.

Store licensing uses the WinRT StoreContext API. Any network traffic that generates belongs to Windows, not to RIVET.

The AI feedback option writes a text file to disk. It does not send anything.

#05Elevation

RIVET never asks for admin rights and contains no self-elevation code. No requestedExecutionLevel manifest, no runas, no UAC prompt. The MSIX package declares only runFullTrust.

The consequence is that some operations fail, by design, with an explanation telling you to relaunch as administrator yourself:

• HKLM startup entries (all-users startup items)
• All service operations
• System Restore point creation
• Restart and shutdown
• Killing processes owned by other users or SYSTEM
• Cleaning %WINDIR%\SoftwareDistribution\Download and %WINDIR%\Minidump

This is a deliberate trade — no silent privilege escalation, at the cost of some features needing a manual relaunch.

#06What RIVET deliberately does not do

• No registry cleaning. No orphaned-key scanning, no "issues found" counts, no deletion of registry keys.
• No driver updating.
• No unmeasurable speed claims. Startup impact figures come from measured timings, not a made-up score.
• No PowerShell. No bcdedit, netsh, or powercfg either. The only child process RIVET ever launches is reg.exe.
• No hosts file edits, firewall rules, or power plan changes.
• No service creation or deletion.
• No touching Windows' own scheduled tasks. The \Microsoft task folder is excluded from enumeration.
• No telemetry, no account, no cloud.

#07Known limitations

Stated plainly, because you'll find them anyway:

1. Undo survives a restart only for registry tweaks. Section 2. Service, startup and bulk restore-defaults changes are undoable only in the session that made them.
2. The restore point usually fails. It only applies to one cleanup category, and it needs elevation the app doesn't have.
3. Cleanup is irreversible. Deleted files are deleted. There's no quarantine.
4. Elevation-dependent features require a manual relaunch. RIVET will tell you, but it won't do it for you.
5. The AI runs on CPU only. On a slow machine, responses take a while. There's no GPU offload.
6. The assistant is a 1.7B model. It's grounded in real measurements and guarded against inventing paths, but it is a small model and it is not a diagnostic oracle.
7. First AI use needs a ~1.3 GB download. Nothing is uploaded, but the app isn't fully offline until that's done.

#·Contact

Will — hello.rivet@outlook.com

If something in this document is wrong, I'd genuinely rather hear it than not.