pdombkins gives administrators real control over AI model choice

The fork tightens model access for student groups, making budget and governance rules more dependable.

securityworkflow

Administrators can now limit a group to approved AI models, a practical control for keeping cohorts on the tools their organisation has chosen to support. The important follow-up is that the restriction was repaired where it did not consistently cover every non-admin route.

That is less glamorous than adding a new AI feature, but more useful: a model policy only works if it holds wherever a user can ask for AI help. The fork also replaces experimental Gemini model choices with more stable options, reducing the chance that a live workflow breaks when a preview service changes.

For legal teams, educators and product operators offering shared AI access, this is a sensible governance upgrade worth inspecting on GitHub.

So what Anyone giving groups access to legal AI should care because inconsistent model controls can undermine both spending limits and policy guardrails.

View this fork on GitHub →

Spotted something wrong? Or know the PR text has fresher detail than the writeup above?

Commits in this thread

4 commits from pdombkins/rose_lawyer, oldest first. Source extracted verbatim from the harvested git log.

SHA	Subject	Author	Date
`5110f1ba`	Lock down /admin: shared client-side admin guard over all admin pages	Peter Dombkins	2026-07-24	↗ GitHub
`69e545a1`	Admin: site-wide LLM model restriction for student groups	Peter Dombkins	2026-07-25	↗ GitHub
`a8e22812`	fix(models): admin allow-list now binds every non-admin, on every feature	Peter Dombkins	2026-08-02	↗ GitHub
commit body Two holes in the Admin -> allowed models setting. isRestrictedStudent was keyed on user_group membership, so anyone added outside a group was unrestricted -- including every account between creation and being put in a group. It is now simply 'not an admin'. The workflow machinery bypassed the list entirely: blueprintModel() and /compile called bare resolveModel(null, DEFAULT_MAIN_MODEL), and workflow runs were created with model: null so the executor fell back to DEFAULT_MAIN_MODEL unchecked -- every step and every partner review. All three now resolve through resolveModelForUser, and the executor clamps again at run time so a recovered run cannot keep calling a model since removed from the list. This was benign only by coincidence: DEFAULT_MAIN_MODEL is gemini-3-flash-preview, which is currently allowed. Removing it would have left every workflow run calling it anyway. Verified: the only bare resolveModel() calls left are in routes/user.ts for displaying and validating stored preferences, neither of which reaches a model. 3 admins exempt, 36 non-admins restricted, 0 stored prefs out of policy.
`52823910`	Move every model default off Gemini preview ids	Peter Dombkins	2026-08-02	↗ GitHub
commit body A class of 36 cannot run on preview builds. Google caps them at ~250 requests per DAY even on the paid Tier 1, and one workflow run is 10+ calls once you count the blueprint, pre-flight, each step and each partner review - so the cohort would exhaust a day's quota in minutes regardless of billing. All three defaults (main, title, tabular) were preview ids. Note for later: an AI Pro/Ultra subscription does not raise this. Ultra lifts limits in the AI Studio playground and Build mode; an API key called from a backend is governed by whether billing is enabled on its Cloud project. The reasoning is written above the Gemini block in models.ts because this is exactly the kind of change that gets reverted by someone picking the cheapest per-token id.

Capture this thread into my fork

Download a single Markdown prompt that tells Claude how to port every commit above into your working tree — adapting paths and structure to match your repo. Run it via claude -p < capture-thread-940.md from inside the repo you want the changes in.

⬇ Download capture-thread-940.md