# Open model approval desk for your production AI stack

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

- Workflow type: app
- Services: Hugging Face, Notion, Slack Bot
- Categories: Operations, Engineering
- Published: 2026-08-24

## What it does

- One row for every open model your company runs, showing the team that owns it, what it is used for, the assigned reviewer, and whether it is approved, in review, rejected, or due for another look.
- Live details pulled straight from Hugging Face on every row: the current license, whether the repo is gated or private, how many downloads it has, and the date it last changed.
- A Vet this model button that sends a research agent to read the model card, the repo file list, and the recent community threads, then write a short risk brief covering license terms, training data disclosure, and open security or quality complaints, ending with a recommended verdict.
- Approvals and rejections stay with a person. The reviewer adds their own notes, the decision is written into your Notion registry and announced in your platform team's Slack channel, and the full history stays on the row for auditors.

## What you'll need

- A Hugging Face account and access token. Public models work with any token, and a token also lets the app see private or gated repos your company already has access to.
- A Notion workspace with a registry database, shared with the connection so the app can read and write it.
- A Slack workspace where the app can post to the channel your platform team watches.
- The list of open models you already run in production, along with the team that owns each one and the reviewer responsible for it.

## Prompt

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.

## How to customize

- Change the status options to match your process, for example adding approved with conditions or sunset planned alongside the four defaults.
- Choose which Slack channel hears about decisions, and whether rejections get a louder announcement than approvals.
- Tune what the risk brief weighs most heavily, such as commercial use restrictions, training data disclosure, or unresolved security reports.
- Decide which fields are required before a model can be marked approved, so nothing gets signed off without an owner and a stated use.

## FAQ

### Does the agent decide whether a model is allowed?

No. The agent only gathers evidence and writes a recommended verdict into the row. A person still has to press approve or reject and add their own notes, and only that human decision changes the model's status or gets recorded in Notion and Slack.

### What does needs recheck mean?

It means the model has changed on Hugging Face since the day you approved it. The app remembers the last updated date at the moment of approval and compares it against the current one every time you open the registry. If the date has moved, the row flips to needs recheck and sorts to the top, so a quiet license change or a re-upload never slips past you.

### Will this work with private or gated models?

Yes. Public repos are readable with any access token, and if you connect a token that has access to your company's private or gated repos, those rows show their details too. The registry also flags on each row whether a repo is gated or private, which is often the detail teams miss.

### Do we need a Notion database set up first?

Yes, you need a database in Notion to act as the registry of record, and it has to be shared with the connection or the app will not be able to read or write it. The app loads whatever is already in there when it opens, so an existing registry carries over rather than starting from scratch.

### Can an auditor see who approved what and when?

That is the point of the decision history on each row. Every approval and rejection is kept as its own entry with the reviewer's name, the date, their notes, and a snapshot of the license, gating and last updated date as they were at that moment, so you can show what evidence a decision was made on rather than just its outcome.

Use this prompt in General Input: https://www.generalinput.com/prompts/open-model-approval-desk-for-your-production-ai-stack