The Profile Everything Rides On

"Some choices belong to the job. Some belong to the machine. Put each where it changes, not where it's convenient."

One Profile for the Whole App

Alongside the per-macro vault dial sits a single app-wide execution profile: where inference runs (local, server, cloud), which brain, how much effort it spends, which soul (if any), and the Ollama tier and model. These are settings you pick once and rarely touch — they describe your machine and your preference, not the individual transformation. So they live once, at the app level, rather than being copied into every macro. A macro says what to do and how much context it needs; the profile says how the whole app runs.

Scope Follows Change Rate

The reason vault mode is per-macro and the profile is app-wide is simply how often each changes. Vault use-or-bypass genuinely differs from one transformation to the next, so it belongs to the macro. Brain, effort, and tier are stable choices for your setup that you'd want to apply to everything — duplicating them into every macro would just create dozens of copies to keep in sync. Put a setting at the scope where it actually varies: the volatile decision on the unit of work, the stable one on the app.

PER MACRO (varies per job)     APP-WIDE (stable preference)
--------------------------     ----------------------------
vault use / bypass             Pippa location (local/server/cloud)
prompt template                brain
hotkey                         effort
enabled                        soul
                               Ollama tier / model

Per-Request, Not a Side Effect

There's a subtle invariant hiding in the profile. When Flint picks an Ollama tier and model for a request, that choice travels with the request — it does not reach across the boundary and change the brain's own global model. Flint stating 'run this one on the local tier' must never leave the brain stuck on the local tier for its other callers. The profile configures Flint's requests; it is not a remote control for the brain's global state. Settings on one side of a boundary must not mutate the other side's state as a side effect.

A client's setting must not silently mutate the server's global state. The dangerous shortcut is to implement 'use the local tier' by flipping the brain's global default — quick to build, and a trap: now every other client of that brain is affected by a preference Flint changed for itself. The correct shape is per-request: the tier rides in the call and applies only to that call. If changing your settings changes someone else's behavior, the boundary has a leak.

Simple and Verbose change what you're told, never what happens. Flint's two presentation modes differ only in explanation density — Verbose gives novice-complete explanations, Simple stays quiet — and expose byte-for-byte identical behavior: same capture, same prompt, same insertion, same safety. A mode toggle that quietly altered behavior while claiming to only change verbosity would be a lie the user can't see. Presentation and behavior are different axes; never let one masquerade as the other.

Code

The app-wide profile, and the per-request tier that doesn't leak·swift

struct ExecutionProfile: Codable {
    var location: PippaLocation      // local / server / cloud
    var brain: String                // which model family
    var effort: Effort               // how hard it thinks
    var soul: String?                // persona, or none
    var ollamaTier: OllamaTier?      // local / server / cloud model
    var presentation: Presentation   // .simple or .verbose
}

enum Presentation { case simple, verbose }   // density ONLY, never behavior

// The tier travels WITH the request; it never mutates the brain's global
// sticky model. Flint configures its own call, not the brain's world.
brain.applyFree(prompt: rendered,
                vault: macro.vaultContextMode,
                tier: profile.ollamaTier)     // per-request, no side effect

Exercise

Sort these settings into per-macro vs app-wide and defend each placement: (a) which model to use, (b) whether to bypass the vault, (c) the effort level, (d) the chord, (e) Simple vs Verbose. Then explain the invariant that keeps Flint choosing a local tier for one request from stranding the brain's global model on local for everyone else.

Hint

Per-macro: bypass-vault (b) and chord (d) — they vary per job. App-wide: model (a), effort (c), and presentation (e) — stable preferences. The invariant is per-request scoping: Flint's tier choice is a parameter of the individual call, carried in that request only, so it configures Flint's own inference without writing to the brain's global sticky model — a client setting that never mutates server state.

The Profile Everything Rides On

One Profile for the Whole App

Scope Follows Change Rate

Per-Request, Not a Side Effect

Code

External links

Exercise

Progress

Comments 0