Open model approval desk for your production AI stack

By General Input

See every open model your teams run in production, who approved it, and whether a quiet license change means it needs another look.

Integrations

  • Hugging Face
  • Notion
  • Slack Bot

Type

App

Categories

  • Operations
  • Engineering

Build me an internal app that works as the approval desk for every open model my company runs in production. Right now nobody can answer which open models we are using and whether each one is still allowed without asking around, so this app is the working surface where reviewers actually approve or reject a model, and where the record of that decision lives.

The main view is a registry table with one row per model. The columns I manage myself are: the Hugging Face model id (a repo id like meta-llama/Llama-3.1-8B-Instruct), the team that owns it, what we use it for, the assigned reviewer, and a status of approved, in review, rejected, or needs recheck. There is an Add model form to create a row with those fields, and each of them stays editable inline.

Every row also shows live facts pulled from Hugging Face rather than anything typed by hand. Use the Hugging Face Get Model operation per row to display the current license (from the repo card data or tags), whether the repo is gated, whether it is private, the download count, and the date it was last updated. Show these as their own columns so the table can be scanned quickly, and handle a repo that has been renamed or deleted by marking the row as unreachable instead of failing the whole view.

The rule that makes this app worth opening: when a model is approved, store the last updated date that Hugging Face reported at that exact moment alongside the approval. Every time the registry loads, compare that stored date against the current one from Get Model. If it has moved, the row automatically flips to needs recheck and sorts to the top of the table. The default sort is needs recheck first, then in review, then everything else, so a quiet license change or a re-upload of the weights never slips through unnoticed. Show a short inline note on those rows saying the model changed on a given date after being approved on an earlier one.

Every row has a Vet this model button that starts a background agent for that model. The agent reads the repo metadata with Hugging Face Get Model, then uses List Repository Files to find and open the model card (usually README.md, plus any license or config files in the tree), then reads the recent community threads on that repo with List Discussions, pulling the detail of the most relevant ones with Get Discussion. While it runs, show the row in a working state so the reviewer knows a vet is in progress and can keep using the rest of the table.

The agent writes a short risk brief back into that row, structured in three parts plus a verdict: license terms and what they allow for commercial use, including any use restrictions or acceptable use policy attached to the model; provenance and training data disclosure, meaning how much the model card actually says about where the data came from and how the model was built; and any unresolved security or quality complaints people have raised in the discussions, such as reports of broken weights, suspicious files, or unanswered questions about the license. It ends with a recommended verdict and a one line reason. The brief must cite what it saw, for example the license tag it found or the discussion title it is referring to.

Nothing is decided by the agent alone. The recommended verdict is only a recommendation. A reviewer approves or rejects on the row with their own notes, and only that human action changes the status. On a decision, write the record to our Notion registry database and post the verdict to the Slack channel our platform team watches. Use Notion Create a Page for a model that is not in the registry yet, storing the resulting page id on the row, and Notion Update a Page for one that already has a page, so we get one page per model rather than a pile of duplicates. The Notion record should carry the model id, owning team, use case, reviewer, verdict, decision date, the reviewer notes, and the license and last updated date as they stood at the time. Then use Slack Bot Send a Message to announce the verdict with the model id, who decided, the verdict, and the headline reason.

When the app opens, load the existing registry from Notion with Query a Data Source so models already recorded there show up as rows rather than having to be re-entered, and match them to the live Hugging Face facts by model id. Let me set the Notion data source and the Slack channel in a small settings view.

Keep the full decision history on each row so an auditor can see who approved what, when, and on what evidence. Every approval and rejection is appended as its own entry and never overwrites the previous one. Each entry records the reviewer, the timestamp, the verdict, their notes, and a snapshot of the evidence at that moment: license, gated and private flags, download count, last updated date, and the agent risk brief that was on the row when the decision was made. Clicking a row opens a detail panel showing the live facts, the current risk brief, and that decision history as a timeline, and a model that has been vetted and decided on several times should read as a clear chronological trail.

Related prompts

Explore more prompts
A brand asset library your marketing team actually searchesTurn Mailjet email clicks into ranked HubSpot follow-upsClean out the Looker dashboards and Looks nobody opensLiveKit live operations console for room moderationWake up dormant Keap leads with a researched reasonLiveChat coverage board for planning next week's shiftsPhone routing control panel for LiveKit voice agentsLinkedIn Ads budget pacing dashboard for every client accountGive your team Looker numbers without buying more seatsPause marketing emails to escalated customers, then restore them